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