On Fri, Mar 06, 2026 at 07:18:21AM -0500, David Benjamin wrote:
> On Wed, Mar 4, 2026, 13:04 Ilari Liusvaara <[email protected]> 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?
And there are some discussion about log "generations" in PLANTS (to
handle the inevitable incidents that bork logs). How would that be
accommodated?
> 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.
> > 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).
And then there are some edge cases, like all MTC certificates ignoring
signature_algorithms_cert.
> Protocol-wise, we could also have the client send ranges, but this seemed
> an tidier modification in my eyes, since the protocol proper doesn't
> actually need to believe in ranges. It's just a matter between the CA and
> server software to program in the right matching function.
>
> Beyond that, yes, the server would need to implement the thing the spec
> says to implement and not something that the spec doesn't say to implement.
> :-)
>
> 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.
-Ilari
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
