Re: More on KEKIdentifiers, and a suggested addition to CMS

["Rich Ankney" <[e-mail]>]

I agree with this approach.  Otherwise I'd like to reserve the version
number 73, for X9.73 with CKM key management :-)

/ Rich

----------
> From: ross@secstan <[e-mail]>
> To: [e-mail]; John Pawling <[e-mail]>
> Subject: Re: More on KEKIdentifiers, and a suggested addition to CMS
> Date: Tuesday, March 16, 1999 12:11 PM
> 
> John,
> 
> If the choice includes an OID extension with an OCTET STRING, then the
one
> pass ASN.1 decoding strategy on the entire object works OK. Correct?
> 
> If the implementation can support an OID extension will  it need to dig
> deeper into the OCTETSTRING.  Implementations that do not support any OID
> extension to the choice will just ignore it,  there should be no syntax
or
> decoder failure.   The end result will be that envelopeData will decode
> correctly.
> 
> So I favour adding the OID extension to the choice.
> 
> Regards
> 
> JR
> .
> 
> 
> 
> -----Original Message-----
> From: John Pawling <[e-mail]>
> To: [e-mail] <[e-mail]>
> Date: 15 March 1999 16:21
> Subject: Re: More on KEKIdentifiers, and a suggested addition to CMS
> 
> 
> >John,
> >
> >You stated:
> >>I agree with Peter, CMS should allow the extension of the Choice syntax
> >> i.e. in text using  the old ASN.1 rules), which gives a good pointer
to
> the
> >>implementors that they should not object if the they receive an
extended
> >>choice.
> >
> >I agree that the CMS RecipientInfo CHOICE syntax could be modified in
> future
> >versions of CMS through the addition of well-defined ASN.1 syntaxes, but
I
> >disagree that adding "..." in the current CMS RecipientInfo syntax adds
any
> >value.  If your use of "extended choice" refers to a RecipientInfo
> including
> >a CHOICE alternative not specified in the CMS document, then I object to
> >your statement that implementors "should not object if the they receive
an
> >extended choice."  Please see my previous message for the explanation of
> why
> >I object to the premise that it is straightforward for recipient
software
> to
> >ignore undefined CHOICE alternatives.
> >
> >- John Pawling
> >