This is very awesome. Just some quick thoughts: This extension seems very useful in internal environments with their own proprietary PKI. The first bullet in the intro does get at this, but I think it still undersells just how compelling this extension would be. FSIs/Banks, Governments, technology companies often have CAs with validities in short durations and have to perform rotations very often. This extension makes that so much more manageable and safer. I think there's a strong internet stability argument here ... many large outages of organizations have been caused by mishandling these rotations.
In the security / privacy considerations: 1. Since this extension can appear in the CH in the clear, should we consider the case where network operators may use it to "enforce" support of particular trust anchors? For example, a firewall may reject connections based on anchors that do or don't support. and 2. Is this another fingerprint, at least at system level? For example; corporate user's whose organizations who add their own TAs may become finger-printable as coming from those organizations. Why sort TrustStores first by name-length, and then lexicographically? Just seems a little unnecessarily complex and unfriendly to indices. On Thu, Oct 19, 2023 at 8:38 AM David Benjamin <david...@chromium.org> wrote: > > Hi all, > > We just published a document on certificate negotiation. It's a TLS > extension, which allows the client to communicate which trust anchors it > supports, primarily focused on use cases like the Web PKI where trust stores > are fairly large. There is also a supporting ACME extension, to allow CAs to > provision multiple certificate chains on a server, with enough metadata to > match against what the client sends. (It also works in the other direction > for client certificates.) > > The hope is this can build towards a more agile and flexible PKI. In > particular, the Use Cases section of the document details some scenarios > (e.g. root rotation) that can be made much more robust with it. > > It's very much a draft-00, but we're eager to hear your thoughts on it! > > David, Devon, and Bob > > ---------- Forwarded message --------- > From: <internet-dra...@ietf.org> > Date: Thu, Oct 19, 2023 at 11:36 AM > Subject: New Version Notification for draft-davidben-tls-trust-expr-00.txt > To: Bob Beck <b...@google.com>, David Benjamin <david...@google.com>, Devon > O'Brien <asymmet...@google.com> > > > A new version of Internet-Draft draft-davidben-tls-trust-expr-00.txt has been > successfully submitted by David Benjamin and posted to the > IETF repository. > > Name: draft-davidben-tls-trust-expr > Revision: 00 > Title: TLS Trust Expressions > Date: 2023-10-19 > Group: Individual Submission > Pages: 35 > URL: https://www.ietf.org/archive/id/draft-davidben-tls-trust-expr-00.txt > Status: https://datatracker.ietf.org/doc/draft-davidben-tls-trust-expr/ > HTML: > https://www.ietf.org/archive/id/draft-davidben-tls-trust-expr-00.html > HTMLized: https://datatracker.ietf.org/doc/html/draft-davidben-tls-trust-expr > > > Abstract: > > This document defines TLS trust expressions, a mechanism for relying > parties to succinctly convey trusted certification authorities to > subscribers by referencing named and versioned trust stores. It also > defines supporting mechanisms for subscribers to evaluate these trust > expressions, and select one of several available certification paths > to present. This enables a multi-certificate deployment model, for a > more agile and flexible PKI that can better meet security > requirements. > > > > The IETF Secretariat > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- Colm _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
