John:
1) Sec 3, last para: I believe that this paragraph describing "external
signatures" should be moved to Sec 5.1, SignedData contentInfo description.
That is the only use of ContentInfo to which the "external signatures"
paragraph applies.
I noticed this too. I was a carry over from the PKCS#7 document. I will
make the change in the next document.
2) Sec 6, bullet 3: Please delete "the originator and" from the following:
"3. For the originator and each recipient, the encrypted content-encryption
key and other recipient-specific information are collected into a
RecipientInfo value, defined in Section 6.2." The 10 Dec 97 S/MIME WG
decided that the requirement for the inclusion of a copy of the
content encryption key encrypted for the originator in an envelopedData
object must not be included in the CMS I-D, but that it must be included in
the S/MIME v3 Message Specification as a SHOULD requirement.
Agree. I will remove the words.
3) Sec 6.2, RecipientInfo originatorCert description: Please add "This
field should be included when the recipientInfo keyEncryptionAlgorithm field
indicates a key agreement algorithm and the originator's certificate is
omitted from the envelopedData originatorInfo field (i.e. the originator's
public key material is required as part of the process to decrypt the
encryptedKey, but the originator's certificate is not included in the
envelopedData object)."
I do not understand this one. In the bag-of-certificates, the originator
may have more than one with the specified key management algorithm. In
this case, the originator tells the recipient which one to use. The
certificate itself is not carried here, rather an EntityIdentifier is carried:
EntityIdentifier ::= CHOICE {
issuerAndSerialNumber IssuerAndSerialNumber,
subjectKeyIdentifier SubjectKeyIdentifier }
So, I do not see the change that is needed....
4) Sec 9.7, IssuerAndSerialNumber. The PKIX X.509 Cert and CRL Profile
allows X.509 Certs to include an empty sequence as the Issuer Name and a
IssuerAltName extension which may (or may not) contain a Name form. The
current CMS IssuerAndSerialNumber does not include sufficient flexibility to
uniquely identify X.509 certs that use non-Name IssuerAltName forms instead
of the Issuer Name. If the S/MIME v3 Certificate Handling spec allows empty
Issuer Names and non-Name IssuerAltName forms, then I believe that
IssuerAndSerialNumber should be changed as follows:
IssuerAndSerialNumber ::= SEQUENCE {
issuer Name,
serialNumber SerialNumber
issuerAltName [0] IMPLICIT GeneralNames OPTIONAL}
This would be backwards compatible with PKCS #7, v1.5.
I talked to Blake about this issue. The next draft of the certs draft will
mandate the population of the issuer name. I think this is a much simplier
solution to the issue that you raise.
5) If comment 4 is accepted, then the signedData signerInfo version
description should be changed to state that the version shall be 1 if the
issuer Name is used and issuerAltName is absent. If the issuerAltName is
present, then the version shall be 2. Similar changes would be needed for
the recipientInfo version and originatorCert descriptions.
Actually, this is the reason that I prefer the mandatory issuer name
solution. I am personally more concerned with backward compatibility of
signed messages than encrypted messages.
6) References: Please delete the references to PKCS #6 and PKCS #9.
I disagree. I have pulled stuff into CMS from both of these documents, so
they deserve the reference.
7) References: Please change PKCS #7 to match that in the ESS I-D.
I included both forms of reference.
Thanks for the review,
Russ