There is merit in the proposed approach. However, it will require co-operation of several players in the ecosystems. I've already seen an email from a TLS library author who isn't keen on this I-D.
I'm curious about at least a PoC implementation of this I-D ? On Wed, 15 Jan 2025 at 20:27, Bob Beck <b...@obtuse.com> wrote: > > Rather obviously, I support adoption. > > I believe TAI is a good starting point for a practical solution for the > problem we agreed was a useful thing to solve at the interim. > > > > On Jan 15, 2025, at 8:59 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 > > [2] Trust is non-negotiable, draft-jackson-tls-trust-is-nonnegotiable-00 > > > > [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
