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

["Jim Schaad (Exchange)" <[e-mail]>]

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.

jim


-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
Sent: Wednesday, March 10, 1999 6:34 AM
To: [e-mail]
Cc: [e-mail]
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
ALGORITHM-IDENTIFIER syntax.

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
========================================================