1. the usage of the phrase "protection content type" is inconsistant
between section 2 (general overview) and section 3 (General syntax). For
one it is the same as the data content type for the other it is an OID. No
suggested text since I was not clear on which one you really meant it to be.
2. Section 6.2.2 the paragraph on recipientEncryptedKeys: Change to
"includes a receipient identifier and encrypted key for one or more
recipients."
3. Section 9 - Authenticated-data Content Type: I think I have identified
what I consider to be a security weakness. Specifically if you create an
authenticated data object with authenticated attributes, I can remove the
authenticated attributes and come up with a stil legal authenticated data
object. To fix this I propose that we change authenticated data in the
following ways:
a) In AuthencatedData macAlgorithm be changed to hashAlgorithm.
b) autenticatedAttributes becomes a REQUIRED field (remove the OPTIONAL)
c) a digest-value becomes a required attribute in the
autenticatedAttributes (replacing mac-value)
d) in processing, you hash the encapContentInfo, put the has in the
authenticated attributes and MAC this value.
4. Section 9.2 paragraph 4: I don't understand why this paragraph exists.
It does not appear to have an analogus paragraph in the signature message
digest paragraphs. I think this paragraph should be struck.
5. Section 12.5.2. DES MAC should be struck and replace with 3DES MAC.
6. ASN Module changes:
- ContentType is defined twice
Jim Schaad