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

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

Alfred,

Thanks again for the review. Responses inline. In the version I'm about to
post I haven't addressed comment (0) or (29).

All,

Curious what others feel about (0) and (29).

spt

>-----Original Message-----
>(0)  Front Matter / Standards Actions
>
>The draft already indicates in its front matter:
>  Obsoletes: 3851
>
>During supporting investigations, it became clear that, due to 
>specific circumstances, this will let us end up with two "valid"
>sets of S/MIME specifications -- those for S/MIME v3.2  and 
>those for S/MIME v2  !
>
>The historic reason for this scenario seems to be buried in 
>the S/MIME v2 specifications being published as Informational 
>RFCs and not expressly being Obsoleted by the S/MIME v3 RFCs.
>
>In Section 1.3, this draft lists RFCs 2311 through 2315 as the 
>documents originally specifying S/MIME v2.  In the RFC index, 
>the entries for all these RFCs list INFORMATIONAL status,
>  -  RFC 2313 is tagged (Obsoleted by RFC2437),
>  -  RFC 2314 is tagged (Obsoleted by RFC2986), but
>  -  RFCs 2311, 2312, and 2315 look like being current.
>
>Arguably, it would be a matter of CMS to take action for RFC 
>2315, but at least RFC 2311 and RFC 2312 are clearly within 
>scope of the S/MIME v3.2 drafts.
>
>I suggest to take the opportunity to clean up the RFC metadata 
>and either:
>
>  - also formally Obsolete the S/MIME v2 RFCs with the publication
>    of the corresponding intended S/MIME v3.2 RFCs,
>    (i.e. add RFC 2311 to the Obsoletes list of this draft,
>    add RFC 2312 to the Obsoletes list of [CERT32], and
>    defer action for RFC 2315 to CMS), or
>
>  - to explicitely declare the S/MIME v2 RFCs as Historic in one place.

We should address this one coment (0) and (25) togther seperately.

>(14)  Section 2.5.3.1
>
>The second bullet there says:
>
>    - If an SMIMEEncryptionKeyPreference attribute is not found in a
>      SignedData object received from the desired recipient, the set of
>      X.509 certificates SHOULD be searched for a X.509 certificate
>|     with the same subject name as the signing of a X.509 certificate
>                                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>|     which can be used for key management.
>      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
>I really do not understand precisely what the last two lines 
>want to say.  Please clean up and clarify.
>
>
>(15)  Section 2.7.1.2
>
>The visible paragraph structure there is broken; the section 
>looks like:
>
>   If the following two conditions are met:
>
>    - ...
>
>    - ...
>
>   [[end of section]]
>
>More closely looking at the text, it turns out that 
>fortunately the situation can be cured by inserting a 
>paragraph break in the second bullet.  For grammatical 
>consistency, also the initial capitalization of the bullets 
>should be changed.
>
>Thus, the section should be changed to:
>
>   If the following two conditions are met:
>
>    - the sending agent has no knowledge of the encryption capabilities
>      of the recipient; and,
>
>    - the sending agent has no knowledge of the version of 
>S/MIME of the
>      recipient,
>
>   then the sending agent SHOULD use AES 128 because it is a stronger
>   algorithm and is required by S/MIME v3.2.  If the sending agent
>   chooses not to use AES 128 in this step, it SHOULD use tripleDES.
>
>Additionally, the punctuation at the end of the first bullet now could
>be easily simplified:    s/; and,/, and/

Accepted

