On May 27, 2024, at 2:56 PM, Deb Cooley via Datatracker <nore...@ietf.org> wrote: > These are all pretty picky comments. I won't be upset if you choose to ignore > some/all of them.
I think most seem trivial changes to make, so it's good to make 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. I'll tweak the wording to make this clear. I tend to lean towards explaining things exhaustively. It's more wordy, but tends to be clearer than "you know what to do". > 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. I'll change the wording. > 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. Good point. I'll do that. > 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'. Dne. > 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. I'll clarify that and clean it ip. > 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). I think it's worth keeping to explain the reasoning behind the previous recommendations. i.e. rather than just saying "do this" or "do that", it's good to explain why the recommendations are made, and what happens when they are ignored. My particular pet peeve on this point is people doing "the RFC allows me to do this _idiotic behavior_". No, that behavior isn't even mentioned in the RFC. The RFC is _silent_ on that topic. But apparently because idiotic things aren't explained or banned in the document, they're the best course of action. :( > 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. Uppercase MUST is correct, I think. And then yes, you can't ignore something if you should send a failure TLV. I'll just delete the last sentence. > 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. Sure. I'll change that. > 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. Plus, it's difficult to get non-web certs from public CAs. And allegedly using web CAs for non-web uses will cause the world to end. > 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. Yes. > '[]' 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). TBH that's left over from 7170, and I'm not entirely sure. > 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). That diagram was a later addition. I'll see if I can find time to re-do the diagrams manually before AUTH 48. Alan DeKok. _______________________________________________ Emu mailing list -- emu@ietf.org To unsubscribe send an email to emu-le...@ietf.org
