[TLS] Re: PLANTS and extending TLS Trust Anchor IDs

[David Benjamin <[e-mail]>]

(Sorry about the late reply. I was traveling all of March, and then caught
a cold, so this got buried in my inbox.)

On Fri, Mar 6, 2026, 11:51 Ilari Liusvaara <[e-mail]> wrote:

> On Fri, Mar 06, 2026 at 07:18:21AM -0500, David Benjamin wrote:
> > On Wed, Mar 4, 2026, 13:04 Ilari Liusvaara <[e-mail]>
> wrote:
> >
> > > On Wed, Mar 04, 2026 at 10:44:43AM -0500, David Benjamin wrote:
> > > >
> > > > In MTC, landmarks are not global. They're CA-specific and allocated
> per
> > > CA.
> > > > Thus, if your CA is 32473.1, then your landmarks for that CA
> > > > are 32473.1.1, 32473.2, 32473.1.3, etc. A landmark ID specifies
> *both*
> > > the
> > > > landmark *and* the issuer and identifies the thing the relying party
> must
> > > > trust to accept this certificate. That works with TAI as-is without
> any
> > > > fuss.
> > > >
> > > > The invariant this is encoding is simply that, in a CA with 100 live
> > > > landmarks, every client which supports 32473.1.200 can also be
> assumed to
> > > > know about 32473.1.{101-199}. Thus, in a certificate issued by
> > > 32473.1.101,
> > > > the CA can be defined (in the MTC spec) to set trust_anchor =
> 32473.1.101
> > > > and additional_trust_anchor_ranges = 32473.1.{102-200}. Then the
> relying
> > > > party only needs to send 32473.1.{latest-for-this-CA} to capture the
> > > whole
> > > > range.
> > >
> > > 1) If client trusts some landmarks, it probably trusts the parent log
> > > as well (cases where it does not are expected to be exceptional), so
> > > needing to duplicate the parent identifier wastes space.
> > >
> >
> > Indeed. The standalone certificate can probably mark the full range of
> > landmark IDs as aliases and then the client can just send one ID for the
> > whole CA. No duplicate parent identifier.
>
> What does client that trusts some log but has no landmarks for it send?
> X.0?
>

Just X. That's the name for the CA overall.

And there are some discussion about log "generations" in PLANTS (to
> handle the inevitable incidents that bork logs). How would that be
> accommodated?
>

In the model where we try to advertise CAs individual, with log generations
(which still needs to be spec'd), the CA is named X, a single log is X.Y,
and landmark within that log is X.Y.Z. A landmark-relative certificate at
landmark Z of generation Y would configure something like trust_anchor =
X.Y.Z and trust_anchor_aliases = X.Y.(Z+1....). Then any landmark
advertisement of Z or higher would match. Since CAs are only expected to
have one active landmark at a time, I think we don't need to worry about
inter-log-generation advertisements. A relying party only needs to have the
active generation's worth of landmarks configured.

Though it's true that the PR as written is not currently able to express
that a standalone certificate issued by X has an alias of X.*.* because we
only get one wildcard, so that would probably require X on its own to also
be listed. Or we could extend that a bit. Or the certificates can just be
configured with a small window of generation's worth of aliases; after the
certificate expires, you don't care anymore. (How many incidents are you
going to have in 45 days??) So just listing a handful should be plenty.

This also assumes we do an individual-CA-advertisement model. That's very
straightforward when the number of anchors is few enough that we can just
list them all. While TAI does have the (horrible) DNS mechanism, it's never
been a requirement. It's really only there when you aren't able to just
list them all. I think "just list them all" is a much, much better
direction when you can manage it.

*If* you can't manage it, while there is the DNS mechanism, this extension
does actually allow deployments to design bulk trust anchor encoding
schemes in general. As long as you can express the inverse mapping on the
CA -> authenticating party configuration side, that one piece of server
logic can apply. The retry also gives a little tolerance for signalling
inaccuracies as things shift over time. (The trust expressions design had
this complex excluded_labels thing to work around some version skew edge
cases. Those edge cases can instead be handled by a retry. Though those
edge cases are also much fewer with SCTNotAfter-based distrust anyway.
Indeed this idea, trust anchor IDs, and trust expressions all share some
DNA.)

