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]
