Re: WG Last Call: draft-ietf-smime-rfc2633bis-03.txt

I have a few comments on draft-ietf-smime-rfc2633bis-03.txt.   My comments 
are divided into technical and editorial.  In my opinion, the technical 
comments ought to be resolved before the document is forwarded to the IESG.

TECHNICAL COMMENTS

Section 1.1, 4th paragraph.  Change "... an S/MIME agent has to follow ..." 
to "... an S/MIME agent MUST follow ... ."  I realize that this MUST 
statement will appear before section 1.2, but I do not see any other MUST 
statements that capture this point.  Alternatively, insert an appropriate 
MUST statement elsewhere in the document.
Section 2.4.  CompressedData needs to be added to the list of content types 
that are supported.  Also, section 2.4.4 should be added to discuss the 
content type.
Section 2.5, 2nd paragraph.  CMS requires the inclusion of the contentType 
and messageDigest signed attributes if any other signed attributes are 
present.  We should include these in the bulleted list.
Section 2.5, last paragraph.  How do mail list agents fit into this 
requirement to "display those attributes to the user?"  Such devices 
certainly do not have a user interface, but they must include 
mlExpansionHistory.
Section 2.5.2, 6th paragraph.  Please reword: "The OIDs used with S/MIME 
are assigned in several different RFCs; however, all OIDs associated with 
the MUST and SHOULD implement algorithms are included in Appendix A of this 
document."
Section 3.4.3.2, micalg table.  Please add SHA-256, SHA-384, and SHA-512 to 
avoid the need for future updates.  A reference to FIPS 180-2 will be needed.
Section 3.8, last paragraph.  Please reword as follows: "S/MIME v2 
[SMIMEV2] specified a method for "registering" public keys with certificate 
authorities using an application/pkcs10 body part.  Since that time, the 
IETF PKIX Working Group has developed other methods for requesting 
certificates.  However, S/MIME v3.1 does not require a particular 
certificate request mechanism."

EDITORIAL COMMENTS

General.  Please change "CMS objects" to "CMS content types"  throughout 
the specification.
Section 1.1, 2nd paragraph.  Remove the extra space from 
"application/pkcs7- mime."
Section 1.3.  Please add references for X.208, X.209, and X.509, including 
the date of the version that is being referenced.  I suspect that the same 
ones that are used in [CMS] should be referenced.
Section 2.5.  Please reword the 3rd paragraph, as follows: "Further, 
receiving agents SHOULD be able to handle zero or one instance in the 
signingCertificate signed attribute, as defined in section 5 of [ESS]."
Section 2.5.2, 3rd paragraph.  Change "OIDs" to "object identifiers (OIDs)."

Section 2.6.  This paragraph should talk about S/MIME v3.1 as well as 
S/MIME v3.
Section 2.7.1.2.  Change the first part of the first sentence to: "If the 
following three conditions are met:"
Section 2.7.1.3.  Change the first part of the first sentence to: "If the 
following two conditions are met:"
Section 3, 1st paragraph.  Please change "CMS objects" to "CMS content 
types."  This is used several places.
Section 3.1, 1st paragraph.  Add a forward pointer to the processing that 
is used when RFC 822 headers need protection.
Section 3.1.3, 1st paragraph.  The word "EVER" does not have a reserved 
meaning in RFC 2119.  Please change it to lower case.
Section 3.2, 1st paragraph.  Remove the extra space from 
"application/pkcs7- mime type."
Section 3.2.2, 1st paragraph.  Remove the extra space from "smime- types."

Section 3.2,2, 3rd paragraph.  Remove the extra space from "encrypted- *."

Section 3.6, 1st paragraph.  Please reword as: "The signed-only, 
encrypted-only, and compressed-only MIME formats can be nested. This works 
because these formats are all MIME entities that encapsulate other MIME 
entities."
Section 3.9, 1st paragraph, last sentence.  Please reword as follows: "A 
message is considered an S/MIME message if it matches any of the criteria 
listed below."

Russ