Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification
draft-ietf-lamps-rfc5751-bis-12

Thanks for addressing the discuss point; original ballot comments retained below.

I suspect it's too late for changing this to be a good idea, but
using "authenticated enveloped" and in the same breath talking about how it
does not provide proof of origination ("wait, isn't that authentication?),
but it does provide "a level of authentication", is kind of confusing for
the reader.  Could "integrity protection" be used to distinguish the AEAD
property from proof-of-origin authentication?

Similarly, it might be helpful to use the term "AEAD" before the security
considerations section.

Should the Abstract/Introduction mention that AEAD encryption provides non-malleability?

Section-by-Section comments follow.

Section 1

nit: Does FAX need to be all-caps?

Section 1.1

   In order to create S/MIME messages, an S/MIME agent MUST follow the
   specifications in this document, as well as the specifications listed
   in the Cryptographic Message Syntax document [CMS], [RFC3370],
   [RFC4056], [RFC3560], and [RFC5754].

nit: is that "[CMS] documents" plural?

I have been observing growing unease with Postel's Principle over time;
it's less clear that blindly repeating it is the best position to take.

Section 1.2

BER does not appear to be used in the body text?

Section 1.5

I recognize this is historical text, but to modern readers, there is not a
single "the AES symmetric encryption algorithm" -- there are CBC modes and
GCM modes, and v4.0 distinguishes between them.  Should this text get
clarified about the difference?

Section 2.5.2

   The OIDs that correspond to algorithms SHOULD use the same OID as the
   actual algorithm, except in the case where the algorithm usage is
   ambiguous from the OID.  For instance, in an earlier specification,
   rsaEncryption was ambiguous because it could refer to either a
   signature algorithm or a key encipherment algorithm.  In the event
   that an OID is ambiguous, it needs to be arbitrated by the maintainer
   of the registered SMIMECapabilities list as to which type of
   algorithm will use the OID, and a new OID MUST be allocated under the
   smimeCapabilities OID to satisfy the other use of the OID.

(nit?) "the other use" implies there will only ever be one other (two
total), which is perhaps needlessly limiting.

Section 2.7.2

With "Algorithms such as RC2"; "Algorithms such as TripleDES", I'm not sure
what to make of "such as" in these statements -- what are the attributes
that would qualify for sufficient similarity to match the "such as", other
than equality?

Section 3.1

   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.  It is
   RECOMMENDED that a distinction be made between the location of the
   header.

nit: I'm not sure this last sentence is grammatical.  Do we want "between
the locations", or "a visible distinction be made for the different
possible locations of the header", or something else?

Section 3.1.2

   In the case where S/MIME implementations can determine that all
   intended recipients are capable of handling inner (all but the
   outermost) binary MIME objects SHOULD use binary encoding as opposed
   to a 7-bit-safe transfer encoding for the inner entities.

nit: I think that some words got dropped in here; the sentence doesn't really
parse.  I guess there's a missing "implementations" in "implementations
SHOULD use"?

Section 3.3

   but not signed messages does not provide for data integrity.  The
   Enveloped-Only structure does not support authenticated symmetric
   algorithms, use the .Authenticated Enveloped structure for these
   algorithms.  [...]

nit: Is the '.' in ".Authenticated" correct?  (Also, that sentence looks like a
comma splice.)

Section 3.5.3.2

I agree with Adam that there should be some notation in the table
or adjacent to it that some algorithms are present only for historical
compatibility and should be considered deprecated/insecure/risky/whatever.

Section 6

   Some cryptographic algorithms such as RC2 offer little actual
   security over sending plaintext.  Other algorithms such as TripleDES,
   provide security but are no longer considered to be state of the art.
   S/MIME requires the use of current state of the art algorithms such
   as AES and provides the ability to announce starter cryptographic
   capabilities to parties with whom you communicate. [...]

I can't figure out what "starter" means, here.

   Modification of the ciphertext in EnvelopedData can go undetected if
   authentication is not also used, which is the case when sending
   EnvelopedData without wrapping it in SignedData or enclosing
   SignedData within it.  This is one of the reasons for moving from
   EnvelopedData to AuthEnvelopedData as the authenticated encryption
   algorithms provide the authentication without needing the SignedData
   layer.

nit: I think a comma before "as the" would help the last sentence.

When talking about compression oracles, do we want to explicitly say that a
common way to do so is to compress attacker-controlled data in the same
corpus as the attacker's target data?

   mail clients deal with HTML and multipart/mixed messages.  Clients
   MUST require that a text/html content type is a complete HTML
   document (per [RFC1866]).  Clients SHOULD treat each of the different
   pieces of the multipart/mixed construct as being of different
   origins.  Clients MUST treat each encrypted or signed piece of a MIME
   message as being of different origins both from unprotected content
   and from each other.

Do we need to cite RFC 6454 for the specific "web origin" concept (as opposed
to just the normal English usage of the word)?

Appendix B

   This appendix contains a number of references to documents that have
   been obsoleted or replaced, this is intentional as frequently the
   updated documents do not have the same information in them.

nit: comma splice

Appendix B.2

   -  Hash functions used to validate signatures on historic messages
      may longer be considered to be secure.  (See below.)  While there
      are not currently any known practical pre-image or second pre-
      image attacks against MD5 or SHA-1, the fact they are no longer
      considered to be collision resistant the security levels of the
      signatures are generally considered suspect.  [...]

nit: there seems to be (at least) a missing verb in this last sentence.

      [...] If a message is
      known to be historic, that it it has been in the possession of the
      client for some time, then it might still be considered to be
      secure.

nit: maybe "and it has been"