ietf-smime
[Top] [All Lists]

Re: Extensibility discussion

1998-12-08 01:56:59
Russ

OK, 
but what about extending the choice, are you also opposed to that?

Regards

JR
    -----Original Message-----
    From: Russ Housley <housley(_at_)spyrus(_dot_)com>
    To: John Ross <ross(_at_)jgross(_dot_)demon(_dot_)co(_dot_)uk>
    Cc: ietf-smime(_at_)imc(_dot_)org <ietf-smime(_at_)imc(_dot_)org>
    Date: Monday, December 07, 1998 8:36 PM
    Subject: 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: 
    --Cut--
    
        
         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