On Thu, Oct 19, 2023 at 11:38:33AM -0400, David Benjamin 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!
Some quick thoughts: - The multiple certificates from one ACME order really scares me. It seems to me that can lead to all sorts of trouble. - If there can be only one certificate, one could send all the chains in one go via fist sending the certificate, then issuer chains each ended by entry describing the trust anchor. - The latest version and previous version stuff seems pretty confusing to me. - I am not sure this is useful for the client->server direction. What I think is a simpler version that might work: Information from root program to CA: - Root program name. - For each trust anchor: * Trust anchor certificate. * First version TA appeared in. * Expiry time * List of indices. Indices can be reused after all TAs using those have expired. Information from CA to TLS server for each TA: - For each root program: * Root program name * The first version TA appeared in. * List of indices. CA MUST NOT include entries that expire before the certificate. Information from TLS client to TLS server: - Root program name. - Root program version. - List of revoked indices. The revoked indices specifies TAs that have been recently removed before expiry (there could still be unexpired certificates out there). Chain is usable if it includes an entry where: a) Root program name matches, AND b) Root program version is at least the first version, AND c) Intersection of indices and revoked indices is empty. If TLS server has multiple configured certificates, it should skip ones that have no usable chains. If no certificate has usable chain, it should act like the extension was not sent. > ---------- 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> > > 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 -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
