3 ms·
There's a section missing on the inclusion proof and what exactly the clients will be getting. If I understand this correctly each CA publishes a signed list o
by matthewaveryusa 1y ago
There's a section missing on the inclusion proof and what exactly the clients will be getting.
If I understand this correctly each CA publishes a signed list of landmarks at some cadence (weekly)
For the certs you get the landmark (a 256-bit hash) and the hashes along the merkle path to the leaf cert's hash. For a landmark that contains N certs, you need to include log2(N) * hash_len bytes and perform log2(N) hash computations.
For a MTC signature that uses a 256bit hash and N=1 million that's about 20*32=620bytes.
Is this the gist of it?
I'm really curious about the math behind deciding the optimal landmark size and publishing cadence
- mcpherrinm 1y agoYeah. From the RFC draft: > If a new landmark is allocated every hour, signatureless certificate subtrees will span around 4,400,000 certificates, leading to 23 hashes in the inclusion proof, giving an inclusion proof size of 736 bytes, with no signatures. https://davidben.github.io/merkle-tree-certs/draft-davidben-tls-merkle-tree-certs.html#name-size-estimates https://davidben.github.io/merkle-tree-certs/draft-davidben-... That's assuming 4.4 million certs per landmark, a bit bigger than your estimate. There's also a "full certificate" which includes signatures, for clients who don't have up-to-date landmarks. Those are big still, but if it's just for the occasional "curl" command, that's not the end of the world for many clients.
- politelemon 1y agoDoes this mean that some https fetch activities could break if a machine hasn't run sudo apt upgrade in a while?