> Data scoping constraints make it difficult for trusted log identifier
> > > sets to not be server-global for initial advertisment, so there can be
> > > more than a few of those.
> >
> >
> > Not sure I follow what you mean by this. (Sorry, I'm probably confused.)
> > The ranges business on the server allows the client to describe its state
> > for each CA with one ID. The client's landmark state in MTC for a given
> CA
> > is independent of which server it's talking to.
>
> Basically, due to how DNS works, the CA info in DNS has to be
> conservative. And this means there can be fair bit of CAs. So the client
> advertisment for each CA should be as compact as possible.
>
> If one counts conservatively, just Let's Encrypt is currently 16(!) CAs.
>
> Then some servers use multiple ACME servers for backup, which multiplies
> the CA count. And since there is no way to tell apart alias sources, if
> there are any oddball CAs used by some domain, those must be included
> too.
>

I'm guessing you're assuming a server deployment that has to fold all
co-hosted target names onto a single DNS configuration, because they've all
been aliased together via CNAMEs and whatnot? I don't think that's a
universal limitation—Cloudflare seems to encourage CNAMEing a hostname-specific
destination
<https://developers.cloudflare.com/dns/zone-setups/partial-setup/>—but yeah
if you're unioning a bunch of disparate origins together, something using
DNS records would requires you to union them together. This isn't really
specific to TAI, rather a general fact about the HTTPS/SVCB design that the
IETF standardized. The more server properties you put into a DNS record,
the less you're able to just alias a bunch of disparate configurations
together. (E.g. if you want names to differ in QUIC support, or ECH
support. or any future SvcParam, you had better be able to differentiate
them at the DNS level.)

Back to the matter at hand, this PR doesn't currently propose to change the
DNS or retry parts, except in that it gives us tools to reduce the need for
the DNS part. The PR still keeps the authenticating party's "I have these
trust anchors available" parts of the design (EE or DNS) as the true IDs of
the trust anchors, since there was less of a need to do anything there. I
think you raise a good point that DNS has a harder time listing the IDs of
the actual trust anchors, so perhaps we should do even more? I think we can
probably explore that separately though. Here I'm just trying to address
the relying party's "I trust these anchors" half. I think it makes sense to
separate them because the better we get at the RP half, the less we have to
care about the DNS scheme at all. It seems to me that only improves the
situation here. (Maybe it's enough of an improvement to not care about DNS
at all? That sure would be nice.)

I'm not sure counting intermediates from CA operator's today is directly
analogous because today's PKIs basically assume there is no cost to
proliferating intermediates. Today, they're not too big, and not pushed to
RPs. But things will look very different for a PQ PKI. Each distinct CA
instance key is a separate, large key that either needs to be pushed to
relying parties, or needs to be sent during the TLS handshake. With Merkle
Tree Certificates, each CA instance in active use is another set of
landmarks that needs to be maintained and provisioned. So I think we can
reasonably expect things to settle at not so many intermediates per
operator in a PQ PKI.

Still, many intermediates doesn't necessarily have to be a problem for this
particular part. Spitballing, if a given CA operator has a whole suite of
intermediates, you could imagine just giving them a versioned identifier
(version is last OID component) that increments when you add new ones. Each
intermediate then is aliased to
(oldest_version_including_that_intermediate, ...) and now the RP can utter
that CA's whole intermediate set with one ID. That can be expressed by this
PR just as easily as the MTC landmarks thing.

> > 2) The client could send 32473.{1-3}. If the server implements ranges
> > > as lexicographic compares, this goes badly wrong, as it will match any
> > > landmark issued by 32473.1 or 32473.2, even ones too new for the
> > > client.
> >
> >
> > 3) And even if client only uses ranges for landmarks, the lexicographic
> > > compares go wrong in some edge cases (crossing to 2^14, 2^21, 2^28,
> > > ...). If log issues landmarks once per hour, it takes about 22 months
> to
> > > reach 2^14.
> > >
> >
> > Hmm. I think there might still be a misunderstanding here? Or maybe I'm
> > confused (pretty often true!). The proposal is not that the client sends
> > ranges. A client sends one ID and the server has information on each cert
> > (from the CA ideally) for whether that ID matches the cert.
> >
> > Basically the CA tells the server "these are the conditions that can
> > activate this cert". (In BoringSSL, we've modeled cert selection as an
> > ordered preference list of "credentials". The TLS stack iterates over the
> > credentials and picks the first usable one. "Usable" includes things like
> > sigalg negotiation, etc. And then if you set the must_match_issuer flag
> on
> > the credential, we will require *some* signal of matching trust anchor,
> be
> > it TAI or certificate_authorities or whatever else we end up doing. Under
> > that model, trust anchor negotiation boils down to knowing when to say
> yes
> > to this question.)
>
> Well, this needs new extension for signaling anyway.
> Certificate_authorities
> does not support recovering from DNS signaling failure (and is more
> verbose than needed, which is an issue due to number of CAs).
>
> Then trying to extend the X.509 negotiation in TLS servers to MTC can be
> a major mess. E.g., it would be a non-starter in TLS library I have
> written (it would need to be fourth(!) certificate negotiation).
>

