Extensibility discussion

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