All,
IMHO, Paul has done a miraculous job of incorporating the group's comments
into ESS-04. I have the following comments regarding the 12 Mar 98 ESS-04 I-D:
1) Sec 1: Please change "[MSP]" to "[MSP4]".
2) Sec 1.2: I agree that the "|" characters delineate the encrypted data
correctly and that the accompanying footnote explains that the encrypted
data is encapsulated in an envelopedData block, but I believe that it is
extremely useful to see the "envelopedData block" text as part of the
"picture" to make it inherently obvious to even the most casual observer.
Please change the triple wrapped message example that uses multipart/signed
for both signatures as follows:
After [step 6] please add:
[step 5] envelopedData block )
[step 5] | )
3) Sec 1.2: Please change the triple wrapped message example that uses
multipart/signed for both signatures as follows:
OLD: [step 7] outer signedData block
NEW: [step 7] outer signedData block (eContent is missing)
4) Sec 1.2: Same logic as Comment 2, please change the triple wrapped
message example that uses application/pkcs7-mime for both signatures as
follows:
After [step 6] please add:
[step 5] envelopedData block ) O
[step 5] | ) O
5) Sec 1.3.4, Table: Please add "sMIMEEncryptionKeyPreference | id-TBD [MSG]
| either | yes". OID not yet assigned.
6) Sec 1.3.4, Table: Please add "signingCertificate | id-TBD [CMS] | either
| yes". OID not yet assigned.
7) Sec 2.3, 2nd para: Please make the following change:
OLD: "Because all receiptRequest attributes in a SignedData object must be
identical, the receiving application fully processes (as described in the
following paragraphs) the first receiptRequest that it encounters in a
SignerInfo that it can verify, and it then ensures that all other
receiptRequests are identical to the first one encountered. If
ReceiptRequests which conflict are present, then the processing software
MUST NOT return any receipt."
NEW: "Before processing a receiptRequest authenticatedAttribute, the
receiving agent MUST verify the signature of the SignerInfo which covers the
receiptRequest attribute. A recipient MUST NOT process a receiptRequest
attribute that has not been verified. Because all receiptRequest attributes
in a SignedData object must be identical, the receiving application fully
processes (as described in the following paragraphs) the first
receiptRequest attribute that it encounters in a SignerInfo that it
verifies, and it then ensures that all other receiptRequest attributes in
signerInfos that it verifies are identical to the first one encountered. If
verified ReceiptRequest attributes which conflict are present, then the
processing software MUST NOT return any signed receipt. A signed receipt
SHOULD be returned if any signerInfo containing a receiptRequest attribute
can be validated, even if other signerInfos containing the same
receiptRequest attribute cannot be validated because they are signed using
an algorithm not supported by the receiving agent."
8) Sec 2.3, 3rd para: Please delete the last sentence because it is now part
of the 2nd paragraph: "A receipt SHOULD be returned if any signature
containing a receipt request can be validated, even if other signatures
containing the same receipt request cannot be validated."
9) Sec 3.1.2, Please add as 3rd para: (This text was included in ESS-03,
but was mistakenly deleted from ESS-04.)
"Receiving agents SHOULD have a local policy regarding whether or not to
show the inner content of a signedData object that includes an
eSSSecurityLabel security-policy-identifier that the processing software
does not recognize. If the receiving agent does not recognize the
eSSSecurityLabel security-policy-identifier value, then it SHOULD stop
processing the message and indicate an error."
10) Sec 3.2 and App A: Please define "v1" and "v2" referred to in
ESSSecurityLabel and ESSPrivacyMark syntaxes. Recommend the following:
v1 INTEGER ::= 1
v2 INTEGER ::= 2
11) Sec 4.1, 5th para: Please make the following change:
OLD: "A recipient SHOULD only process an 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 cannot authenticate."
NEW: "A recipient MUST verify the signature of the SignerInfo which covers
an mlExpansionHistory attribute before processing it. A recipient MUST NOT
process an mlExpansionHistory attribute which the recipient cannot
authenticate."
12) Sec 4.1, last para, last sent: Please change:
OLD: "and then ensures that all other mlExpansionHistory attributes are
identical to the first one encountered."
NEW: "and then ensures that all other mlExpansionHistory attributes in
signerInfos that it verifies are identical to the first one encountered. If
the mlExpansionHistory attributes in the signerInfos that it verifies are
not all identical, then the receiving agent MUST stop processing the message
and MUST notify the user or MLA administrator of this error condition."
================================
John Pawling
jsp(_at_)jgvandyke(_dot_)com
J.G. Van Dyke & Associates, Inc.
================================