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
So I favour adding the OID extension to the choice.
From: John Pawling <jsp(_at_)jgvandyke(_dot_)com>
To: ietf-smime(_at_)imc(_dot_)org <ietf-smime(_at_)imc(_dot_)org>
Date: 15 March 1999 16:21
Subject: Re: More on KEKIdentifiers, and a suggested addition to CMS
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
implementors that they should not object if the they receive an extended
I agree that the CMS RecipientInfo CHOICE syntax could be modified in
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
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
I object to the premise that it is straightforward for recipient software
ignore undefined CHOICE alternatives.
- John Pawling