I support adoption. As our PKIs change, we need mechanisms to allow servers to move forward, while maintaining widespread compatibility. While currently available mechanisms (eg cross signing) can help in some circumstances, they are not sufficient.
Trust negotiation has unique challenges, and as with any negotiation mechanism, has risks it could be used to negotiate something we find undesirable, but I believe our experience with negotiation of other parameters and properties in the TLS ecosystem have shown the advantages of an explicit negotiation far outweigh the downsides. The trust anchor draft is a good starting point towards that. From: Joseph Salowey <j...@salowey.net> Sent: Wednesday, January 15, 2025 10:59 AM To: <tls@ietf.org> <tls@ietf.org> Subject: [TLS] Adoption Call for Trust Anchor IDs 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 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://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-beck-tls-trust-anchor-ids/__;!!Bt8RZUm9aw!6T0ClH1gMBEuJrg3t_yxTnfmF3UJl9FI27FhJgDeuROq-2NN9JYJslgs8vPil89Y6GM3ncvLKg$> [2] Trust is non-negotiable, draft-jackson-tls-trust-is-nonnegotiable-00<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-jackson-tls-trust-is-nonnegotiable/__;!!Bt8RZUm9aw!6T0ClH1gMBEuJrg3t_yxTnfmF3UJl9FI27FhJgDeuROq-2NN9JYJslgs8vPil89Y6GOjCSs7Kg$> [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
