Yes, absolutely correct. I was just generalizing the example, perhaps unclearly. On Sun, May 18, 2025 at 10:04 PM brent saner via NANOG < nanog@lists.nanog.org> wrote:
On Sun, May 18, 2025, 20:28 Tom Beecher via NANOG <nanog@lists.nanog.org> 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/nanog@lists.nanog.org/message/TFGSQP42...