Denis,
I understand that when adding the signature polcy as a signed attribute, the
signer explicitely indicates that he agrees and applied the policy contents.
I also understand that when adding a commitemnt text as a signed attribute, the
signer indicates that he is endorsing a particular act or will.
To be honest i didn't understand what it does express to add an attribute
certificate as signed attribute within a CMS signed data?
Of course, we may consider a closed community having its own dedicated or
outsourced AC authority implementing a "signature delegation" having the
following functioning:
- The AC receives a request from the "SUPERIOR" (namely the person who will
delegates his signature to the end-entity) requesting an AC for the end-entity.
This AC will contain propriatary attributes for signature delegation
(attributes not defined within RFC 3281).
- The end-entity receives its AC and may hence include it as signed attribute
within messages it signs.
The above scheme seems to work but it suffers from my point of view from
several questions must be explicitely addressed:
- The superior shall have the privileges to provide "the signature delegation"
privilege (attribute) to the end entity (via the AC authority)
- The AC provided to the end-entity should address the problem of a SUPERIOR
denying having provided a particular signature delegation privilege (attribute)
to the end-entity.
- A signature policy must explicitely specify the context of signature
delegation so that bothe the superior and the end-entity are liable and cannot
deny a particular signing act
- When the end-entity signs by delegation a particular message, a signature
receiving and verifying agent shall be able to adequately verify the signature.
This verifying agent, unless within the closed community, won't be able to
verify the CMS signed data in a standard way.
So leads me conclude my argumentation by saying:
- An attribute certificate chain constituted from at least 3 AC's shall be
provided to the signing and verifying entity.
- The first AC in the chain should be the AC authority root key
- The second one should be the SUPERIOR AC where the signature
delegation capabilities of - the superior will be expressed.
- The last AC is the end-entity AC.
- A "signature delegation policy" is needed. It may live in its own dedicated
contex of may be included in a more general "signature policy".
- The definition od standard attributes for signature delegation.
When i will have more time i will write a short document containing a solution
to the "signature delgation" with non-repudiation and in a standard way.
Regards,
malek.
-----Original Message-----
From: Denis Pinkas [mailto:Denis(_dot_)Pinkas(_at_)bull(_dot_)net]
Sent: 25 October 2002 16:11
To: malek(_dot_)bechlaghem(_at_)belgacom(_dot_)be
Cc: ietf-pkix(_at_)imc(_dot_)org; S-MIME / IETF
Subject: Re: delegation attribute within a signed message
Malek,
I have presented some slides on that topic at the IETF meeting in Salt Lake
City in December 2001. The presentation is called "Signature delegation".
The main idea is to use an Attribute Certificate. Since Attribute
Certificates may incorporated in a CMS structure (see RFC 3126),
then no addition to the signature format is necessary.
In such a case, there would be two documents to produce:
1) a profile for an Attribute Certificate usable for delegation,
(a PKIW work item),
2) a document saying how such an Attribute Cetificate is verified when
present in the CMS structure defined in RFC 3126, (an S-MIME work item).
Hence why I am posting this document to the S-MIME working group too.
Denis
I am trying to investigate the possibility to implement a delegated
electronic signature. I mean implement the fact that a signer has the
necessary attributes to sign on behalf of some-one else.
My understanding is that we should address this question from 2 angles:
1. The signer should express in his signed message the fact that he is
signing on behalf of some-one else (fopr the sake of
simplicity, let's say the superior).
2. The signer should have the necessary privleges to sign on behalf of
the superior
If we take into consideration CMS signatures, a possible implementation
of the above two points can be summarized as follows:
- Defining an additional attribute: "Detegated Signature". The fields of
this attributes may be a reference to the document where the
privilege of signing on behalf someone else are expressed. It may
simply be teh hash of the superior signing certificate.
- Adding this additional attribute as a signed attribute in the SigneInfo
of the signed data within the CMS signature.
- Having a reference to the signature policy added a signed attribute.
Within the sigature policy, we should exress the fact that when a "delegated
signature" signature is added as a signed attribute, this mens that the
signatory is signing on behalf a "superior".
- The document highlighting the privileges can be expressed within an
X509 Attribute certificate. This means that the SUPERIOR will have its own
ATTRIBUTE AUTHORITY. And the privilege withine the X509 attribute
certificate can be expressed as follows:
Privilege type: OID describing the privilege of signature delegation
Superior reference: Signing certificate of teh superior.
This solution doesn't seem to be simple to express but provided that the
necessary ASN.1 structures exist, it is intuitive to implement.
I have in mind several solutions but can you please tell me if signature
delegation has already been specified within some standard or RCF (up to my
knowledge, no such functionality has already been expressed in ETSI or PKIX
standards). And if it doen't exist, what do you think about the solution i
summarized above.
regards,
___________________________________________________________
Malek Bechlaghem
e-Security Product Development Manager
Strategy, Business Development and Product Management (SBP)
Internet Business Unit (IBU)
Belgacom SA/NV
Bd du Roi Albert II, 27, B-1030 Brussels
Tel.: +32 2 202 79 02
Fax: +32 2 202 41 06
E-mail: malek(_dot_)bechlaghem(_at_)belgacom(_dot_)be
We bring security to the e-world : www.e-trust.be
**** DISCLAIMER ****
"This e-mail and any attachments thereto may contain information
which is confidential and/or protected by intellectual property
rights and are intended for the sole use of the recipient(s) named above.
Any use of the information contained herein (including, but not limited to,
total or partial reproduction, communication or distribution in any form)
by persons other than the designated recipient(s) is prohibited.
If you have received this e-mail in error, please notify the sender either
by telephone or by e-mail and delete the material from any computer.
Thank you for your cooperation."
**** DISCLAIMER ****
"This e-mail and any attachments thereto may contain information
which is confidential and/or protected by intellectual property
rights and are intended for the sole use of the recipient(s) named above.
Any use of the information contained herein (including, but not limited to,
total or partial reproduction, communication or distribution in any form)
by persons other than the designated recipient(s) is prohibited.
If you have received this e-mail in error, please notify the sender either
by telephone or by e-mail and delete the material from any computer.
Thank you for your cooperation."