I am joining this thread a bit late but have been following the discussion. I want to express my support for Trust Expressions and comment on a few points that have been made.
First, the reality is that websites already have to support multiple certificates to accommodate both ECC and RSA. This is a common reality that will only become more pronounced with the advent of post-quantum cryptography. These certificates typically come from different CA hierarchies, as most customers prefer algorithm-pure chains. The complexity of this is managed by the server or certificate lifecycle management solution they use. For example, Caddy hides all of this from the operator. Therefore, arguments suggesting that this proposal adds complexity seem disconnected from the current operational reality. Regarding the concern about government-mandated adoption of root certificates, I also care deeply about this issue. This is why I am disappointed by the one-sided nature of the conversation. I see no mechanism in this proposal that bypasses operator consent, and while governments do and will continue to force operators to make changes not in their interest, this proposal doesn't change that reality. Continuing to focus on this issue in this way detracts from the more constructive discussions happening in this thread. The most compelling argument against Trust Expressions I see in the thread is the potential for fragmentation. However, the current conversation on this topic overlooks the existing fragmentation challenges faced by site operators. The primary concern I hear from these operators is the anxiety over changes related to cipher suites and certificates, fearing that these changes might inadvertently break services in exchange for security properties that their leadership isn’t asking for. Trust Expressions, in my view, offers a net-positive solution to this problem by allowing site operators to manage the trust anchor portion of this risk, which they cannot do effectively today. At the same time, we are seeing more embedded devices being deployed without long-term maintenance strategies, automatic updates, or mechanisms to manage root store lists. This makes the Web PKI less agile, and Trust Expressions provides a way to manage this reality. Basically, fragmentation is already a present issue and is worsening, making the web less agile. Even if these devices don’t adopt Trust Expressions, it still provides a way to serve a separate certificate to well-maintained clients. So, rather than ignoring the issue, this proposal acknowledges that reality and provides a structured way to manage it. I believe Trust Expressions addresses tangible problems faced by server operators today. While I support continued discussion, I am supportive of this proposal. Ryan Hurst On Thu, May 23, 2024 at 10:40 AM Watson Ladd <watsonbl...@gmail.com> wrote: > On Thu, May 23, 2024 at 12:42 PM David Benjamin <david...@chromium.org> > wrote: > <snip> > > > > Of course, whether this property (whether servers can usefully > pre-deploy not-yet-added trust anchors), which trust expressions does not > have, even matters boils to whether a root program would misinterpret > availability in servers as a sign of CA trustworthiness, when those two are > clearly unrelated to each other. Ultimately, the trustworthiness of CAs is > a subjective social question: do we believe this CA has *and will continue* > only sign true things? We can build measures to retroactively catch issues > like Certificate Transparency, but the key question is fundamentally > forward-looking. The role of a root program is to make judgement calls on > this question. A root program that so misunderstands its role in this > system that it conflates these two isn't going to handle its other > load-bearing responsibilities either. > > As the old saw goes "past performance is no guarantee of future > results, but it sure helps". Moreover root programs have to balance > the benefits of including a CA against the costs. One of those > benefits is the number of sites that use it. > > Sincerely, > Watson > > > > > David > > _______________________________________________ > > TLS mailing list -- tls@ietf.org > > To unsubscribe send an email to tls-le...@ietf.org > > > -- > Astra mortemque praestare gradatim > > _______________________________________________ > 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
