On Sun, May 18, 2025 at 7:03 PM brent saner via NANOG <[email protected]> wrote: > See RFC 4949, "authenticate" definition
Hi Brent, From RRFC 4949: "authenticate: Verify (i.e., establish the truth of) an attribute value claimed by or for a system entity or system resource." In a letsencrypt certificate, the attribute whose truth is to be established is an encryption key associated with one or more FQDNs. Anything placing additional limits on that context is authorization. > second and third deprecations. Which basically state that Internet Drafts (and hence RFCs) should use a couple more precise terms (verify and validate) when talking about specific steps of the authentication process. They're "should," not "must" but even if you read them as "must," they in no way change the meaning of "authenticate." > 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. I appreciate the effort but you haven't convinced me. Deciding that a verified identity is acceptable within a particular transaction role is _authorization_. The authentication was complete when the identity was verified. I'll buy the argument that our happy fun certificates from letsencrypt intentionally include an authorization component if you care to make that argument. Regards, Bill Herrin -- William Herrin [email protected] https://bill.herrin.us/ _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/[email protected]/message/OZ3BMILSGNS623KQZKGMJX5FY3HSC2XJ/
