Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Certificate Handling
draft-ietf-lamps-rfc5750-bis-08
Yes
(Alexey Melnikov)
(Eric Rescorla)
No Objection
Warren Kumari
(Alvaro Retana)
(Deborah Brungard)
(Ignas Bagdonas)
(Martin Vigoureux)
(Mirja Kühlewind)
(Spencer Dawkins)
(Suresh Krishnan)
(Terry Manderson)
Note: This ballot was opened for revision 06 and is now closed.
Warren Kumari
No Objection
Adam Roach Former IESG member
Yes
Yes
(2018-06-18 for -06)
Unknown
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.
Alexey Melnikov Former IESG member
Yes
Yes
(for -06)
Unknown
Ben Campbell Former IESG member
Yes
Yes
(2018-06-18 for -06)
Unknown
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.
Benjamin Kaduk Former IESG member
Yes
Yes
(2018-06-20 for -06)
Unknown
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.
Eric Rescorla Former IESG member
Yes
Yes
(for -06)
Unknown
Alissa Cooper Former IESG member
No Objection
No Objection
(2018-06-20 for -06)
Unknown
It seems a bit odd that Appendix B recommends that RFC 2312 be made historic, because that already happened.
Alvaro Retana Former IESG member
No Objection
No Objection
(for -06)
Unknown
Deborah Brungard Former IESG member
No Objection
No Objection
(for -06)
Unknown
Ignas Bagdonas Former IESG member
No Objection
No Objection
(for -06)
Unknown
Martin Vigoureux Former IESG member
No Objection
No Objection
(for -06)
Unknown
Mirja Kühlewind Former IESG member
No Objection
No Objection
(for -06)
Unknown
Spencer Dawkins Former IESG member
No Objection
No Objection
(for -06)
Unknown
Suresh Krishnan Former IESG member
No Objection
No Objection
(for -06)
Unknown
Terry Manderson Former IESG member
No Objection
No Objection
(for -06)
Unknown