[TLS] Re: Adoption Call for Trust Anchor IDs

[Joseph Salowey <[e-mail]>]

The adoption call for draft-beck-tls-trust-anchor-ids-03
<https://datatracker.ietf.org/doc/draft-beck-tls-trust-anchor-ids/> has
completed. The chairs judge that there is consensus to adopt this draft.
The consensus of the group was rough with people weighing in on both sides.
>From the discussion it's clear that the draft and approach will need more
work. Since this is an area the working group has expressed interest in,
the chairs believe that it is better for this development and discussion to
happen within the working group.  The adoption of this draft does not
preclude the adoption of other drafts based on other ideas in this area,
such as those discussed on the list. These additional drafts may influence
or even supersede the direction of this work. We hope for productive
discussion and collaboration within the working group.

Thanks,

Joe, Sean, and Deirdre

On Wed, Jan 15, 2025 at 7:59 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
>
>