On Fri, Feb 7, 2025 at 12:17 PM 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. > > Really, the only reason the IDs exist at all is that X.509 names are too > long. (Public Web PKI names are roughly 100 bytes.) X.509 conflates > identifying a CA with human-readable names for CAs, and ends up with > something that does a bad job of both. (Names of CAs are pretty meaningless > once keys change hands.) In another PKI design > <https://davidben.github.io/merkle-tree-certs/draft-davidben-tls-merkle-tree-certs.html>, > these IDs could simply be what goes in the issuer field as-is. The thinking > was that when you stood up a CA, you would simply pick an ID, just as you > already have to pick a name. And if your CA predates this system, just go > ahead and allocate that ID now. This is also why we went with an OID-based > allocation, because it's reasonably compact and allows anyone to allocate > IDs without any fuss. > > The other minor difference between TAI and an X.509 name is that it also > encompasses the public key. This is simply a (minor) bug in > certificate_authorities, because X.509 allows (though it works really > badly) "self-issued" CAs with the same name and different keys. Since we're > defining a new ID anyway, it made sense to just fix that mistake. > > Now, the ID needs to make its way to clients and servers. This is where we > did have to invent some out-of-band communication, but I think this can be > made to work. The observation is that all the communication paths are ones > that already exist: > > - The client needs to know the IDs of all its trust anchors, but it > already needs to pick up the rest of the trust anchor information from > somewhere, and storing metadata with trust anchors is a very common thing > now. We also defined an extension to embed it in the trust anchor, if it's > represented as a self-signed certificate, though that doesn't work as well > for pre-existing CAs. > > - The server needs to know the ID of the certificate. But it ultimately > gets the certificate from the CA, which picked the ID. Here, we do not have > as robust of a preexisting pipeline for communicating metadata with issued > certificates, but I think it would be valuable such a pipeline for many > reasons[2]. So that's what the draft tries to do, by defining this > CertificatePropertyList to get this done once, and hopefully we can enrich > the certificate pipelines with this metadata. > Looking over this, I realized I both said the paths already exist and that the metadata pipeline doesn't exist. That was probably confusing, so let me try again. :-) What I mean is that the arrows between who communicates with what already are the right shape. Your server software gets the certificate from the CA, possibly transiting through whatever certificate issuance pipeline, customer certificate upload box, etc., that you've got. Since the root of that pipeline has the ID, *who* communicates is already the right shape. *What* is communicated isn't the right shape, so we would need to enrich all those arrows (add another field to the structure, add support for this other PEM format, or whatever makes sense) to communicate the new field, but the fundamental shapes of the systems doesn't have to change. That makes me think this is viable. We definitely don't want to do this more than once, so CertificatePropertyList is extensible, but I think that extensibility also makes going down that path more compelling. (It's also possible I'm wrong and we should modify it to do the issuerTrustAnchorID route, or both, but that was the thinking.) > The hope then is that, when client, server, and CA are participating in > this scheme, the IDs work reliably and we don't have any of these adverse > effects. If a client wants to add some CA and that CA has an ID, it should > be able to send it and assume that ID is as well supported as any other ID > it might send. (Well-supported = servers that implement TAI will understand > it and servers that don't, well, won't understand any of it anyway.) > > In my mind, I think the main question is whether we can get this > CertificatePropertyList pipeline to work. If that doesn't work, it would be > quite easy to remove the dependency, really at any point in time, by just > defining an issuerTrustAnchorID X.509 extension that you put at the last > certificate in the chain, and server software can extract it from there. > That could even be done years after TAI is all done, since it's purely > additive. But I think it's worth starting with the CertificatePropertyList > path because: > > - Having this metadata pipe would be really useful. We can't embed > arbitrary things in certificates because they get signed, and not all > information makes sense to send to the client bytes-wise. > > - While small, it is a waste of bandwidth to send that information down to > the client. The client already has plenty of information to find the trust > anchor in X.509 already. > > - Existing issued certificates (notably existing intermediates) do not > currently have this issuerTrustAnchorID extension, and adding it would > require reissuing the certificate. So out-of-band metadata is easier to > bootstrap onto existing systems while the happy automated path gets lit up. > > Does that answer your concerns? Have I missed something? > > David > > [1] Since I know this has caused some folks confusion, "trust anchor" > isn't some abstract term or anything. It's what X.509 itself calls a "root > CA". E.g. https://www.rfc-editor.org/rfc/rfc5280#page-76 > > [2] As another example, had this pipeline existed, stapled SCTs could have > been communicated through it and we might have avoided the double-issuance > pre-certificate hack in CT by now. >
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
