Rename to standalone and landmark certificates

[davidben]

Closes #163

[lukevalenta]

I really like this edit. It makes the relationship between landmark certificates and landmark tree sizes very clear.

[initsecret]

reads well to me.

on a tangent, the terminology section got me wondering if a standalone cert would ever present an inclusion proof to a not-landmark subtree. That seems analogous to signing an end certificate with the root certificate.

[davidben]

on a tangent, the terminology section got me wondering if a standalone cert would ever present an inclusion proof to a not-landmark subtree. That seems analogous to signing an end certificate with the root certificate.

I expect inclusion proof to non-landmark subtree to be the default case for standalone certs. :-) Part of the point of a standalone cert is to that you can get a cert immediately (imagine having to rekey in a hurry). That means you don't want to wait for a landmark.

The way I've imagined this is that you have two checkpoint feeds, a fast one and a slow (landmark) one. Your fast one runs about as fast as you're able to generate signatures and ping witnesses/mirrors. Let's say that's every 30 seconds. So every 30 seconds, you mint a new fast checkpoint, and collect cosigs. Then you can generate standalone certificates based on the subtree(s) between the last fast checkpoint and the current one. If you look at it funny, this is kind of like a batch signing scheme.

Then there's a slow feed of checkpoints which is every couple of hours (the landmarks). Now, you could use that feed to generate standalone certs too, but there's not much point. You may as well use the fast feed. The only reason for the slow feed is so the total number of live checkpoints is small and predistributable. So we use those to generate the landmark certificates, without cosignatures.

[davidben]

Your fast one runs about as fast as you're able to generate signatures and ping witnesses/mirrors.

handwave handwave unless we decide to lightly throttle those for the sake of better auditing, as in Section 5.2 of this paper, but not the priority to solve right now. 😄

[initsecret]

I really like the amortization of signature cost model, it’s how I explain this to myself.

Good point on fast re-keying, I wasn’t thinking of that case. I’m on a bus and can’t do math¹, but have y’all run numbers on this. I feel like there’s a tension here between landmark epoch lengths and efficiency.

Footnotes

1. unrelated facts :3 ↩

[aww-aww]

nit: s/,/and/