ietf-smime
[Top] [All Lists]

RE: delegation attribute within a signed message

2002-10-29 03:00:53

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."


<Prev in Thread] Current Thread [Next in Thread>