John,
From: jsp(_at_)jgvandyke(_dot_)com [mailto:jsp(_at_)jgvandyke(_dot_)com]
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.]
[Jim Schaad: The problem here is that the way you do signing of non-data
content has changed from PKCS#7 to CMS (direct DER encode to wrapping in
Octet string). This means that the receipts generated from one client
could not be read by another client. This is a large enough change that
I think we should cut off this line of implementation up front.\
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."]
[Jim Schaad: This looks good, except that I question the reference to
section 2. This is already in section 2 so the reference does not make
sense. Propose we accept the above with the deletion of sentence
starting "Section 2 ...".]
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.]
[Jim Schaad: Would the following sentence be more acceptable. "If an
MLA finds a message with a SignerData object where one or more of of the
SignerInfo objects contain an mlExpansionHistory attribute, and the MLA
is unable to verify atleast one of these SignerInfo objects then the MLA
SHOULD NOT expand and redistribute the message."]
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.]
[Jim Schaad: Agreed.]
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.]
[Jim Schaad: That is find for the OIDS defined by CMS and S/MIME,
however I firmly believe that a document that defines the structures
referenced by an OID should also define the OID.]