Re: Extensibility discussion

John:

If you read the document carefully, you will see that each *RecipientInfo
structure has a different version number in it.  I would not like to
see an OID followed by an ANY structure here.  It will simply
increase the liklihood on non-interoperability.  In fact, the MSG
spec would have to profile out its use.

What key management technique is not supported by the alternative
provided?

Russ


At 09:00 AM 12/8/98 -0800, John Ross wrote: 
> 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