[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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,
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