3 ms·
We have a similar approach planned in sigstore, but with a slightly different approach to the timestamps by using Transparency Logs. We have some demos here on
by dlor 6y ago
We have a similar approach planned in sigstore, but with a slightly different approach to the timestamps by using Transparency Logs. We have some demos here on how to sign git commits: https://github.com/sigstore/cosign/blob/main/FUN.md https://github.com/sigstore/cosign/blob/main/FUN.md
The idea is that you can use short-lived keys, bound to certificates via an ACME-style challenge, but based on an email address. The signature goes into a Transparency log to prove it happened while the cert was valid. Then revocation is no longer an issue.
- petertodd 6y agoSo a big problem with that is that the long term durability of transparency logs is doubtful. Being a record of every SSL cert ever issued, they're an enormous amount of data, and I won't be surprised if actually getting that data in the future becomes hard. OTS just depends on the Bitcoin block headers (megabytes/year), and the databases of timestamps maintained by the public calenders, (a few GB/year; it's new entry per calendar per second). It's a more easier to archive a few GB of data than the tens of terabytes in the public CT logs.