Re: Extensibility discussion

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?
>  
> 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
>