Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Certificate Handling
draft-ietf-lamps-rfc5750-bis-08

Thanks to everyone for the work put into updating this document. I reviewed
the diffs from the previous RFC, and the changes all seem to make sense.  I
found a couple of minor editorial nits.

---------------------------------------------------------------------------

§2.2.1:

>  Receiving agents MUST be able to parser and process a message
>  containing PKCS #6 extended certificates although ignoring those
>  certificates is expected behavior.

Nit: "...be able to parse..."

---------------------------------------------------------------------------

§A.1:

>  -  Hash functions used to validate signatures on historic messages
>     may longer be considered to be secure (see below).

Nit: "...may no longer..."

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

This final clause appears to be missing some words. Consider rephrasing.

Thanks for this work. I'm balloting "yes", but have a few comments. I realize some of these may be leftovers from previous versions. None are blocking, so I leave it to the authors, WG, and AD to choose.

Substantive:

§1.3, last paragraph: Is the "SHOULD NOT" really constrained to mail? It seems like it should apply to other messaging systems, although I can see the need to decrypt old messages as more important for mail than for more real-time messaging.

§2.2.1, 2nd paragraph: "...although ignoring those
   certificates is expected behavior..."
I'm surprised not to seem a MUST or SHOULD here--is it ever reasonable to _not_ ignore these certificates?

§2.3: 

- The requirement to be able to handle an arbitrary number of certificates seems like a potential DOS vector. Aspects of that are mentioned in the security considerations. Shouldn't a receiving agent put some limits on the number/size it will accept? Or is "fail gracefully" an acceptable strategy to "handle" too many certs?

- 4th paragraph: "Note that
   receiving agents SHOULD NOT simply trust any self-signed certificates
   as valid CAs, but SHOULD use some other mechanism to determine if
   this is a CA that should be trusted."

Why are those SHOULDs not MUSTs? (Or SHOULD+'s)?

§4.4, 2nd paragraph: "Some mechanism SHOULD
   exist to gracefully handle other certificate extensions when they
   appear in end-entity or CA certificates."

Can you elaborate on that? Does it imply more than discussion of the "critical" bit in the next paragraph?

Appendix B: It seems odd to find this in an appendix.  Does this draft actually purport to _request_ the move to historic, or just sort of wish we would do so?

Editorial:

Abstract: Should the RFC Editor remove the "Contributing to this document..." paragraph?

§1.1: 

- The definition for AC does not contain an actual definition.
- CRL definition: " prematurely" seems an odd choice of words; one assumes the issuer does not revoke before it needs to. I assume the intent was to describe revoking certs prior to their expiration?

§1.4 (and subsequent change version): I infer from the section titles that the normative keywords in these sections are intended to describe requirements added to those versions, not new requirements in _this_ version. It would be better to make that explicit; the body text should stand alone without the titles.

§2.2.1, 2nd paragraph: s/parser/parse

§3: Paragraph 5: " Some localities may perform other
   transformations on the local name component before doing the
   comparison, however an S/MIME client cannot know what specific
   localities do."

That's an odd statement, since software localization rules can certainly include comparison policies. It's not material to the document, though, so I will leave this as an editorial comment.

§4.1, first paragraph: "get information stored away from incoming messages."
I don't understand what that means. Should "away from" simply be "in"?

§4.2, first paragraph: The first sentence seems more like a statement of principle than a normative requirement.

Lots of good comments from Ben et al; I tried to trim duplicates from my own.

Section 1.2

   The term RSA in this document almost always refers to the PKCS#1 v1.5
   RSA signature algorithm even when not qualified as such.  There are a
   couple of places where it refers to the general RSA cryptographic
   operation, these can be determined from the context where it is used.

nit: this is a comma splice; I suggest using a semicolon instead.

Section 2

   [...] Most of
   the CMS format for S/MIME messages is defined in [RFC5751].

We cite 5751bis elsewhere; is the non-bis reference intentional?

Section 2.3

   [...] Receiving S/MIME agents SHOULD be able to
   handle messages without certificates using a database or directory
   lookup scheme.

Maybe clarify that this lookup is to obtain the certificates (and chain) in
question?

Section 3

   Note that this attribute MUST be encoded as IA5String and has an
   upper bound of 255 characters.  The right side of the email address
   SHOULD be treated as ASCII-case-insensitive.

What does "treated as" mean here?  Is it limited to "for comparison
purposes"?  Am I expected to normalize for display?  (I guess enforcing the
ASCII range is inherent in IA5String, so checking that is out of scope.)
The next paragraph has a MUST-level case-insensitive comparison, so maybe
this whole sentence is redundant?

   [...] A receiving agent SHOULD provide some explicit
   alternate processing of the message if this comparison fails, this
   might be done by displaying or logging a message that shows the
   recipient the mail addresses in the certificate or other certificate
   details.

nit: This is another comma splice.

Section 4.3

Why are we going from SHOULD+ (in RFC 5750) to just SHOULD for RSASSA-PSS 
with SHA-256?

Section 4.4

   The PKIX Working Group has ongoing efforts to identify and create
   extensions that have value in particular certification environments.

Isn't the PKIX WG closed?

   [...] Other extensions may be included, but those extensions
   SHOULD NOT be marked as critical.

Is this a candidate for a 2119 MAY?

Section 6

   In addition to the Security Considerations identified in [RFC5280],
   caution should be taken when processing certificates that have not
   first been validated to a trust anchor.  Certificates could be
   manufactured by untrusted sources for the purpose of mounting denial
   of service or other attacks.  For example, keys selected to require
   excessive cryptographic processing, or extensive lists of CRL
   Distribution Point (CDP) and/or Authority Information Access (AIA)
   addresses in the certificate, could be used to mount denial-of-
   service attacks.  Similarly, attacker-specified CDP and/or AIA
   addresses could be included in fake certificates to allow the
   originator to detect receipt of the message even if signature
   verification fails.

Should malformed/misencoded/strangely-encoded certificates be included in
the list of examples here?  Historically, ASN.1 parsers have been unfortunately
fragile, after all.