Hmm, I'm not quite following what you're saying with the multi-log /
single-ID business. Not sure if the misunderstanding is in my reading your
email, or you reading the mechanism. Let me give clarifying the mechanism a
shot and see if that helps:
Nothing here is proposing that a single ID match multiple logs. (Best
ignore the parenthetical at the end of my message. That was probably a
distraction and probably just made the email more confusing.)
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.
Does that clear things up, or is the misunderstanding elsewhere (perhaps on
my end)?
On Wed, Mar 4, 2026 at 2:13 AM Ilari Liusvaara <[email protected]>
wrote:
> On Mon, Mar 02, 2026 at 04:29:38PM -0500, David Benjamin wrote:
> > Hi TLS folks,
> >
> > One key part of the draft is negotiating whether to send the default
> > “standalone certificate”, or a more optimized “landmark certificate”.
> > Landmark certificates need to signal whether the relying party has prior
> > knowledge of a given “landmark”. Happily, landmark numbers fit neatly
> into
> > the RELATIVE-OID scheme of Trust Anchor IDs. Having some hand in both,
> this
> > is not a coincidence. :-)
>
> I think the fit is not as neat as it seems. Merging two different things
> into the same namespace might not be a good idea.
>
>
> > This would work even better with one tweak. (We left this out of the
> > original Trust Anchor IDs draft because it was harder to motivate without
> > MTC.)
> >
> > https://github.com/tlswg/tls-trust-anchor-ids/issues/62
> >
> > Landmarks are slightly structured. A relying party will be configured
> with
> > a range of landmarks spanning some snapshot of currently unexpired
> > certificates (say landmarks 100 to 200). This means if you support
> landmark
> > 200, you also support 199, 198, 197, etc. Incorporating that lets TLS
> > negotiate this more efficiently.
> >
> > The MTC draft contains a sketch of a TAI extension to do this. I’ve
> applied
> > it to the TAI draft as a PR here:
> >
> > https://github.com/tlswg/tls-trust-anchor-ids/pull/104
>
> To me it looks like, while this mechanism seems simple on surface, it
> hides great complexity.
>
> What it quickly seems to be is to advertise issuer X with landmarks
> Y..=Z available.
>
> The problem is, it does not actually seem to advertise the issuer
> itself, and can advertise across issuers. I think many servers will
> the it wrong.
>
>
> > The idea is to statically configure (via the CA or ACME server) with each
> > certificate a set of “additional IDs” that also match it. We’d use the
> same
> > CertificatePropertyList format that we use to configure the main ID. This
> > lets us encode schemes where one ID can imply multiple trust anchors,
> like
> > landmark 200 implying the landmarks below it. In applications that use
> > this, relying parties can then send a smaller set of IDs to convey the
> same
> > information.
>
> To me, this seems like a bad idea.
>
> If a single ID can match multiple logs, both the client and the server
> need to agree on that set (at least conservatively). Which is not going
> to work, for pretty obvious reasons (distributed systems must always
> account for relativity).
>
> How I would handle landmarks is for the client to send list of issuers
> it trusts, and range of landmarks it has available (which may be none)
> for each. "[...]advertise issuer X with landmarks Y..=Z available.".
>
>
> > The extension can be used in MTCs like this:
> >
> >
> https://www.ietf.org/archive/id/draft-ietf-plants-merkle-tree-certs-02.html#section-8.2
> >
> > The proposal is more general though. As before, the observation is that
> > upgrading server software across an ecosystem is expensive, particularly
> > for servers operated not by major players. Hence, the preference for
> > flexible schemes that we can invest in once and reuse.
>
> The problem with flexible schemes is that those tend to be overly
> complex and difficult to implement correctly. And bad implementations
> can be nasty to sort out.
>
> Sure, sometimes one has even overly flexible ("who would want to do
> that?") very simple ("what it does is obvious") schemes. Those can very
> much be worth it.
>
> Furthermore, I do not see this kind of flexibility as helpful in solving
> the actually challenging issues with trust anchor negotiation.
>
>
> > (E.g. if someone wants one number to represent landmarks from multiple
> CAs,
> > it's possible to encode this here. Though there are challenges regarding
> > whether one unreachable CA can knock out the optimization for all, so I'm
> > not sure if that's actually wise.)
>
> Even if all landmarks need to be associated with a log, that could be
> represented as a log with NULL key. While such log could not issue any
> stand-alone certificates (there is no way to make signature that
> verifies), it could still issue landmark checkpoints.
>
>
>
>
> -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]
