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(_at_)secstan <ross(_at_)secstan(_dot_)com>
To: ietf-smime(_at_)imc(_dot_)org; John Pawling <jsp(_at_)jgvandyke(_dot_)com>
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 <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