Deb Cooley has entered the following ballot position for draft-ietf-emu-rfc7170bis-17: No Objection
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/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-emu-rfc7170bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- These are all pretty picky comments. I won't be upset if you choose to ignore some/all of them. Section 3.11, para 2: Part of the authentication process is to show that the server presenting the certificate holds the private key. Presentation of a certificate is insufficient, it is the certificate validate (in TLS language) that matters. I'm not asking you to change anything here, just pointing out a pet peeve. Section 3.11, para 4: (because of my PKI background): "This ensures that the authenticated TEAP peer is in possession of the private key used to sign the certification request." This is stated backwards, maybe "This ensures that the signed certificate request is being presented by an authenticated TEAP peer which is in possession of the private key." But, this is very pedantic on my part. Section 3.11.2, para 2: "Alternatively, the supplied information could contain private data which should not be sent over a TLS 1.2 connection where that data would be exposed." Since you have specified that TLS cipher suites that do not provide confidentiality MUST NOT be used (Section 3.2), this seems like a weird statement. If you remove it, you can combine this paragraph with the next one. Section 3.11.2, para 4: It is not uncommon for a (private) CA to ignore some fields in the CSR and instead populate the certificate fields based on local policy. I would add 'or modify' in addition to 'can refuse'. Section 3.11.2, para 2-4: Personally, I'd make this one paragraph. It would tighten up the section a bunch and possibly make it easier to understand. Section 3.11.2, para 5 and beyond: Well it could be used for other purposes, except that you have specified in Section 3.3 that private CA SHOULD be used. Personally, I'd remove the rest of this section, unless you are attempting a tutorial (and then I'd have other comments). Section 4.2.12, para 2: There is a lower case 'should' in first sentence, is that correct? Second sentence, if a Result TLV w/ failure is sent, is it possible to ignore the deprecated TLV? These two options appear to be at odds. Section 7.1, last sentence: This would be clearer if you said 'both server and peer authentication' instead of 'mutual authentication'. The normal assumption for 'mutual auth' is that the peer has to authenticate. In this case, we need the server AND the peer to authenticate. Section 7.5.1: General comment: Requiring (with a SHOULD) a private CA makes it harder for an 'on-path attacker' to impersonate a server - a good thing. Appendix C: I like this section. But there is some terminology that isn't explained. '()' appears to be the contents of whatever message is being sent. '[]' I have no idea, in TLS 1.3 it would signify encrypted messages, but clearly that can't be the case here (TLS server_key_exchange can't be encrypted). I like the ASCII art in Section C.1-C.10, not so much in C.11 on because it is harder to see which way the arrows point (less white space). Deb _______________________________________________ Emu mailing list -- emu@ietf.org To unsubscribe send an email to emu-le...@ietf.org
