On Mon, Jul 22, 2024 at 11:27:37AM -0700, Dennis Jackson wrote: > On 22/07/2024 11:00, Mike Shaver wrote: > > 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.
Yeah, access to DNS records is very problematic. And retrying handshake is something even more problematic. I don't see TE requiring breaking API changes on client: API that lets one add a set of (pseudo) trust anchors plus TE advertisement for those should work? Server-side both require much more extensive API changes. However, I think that it is feasible to add support without breaking API changes (by extending certificate loading to support alternate issuer chains [1]). [1] Or if TLS library has reified issuers (however, I do not know any stable TLS library that does), extending those to support alternate chains. If TLS library does file parsing, one might even not need any API changes. -Ilari _______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
