On Tue, Jun 11, 2024 at 3:25 AM Dennis Jackson <ietf= 40dennis-jackson...@dmarc.ietf.org> wrote:
> I think the above captures the main thrust of your argument in this > thread, but it seems like quite a flawed analysis. If T.E. does not offer > any new capabilities over certificate_authorities, then there is no point > in standardizing it at all. Conversely, arguments that T.E. is a much more > effective mechanism for deploying trust negotiation than > certificate_authorities undermines the claim that T.E. doesn't introduce > new risks that merit discussion. > This is a false dichotomy. TE offers an incremental improvement on certificate_authorities. > > In terms of the differences between the existing certificate_authorities > extension and Trust Expressions, I want to enumerate a few: > > Firstly, certificate_authorities is impractical at any kind of scale > because it requires listing the distinguished name of every CA in the > ClientHello (as you noted). This makes the size blowup is a huge impediment > to actually using it for anything other than in a private PKI setting e.g. > for indicating which client_certs a server would like to see. > > Secondly, certificate_authorities is very poorly supported today. TLS > libraries typically ignore it e.g. OpenSSL requires custom callbacks to > integrate it [2] - I couldn't find anything actually calling this function. > Neither BoringSSL nor NSS support it in ClientHellos as far as can tell. > > Thirdly, certificate_authorities doesn't have any of the machinery > necessary to orchestrate deploying it. Trust Expressions envisions ACME / > TLS Servers implementations and CAs cooperating to distribute these trust > labels to subscribers without requiring them to do any configuration > themselves. > > Trust Expressions proposes to solve all of these drawbacks with > certificate_authorities. The first is achieved by replacing the long list > of distinguished names with a single identifier. The second is to ship > support across servers and clients and make sure it is well exercised and > indeed required. The third is to ensure that CAs can deliver multiple > certificate chains to clients and that clients can transparently select > between them based on a trust label. > > Consequently, T.E. does meaningfully change the calculus over > certificate_authorities and so there are number of active threads > discussing the risks of enabling trust negotiation and evaluating how it > can be abused. > If Trust Expressions does meaningfully change the calculus compared to certificate_authorities, it does it in a way that lessens risk. The certificate_authorities extension doesn't scale support the legitimate use case of trust negotiation/advertisement that Trust Expressions supports, but this problem doesn't exist for certificate_authorities advertising a single government CA. In your first example of how certificate_authorities differs from Trust Expressions, you've given an example of how Trust Expressions is less risky than certificate_authorities. The complexity of deploying certificate_authorities for the government CA "risky" use case is much less than it is for Trust Expressions. The "risky" use case requires clients advertise the name of the CA, and it requires servers to be able to match a name in the certificate_authorities extension against one of its multiple certificates. This deployment has no machinery with CAs, ACME servers, or root programs publishing manifests. When you say certificate_authorities doesn't have any of the machinery necessary, that's because it doesn't need any such machinery, as Devon explained in point 4. In the "risky" use case, Trust Expressions requires the government to implement or compel more actions than it would with certificate_authorities. Starting with the clients, it would need to compel root programs to manage and publish an additional trust store manifest (or manage its own trust store manifest and compel advertisement of that as part of compelling trust). It would also need to have its CA (and the CA's ACME server) support the government trust store in its CertificatePropertyList. It looks like there's a lot more compulsion involved in this government-forced trust use case when the government uses Trust Expressions instead of certificate_authorities.
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
