[Top] [All Lists]

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

1999-03-10 11:15:17
John & Peter,

At this point in time I am not willing to support this. I have two reasons
for this

1.  I want to get CMS approved, and there are other options for how to
approach this (such as a new I-D) and we know a new version of CMS is coming
soon to deal with OEAP

2.  I don't think this is the correct set of items that are needed.  You
have not proposed an appropriate set of text for section 12.  I don't
understand why the Content Encrytion Alg should be encoded twice.  I don't
understand why the KEK Wrap algorithm is not specified.  I just don't think
this is complete yet.


-----Original Message-----
From: jsp(_at_)jgvandyke(_dot_)com [mailto:jsp(_at_)jgvandyke(_dot_)com]
Sent: Wednesday, March 10, 1999 6:34 AM
To: ietf-smime(_at_)imc(_dot_)org
Cc: burt(_at_)RSA(_dot_)COM
Subject: Re: More on KEKIdentifiers, and a suggested addition to CMS

Peter, Russ and friends,

Initially, I was opposed to this proposal because it adds yet more
complexity to CMS.  However, I agree with Peter that it is better to have a
clearly defined, meaningful ASN.1 syntax rather than to kludge data into an
existing syntax.  I assume that PKCS #15 is going to be widely used, so it
is worthwhile to enhance the CMS RecipientInfo syntax to include Peter's
proposed PasswordRecipientInfo CHOICE.   

I have a few comments to Peter's proposed additions to CMS:

1) Peter's proposal uses the ALGORITHM-IDENTIFIER syntax which is not part
of the 1988 ASN.1 grammar.  Many moons ago the S/MIME WG decided that the
S/MIME v3 set of specs will only use the 1988 ASN.1 grammar, so I believe
that Peter's proposal should be re-worded to eliminate use of the

2) Recommend that "KSG" be spelled.  

3) Also, please reword the following to use 1988 ASN.1 syntax:
The ContentEncryptionAlgorithmIdentifier is something like:

     ContentEncryptionAlgorithmIdentifier ::= {
       { IDENTIFIED BY des-ede3-cbc },
       { IDENTIFIED BY rc2CBC },
       { IDENTIFIED BY cast5CBC },
       { IDENTIFIED BY rc5CBC },
       { IDENTIFIED BY ideaCBC },
       { IDENTIFIED BY desCBC },
       ... -- ... and anything else you can think of, eg Skipjack

Assuming that CMS is changed to include PasswordRecipientInfo, I don't
believe that the KEKRecipientInfo kekid needs to be changed to be OPTIONAL
(as Peter also proposed) because PKCS #15 will no longer use the
KEKRecipientInfo syntax.

John Pawling,  Director - Systems Engineering
J.G. Van Dyke & Associates, Inc., a Wang Global Company