Subject: Re: CMS -EnvelopedData extensibility

From: "Darren Harter" <[email-masked]>
Date: Fri, 06 Nov 1998 09:39:47 +0000

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: [email-masked]
Home: [email-masked]

>>> "John Ross" <[email-masked]> 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 }

---

From: Russ Housley <[email-masked]>
Date: Mon, 09 Nov 1998 22:16:34 -0500

Darren:

This was discussed.  Backward compatibility was considered more important
than encrypted attributes.

Russ

At 09:39 AM 11/6/98 +0000, Darren Harter wrote:
>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
>
>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 extension mechanism could also be per recipient using the key transport 
>recipient information and key agreement recipient info.
>