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 }