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

["ross@secstan" <[e-mail]>]

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
>