Re: Massive change in Public Cert behaviour coming soon

[William Herrin via NANOG <nanog () lists nanog org>]

On Sun, May 18, 2025 at 7:03 PM brent saner via NANOG
<nanog () lists nanog org> 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
bill () herrin us
https://bill.herrin.us/
_______________________________________________
NANOG mailing list 
https://lists.nanog.org/archives/list/nanog () lists nanog org/message/OZ3BMILSGNS623KQZKGMJX5FY3HSC2XJ/