Subject: Re: Extensibility discussion

From: "Rich Ankney" <[email-masked]>
Date: Thu, 3 Dec 1998 10:59:01 -0500

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 <[email-masked]>
To: Ietf distribution list <[email-masked]>
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

---

From: "John Ross" <[email-masked]>
Date: Thu, 3 Dec 1998 16:32:03 -0800

I personally think extending the choice will do, but it depends on how
flexible we need to be.

-----Original Message-----
From: Rich Ankney <[email-masked]>
To: John Ross <[email-masked]>; Ietf distribution list
<[email-masked]>
Date: Thursday, December 03, 1998 7:59 AM
Subject: Re: Extensibility discussion