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 <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
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