John:
1) Sec 3, last para: This paragraph discusses "external signatures". This
concept adds significant complexity to the CMS security services. Is it
really needed?
Yes. S/MIME needs it.
2) Sec 3, last para: If it is decided that the CMS spec still needs to
support "external signatures", then the following issue needs to be
clarified. Is it true that the signatureValue in a SignedData object in
which the content is absent is calculated exactly as with a SignedData in
which the content is present? If so, then please add a sentence to the last
para of Sec 3 stating that fact.
Okay. I will add the following:
If the ContentInfo value is absent, the signatureValue is
calculated as though the ContentInfo value were present.
The presumed ContentInfo must have the content type set to
id-data and the content omitted.
3) Sec 3, last para: If it is decided that the CMS spec still needs to
support "external signatures", then please add the following sentence: "In
this case, the content type within the ContentInfo must be id-data and the
content field of the ContentInfo must be omitted (i.e. absent)."
Does the above wording satisfy this concern too?
4) Sec 5.2: This references PKCS #9. The WG still needs to duplicate the
PKCS #9 contents in an IETF-controlled document. The CMS should then be
changed to reference the IETF-controlled document.
Agree. This is an open issue. I think that a future CMS draft will
include a section "Useful Attributes" that duplicates the relevant parts of
PKCS#9.
5) Sec 6, Intro, Step 3: Do you think that it is worthwhile to mention in
the CMS spec that a sending agent should include a copy of the
content-encryption key that is protected using the originator's key material
so that the originator can always decrypt the message?
Good idea. How about:
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.
6) Sec 7.1: This section states: "The definition of
CertificateRevocationList is imported from X.509.
CertificateRevocationLists ::= SET OF CertificateRevocationList".
However, the 97 X.509 Recommendation includes the following definition of
CertificateRevocationList:
"certificateRevocationList ATTRIBUTE ::= {
WITH SYNTAX CertificateList
EQUALITY MATCHING RULE certificateListExactMatch
ID
id-at-certificateRevocationList }
CertificateList ::= SIGNED { SEQUENCE {
version Version OPTIONAL,
-- if present, version must be v2
signature AlgorithmIdentifier,
issuer Name,
thisUpdate Time,
nextUpdate Time OPTIONAL,
revokedCertificates SEQUENCE OF SEQUENCE {
userCertificate CertificateSerialNumber,
revocationDate Time,
crlEntryExtensions Extensions OPTIONAL }
OPTIONAL,
crlExtensions [0] Extensions OPTIONAL }}"
I believe that the intent was for the CMS SignedData and OriginatorInfo
syntaxes to include a SET OF CertificateList rather than SET OF
CertificateRevocationList (which would be a SET of attributes containing
CertificateLists).
Agree. I changed it to CertificateList.
Russ