Re: Massive change in Public Cert behaviour coming soon

[brent saner via NANOG <nanog () lists nanog org>]

On Sun, May 18, 2025, 22:32 William Herrin <bill () herrin us> wrote:

> 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.

Where, precisely, is this public key associated with FQDNs in SMTP? What
are you verifying the CN/SANs against?


> > 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."

How about the next entry, "authentication":

"(I) The process of verifying a claim that a system entity or
      system resource has a certain attribute value."

What "system entity" or "system resource" are you authenticating against in
pure, straightforward TLS? CAs only provide trust and integrity of
presented identity attributea, they don't store, manage, or otherwise
control that identity. The Thawte intermediate keypairs have no clue what
an "example.com" is, they just can provide evidence that was part of data
that they signed.

This is why "verification/validation" is preferred over "authentication"
when *just* TLS is concerned - because "authentication" does not fit.


> > 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 side with IETF on this, thanks.


> I'll buy the argument that our happy fun certificates from letsencrypt
> intentionally include an authorization component if you care to make
> that argument.

Cryptographic exchange is not AAA. It can be used WITH AAA by *reusing the
TLS identity within the service*, but it's not AAA - TLS is not a service
itself, just as e.g. SCTP isn't a service. TLS is a specified transport
layer providing encryption with multiple facilities ensuring that
*communication* with the remote end can be trusted. Data hasn't even *hit
the actual service yet*.

All current RFC specifies AAA in conjunction with system resources/system
entities, which have their own RFC-defined meanings, if you'd like to go
down that route, but there's a reason "authenticate" was deprecated in
favor of "verify" when certificates are confirmed against a trust chain.
_______________________________________________
NANOG mailing list 
https://lists.nanog.org/archives/list/nanog () lists nanog org/message/TWHUSFKQ5VVWUTSLBZIIW24VMTVIY32Y/