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

From: Alfred H�nes <[email-masked]>
Date: Tue, 20 May 2008 16:21:47 +0200 (MESZ)

Hello all,
here we go with the second (and last) part of my review for
     draft-ietf-smime-3851bis-02 .

For ease of reference, the item enumeration below extends
the list from part 1 (posted yesterday).

(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.

(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/

(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.

(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.

(17b)  1st paragraph below 'Step 3.'

Please remove the comma after "where" -- or put it in front of that
"where".

(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.

(18)  Section 3.1.1, 2nd paragraph

According to (16), please   s/MIME type/media type/   (2x).

(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.

(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)"

(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

(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.

(22)  Section 3.2.1, last paragraph

According to (16), please   s/MIME type/media type/     (1x), and
                           s/MIME types/media types/   (1x).

(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).

(24)  Section 3.4.3

According to (16), please   s/MIME type/media type/   (2x).

(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).

(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.

(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.

(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.

(27b)  table

According to (16), please   s/MIME type/media type/   (3x).

(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.

(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.

(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.

(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.

(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.

(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.

(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.

(32c)  B.2, [RANDOM]

Please add    "BCP 106, "  in front of "RFC 4086".
regarding eventual promotion to Normative, please see item (28) above.

Kind regards,
  Alfred HÎnes.

--

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+

----- End of forwarded message from Alfred HÎnes -----