On Tue, Apr 07, 2026 at 07:19:40PM -0400, David Benjamin wrote: > On Fri, Mar 6, 2026, 11:51 Ilari Liusvaara <[email protected]> wrote: > > This also assumes we do an individual-CA-advertisement model. That's very > straightforward when the number of anchors is few enough that we can just > list them all. While TAI does have the (horrible) DNS mechanism, it's never > been a requirement. It's really only there when you aren't able to just > list them all. I think "just list them all" is a much, much better > direction when you can manage it. > > *If* you can't manage it, while there is the DNS mechanism, this extension > does actually allow deployments to design bulk trust anchor encoding > schemes in general. As long as you can express the inverse mapping on the > CA -> authenticating party configuration side, that one piece of server > logic can apply. The retry also gives a little tolerance for signalling > inaccuracies as things shift over time. (The trust expressions design had > this complex excluded_labels thing to work around some version skew edge > cases. Those edge cases can instead be handled by a retry. Though those > edge cases are also much fewer with SCTNotAfter-based distrust anyway. > Indeed this idea, trust anchor IDs, and trust expressions all share some > DNA.)
I do not think bulk trust anchor encodings make sense for X.509. - There are clients with small trust stores, those can send the whole trust store. - There are clients with large trust stores that do not care about latency. Those need retry to send partial trust store. - There are clients with large trust stores that do care about latency (browsers!). Those need both DNS and retry to send partial trust store. I do not think there is any way to compress browser trust store in TAI-type design enough to make sending whole trust store feasible. For client certs, the server has to send its whole trust store (since there is no retry nor DNS). For MTC, having bulk trust anchor encodings requires the AP to have additional data such as cosignature algorithms for correct negotiation. This would leave just having ID for each CA certificate in chain (plus ID for the implicit root entry). > Back to the matter at hand, this PR doesn't currently propose to change the > DNS or retry parts, except in that it gives us tools to reduce the need for > the DNS part. The PR still keeps the authenticating party's "I have these > trust anchors available" parts of the design (EE or DNS) as the true IDs of > the trust anchors, since there was less of a need to do anything there. I > think you raise a good point that DNS has a harder time listing the IDs of > the actual trust anchors, so perhaps we should do even more? I think we can > probably explore that separately though. Here I'm just trying to address > the relying party's "I trust these anchors" half. I think it makes sense to > separate them because the better we get at the RP half, the less we have to > care about the DNS scheme at all. It seems to me that only improves the > situation here. (Maybe it's enough of an improvement to not care about DNS > at all? That sure would be nice.) I think better retry mechanism would be to list all CA certificates the logical server (by outer SNI) has in HRR. I think it is very unlikely that such list is large. And I think browsers require DNS scheme in any TAI-type design. The trust store is just too big and the thing just too latency-sensitive. > > 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). > > What is the "this" that would need a new extension? Negotiating based on > Trust anchor IDs indeed needs a trust anchor IDs extension. Or are you > saying this particular modification to trust anchor IDs needs a new > extension? Why would it? Mechanically, the proposal is to merge it into the > trust anchor IDs draft anyway, which we're still working on. But it's also > compatible in that the relying party message doesn't change. We're just > widening the authenticating party's matching function. (Relying parties do > not send ranges in this PR. They still send singular IDs. Just now some of > those IDs can represent multiple trust anchors, and then we provision the > authenticating party with the inverse mapping: the authenticating party > knows which multi-anchor IDs matches each candidate certificate.) I am saying MTC needs a new extension. Negotiating MTCs can require much more information than negotiating X.509 certs. There are two kinds of RPs in MTC. - RPs that do not care about transparency, and thus directly negotiate cosigners. - RPs that care about transparency (browsers!). Those need to negotiate logs, and since log cosigners can be rotated, also the set of cosigners for the log (log with all rotated cosigners is unusable). If there are any sort of group identifiers for cosigners, then the AP needs to know algorithms and the group identifiers for the covered cosignatures. Stand-alone certificate with no supported primary cosignatures is unusable. The cosigner algorithm data is also useful for stripping out useless cosignatures. For the case where cosigner is directly negotiated, all other cosigners can also be stripped out. And presenting this sort of thing compactly in TLS looks like it would require a new extension. > > And then there are some edge cases, like all MTC certificates ignoring > > signature_algorithms_cert. > > Adding an MTC sigalgs_cert codepoint is easy enough and, yeah, I expect > we'll need one of those. Though in my experience, sigalgs_cert negotiation > is not very widely used or depended on. In a world with trust anchor > negotiation, it's basically redundant—if I know you trust *this* ML-DSA CA, > I implicitly know you support ML-DSA. In a world without trust anchor > negotiation, sigalgs_cert has never been enough—knowing you support ML-DSA > doesn't tell me you support *this* ML-DSA CA. MTC sigalgs_cert would not be useful. That RP supports MTC does not mean that RP supports the required signature algorithms. As noted above, there are cases where sigalgs_cert can not be ignored. And sigalgs_cert is only redundant with direct issuers using modern algorithms, not indirect issuers or legacy algorithms. -Ilari _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
