On 22/07/2024 11:00, Mike Shaver wrote:
I’m not informed enough to comment on the protocol elements of the
specific Trust Anchor proposal, but I agree that more PKI agility will
be healthy.
[...]
Trust Anchor negotiation will require configuration of both sides, but
so does cipher negotiation and so forth, and I think that it will be
fine for a library to come with “sane, web-like” defaults, and then
provide a mechanism for configuring alternative policies when desired.
I think reading the drafts would be really valuable. Unfortunately the
necessary changes are not as simple as anything like cipher selection.
For example, Trust Anchors requires the TLS Library to have access to
additional DNS records, which either the application needs to provide or
the TLS Library needs to fetch itself - neither seem viable by default.
Both drafts also require other breaking API changes on client and server.
This would let modern clients like browsers continue to tend to the
web PKI, without the opposing force of such possible disruptions. From
my experience with root programs, this would be a very welcome capability!
I would love to hear more about these possible disruptions you feel are
a factor> Speaking as someone who is involved in a root program
currently, I don't understand how Trust Anchor Agility would enable
anything for us - discussed at more length here [2].
Best,
Dennis
[2]
https://github.com/dennisjackson/trust-negotiation-comments/blob/main/comments-on-usecases.md
_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
