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.
-- Christian Huitema
_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
