Subject: ESS-10

From: Russ Housley <[email-masked]>
Date: Tue, 12 Jan 1999 11:01:18 -0500

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