Hmm, I'm not sure I follow what you're saying.

Not sure I see the connection to certificate_authorities's lack of
signaling recovery. This PR is about trust anchor IDs.
BoringSSL's must_match_issuer flag indeed checks both.
Since certificate_authorities doesn't tolerate signaling failure, the
authenticating party can reasonably assume that, if the RP was willing to
send certificate_authorities, it indeed trusts the listed CAs. Of
course, certificate_authorities has the limitations you describe, but
that's why we're here. :-) BoringSSL just keys it on the same credential
flag because, the only meaningful application-level semantics is to
distinguish between "this candidate credential is a fallback option" and
"this candidate credential is a issuer-gated option".

What is the "this" that would need a new extension? Negotiating based on
Trust anchor IDs indeed needs a trust anchor IDs extension. Or are you
saying this particular modification to trust anchor IDs needs a new
extension? Why would it? Mechanically, the proposal is to merge it into the
trust anchor IDs draft anyway, which we're still working on. But it's also
compatible in that the relying party message doesn't change. We're just
widening the authenticating party's matching function. (Relying parties do
not send ranges in this PR. They still send singular IDs. Just now some of
those IDs can represent multiple trust anchors, and then we provision the
authenticating party with the inverse mapping: the authenticating party
knows which multi-anchor IDs matches each candidate certificate.)


> And then there are some edge cases, like all MTC certificates ignoring
> signature_algorithms_cert.
>

Adding an MTC sigalgs_cert codepoint is easy enough and, yeah, I expect
we'll need one of those. Though in my experience, sigalgs_cert negotiation
is not very widely used or depended on. In a world with trust anchor
negotiation, it's basically redundant—if I know you trust *this* ML-DSA CA,
I implicitly know you support ML-DSA. In a world without trust anchor
negotiation, sigalgs_cert has never been enough—knowing you support ML-DSA
doesn't tell me you support *this* ML-DSA CA.

> OIDs are a varint encoding, but it's not terribly complicated. (It's just
> > base 128 with the high bit telling you if you're at the end.) I made sure
> > to spell out the exact routine to help people out here, so they can just
> > transcribe that.
>
> How to perform range compare against what client sent? There is simple-
> looking way to do that, but it does not actually work correctly.
>
> How I would implement it is doing prefix strip followed by decoding the
> remainder as integer and then doing range contains. Which is at least
> correct, but very different from what the document seems to specify.
>

Oh? It certainly was meant to be exactly that. I took another look and that
seems to be correct. Where are you seeing the discrepancy? (Steps 1-2 are
the prefix strip. Step 3 decodes the remainder as an integer. Step 4 is the
range contains.)

David