>(16)  Section 3.1 ff. -- terminological issues
>
>Being a designated Standards Track document, the draft should 
>precisely use established IETF terminology and not 
>occasionally fall back to common, yet sluggish (ab)use of the 
>terms regarding the Internet message structure.
>
>Section 3.1.1 of RFC 4249 summarizes the terms established in 
>the Internet Mail and MIME RFCs, which I will explain again in my own
>words:
>
>  - at each conceptual protocol layer, a protocol data unit is
>    comprised of a header and a payload (i.e., the "body" in textual
>    protocols like email), and sometimes a trailer, as well;
>
>  - the header within a protocol layer is comprised of header fields.
>
>  Thus, each Internet (email) message has a single message header
>  (Section 2.1 of I-D.2822-upd now even uses the term "message header
>  section").
>  In a structured MIME message body, each nesting level has a single
>  "MIME header", "MIME entity header", or "MIME part header" of its
>  own (cf. RFC 2045).
>  (We are not interested in lower level details, like MIME prologue
>  and epilogue, etc., for the purpose of this draft.)
>
>  Each message header or MIME header is comprised of header fields,
>  with in turn consist of a field name, the colon separator, and a
>  field value.
>
>  At the MIME top level, the MIME-related header fields are
>  integrated in the RFC[2]822 message header; they sometimes
>  collectively are denoted as the "MIME message header".
>
>Furthermore, as explained in BCP 13, RFC 4288, the IETF should 
>not use the popular term "MIME type", in favor of "media type".
>The former had not even been defined in [MIME-SPEC], and it 
>has become even more misleading with the spread of other 
>protocols making use of these media types.
>
>I strongly recommend to update the draft to always use this 
>precise terminology.
>
>As a side-show, I also recommend consistently using the same 
>spelling and capitalization for header field names -- 
>preferably the spelling and case used in the original document 
>defining the header field --, e.g., replace "content type" and 
>"Content type" by "Content-Type".
>
>Because there are some subtle cases, I try to address most 
>affected instances of these issues I found in the draft text 
>in detail below.

Agree

>(17)  Section 3.1 -- details
>
>(17a)  1st paragraph
>
>Applying the rationale of (16), I suggest to change  (also 
>deleting the repeated second "used" near the end of the third 
>sentence, to streamline the language a bit):
>
>   S/MIME is used to secure MIME entities.  A MIME entity can be a sub-
>   part, sub-parts of a message, or the whole message with all its sub-
>   parts.  A MIME entity that is the whole message includes only the
>|  MIME headers and MIME body, and does not include the 
>RFC-822 headers.
>       ^      ^                                             vvvvvv    ^
>|  Note that S/MIME can also be used to secure MIME entities used in
>   applications other than Internet mail.  If protection of the RFC-822
>|  headers is required, the use of the message/rfc822 MIME type is
>   explained later in this section.
>---                                                   ^^^^
>   S/MIME is used to secure MIME entities.  A MIME entity can be a sub-
>   part, sub-parts of a message, or the whole message with all its sub-
>   parts.  A MIME entity that is the whole message includes only the
>|  MIME message headers and MIME body, and does not include 
>the RFC-822  
>| header.  Note that S/MIME can also be used to secure MIME entities in
>   applications other than Internet mail.  If protection of the RFC-822
>|  header is required, the use of the message/rfc822 media type is
>   explained later in this section.

Accepted

>(17b)  1st paragraph below 'Step 3.'
>
>Please remove the comma after "where" -- or put it in front of 
>that "where".

Deleted the comma

>(17c)  2nd paragraph below 'Step 3.'
>
>Correcting a typo and applying (16), I suggest to change:
>
>|  In order to protect outer, non-content related message headers (for
>  v                                           v           ^^^^^^^
>|  nstance, the "Subject", "To", "From" and "CC" fields), the sending
>   client MAY wrap a full MIME message in a message/rfc822 wrapper in
>|  order to apply S/MIME security services to these headers.  It is up
>                                                    ^^^^^^^
>|  to the receiving client to decide how to present these "inner"
>                                                    ^^^^^
>|  headers along with the unprotected "outer" headers.
>---      ^                                          ^
>|  In order to protect outer, non-content related message 
>header fields  
>| (for instance, the "Subject", "To", "From" and "Cc" fields), the
>   sending client MAY wrap a full MIME message in a message/rfc822
>|  wrapper in order to apply S/MIME security services to these header  
>| fields.  It is up to the receiving client to decide how to present  
>| this "inner" header along with the unprotected "outer" header.

Accepted 

>(18)  Section 3.1.1, 2nd paragraph
>
>According to (16), please   s/MIME type/media type/   (2x).

I only found one.

>(19)  Section 3.1.2
>
>According to (16):
>
>                  [...]  If no Content-Transfer-Encoding header is
>   present, the transfer encoding is presumed to be 7BIT.
>---                                                            vvvvvv
>|                 [...]  If no Content-Transfer-Encoding 
>header field is
>   present, the transfer encoding is presumed to be 7BIT.

Accepted

>(20)  Section 3.1.4
>
>The legacy example of BITNET seems to be rather aged and of 
>very low interest -- if any;  cf. http://en.wikipedia.org/wiki/BITNET .
>
>I therefore suggest to simply delete  " (like BITNET)"

While aged it is part of an example so I think we can leave it.

>(21)  Section 3.2
>
>(21a)  section title
>
>For added precision and consistency, I suggest to add "Media"
>in front of "Type"  -- cf. 3.4.3.1, discussed in (2x) below:
>
>  3.2. The application/pkcs7-mime Type
>---
>  3.2. The application/pkcs7-mime Media Type

Accepted

>(21b) 3rd paragraph
>
>According to (16), please   s/MIME type/media type/   (1x).
>
>(21c) last paragraph
>
>For added precision, and with respect to (16), the last 
>sentence should be amended:
>
>|                                     [...].  The MIME headers of all
>   application/pkcs7-mime objects SHOULD include the optional "smime-
>   type" parameter, as described in the following sections.
>---
>|                                     [...].  The Content-Type header  
>| field of all application/pkcs7-mime objects SHOULD include the
>   optional "smime-type" parameter, as described in the following
>   sections.

Accepted

>(22)  Section 3.2.1, last paragraph
>
>According to (16), please   s/MIME type/media type/     (1x), and
>                           s/MIME types/media types/   (1x).

Fixed

>(23)  Section 3.2.2, last numbered bullet
>
>Please correct punctuation and case:
>                                        vvvv
>|     3. If no common string is assigned.  Then the common string of
>      "OID.<oid>" is recommended (for example, "OID.1.3.6.1.5.5.7.6.1"
>      would be DES40).
>---                                     vvv
>|     3. If no common string is assigned, then the common string of
>      "OID.<oid>" is recommended (for example, "OID.1.3.6.1.5.5.7.6.1"
>      would be DES40).

Accepted

>(24)  Section 3.4.3
>
>According to (16), please   s/MIME type/media type/   (2x).

Fixed

>(25)  Section 3.4.3.1
>
>(25a)  section title
>
>With respect to (16) please change:
>
>  3.4.3.1. The application/pkcs7-signature MIME Type
>---
>  3.4.3.1. The application/pkcs7-signature Media Type
>                                           ^^^^^
>
>(25b)  1st paragraph
>
>According to (16), please   s/MIME type/media type/   (1x).

Accepted

>(26)   Section 3.4.3.2
>
>(26a)  1st paragraph below 'Step 5'
>
>Please adjust:
>                               vv
>|  The multipart/signed Content type has two required parameters: the
>   protocol parameter and the micalg parameter.
>---                            vv
>|  The multipart/signed Content-Type has two required parameters: the
>   protocol parameter and the micalg parameter.

Accepted

>(26b)  last paragraph:
>
>The draft says:
>
>|  The SHA-224 algorithm [SHA224] and SHA-384 and SHA-512 algorithms
>   [FIPS180-3] are not currently recommended in S/MIME, and 
>are included
>   here for completeness.
>
>There's an apparent disparity.  SHA-224 is also covered by 
>FIPS 180-3, and SHA-384 as well as SHA-512 are also covered by 
>RFC 4634 not even listed as a Reference.  Perhaps this has 
>historical reasonse related to the delayed introduction of 
>SHA-224 via a Change Notice to FIPS 180-2.
>
>Since the requirements statement is "not recommended", adding 
>a bulk of references might be overkill; the basic Ref. should suffice.
>Thus, I suggest to drop [SHA224] and simplify the language:
>
>|  The SHA-224, SHA-384, and SHA-512 algorithms [FIPS180-3] are not
>   currently recommended in S/MIME, and are included here for
>   completeness.

Accepted and I deleted the [SHA224] reference

>(27)  Setcion 3.9
>
>(27a)  2nd paragraph
>
>According to (16), please change:
>
>   The file suffix in the table below comes from the "name" 
>parameter in
>|  the content-type header, or the "filename" parameter on the content-
>   v   ^       ^    vv   ^^                                    ^
>|  disposition header.  These parameters that give the file suffix are
>   not listed below as part of the parameter section.
>---
>   The file suffix in the table below comes from the "name" 
>parameter in
>|  the Content-Type header field, or the "filename" parameter on the  
>| Content-Disposition header field.  These parameters that give the
>   file suffix are not listed below as part of the parameter section.

Accepted

>(27b)  table
>
>According to (16), please   s/MIME type/media type/   (3x).

Accepted

>(28)  Section 4.1
>
>The draft says:
>
>   All generated key pairs MUST be generated from a good source of non-
>   deterministic random input [RANDOM] and the private key MUST be
>   protected in a secure fashion.
>
>IMO, this 'MUST' requirement constitutes a *Normative* 
>Reference; so please promote '[RANDOM]' to Normative, moving 
>the entry from
>B.2 to B.1.

Agreed

>(29)  Section 5
>
>Independent on the decision to be made regarding (0) above, 
>this section needs to be amended.
>
>(29a)  Scenario 1:  RFC 2311 *not* Obsoleted / made HISTORIC
>
>In this case, IANA should at least be directed to update the 
>media type registrations for
>
>      "application/pkcs7-mime"
>and
>      "application/pkcs7-signature"
>
>by adding an additional reference to [RFCTHIS], in order to 
>point the reader to the most current update of the media type 
>information.
>
>On the other hand, updating an old media type's information 
>arguably could require updating the registration entirely, 
>using the new registration template from BCP 13, RFC 4288.
>
>I leave it to the high priests of exegesis (or lawyers) to 
>figure out whether RFC 4288 in fact even normatively requests to do so.
>
>(29b)  Scenario 2:  RFC 2311 beinf Obsoleted or made HISTORIC
>
>In this case, the draft should substantially be amended with 
>the two new media type registration templates, filled for both 
>media types, "application/pkcs7-mime" and 
>"application/pkcs7-signature", and IANA should be directed to 
>update the registrations to incorporate this new information.

Address this with (0).

>(30)  Section 6, 7th paragraph
>
>I suggest to make the statement on key size more specific 
>(again, to not interfere with the future addition of other 
>signing algorithms having other key size requirements), and to 
>correct the placement of hyphens, as follows:
>
>   Some S/MIME agents created in the United States have chosen 
>to create
>|  512 bit keys in order to get more advantageous export licenses.
>|  However, 512 bit keys are considered by many to be cryptographically
>   insecure.
>---
>   Some S/MIME agents created in the United States have chosen 
>to create
>|  512-bit RSA keys in order to get more advantageous export licenses.
>      ^   ^^^^ v   vvvv
>|  However, 512-bit RSA keys are considered by many to be
>   cryptographically insecure.

This paragraph got overtaken by events.

>(31)  Appendix A
>
>(31a)  general
>
>At first glance, it comes to surprise that there's a "~~V3dot1"
>ASN.1 module.
>
>For clarity, I suggest adding an introductory statement 
>indicating that this module has been taken essentially 
>unchanged from RFC 3851 and still applies to S/MIME v3.2.

Since there are no changes listed in Section 1.6 it would be clear but I
added the NOTE anyway and the corresponding informative reference to MSG3.1.

>(31b)  ASN.1 comment below id-cap OID definition
>
>I suggest to improve the language a bit, by inserting "OID":
>
>   -- The preferBinaryInside indicates an ability to receive messages
>   -- with binary encoding inside the CMS wrapper
>---                         vvvvv
>   -- The preferBinaryInside OID indicates an ability to receive
>   -- messages with binary encoding inside the CMS wrapper.

Accepted

>(32)   Appendix B
>
>[ Interestingly, the last item for v3.2 happens to be #32  :-) ]
>
>(32a)  section numbering
>
>The RFC Editor prefers References as a numbered section, not 
>as an Appendix.  Therefore, I suggest to shuffle the 
>Appendices and turn this one into Section 7.

I guess I'm going to leave this one alone like I did in 3850bis.

>(32b)  B.1, [FIPS180-3]       { oooops }
>                             vvvvvvvvvvv
>   [FIPS180-3]   "Secure Hash Signature Standard (SHS)", National
>                 Institute of Standards and Technology (NIST).  FIPS
>                 Publication 180-3.
>---
>|  [FIPS180-3]   "Secure Hash Standard (SHS)", National Institute of
>                 Standards and Technology (NIST), FIPS Publication
>|                180-3, June 2007.
>                      ^^^^^^^^^^^
>or better, listing the source first (as also done for ITU-T documents):
>
>|  [FIPS180-3]   National Institute of Standards and Technology (NIST),
>|                "Secure Hash Standard (SHS)", FIPS Publication 180-3,
>|                June 2007.

Fixed

>(32c)  B.2, [RANDOM]
>
>Please add    "BCP 106, "  in front of "RFC 4086".
>regarding eventual promotion to Normative, please see item (28) above.

Fixed

---

From: "Turner, Sean P." <[email-masked]>
Date: Wed, 18 Jun 2008 10:50:25 -0400

For (0), it seems like it might be easiest to add an appendix that says v3.2
is backwards compatible (with the exception of some algorithms) to 2311/2312
and ask that 2311/2312 be moved to Historic.  I'll move the references to
numbered sections and put the "move to historic" text in App B in 3851bis
and App A in 3850bis.

For (29), I'll modify Section 5 to register application/pkcs7-mime and
application/pkcs7-signature with some boiler plate that says we're just
updating the pointers in the IANA registry.

I'll post a new version of both IDs before the end of the week.

spt

>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Turner, Sean P.
>Sent: Tuesday, June 03, 2008 3:42 PM
>To: [email-masked]
>Subject: RE: draft-ietf-smime-3851bis-02 (notes, part 2)
>
>
>Alfred,
>
>Thanks again for the review. Responses inline. In the version 
>I'm about to post I haven't addressed comment (0) or (29).
>
>All,
>
>>During supporting investigations, it became clear that, due 
>to specific 
>>circumstances, this will let us end up with two "valid"
>>sets of S/MIME specifications -- those for S/MIME v3.2  and those for 
>>S/MIME v2  !
>>
>the S/MIME 
>>v2 specifications being published as Informational RFCs and not 
>>expressly being Obsoleted by the S/MIME v3 RFCs.
>>
>>documents originally specifying S/MIME v2.  In the RFC index, the 
>>entries for all these RFCs list INFORMATIONAL status,
>2315, but 
>>at least RFC 2311 and RFC 2312 are clearly within scope of the S/MIME 
>>v3.2 drafts.
>>
>>I suggest to take the opportunity to clean up the RFC metadata and 
>>either:
>>

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 18 Jun 2008 09:46:24 -0700

>numbered sections and put the "move to historic" text in App B in 3851bis

That works for me. But I would want to hear from others in the S/MIME 
greybeard crowd about moving v2 to historic. Are there 
implementations of v2 that are that way for a good reason?