All,
I agree with all of Jim's comments except that I have a few comments
regarding his comments:
At 06:40 PM 2/25/98 -0800, Jim Schaad (Exchange) wrote:
1. Section 1 pargraph #2: Since as time goes by it becomes harder for
me to understand what sections of this document require SMIME3 and what
can be implemented using SMIME2, I would like to be explicit here.
Replace with the following paragraph: "The services described here are
extensions to S/MIME version 2 [SMIME2] and S/MIME version 3 [SMIME3].
The Security Label and Mail List Agent services can be added to S/MIME
version 2, but the Secure Reciepts service requires [CMS] and can only
be added to S/MIME version 3." then contue with the last sentence.
[JSP: Why do you think that signed receipts can't be added to an S/MIME v2
product? It seems like support for the receiptRequest attribute could be
added. Similarly, the S/MIME v2 product could be enhanced to support the
Receipt content. I understand that these are noon-trivial enhancements, but
I don't see why they couldn't be implemented.]
5. Section 2.10 -- Please insert a section describing the
msgDigestAttribute here:
2.10 Message Digest Attribute
This attribute is used only in a Secure Receipt authenticated attributes
section. It contains the message digest of the SignedData object for
which a receipt is being created. Only one msgDigestAttribute can
appear in an authenteicated attributes set.
ASN goes here...\
[JSP: Did you mean "Message Signature Digest". If so, then I recommend the
following re-wording of your proposed para:
"2.10 Message Signature Digest Attribute
This attribute can only be used in the authenticated attributes of a signed
receipt. It contains the digest of the ASN.1 DER encoded
authenticatedAttributes included in the original signedData that requested
the signed receipt. Only one msgSigDigest attribute can appear in an
authenticated attributes set. Section 2 provides more details regarding the
use of the msgSigDigest authenticated attribute. It is defined as follows:
msgSigDigest ::= OCTET STRING."]
9. Section 4.1, paragraph 5. Please as the following sentence. "An
MLA SHOULD NOT expand and redistribute a message if it cannot validate
one or more outer signatures."
[JSP: I respectfully disagree with this comment. A user could send a
double-wrapped message (i.e. envelopedData encapsulating signedData) to an
MLA in which there is not an outer signedData. Furthermore, a user may send
a single-wrapped signedData or envelopedData message to an MLA in which
there is not an outer signedData.]
10. Section 4.2.1, Bullet 2.
This is along the lines of a question, Should the new RecipientInfos be
unioned with the existing set or replaced. There are no security
reasons why it cannot be replacement but this seems odd to me.
[JSP: The MLA deletes the existing recipientInfos and builds a new
recipientInfo for each member of the ML. The recipientInfos in the original
message are not needed in the MLA-expanded message because those users can
decrypt the original message. For example, user 1 sends a message
containing recipientInfos for: ML1, Tom and Dick. ML1, Tom and Dick each
receive their copy of the message and decrypt it using their copy of
recipientInfo. The MLA representing ML1 will expand the copy of the message
that it received. The recipientInfos for ML1, Tom and Dick are not required
in the MLA-expanded message, because the message is not being sent to ML1,
Tom and Dick. It is being sent to the ML recipients.]
13. Section 1.4 and Appendix A. We should not be refering to the imc
URL for the oids anymore or saying we intend to move to IANA to keep the
registry. Recommend deletion of section 1.4 and the inclusion of the
OIDs used by this draft in Appendix A.
[JSP: Why can't we refer to the S/MIME OIDs document? It includes an ASN.1
module that includes all of the OIDs. The ESS and CMS modules can immport
this module.]