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.
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.
> 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.)
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.
>
> -Ilari
>
> _______________________________________________
> TLS mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
>
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
