All,
I believe that this proposal leads to non-interoperable S/MIME
implementations, so I oppose it. If the originator chooses a kext syntax
that the recipient's software does not understand, then the recipient will
not be able to decrypt the EnvelopedData content. I believe that the CMS
RecipientInfo syntax should not be changed until it is proven that it does
not meet a valid requirement ("valid" as defined by consensus of the S/MIME
WG). If that occurs, then we should consider adding a well-defined syntax
as a ReceipientInfo CHOICE (not a wild card).
=========================================================
John Pawling, Director - Systems Engineering
J.G. Van Dyke & Associates, Inc., a Wang Global Company
=========================================================
At 05:51 PM 3/11/99 -0800, John Ross wrote:
If you are going to allow the choice to be extended, I agree with Rick that
it should be controlled. Just extending the choice with a new tag (and by
the way it also then needs a new version number), will give problems in the
future, as it is not a unique identifier. What if a private extensions has
been defined already and used tag 3? Also, if every extension to the choice
needs a new CMSversion number assigned, that may be a lot of CMSversion
around in the future. A while back I proposed to have an extensible "choice"
using octet string, it would be better using OID and any defined by as
follows:.
The following is an example ASN.1:
RecipientInfo ::= CHOICE {
ktri KeyTransRecipientInfo,
kari [1] KeyAgreeRecipientInfo,
kekri [2] KEKRecipientInfo,
kext [3] ExternalyDefinedKeyAgreement --for future or private key
management schemes }
ExternalyDefinedKeyAgreement :: = SEQUENCE {
keyTypeIdentifier ObjectIdentier,
keyTypeInfo OCTECT STRING --any defined by OID}
This will at lease make sure that there is unique identifiers for all the
extensions to recipient info.
Regards
John Ross