John,
Some odd ball comments on your mail. I have not looked carefully at the new
draft, but conversations with Blake have told me that my comments have not
yet been incorperated so I don't know its really worth my time for another
detailed review.
5) Sec 2.5.2: Jim Schaad commented (There was debate regarding this comment,
but I don't remember the answer. Russ, I believe that you had the answer.
Can you please provide it.)
"Section 2.5.2 This is a politics question and one I am not capable of
deciding. Do we need to change from using the IMC as the registration agent
for the OIDs of SMIMECapabilites? I don't see any techincal reasons to
change this at this point in time. I don't see IMC as disappearing any time
soon and from what I hear it would be much faster to get updates than using
IANA. But I don't know if the IESG will be willing to leave this as it is."
[Jim Schaad: This should remain as it is in the original. Russ is the
authority for assigning OIDs in the S/MIME arc and IMC is just acting as a
publishing agent. No problems here]
12) Sec 3, first para: Please add as last sentences: "The Enhanced Security
Services for S/MIME [ESS] document provides examples of how nested, secured
S/MIME messages are formatted. For example, there is an example of how a
triple-wrapped S/MIME message is formatted using multipart/signed and
application/pkcs7-mime for the signatures."
[Jim Schaad: Lets change this slightly. "For example, there is an example"
should be "ESS provides an example...".]
13) Sec 3.2, 2nd para: Please make the following change:
OLD: "The contentInfo field of the carried CMS object always contains a MIME
entity that is prepared as described in section 3.1. The contentInfo field
must never be empty."
NEW: "The carried CMS object always contains a MIME entity that is prepared
as described in section 3.1. Also, see Section 2.4.1 for instructions on
including the id-data OID and MIME entity in the CMS objects."
[Jim Schaad: This is no longer as true of a statement. Unless we are
prepared to say that we are going to use a different mime type for items
such as SignedData/Receipts. I don't know that this should change or just
be a gotta to future implementors.]
25) Sec 4, 1rst para, last sent:
OLD: "S/MIME certification issues are covered in a different document."
NEW: "S/MIME certification issues are covered in the "S/MIME Version 3
Certificate Handling [CERT3]" document."
[Jim Schaad] Don't put in the name here just the [CERT3] reference. This
appears to be the standard method we are using in these docs. "covered in
the [CERT3] document."
30) App D: Recommend deleting Appendix D because it is out of date and is
not needed, IMHO.
[Jim Schaad: I agree -- we don't need to do this since the history of RFCs
is now present. However intro sections MUST say that this document
obsoletes [SMIME2].]