ietf-smime
[Top] [All Lists]

Re: CMS -EnvelopedData extensibility

1998-11-06 02:49:02
It's possible that this one has slipped through unnoticed, but I'm a little 
suprised by the lack of response.

I think John has a good point in that unlike SignedData, EnvelopeData is not 
extensible.  Regardless of how unlikely it may seem, it is possible that an 
appliation may wish to send some information 'in-the-clear' using EnvlopedData. 
 For example, to carry CRLs, other certs, and clear label etc.  I believe it 
should be possible to do this without forcin gthe application to wrap the 
EnvelopedData in another SignedData.  After all CMS will be used for purposes 
other than S/MIME.

I agree with John that EnvelopedData should be extended to allow 
unauthenticated clear data to be passed on both a global and per-recipient 
basis.

I don't how other list members feel, but I would be suprised if the IESG would 
approve a standard that was not extensible and future proofed in this way.

Regards,

Darren

-------------------------------------------------------------
Darren Harter BSc Hons MBCS CEng
CASM Technical Architect
CASM Programme Office
CESG
Work: dharter(_at_)cesg(_dot_)gov(_dot_)uk
Home: Darren(_dot_)Harter(_at_)bcs(_dot_)org(_dot_)uk

"John Ross" <ross(_at_)jgross(_dot_)demon(_dot_)co(_dot_)uk> 11/02/98 
06:55pm >>>
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 }