Paul & S/MIME WG Memeber:
1. Section 1, Introduction, says:
This document describes three optional security service extensions for
S/MIME. These services provide functionality that is similar to the Message
Security Protocol [MSP4], but are useful in many other environments,
particularly business and finance. The services are:
- signed receipts
- security labels
- secure mailing lists
I think that the signature attribute stuff should be included in the
introduction.
2. Section 1.3.4, Placement of Attributes, should be slightly expanded. It
should state that UnprotectedAttributes from EnvelopedData are not used to
carry
any of the attributes specifed in ESS.
3. Section 1.3.4, Placement of Attributes, still talks about the macValue
attribute. It has been deleted from [CMS], and it should be deleted here too.
4. Section 2.2.1 says, "Each recipient SHOULD return only one signed
receipt."
A related section should also state that recipients of receipts should be
prepaed to deal with duplicates.
5. Section 3, Security Labels, says:
... The labels are often priority based ("secret", "confidential",
"restricted", and so on) or role-based, describing which kind of people can
see the information ("patient's health-care team", "medical billing
agents", "unrestricted", and so on).
I think that "priority" is the wrong word. These labels state the amount of
harm that would result from the disclosure of the information.
6. Section 5, Signing Certificate Attribute, says:
Attribute certificates can be used as part of a signature verification
process. ...
I would prefer: Attribute certificates might support signature verification.
7. Section 5.1, Attack Descriptions, says:
At least three different attacks can be launched against a possible
signature verification process by changing the certificate or certficates
used in the signature verification process.
I would prefer "substituting" or "replacing" instead of "changing." The
certificate cannot be modified without invalidating the signature.
8. Section 5.4.1, Certificate Identification,
The best way to identify certificates is an often-discussed issue. CMS has
imposed a restriction for SignedData objects that the issuer DN must be
present in all signing certificates. ...
I think that the restriction is in CERT (not CMS). Please confirm.
Russ