That was way more changes than I expected, so thanks for that. A couple of comments (no actions required on your part):
1. "And allegedly using web CAs for non-web uses will cause the world to end." This made me chuckle. I do agree that sometimes the Web PKI language is a bit much. 2. Appendix C: So whatever that is has been around for a long time. In which case, either people understand what it all means, or it doesn't matter. At this point, I'd leave it alone. 3. ASCII art... only if you have time! Deb On Tue, May 28, 2024 at 7:46 AM Alan DeKok <al...@deployingradius.com> wrote: > 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
