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 }