On Fri, Feb 7, 2025 at 9:17 AM David Benjamin <david...@chromium.org> wrote: > > On Fri, Feb 7, 2025 at 9:44 AM Mike Shaver <mike.sha...@gmail.com> wrote: >> >> Hi Watson, >> >> On Thu, Feb 6, 2025 at 8:10 PM Watson Ladd <watsonbl...@gmail.com> wrote: >>> >>> A negotiation where what is advertised is an inherently opaque >>> pointer, and where each side must maintain an idea of what that could >>> mean, does not have this property. Servers have to explicitly act to >>> support the new identifier by getting a configuration that includes >>> it. Whether or not this is indirectly away as part of ACME doesn't >>> really change the equation. New clients can't count on server support, >>> unless they advertise an already existing value. There's been various >>> ways to express deltas to try to solve this, but they all involve >>> paying a penalty for deviation. >>> >>> The dynamic I'm worried about most then isn't fracturing: as you point >>> out there are some countervailing forces where people want easy >>> support. Rather it's that we artificially drive up the price of >>> picking different CAs than the dominant implementation. >> >> >> I very much share the concerns you've articulated here: increased barriers >> to entry both for new CAs and for new clients which have different >> root-management policies than the existing dominant implementation, and >> outsized penalties for differing from a "well-known set" as might happen >> from having tighter requirements on CA operation over time. The opaque token >> seems like it could lead to the properties that you (and I) wish to avoid, >> but when expressing my support for the group taking up the draft, I felt >> that the specific identifier form for trust anchors was still mutable, and >> therefore that it wasn't a barrier to draft adoption. >> >> If I have misunderstood, and identifiers must inherently be opaque in that >> way for all forms of trust anchors negotiation, then I appreciate the >> correction! > > > Hi Mike and Watson, > > Hmm, well, if we have one concern that (against all realities of how PKIs > work) this will make it too easy for clients to pick different CAs, and > another concern that this will make it too hard, clearly we've struck a happy > medium and all is well! ;-D > > More seriously, I completely agree that we need to avoid this. As valuable as > the existing CAs and root programs are, as much as I hope they continue to be > valuable, I think any design in this space which advantages and grandfathers > in existing players is simply bad for the internet. We are dealing with > inherently subjective delegations of trust here, and such systems *need* room > to change as trust evolves. > > When Devon, Bob, and I worked on these initial drafts for TAI (and the > previous TE design), the three of us spent a lot of time thinking about > exactly this and trying to make sure we avoided such effects. So if you all > think we didn't quite get it right, that's very much something I care about > and would want to tweak accordingly---I mean, getting eyes on this beyond the > three of us is why I care about bringing the work here and having the working > group adopt and tweak it, despite the year's worth of aspersions against my > motivations that it has so tiringly engendered. > > To that end, I don't think this design causes those problems. I'll explain my > thinking, and perhaps you all can poke holes in it if you think I've missed > something. (This is also something we can adjust post-adoption. Procedurally, > modifying things with WG consensus is very hard before adoption–I would know, > I've been trying all year!) > > First, the identifiers in TAI are not meant to be some opaque thing, > representing some coupled mishmash of parameters. They represent the trust > anchor[1] and only the trust anchor. I think, if we had better trust anchor > negotiation, things like signature_algorithms_cert might have been > unnecessary because we could have just negotiated trust anchors, in a world > where we established a new root when adding a new incompatible sigalg anyway. > (And perhaps we should have? Have one joint and keep it well-oiled and all.) > But the extension itself doesn't take any opinion on this. It expresses trust > anchors, and if there are other TLS extensions that apply other constraints, > your server software is expected to continue to process those as it always > would.
Silly clarification: the TAI identifier is just a compact identifier for the root cert, like (making it up) a 4 byte identifier? So the client sends the entire list of root certs supported, so about 100, so 400 bytes? In that case I think you can inject it into an end-entity cert on issuance, and into the root representations in the trust store. Where this doesn't work out well is on cross signs where the cert can root to multiple places/when more than one cert is needed to cover and the config only has one, but this would solve a bunch of the issues for command line programs where the trust store format is a bag of certs on disk. It could also work for cross signs since the intermediates used are known by the CA. Sincerely, Watson _______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
