RE: draft-ietf-smime-3851bis-02 (notes, part 1)

["Turner, Sean P." <[e-mail]>]

Alfred,

Thanks for the review. Responses inline.


All,

Alfred suggests demoting UTCTime to a SHOULD- in his last comment. I think
we should stay aligned with CMS/PKIX - curious what others think.

spt 

>-----Original Message-----
>(1)  Conventions used ...
>
>- The RFC Editor will want to make that a proper (numbered) section.
>  I suggest to move it to between the current sub-sections 1.1 and 1.2.

Fixed.

>- The comments I sent on the same part of draft-ietf-smime-3850bis-02
>  also apply.

Fixed.

>(2)  Section 1
>
>(2a)  1st paragraph
>
>For completeness (and matching of what is said in the 
>Abtract), I suggest to add a short note on message compression 
>to the end of the first paragraph of Section 1, for instance:
>
>   As a supplementary service, S/MIME provides for message compression.

Added the sentence.

>(2b)  2nd paragraph
>
>Perhaps the most important usage scenario for S/MIME now is 
>bound to SIP (using the 'sips' URIs) to protect the 
>negotioation of multimedia session parameters (cf. RFC 3261).
>Therefore, I suggest to replace in the second paragraph of 
>Section 1 the clause "such as HTTP" by "such as HTTP or SIP".

Added the SIP reference.

>(3)  General -- terminology
>
>It has been generally recognized that the media type concept 
>defined in [MIME-SPEC] has outgrown the narrow context of 
>MIME, and RFC 4288 (BCP 13) has confirmed that the popular 
>sluggish term "MIME Type"
>should not be used, in favor of the proper term "Media Type", 
>which already had been used throughout [MIME-SPEC].
>
>Therefore, I recommend to also change in this draft all 
>occurrences of "MIME type" to "media type" (inclusive of the 
>title of Section 3.4.3.1).
>
>Also, when refering to MIME header fields, their names should 
>be quoted faithfully for clarity and precision; in particular, 
>the hyphen should always be included after "Content", e.g.,
>  "Content type"  -->  "Content-type".

Agreed

>(4)  Section 1.1
>
>(4a)  1st paragraph
>
>The draft says:
>
>   This document describes a protocol for adding cryptographic 
>signature
>   and encryption services to MIME data.  The MIME standard [MIME-SPEC]
>|  provides a general structure for the content type of Internet  
>| messages and allows extensions for new content type applications.
>
>There are two issues with the use of "content type":
>
>-  "structure of the content type" is a slight abuse of language;
>   "structure of content" is the proper designation.

It does say "structure for the content type :) I changed it to ...structure
for the content of Internet messages...

>-  "content type applications" seems to be vague and unclear.
>   I suggest to use "content type specific applications" or
>   "content type based applications" instead

Choose the later

>(4b)  2ns and 3rd paragraph
>
>Please apply (3) -- 3 occurrences.

I did a search for MIME type and replaced them with media type

>(5)  Section 1.3
>
>For clarity, please add another comma after the first instance 
>of "inclusive", or place this word in parentheses.

I tweaked it a bit but I think it's fixed now.

>(6)  Section 1.4
>
>(6a)  section title
>
>The legacy section title obviously is outdated, turning it ambiguous.
>It should better be changed:
>
>  1.4. Changes Since S/MIME v3
>---
>| 1.4. Changes From S/MIME v3 to S/MIME v3.1
>
>This should properly complement the correctly entitled new section,
>
>  1.5. Changes Since S/MIME v3.1

Fixed

>(6b)  last two paragraphs
>
>Please apply (3) -- two occurrences.

Fixed

>(7)  Section 1.5 -- typo
>
>Please replace "in parantheticals"  by either "parenthetical" 
>or "in parenthesis".

I deleted "in parantheticals" - it wasn't needed.

>(7)  Section 1.5 -- typo
>
>Please replace
>                     vv    v
>           "AES-CBC" in parantheticals.
>by either:
>           parenthetical "AES-CBC".
>or:
>           parenthetic "AES-CBC".
>or:
>           "AES-CBC" in parenthesis.

Accepted - I just removed the in parenthesis.

>(8)  Section 2 -- clarification of the role of [ESS]
>
>I suggest to add a note to the text in Section 2 clarifying 
>that RFC 2634 [ESS] is applicable for S/MIME v3.2 as well.
>
>This is intended to complement the remarks in Section 1.3 
>stating that RFC 2634 is part of the S/MIME v3 and S/MIME v3.1 
>specification.

ESS gets pulled in in section 2.5 when discussing attributes. I did add text
to address ESS in section 2.

>(9)  Section 2.3
>
>Please replace
>                using rsaEncryption algorithm.
>by either:
>                using the rsaEncryption algorithm.
>or:
>                using rsaEncryption.

Accepted

>(10)  Section 2.4.1
>
>The draft says:
>
>                vvvvvvvvvvvv
>        ... the MIME content MUST be stored in the SignedData
>    encapContentInfo eContent OCTET STRING ...
>
>This is misleading; the Content-Type has to be stored there, 
>not the "content".
>In line with (3) above, I suggest to use the phrase:
>
>               vvvvvvvvvvv
>|       ... the media type MUST be stored in the SignedData
>    encapContentInfo eContent OCTET STRING ...

Accepted

>(11)  Section 2.4.4, 1st paragraph
>
>I suggest to insert the article "the" giving "reduce the message size".

Accepted

>(12)  Section 2.5
>
>(12a)   1st paragraph
>
>The draft says, using redundant/replicated wording:
>
>                              vvvvvvvvvvvvv
>   The SignerInfo type allows the inclusion of unsigned and signed
>   attributes to be included along with a signature.
>              ^^^^^^^^^^^^^^
>I suggest to simplify the wording to:
>
>   The SignerInfo type allows the inclusion of unsigned and signed
>|  attributes along with a signature.
>             ^

Accepted

>(12b)  2nd-to-last paragraph
>
>The draft says:
>
>                    [..].  Receiving agents SHOULD handle attributes or
>   values that it does not recognize in a graceful manner.
>
>The wording "receiving agents ... it does not" should be improved upon.
>I suggest either to turn to singular:
>
>                           vv              vv
>|                   [..].  A Receiving agent SHOULD handle 
>attributes or
>   values that it does not recognize in a graceful manner.
>
>or substitute "they" in the last line:
>
>                    [..].  Receiving agents SHOULD handle attributes or
>|  values they do not recognize in a graceful manner.
>          ^^^^^^^

Accepted (used the 2nd one)

>(13)  Section 2.5.1
>
>The rules for UTCTime vs. GeneralizedTime are unfortunate for 
>several reasons, as I have pointed out in recent comments on 
>RFC 5280.  They violate the lessons learned during Y2K that
>4 decimal digits should *always* be encoded for year numbers, 
>and they cause general non-exercising of 'MUST implement'
>code, generating a new security risk.
>
>I strongly recommend to, at a minimum, demote the "MUST" to 
>encode signing-time through 2049 as UTCTime to a "MUST-", 
>preferably "SHOULD", to promote starting general migration to 
>GeneralizedTime.

I think we should stay aligned with CMS & PKIX on this.  But, I think we
should add that receiving agents must support both UTCTime and
GeneralizedTime.

spt