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

From: "Turner, Sean P." <[email-masked]>
Date: Tue, 3 Jun 2008 15:41:54 -0400

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

---

From: Blake Ramsdell <[email-masked]>
Date: Tue, 3 Jun 2008 15:20:13 -0700

> we should stay aligned with CMS/PKIX - curious what others think.

Either UTCTime or GeneralizedTime needs to be a MUST in order for
implementations to be compatible with each other. Have the historical
problems with UTCTime (now that we're almost nine years into the 2000's)
been that much of an issue?

The migration to GeneralizedTime is already in place. We have addressed
the expressed concern of the two digit ambiguity already. I think it's
fine as is.

Blake