All,
IMHO, Paul has done a miraculous job of sifting through the millions of
e-mail messages regarding the last version of ESS to produce the 11/18/97
ESS. I have a few comments:
1) Sec 1.3.4, table: The implication of the table of attributes is that
"authentication is optional" for the counterSignature attribute. PKCS #9
states that the counterSignature attribute MUST NOT BE authenticated.
Please add the following text immediately after the table: "If a
counterSignature attribute is present, then it MUST BE included in the
unauthenticated attributes. It MUST NOT BE included in the authenticated
attributes."
2) Sec 2, intro, 1rst para: Please change: "Returning a signed receipt
provides proof of delivery to the originator of
a message and allows the originator to demonstrate to a third party that the
recipient received the message." to "Returning a signed receipt provides
proof of delivery to the originator of a message and allows the originator
to demonstrate to a third party that the recipient was able to verify the
signature of the original message."
3) Sec 2.2, intro para: Please add: "A ReceiptRequest attribute MUST NOT be
included in the attributes of a SignerInfo in a SignedData object that
encapsulates a Receipt content. In other words, the user agent MUST NOT
request a signed receipt for a signed receipt."
4) Sec 2.2, intro para: Please add: "A MLExpansionHistory attribute MUST NOT
be included in the attributes of a SignerInfo in a SignedData object that
encapsulates a Receipt content. This is true because when a
SignedData/Receipt is sent to an MLA for distribution, then the MLA must
always encapsulate the received SignedData/Receipt in an outer SignedData in
which the MLA will include the MLExpansionHistory attribute. The MLA MUST
NOT change the authenticatedAttributes of the received signedData/Receipt
object, so it can't add the MLExpansionHistory to the SignedData/Receipt."
5) 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 send a signed receipt for the message that requests a
signed receipt."
6) Sec 2.4, Receipt Creation: I believe that Section 2.4 should be changed
so that it includes hashing the authenticatedAttributes included in the
SignerInfo containing the receipt signature value included in the
SignedData/Receipt. This allows the recipient of a signedData/Receipt to
verify the authenticity of the authenticatedAttributes such as signingTime,
etc. If people agree with this recommendation then I will draft a new
section 2.4 that is similar to the CMS text for hashing either the content
or content with authenticatedAttributes.
7) Sec 2.6: Please replace "[More is needed here or in an appendix
detailing how to do this for each
kind of signature.]" with "Separate documents describe the
algorithm-specific details of the signature verification process for each
signature algorithm that is used in conjunction with the CMS protocol."
8) Sec 2.7, bullet 2: Please move "as described in the "Receipt Creation"
section." to the end of Sec 2.7, bullet 3.
9) Sec 4.2.2, bullet 3.3.1: Please replace: "The MLA encapsulates the
received signedData object in an SignedData object," with "The MLA
encapsulates the received signedData object in an outer SignedData object,".
Added the word "outer" to reinforce the fact that an outer SignedData
created by the MLA encapsulates an inner SignedData (created by the
originating user) that was received by the MLA.
10) Sec 4.2.2, flow chart: Please replace bullet 3.3 in the flow chart with:
"3.3. Encapsulate in a SignedData layer and add a mlExpansionHistory
attribute." The rest of the text is not needed because the only way to
reach this point in the flow chart is if the signed data was neither
SignedData nor EnvelopedData.
11) Appendix C, Open Issues: Agree that an ASN.1 module should be added
that collects all the ASN.1 from the whole document.
12) Appendix C, Open Issues: Recommend that the ASN.1 definitions included
in the text should not be changed. In other words, I believe that ESS
implementors can correctly interpret the inclusion of the two ASN.1:1994
types (BMPString and UniversalString) in the draft.
13) Appendix C, Open Issues: I am not sure what this means: "5: The
security considerations section needs to be fleshed out, including
discussions of what happens if receiving clients don't check things very
well." Does this imply that more error checking guidance needs to be added??
================================
John Pawling
jsp(_at_)jgvandyke(_dot_)com
J.G. Van Dyke & Associates, Inc.
================================