The attributes are outside the RecipientInfo, so they can be used
with key transport recipients, key agreement recipients, or KEK
recipients. Is there really a need to put them inside the RecipientInfo?
as well (or instead)?
I do like the idea of adding an additional CHOICE to accommodate
future key management mechanisms. The OID/ANY approach seems
the most flexible approach.
/ Rich
----------
From: John Ross <ross(_at_)jgross(_dot_)demon(_dot_)co(_dot_)uk>
To: Ietf distribution list <ietf-smime(_at_)imc(_dot_)org>
Subject: Extensibility discussion
Date: Thursday, December 03, 1998 6:12 PM
The latest version of CMS (09) has added plaintextAttrs to EnvelopedData
which allows extension to be defined for EnvelopedData,
Is there any reason why keyAgreeRecipientInfo should not be made extensible
in the same way?
The following is an example ASN.1:
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 }
However, if CMS want to be able to support more key agreement algorithms in
the future, perhaps the best way to allow that would be to allow the CHOICE
of RecipientInfo to be extendable .
The following is an example ASN.1:
RecipientInfo ::= CHOICE {
ktri KeyTransRecipientInfo,
kari [1] KeyAgreeRecipientInfo,
kekri [2] KEKRecipientInfo
kext [3] ExternalyDefinedKeyAgreement --for future or private key
management schemes }
ExternalyDefinedKeyAgreement :: = OCTET STRING
Alternatively, the syntax of the externally defined key management use the
OID extension mechanism:
ExternalyDefinedKeyAgreement :: = SEQUENCE {
ExternalID OBJECT IDENTIFIER {
ExternalValue ANY DEFINED BY ExternalID
}
I slightly favor the OID extension but if there is objection to that
extension mechanism, the OCTET STRING approach would be adequate.
John Ross