Subject: Re: CMS -EnvelopedData extensibility

From: "Darren Harter" <[email-masked]>
Date: Tue, 10 Nov 1998 09:36:46 +0000

Russ,

Thanks for the confirmation.  The point I was trying to make is that it's not encrypted attributes that are needed, it's clear attributes.

Currently, if I wish to encrypt a message and send the recipient an arbitrary set of certifictes and CRLs, I would have to either wrap the EnvelopedData in a SignedData or vice versa, and store the certs/CRLs in the SignedData.

IMHO, this is wasteful when a simple addition to EnvelopedData would save having to do an extra ASN.1 encoding ad MIME wrapping.

Regards,

Darren 

-------------------------------------------------------------
Darren Harter BSc Hons MBCS CEng
CASM Technical Architect
CASM Programme Office
CESG
Work: [email-masked]
Home: [email-masked]

>>> Russ Housley <[email-masked]> 11/10/98 03:16am >>>
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:
>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: Francois Rousseau <[email-masked]>
Date: Tue, 10 Nov 1998 11:54:20 -0500

Russ,

I do not agree that the proposed extensibility, as previously proposed by
Darren, will necessarily affect the backward compatibility with S/MIME v2
and PKCS#7 v1.5 as you have suggested.

To support this proposed extensibility while still addressing your backward
compatibility concern, CMS would only have to mandate that the "CMSVersion"
shall be 2 when the optional unsigned attribute is added to the
EnvelopedData. Similarly CMS would also have to mandate that the
"CMSVersion" shall be 2 when the optional unsigned attribute is added to
the KeyTransRecipientInfo. There should be not backward compatibility issue
with PKCS#7 v1.5 when the unsigned attribute is added to the
KeyAgreeRecipientInfo since it never existed before.

Francois Rousseau
AEPOS Technologies

Darren wrote:
>Russ,
>
>Thanks for the confirmation.  The point I was trying to make is that it's
not encrypted attributes that are needed, it's clear attributes.
>
>Currently, if I wish to encrypt a message and send the recipient an
arbitrary set of certificates and CRLs, I would have to either wrap the
EnvelopedData in a SignedData or vice versa, and store the certs/CRLs in
the SignedData.
>
>IMHO, this is wasteful when a simple addition to EnvelopedData would save
having to do an extra ASN.1 encoding ad MIME wrapping.