[lamps] Ben Campbell's Yes on draft-ietf-lamps-rfc5750-bis-06: (with COMMENT)

[Ben Campbell <[e-mail]>]

Ben Campbell has entered the following ballot position for
draft-ietf-lamps-rfc5750-bis-06: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5750-bis/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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.