On Fri, May 24, 2024 at 2:05 PM Christian Huitema <huit...@huitema.net> wrote:
> > > On 5/23/2024 9:41 AM, David Benjamin wrote: > > At the end of the day, the TLS components of trust expressions are > > simply a more size-efficient form of the certificate_authorities field. > > The rest is working through the deployment implications to reduce server > > operator burden. However, the way we achieve this size efficiency is by > > *not* saying the CAs names. Instead, the CA sets are indirected through > > named and versioned "trust stores". However, the price one inherently > > needs to pay here is that servers need to know how to map from those > > trust stores back to the certificates. We solve this with the > > TrustStoreInclusionList metadata from the CA. > > > > That TrustStoreInclusionList structure is necessarily a point-in-time > > snapshot of the state of the world. If a root program has not included a > > CA yet, the CA cannot claim it in the metadata or connections will fail. > > If the CA is included in zero root programs, the only viable (i.e. > > correct and does not cause interop issues) TrustStoreInclusionList is > > the empty list, in which case the certificate will never be presented. > > I think this is making the assumptions that the only choice for clients > is to adopt one "well known" trust store, probably from a short list. I > am concerned that such mechanisms reinforce ongoing centralization of > the web. > > I think this is a worthwhile concern, and while noting that I am an author of this draft, I will attempt to wear a slightly different hat temporarily. In another life I help maintain an OS trust store for non-mainstream clients to access the web. My "choices" today are basically to follow Firefox or Chrome and include most of what they support. (we have basically followed Firefox for many years). We can decide to not include certain CA's that we don't feel have merit, but only if they have very little use. We do not have an effective way to add anything separate or distinct for our clients, as such servers can not also be used with the public web in general. So I think as far as the situation is today, trust store choice is already very centralized if you want your client to "usually work" on the public web. We have basically two choices. both of which are very very similar in their content. I am not certain that trust expressions would change that situation for a non-mainstream client like this, but I don't think that it makes my choices worse. I still have the same choice - follow one of the well known trust stores. I can do this either by continuing as always and not having the client send a trust expression, or, by fetching the trust anchors from a "well known" big trust store and modifying the client to support the necessary things and to send the appropriate trust expression. Were a "new" trustworthy root program to show up with CA partnerships that were useful and made use of trust expressions, a non-mainstream client could potentially start to make use of that as another choice, *If* they trusted the operators of such a program to do a good job of evaluating the trustworthiness of the CA's they were including. -Bob > _______________________________________________ > TLS mailing list -- tls@ietf.org > To unsubscribe send an email to tls-le...@ietf.org >
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
