All,
IMHO, Paul has done an excellent job of editing the 31 Oct 97 "Enhanced
Security Services (ESS) for S/MIME" document. I have the following comments:
1) Sec 1.1.1, 1rst para, last sent: In a secure mailing list, all recipients
are supposed to be able to read every message sent to the mail list. Please
delete the following sentence because it doesn't make sense: "This is
typically the case in a secure mailing list where some of the messages are
not meant to be readable by all of the recipients."
2) Sec 1.2, last para: Please add as the second sent: "As defined in
[PKCS7-1.5] and [CMS], each SignedData and EnvelopedData object MUST be
encapsulated by a ContentInfo SEQUENCE."
3) Sec 1.3.1, 1rst para, 1rst sent: Please change "A signed receipt may be
requested in any signed body part." to "A signed receipt may be requested in
any SignedData object."
4) Sec 1.3.2, 3rd para, 1rst sent: Please change: "A security label in
authenticated attributes may also be included in the outer SignedData block"
to "A security label may also be included in the authenticated attributes of
the outer SignedData block"
5) Sec 1.3.3, last sent: Please change "In all cases, the agent adds or
updates an mlExpansionHistory attribute to document the agent's processing,
and ultimately replaces the outer signature on the message to be
distributed." To "In all cases, the agent adds or updates an
mlExpansionHistory attribute to document the agent's processing, and
ultimately adds or replaces the outer signature on the message to be
distributed."
6) Sec 1.3.4, 1rst para, 1rst sent: Please change "SignerInfo" to "SignedData".
7) Sec 1.3.4: For completeness, please add the following attributes to the list:
Attribute Inner or outer MUST BE authenticated
counterSignature either yes
contentType either no
messageDigest either yes
8) Sec 2.2, 1rst para: Please add as the third sentence: "Only one
receiptRequest attribute can be included in the authenticatedAttributes of a
SignerInfo."
9) Sec 2.2, 1rst para, last sent: Please change "signed message" to
"signerInfo" in the following: "A sender requests receipts by placing a
receiptRequest attribute in the authenticated attributes of a signed message
as follows:"
10) Sec 2.2: Please add as last para:
"There can be multiple SignerInfos present within a SignedData object. Each
SignerInfo can include authenticatedAttributes. Therefore, the syntax
allows a single SignedData object to include multiple SignerInfos each of
which could include a receiptRequest attribute. For example, if an
originator desires to send a signed message requesting signed receipts to a
set of users composed of RSA-only and DSA-only users. The originator's
software can include one SignerInfo that includes an RSA signature value and
a receiptRequest attribute. The same SignedData object could include
another SignerInfo that includes a DSA signature value and a receiptRequest
attribute. In this example, the RSA-capable recipients should return an RSA
signed receipt to the originator and the DSA-capable recipients should
return a DSA signed receipt to the originator."
11) Sec 2.3, 1rst para, 2nd sent: Please change "Processing software SHOULD
examine the authenticatedAttributes field of the innermost SignerInfo object
to determine if a receipt is requested." To "Processing software SHOULD
examine the authenticatedAttributes field of each of the SignerInfos for
which it verifies a signature in the innermost signedData object to
determine if a receipt is requested. A receiving agent SHOULD build a
signed receipt for each SignerInfo in the SignedData object for which it
verifies the signature and which requests a signed receipt. This may result
in multiple signed receipts being constructed and sent for a single
SignedData object."
12) Sec 2.3, 2nd para, first sent: Please change: "then a signed receipt has
not been requested from any of the message recipients and MUST NOT be
created." To "then a signed receipt has not been requested for this
signerInfo from any of the message recipients and MUST NOT be created for
this signerInfo."
13) Sec 2.3, 2nd para, last sent: Please replace "In this case, the
receiving agent may choose whether or not to send a receipt." With "In this
case, the receiving agent SHOULD construct and send a signed receipt for the
message that requests a signed receipt."
14) Sec 2.3, bullet 1: Please change: "If an mlExpansionHistory attribute is
present in the outermost authenticatedAttributes block.." to "If an
mlExpansionHistory attribute is present in the outermost signedData block"
15) Sec 2.3, bullet 2.1: "then a signed receipt MUST NOT be created." To
"then a signed receipt MUST NOT be created for this signerInfo."
16) Sec 2.3, bullet 2.3.1: "and a signed receipt MUST NOT be created." To
"and a signed receipt MUST NOT be created for this signerInfo."
17) Sec 2.3, bullet 3.2: "then a signed receipt MUST NOT be created." To
"then a signed receipt MUST NOT be created for this signerInfo."
18) Sec 2.3, flow chart: Please change "A flow chart for the above steps
would be:" to "A flow chart for the above steps to be executed for each
signerInfo for which the receiving agent verifies the signature would be:"
19) Sec 2.3, flow chart 2.3.1: Please change "2.3.1. Create a receipt, then
-> STOP." To "2.3.1. STOP".
20) sec 2.3, flow chart 2.3.2: Please change "2.3.2. STOP" to "2.3.2. Create
a receipt, then -> STOP."
21) sec 2.4, intro: Please add: "Note that multiple signed receipts may have
to be created and sent, if applicable (see "Receipt Request Creation" section)."
22) sec 2.4, bullet 2.2: Please change "The encapsulatedContentType and
signedContentIdentifier values are copied from the original message's
receiptRequest.." to "The encapsulatedContentType and
signedContentIdentifier values are copied from the SignerInfo's receiptRequest"
23) sec 2.4, bullet 2.3: Please change "protectionValue" to "signatureValue".
24) sec 2.5, intro: Please add: "If multiple signed receipts are being sent,
then the following process must be repeated for each signed receipt created."
25) sec 2.6, bullet 4: Please change "protectionValue" to "signatureValue".
26) sec 2.7, bullet 1: Please change "The encapsulated content type, signed
content identifier, and encrypted digest value (signature value) derived
from the message content are copied from the original message into a Receipt
structure." To "The encapsulated content type, signed content identifier,
and encrypted digest value (signature value) derived from the message
content are copied from the SignerInfo including the receiptRequest into a
Receipt structure."
27) sec 2.7, bullet 3: Please add: "(as described in the "Receipt Creation"
section)."
28) sec 2.9, last para: Please change to: "The encapsulatedContentType and
signedContentIdentifier fields are copied from the receiptRequest attribute
of the SignerInfo contained within the message being receipted, and are used
to link the receipt to the original signed message. The
originatorSignatureValue field contains the
signatureValue copied from the SignerInfo requesting the signed receipt."
29) Sec 3.1, 1rst para, 1rst sent: Please change "signed message" to
"signedData object".
30) Sec 3.1.1, 1rst para, 4th sent: Please change "SignedData signature
value" to "SignerInfo signature value".
31) Sec 3.1.1, 3rd para, last sent: Please change: "signed message" to
"signedData object".
32) Sec 3.1.1, please add as 5th and 6th paras: "There may be multiple
SignerInfos present within a SignedData object. Each SignerInfo can include
authenticatedAttributes. Therefore, the syntax allows a single SignedData
object to include multiple SignerInfos each of which could include a
securityLabel attribute. For example, if an originator desires to send a
signed message including a security label to a set of users composed of
RSA-only and DSA-only users. The originator's software can include one
SignerInfo that includes an RSA signature value and a securityLabel
attribute. The same SignedData object could include another SignerInfo that
includes a DSA signature value and a securityLabel attribute. In this
example, the RSA-capable recipients would process the security label in the
RSA-signed signerInfo and the DSA-capable recipients would process the
security label in the DSA-signed signerInfo. This is true because a
recipient should only process a securityLabel attribute if the recipient can
verify the signature of the SignerInfo which covers the securityLabel
attribute. A recipient should not use a security label which the recipient
can't authenticate.
The following rules MUST be followed be sending agents:
1) All security labels included in a SignedData object must be identical.
2) There can't be multiple SignerInfos containing the same
signatureAlgorithm that all include securityLabels. In other words, there
can only be one securityLabel per signatureAlgorithm applied to the SignedData."
33) Second Sec 3.1.1 (note that there are two Sections marked 3.1.1):
Please change the first sentence to be: "A receiving agent that processes
security labels MUST process the securityLabel attribute, if present, in
each SignerInfo in the SignedData object for which it verifies the
signature. This may result in the receiving agent processing multiple
security labels included in a single SignedData object. Because all
security labels in a SignedData object must be identical, then the receiving
application processes (e.g. performs access control) the first securityLabel
that it encounters in a SignerInfo that it can verify and then ensures that
all other securityLabels are identical to the first one encountered."
34) Sec 3.3.1: Please add as last sentence: "If the receiving agent does
not recognize the securityLabel security-policy-identifier value, then it
should stop processing the message and indicate an error."
35) Sec 4.1, intro, 2nd para: Please add as last sent: "Only one
MLExpansionHistory attribute can be included in the authenticatedAttributes
of a SignerInfo."
36) Sec 4.1, intro: Please add as 3rd para: "The syntax allows a single
SignedData object to include multiple SignerInfos each of which could
include an ML Expansion History attribute. For example, if an MLA needs to
relay a message to a ML composed of RSA-only and DSA-only users. The MLA
can include one SignerInfo that includes an RSA signature value and a
MLExpansionHistory attribute. The same SignedData object could include
another SignerInfo that includes a DSA signature value and a
MLExpansionHistory attribute. In this example, the RSA-capable ML
recipients would process the MLExpansionHistory attribute in the RSA-signed
signerInfo and the DSA-capable ML recipients would process the
MLExpansionHistory attribute in the DSA-signed signerInfo. This is true
because a recipient should only process a MLExpansionHistory attribute if
the recipient can verify the signature of the SignerInfo which covers the
attribute. A recipient should not use an MLExpansionHistory attribute which
the recipient can't authenticate.
When constructing the outer SignedData object, the MLA MUST follow these rules:
1) All MLExpansionHistory attributes included in a SignedData object must be
identical.
2) There can't be multiple SignerInfos containing the same
signatureAlgorithm that all include MLExpansionHistory attributes. In other
words, there can only be one MLExpansionHistory attribute per
signatureAlgorithm applied to the SignedData.
When receiving a message that includes an outer SignedData object, a
receiving agent that processes MLExpansionHistory attributes MUST process
the MLExpansionHistory attribute, if present, in each SignerInfo in the
SignedData object for which it verifies the signature. This may result in
the receiving agent processing multiple MLExpansionHistory attributes
included in a single SignedData object. Because all MLExpansionHistory
attributes must be identical, then the receiving application processes the
first MLExpansionHistory attribute that it encounters in a SignerInfo that
it can verify and then ensures that all other MLExpansionHistory attributes
are identical to the first one encountered."
37) Sec 4.2, 1rst para, last sent: Please change "signature of the
signedData" to "signature of the signerInfo".
38) Sec 4.2, 1rst para: Please add as 4th sent: "The MLA should continue
parsing the MIME-encapsulated message to determine if there is a security
label associated with an encapsulated SignedData object. This may include
decrypting an EnvelopedData object to determine if an encapsulated
SignedData object includes a securityLabel attribute."
39) Sec 4.2, intro: recommend deleting "or digestedData" because it is not
included in [CMS].
40) Sec 4.2.1, bullet 1: Please delete "record".
41) sec 4.2.1, bullet 3.3.1: Please change: "The MLA encapsulates the signed
data in a Si1gnedData layer, and adds an mlExpansionHistory attribute
containing the current ML expansion information as described in the "Mail
List Expansion" section." To "The MLA encapsulates the received signedData
object in an SignedData object, and adds an mlExpansionHistory attribute to
the outer SignedData object containing the current ML expansion information
as described in the "Mail List Expansion" section."
42) Sec 4.2.3: recommend deleting "digestedData" because it is not included
in [CMS].
43) Reference ACP120: Please change "21 May 97 Final Draft" to "28 Oct 97".
ACP120 has been finalized.
44) Reference MTSABS: Please move the following to sec 3.2, intro, 2nd sent:
"(The MTSAbstractService module begins with "DEFINITIONS IMPLICIT TAGS ::=".)"
45) Please add an ASN.1 module that consolidates all of the ASN.1 syntaxes
defined throughout the spec.
================================
John Pawling
jsp(_at_)jgvandyke(_dot_)com
J.G. Van Dyke & Associates, Inc.
================================