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

[[e-mail] (John Pawling)]

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
>