[TLS] Re: Adoption Call for Trust Anchor IDs

[David Schinazi <[e-mail]>]

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 <[e-mail]> 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 -- [e-mail]
> To unsubscribe send an email to [e-mail]
>