Subject: Extensibility discussion

From: "John Ross" <[email-masked]>
Date: Thu, 3 Dec 1998 15:12:41 -0800

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

---

From: Russ Housley <[email-masked]>
Date: Mon, 07 Dec 1998 17:12:23 -0500

John:

One bucket for unprotected attributes in the EnvelopedData structure is
more than enough.  If we put two such buckets (by adding a second
one to keyAgreeRecipientInfo), then the processing gets
complex.

I am strongly opposed.

Russ

At 03:12 PM 12/3/98 -0800, John Ross wrote:

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?

version CMSVersion,  -- always set to
3

originator [0] EXPLICIT
OriginatorIdentifierOrKey,

ukm [1] EXPLICIT UserKeyingMaterial
OPTIONAL,

keyEncryptionAlgorithm
KeyEncryptionAlgorithmIdentifier,

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 .

ktri
KeyTransRecipientInfo,

kari [1]
KeyAgreeRecipientInfo,

kekri [2]
KEKRecipientInfo

kext [3]
ExternalyDefinedKeyAgreement --for future or private key management
schemes }

Alternatively,  the syntax of the externally defined
key management use the OID extension mechanism:

}

I slightly favor the OID extension but if there is objection
to that extension mechanism, the OCTET STRING approach would be
adequate.

John Ross