ietf-smime
[Top] [All Lists]

CMS -EnvelopedData extensibility

1998-11-02 03:54:54
CMS-EnvelopedData is currently not easy to extend to carry additional 
information or attributes.  Is that intentional?

Generally, it is a good idea to include a way of extending protocols when 
defining standards. Including a protocol extension mechanism facilitates easy 
migration to meeting new requirements. 

In  particular,  in the case of EnvelopedData future extensions may be required 
to support additional Algorithms.

The first Question I have to the Mail list is:

1) Is there support for providing an extensibility mechanism in EnvelopedData? 
YES or NO.

If there is support, then  the second question is 
2 ) Should a similar scheme to SignedData unsigned attributes could be used? 
YES or NO.

The extension mechanism could be per EnvelopedData (i.e per message).

 The following is an example ASN.1:
 
 EnvelopedData ::= SEQUENCE {
     version CMSVersion,
     originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL,
     recipientInfos RecipientInfos,
     encryptedContentInfo EncryptedContentInfo 
     unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL }

The extension mechanism could also be per recipient using the key transport 
recipient information and key agreement recipient info.

The following is an example ASN.1:
 
KeyTransRecipientInfo ::= SEQUENCE {
     version CMSVersion,  -- always set to 0 or 2
     rid RecipientIdentifier,
     keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
     encryptedKey EncryptedKey 
      unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL }


  KeyAgreeRecipientInfo ::= SEQUENCE {
     version CMSVersion,  -- always set to 3
     originator [0] EXPLICIT OriginatorIdentifierOrKey,
     ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL,
     keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
     recipientEncryptedKeys RecipientEncryptedKeys 
     unsignedAttrs [2] IMPLICIT UnsignedAttributes OPTIONAL }

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