Danny O'BMay 2, 2023
Emily Stark

The (very early stage) draft of Merkle Tree Certificates is worth a read if you haven't already: https://www.ietf.org/id/draft-davidben-tls-merkle-tree-certs-00.html

The idea is to store domain name<->public key bindings in a Merkle tree, mirrored by browser vendors or other designated entities to clients and other interested parties. TLS servers are authenticated via a proof of membership in one of these Merkle trees, instead of via a bunch of signatures in an X.509 certificate chain -- which are huge in a postquantum world. This new form of authentication only works for certain types of clients and certain types of situations, so the whole thing falls back to traditional X.509 certificate chains otherwise. You can think of it as a PKI designed from scratch, with CAs and CT smooshed into one system, as an optimization layer on top of today's web PKI.

The main motivation is postquantum cryptography; PQ signatures are huge and this scheme allows a client to verify a domain name <-> public key association with 0 signatures. The Merkle tree proof is no bigger in a PQ world. There are lots of other interesting properties that MTCs lets us explore too, like being able to negotiate trust anchors -- that is, a client can signal which CAs it supports and the server can authenticate itself in a way that works with those supported CAs. In contrast today a server has to configure a single certificate to work with all clients it wants to support. This part isn't fully fleshed out yet but it's exciting. It's a great time to give feedback on the draft.

All credit to my colleagues David Benjamin and Devon O'Brien!

Merkle Tree Certificates for TLS

This document describes Merkle Tree certificates, a new certificate type for use with TLS. A relying party that regularly fetches information from a transparency service can use this certificate type as a size optimization over more conventional mechanisms with post-quantum signatures. Merkle Tree certificates integrate the roles of X.509 and Certificate Transparency, achieving comparable security properties with a smaller message size, at the cost of more limited applicability.

May 1, 2023 at 11:22pmWeb
Show threadmedium rare birdMay 4, 2023
@estark all of this sounds great except for "a client can signal which CAs it supports". I don't think we should add more fingerprintable signals to clients.
Show threadClemensMay 4, 2023

@estark my main gripe about this is that it falls back to X.509, i.e., it doesn't reduce complexity, but adds even more.

In the worst case this will work in Chrome with Google's servers and nowhere else. Let's hope that won't manifest, but it sure would be nice if we could actually simplify the stack instead of adding more layers.