I support adoption. I personally agree with the consensus from the trust tussle interim - I do think we should work on the problem as described. Not that that opinion is particularly relevant, because the consensus has already been declared by the chairs anyway. On that note, I haven't seen new information that would warrant reopening that consensus call. I found the trust-is-nonnegotiable draft to be well-written -- though perhaps heavy on the amount it was citing the TAI draft -- but I did not find information in it that hadn't already been said or written on the topic so far.
Now that we agree that we want to work on that problem, I think that TAI is a reasonable starting point. I find it more compelling than other ideas discussed in this thread, such as extending HSTS. I agree that this space might have risks, but as we iterate on that solution, I trust in our collective ability to design something that solves the problems and mitigates those issues. Thanks, David On Wed, Jan 15, 2025 at 8:01 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
