Thanks to all the folks who gave feedback on list and GitHub! It definitely helped in improving the text! The PR's been open for quite a while now, so I've merged it based on the feedback and cut draft-04.
On Wed, Apr 15, 2026 at 4:03 AM David Benjamin <[email protected]> wrote: > Hi all, > > In the discussion around > https://github.com/tlswg/tls-trust-anchor-ids/pull/104, originally > centered on landmark-relative Merkle Tree certificates, I realized this was > probably worth describing more generally in the PR (since updated) and > here, as it’s more broadly useful than the original focus. > > So, as a brief recap, Trust Anchor IDs had a few parts: > * Short OID-based IDs to replace overly long X.509 names > * An inverted authenticating-party-offer / relying-party-select flow > driven by DNS > * A retry mechanism to mitigate signaling errors > > This gives a series of building blocks, depending on the application's > needs. If the application didn’t have too many IDs to send, it can just > send them all and move on. If it already had selection heuristics, it could > apply those heuristics and lean on the retry to fix signaling errors, etc. > If the application just has an undirected mass of IDs to send, it could use > a DNS hint to help the client send the right initial request, with all the > fun that entails. > > The idea with the PR is that IDs can just as easily represent groups of > trust anchors. All we need is for the CA-provided certificate metadata to > say not just the trust anchor ID, but also containing group IDs. Originally > it was trying to express some property of landmark-relative Merkle Tree > Certificates (SomeCA.42 also implies SomeCA.41, SomeCA.40, etc.), but it > also could express groups like: > > * Versioned groups of the CAs operated by some CA operator > * Versioned groups of the CAs trusted by some root store > * Other groups one might define > > In a PKI where the RPs and CA metadata both are aware of some group (or > series of groups), the RP can use the group's ID as a stand-in for > individual IDs. Details on how that works are in the PR. In particular, > there’s a very nice alignment between the retry mechanism, and > SCTNotAfter-style removals that make what was once a messy version skew > problem basically moot. It's also only a change to the authenticating > party's evaluation function. The core TLS extension itself is unchanged. > > I think this can be a useful building block, and in particular, should > give enough room to let RPs avoid the DNS mechanism. (The PR doesn't yet go > as far as removing the DNS mechanism. We can keep it defined as yet another > available tool for folks that might want it, or we could remove it if we > don’t think it’s worth keeping around. I figure resolving that can be a > later thing.) > > David >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
