Subject: CMS -EnvelopedData extensibility

From: "John Ross" <[email-masked]>
Date: Mon, 2 Nov 1998 10:58:53 -0800

Russ,

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 you and 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 }