[Top] [All Lists]

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

1999-03-10 07:25:16
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