Jim:
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.
You are correct. I think I fixed it. I removed most of the "protection" words
from both sections, and it is more clear without them. The first paragraph of
section 2 contains the correct definition: "This document defines one
protection content, ContentInfo."
2. Section 6.2.2 the paragraph on recipientEncryptedKeys: Change to
"includes a receipient identifier and encrypted key for one or more
recipients."
The paragraph reads:
recipientEncryptedKeys includes a recipient identifier and encrypted key for
one or more recipients. The KeyAgreeRecipientIdentifier is a CHOICE with two
alternatives specifying the recipient's certificate, and thereby the
recipient's public key, that was used by the sender to generate a pairwise
key-encryption key. The recipient's certificate must contain a key agreement
public key. The content-encryption key is encrypted in the pairwise
key-encryption key. The issuerAndSerialNumber alternative identifies the
recipient's certificate by the issuer's distinguished name and the certificate
serial number; the RecipientKeyIdentifier is described below. The encryptedKey
is the result of encrypting the content-encryption key in the pairwise
key-encryption key generated using the key agreement algorithm.
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.
I understand your proposed change, but I do not understand the "security
weakness." In CMS-07, two MAC values are computed. The first MAC value is
computed from the content, then this MAC value is encoded in an authenticated
attribute. The second MAC value is computed from the DER encoded attributes.
The two MAC values should not be the same. So, if the attributes are removed
by an attacker, the MAC value check should fail.
If you are concerned about an attacker who is a recipient, and thus has the
symmetic key needed to compute the MAC, then I do not think that anything can
be done to make authenticated-data secure.
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.
Okay. I'll delete it.
5. Section 12.5.2. DES MAC should be struck and replace with 3DES MAC.
My notes from Chicago indicate that HMAC with SHA-1 and DES MAC are the two
algorithms that will be included. As 12.5 says: "CMS implementations that
support authenticatedData must include HMAC with SHA-1. CMS implementations
may also include DES MAC."
6. ASN Module changes:
- ContentType is defined twice
I removed the second one.
Enjoy,
Russ