Jim:
1. Section 2, Last paragraph, Sentence 4: I think that "However, signed
attributes within the signed-data content type and authenticated attributes
within the authenticated-data content type require DER encoding." should
read "However, signed attributes within the signed-data content type
andauthenicated a attributes within the authenticated-data content type are
the only places where DER encoding is required."
I prefer:
... However, signed attributes within the signed-data content type and
authenticated attributes within the authenticated-data content type require DER
encoding. Signed attributes and authenticated attributes must be transmitted
in DER form to ensure that recipients can validate a content that contains an
unrecognized attribute. Signed attributes and authenticated attributes are the
only CMS data types that require DER encoding.
2. ASN Module Errors
"cms.asn", line 176 (CryptographicMessageSyntax): A0256W: 'DigestAlgorithm'
is referenced, but is not defined.
Need to change DigestAlgorithm to DigestAlgorithmIdentifier in
AuthenticatedData
Ooops. You are correct.
3. The algorithm OIDs defined and used in section 12 are not included in the
ASN module.
I know. This is a philosophy question. Since these identifiers will
eventually be in the IANA registry, I did not know whether or not these values
should be part of the module.
I would be glad to add these values to the module if the working group thinks
they belong there. Comments?
4. Section 5, First pagagraph after the bullets. The text has not been
updated to reflect the SKI addition to the signer info object.
Good catch. How about:
... The signer's public key is referenced by an issuer
distinguished name along with an issuer-specific serial
number or a subject key identifier that uniquely identify
the certificate containing the public key.
5. Same as above: "that uniquely identify the certificate containing the
public key" Should read "that uniquely identifies the certificate..."
I changed "identify" to "identifies."
6. Section 5.1: The last two paragraphs really belong as part of section
5.2 as they are discussing EncapsulatedContentInfo. This is especially true
given that it is refered to from places like section 7.
Agreed. I moved them to the end of section 5.2.
7. Section 5.1: Text on version needs to be expanded to deal with SKI.
Must be 3 if any SignerInfo version is 3.
Are you saying that a version 3 SignerInfo should cause parent SignedData
version to be 3?
Is there a reason to prohibit version 3 SignerInfo from being encapsulated in a
version 1 SignedData?
8. Section 9. nit-pik -- authenticatedAttributes is misspelt in the ASN for
AuthenticatedData (but it is consistantly misspelt).
I did a global substitution of "authenctiatedAttributes" with
"authenticatedAttributes."
9. Section 10.2.6 -- I don't like the first sentence. How about "The
UserKeyingMaterial type gives a syntax for user keying material (UKM)."
Okay. I added "for" to the sentence.
10. Section 12.3.1, paragraph 3. I would like to change the first sentence
to "A CMS Implementation should support mixed key-encryption and
content-encryption algorithms."
Disgree. I am reluctant to change "may" to "should." What do other people
think?
11. Section 12.3.3 - Please insert the following paragraph in this section
" A CMS implementation should support mixed key-encryption and content-
encryption algorithms. For example, a 128-bit RC2 content-encryption
key may be wrapped with 168-bit Triple-DES key-encryption key.
Similarly, a 40-bit RC2 content-encryption key may be wrapped with
128-bit RC2 key-encryption key."
As with comment 10, I would like to hear what other people think before
changing "may" to "should."
12. Ditto 11 for section 12.6
Ditto. As with comments 10 and 11, I would like to hear what other people
think before changing "may" to "should."
13. Security Considerations, pargraph 7 - Typo with wises for wishes
I changed it to "wishes."
Russ