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.
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
Russ Housley <housley(_at_)spyrus(_dot_)com> 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: 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 }