Yes, absolutely correct. I was just generalizing the example, perhaps unclearly.
On Sun, May 18, 2025 at 10:04 PM brent saner via NANOG < [email protected]> wrote: > On Sun, May 18, 2025, 20:28 Tom Beecher via NANOG <[email protected]> > wrote: > > > > > > > "This identity may only be used for clients verifying servers," smells > > > like authorization to me. > > > > > > It's not. It's "This certificate can only be used to authenticate me if > it > > is being used in the manner with which I specify." > > > > Ex 1 : > > > > 1. Alice creates certificate A, with the EKU set to Server Auth Only. > > 2. Alice connects to Bob, says "Hello, I am Alice. " She has *identified* > > herself. > > 3. Bob says "Hello, prove you are Alice." > > 4. Alice sends certificate A. > > 5. Bob verifies certificate A cryptographically, but since it is only > > allowed to be used as Server Auth, not Client Auth, then *authentication* > > fails. > > > > No authorization of anything ever occurs here, because authentication has > > failed. > > > > Ex 2 : > > 1. Alice creates certificate A, with the EKU set to Client Auth Only. > > 2. Alice connects to Bob, says "Hello, I am Alice. " She has *identified* > > herself. > > 3. Bob says "Hello, prove you are Alice." > > 4. Alice sends certificate A. > > 5. Bob verifies certificate A cryptographically, and it is allowed to be > > used for Client Auth. *Authentication* succeeds. > > > > Now that Alice has been authenticated, Bob can determine if she is > > *authorized* to do the thing she is trying to do. > > > > > Generally yes, precisely this, but what I think many are missing is TLS > verification itself is still not even authentication unless actual > identification context is associated (e.g. a certificate attribute is given > meaning). See RFC 4949, "authenticate" definition, second and third > deprecations. > > #5 in both the above examples is *service*-specific, and should probably be > split into: > > == > > 5.a.) Bob verifies certificate A cryptographically; it's verification (may) > determine validity/continuance of TLS communication > 5.b.) (Only in certain services) The usage of the certificate is verified > in its current transaction role (id-kp-clientAuth vs. id-kp-serverAuth), > which (may) determine continuance of TLS communication. > > == > > Internet-facing MTAs do not do 5.b. when communicating with other MTAs (and > typically don't even do it for clients, opting instead for doing encryption > via TLS and authentication via SASL). > > Most wide-trust CAs don't even issue certs with id-kp-clientAuth set, I > wasn't aware LE was even doing so until I found out about them removing it- > because it's generally not useful for internet-facing resources unless you > control the authority. > _______________________________________________ > NANOG mailing list > > https://lists.nanog.org/archives/list/[email protected]/message/TFGSQP42CU3FWGDZX75B3EC3O3WTPYH3/ > _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/[email protected]/message/FRVKSQPKTMFFZMAIWCNK2I72ALBITOSN/
