I read both drafts and oppose adoption. I think Dennis'
draft contains good arguments against doing this, and
separately, I think we'd be better off devoting effort
towards efforts that go beyond, rather than fiddle-with,
X.509, so that there's some chance of not needing 50
year old X.509 code in a decade or two.

Cheers,
S.

On 15/01/2025 15:59, Joseph Salowey 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

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature

_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

Reply via email to