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!
Emily Stark /
npub1re…ht545
2023-05-01 23:22:01
Author Public Key
npub1rex70pzwcky27tsctwper2dcpd52slcxjmasen9qrfwlx6zrl80q5ht545Published at
2023-05-01 23:22:01Event JSON
{
"id": "d6609ce8b56f15e0456ff79b05b45003058bc255d9a812800cb12aeae84a9a52",
"pubkey": "1e4de7844ec588af2e185b8391a9b80b68a87f0696fb0ccca01a5df36843f9de",
"created_at": 1682983321,
"kind": 1,
"tags": [
[
"mostr",
"https://infosec.exchange/users/estark/statuses/110295994936922518"
]
],
"content": "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\n\nThe idea is to store domain name\u003c-\u003epublic 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.\n\nThe main motivation is postquantum cryptography; PQ signatures are huge and this scheme allows a client to verify a domain name \u003c-\u003e 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.\n\nAll credit to my colleagues David Benjamin and Devon O'Brien!",
"sig": "6ee33a0b01581455ab756dbbc3e7d49fbfd76a23fa120433f7c0f48bf4b9c517e020e6ee2541e61bc9fc4e9d9acbb3c06b36ac56513a0bb8817aefca139fb801"
}