[Top] [All Lists]

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

1999-03-12 07:54:31

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

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.


John Ross

<Prev in Thread] Current Thread [Next in Thread>