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