I support adoption I still like the framing I gave in my last email: The current solution to trust anchor agility is path building / cross-signing. So the question is whether an incremental improvement on path building is feasible, or if Something Else is needed. I firmly believe that path building is unsalvageable. In addition to the interim discussions, this blog post [1] by Ryan Sleevi was very convincing to me. The TAI draft says that path building MAY be disabled, I would obviously make this MUST.
1. https://medium.com/@sleevi_/path-building-vs-path-verifying-the-chain-of-pain-9fbab861d7d6 On Wed, Jan 15, 2025 at 2:11 PM Ryan Hurst <ryan.hu...@gmail.com> wrote: > As someone with experience building and managing many CAs, running a root > program, and building out platform technology to enable TLS use cases, I > believe this work is important and fully support its adoption. Today’s > manual, out-of-band management of trust anchors not only holds the web back > but also unnecessarily exposes users to trust anchors that are not > essential for enabling TLS on the web. This proposal provides a credible > path to address this lack of agility. While it’s clear that this > slow-moving and fragile approach is already problematic, it will only > become more challenging as time goes on. As with all specifications, > adoption remains the key challenge, but I believe this draft offers a > practical solution to these issues without disrupting existing systems. > > Ryan Hurst > > On Wed, Jan 15, 2025 at 8:00 AM Joseph Salowey <j...@salowey.net> wrote: > >> At the trust tussle Interim in October we had consensus that the working >> group was interested in working on the following problem: >> >> “Avoid client trust conflicts by enabling servers to reliably and >> efficiently support clients with diverse trust anchor lists, particularly >> in larger PKIs where the existing certificate_authorities extension is not >> viable” >> >> After IETF 121, we asked for submissions for possible working group >> adoption as a starting point for this work. We received two submissions: >> >> [1] Trust Anchor Identifiers, draft-beck-tls-trust-anchor-ids-03 >> <https://datatracker.ietf.org/doc/draft-beck-tls-trust-anchor-ids/> >> >> [2] Trust is non-negotiable, draft-jackson-tls-trust-is-nonnegotiable-00 >> <https://datatracker.ietf.org/doc/draft-jackson-tls-trust-is-nonnegotiable/> >> >> [1] defines a new protocol mechanism, while [2] provides an explanation >> of why the mechanism in [1] may not be needed and may be problematic. Since >> the second draft does not define a protocol mechanism we are not >> considering it for adoption, but we request that working group members >> review both documents and use [2] as input into determining whether we >> should adopt [1] as a working group item. Adoption as a working group item >> means the working group has change control over and can modify it as >> necessary; an adopted document is only a starting point. Please respond to >> this thread if you think the document should be adopted as a working group >> item. If you think the document is not appropriate for adoption please >> indicate why. This adoption call will close on February 7, 2025. Also >> please remember to maintain professional behavior and keep the discussion >> focused on technical issues. >> >> >> Thanks, >> >> >> Sean, Deirdre and Joe >> >> _______________________________________________ >> 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 >
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
