Unsurprisingly, I support adoption. Some form of trust anchor negotiation is a requirement for a robust post-quantum web PKI.
> I'm curious about at least a PoC implementation of this I-D At minimum, Chrome/BoringSSL are planning on implementing the draft. -dadrian On Tue, Jan 21, 2025 at 8:09 AM Loganaden Velvindron <logana...@gmail.com> wrote: > 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 >
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
