It's a bit more complicated than that, needing a supermajority of Certificate Issuers and a majority of Certificate Consumers, plus also a quorum needs to be met. Almost as complicated as X.509 is
I'm interested what LE is going to do now. @mcpherrinm already said LE (I'm guessing is meant with "we") is going to "jump on that" if OCSP wasn't required for these short-term certs (which, if I read SC-063 v4 correctly, is indeed the case).
But I guess the root programs need modification too after the ballot has passed? So it's step for step and might take a while?
It'll be a while for the ballot to come into effect, and at a minimum Microsoft's root program still requires OCSP. But we're definitely thinking about what comes next here. There's a bunch of upcoming scale work we'll still need to do first, as well. This is like a "years" timeline though, not a "months" one.
I'm curious how that CT log you guys run will cope
But rooting for it to happen soon! (On a cosmic scale)
I kinda wonder yet it allows 10-day to be considered short-lifed until 2026 than reduce it to 7 days, not starting with 7 days from beginning. I know it was to align with ocsp lifetime but nobody would implement new thing while it'll break in next 3 years
I interpreted this bit as being a safe buffer for the migration to 7 days under the new rules to incentivize early adoption. The way the changes are structured, they define a new "Short Lived Certificate" concept that has a different rules applied to it. A CA could start issuing under the new requirements with max-10 days, giving the time to scale up the resources needed for max-7 days if they wanted to. In a worst case scenario, a misiussed/revoked 10 day cert will behave like a current revoked certificate under OCSP. If a CA feels like they can push ahead with 7 days, they can.
There could be other reasons going on, but it just jumps out at me that offering the extra 3 days gives a nice buffer to get infrastructure up to speed and test all this out in production - while maintaining the same security concerns the current BRs do with OSCP. On a single domain cert with renewal 2/3 of the way through - 10 day certs are about 50 renewals a year, and 7 day certs are about 75. When you're coming from 90 day certs at 6 renewals a year, that is significant scaling.
CT log volume is definitely a concern for us as log operators. Boulder's database is also going to be a problem with shorter-lived certs, for largely the same reasons: They're a single MySQL or MariaDB instance.
I want to write a new CT storage engine that's based on "Object Storage" (S3 or the s3-compatible minio) which should have scale properties that match a CT log's append-only properties with scale-out read better than a relational database.
We're also working on horizontally sharding boulder's database too.
Remember, GitHub - cloudflare/ct-log: A low-cost Certificate Transparency log for deployment in the cloud. exists and we can start from there
Cloudflare’s CT log is also largely based on trillian.
What about using distributed DBs like MariaDB XPand or TiDB.
I don't know the technical needs, so I'll just drop some things on your radar if you haven't considered them yet:
- Ceph has an S3 compatibility layer and may be a better fit than minio. RedHat bought it a while back, and uses it as their cloud storage for openstack among other things.
- I really like column storage stuff for large and growing datasets, but my experience is Advertising and Marketing analytics - not logging or providing public reads. Cassandra might be a usable option too, as it's a bit of a hybrid system.
I've been fiddling with some CT log stuff in my spare time, so this isn't really a Let's Encrypt project at all (...at least yet!), but I think we should be able to scale CT up significantly without big cost increases.
I think what I want is to use actual S3 to allow full public access to the underlying dataset in a well-supported format (probably https://delta.io/, maybe just plain parquet), since we can do requester-pays access. One problem people have with CT today is that the underlying datasets are somewhat challenging to scrape, so providing the data in a format amenable to being incorporated into a data-analytics pipeline directly. And the version of this that's going to run on my dev/home server can use minio, which is already there
The actual served traffic via CT APIs would ideally very infrequently read from S3, and instead serve from cheaper tiered caching - ephemeral disks on VMs, hot records in memory, etc. The magic of append-only datastores means there's no cache invalidation!
Personally I also want some ecosystem variance and don't want to base this on Trillian at all, as most of the other logs are using that.
I have done that before. It's great. If the reads are low enough, you can even use Glacier for storage and really cut costs.
I'm confused about what the change implemented by the new ballot is. Is there a new upper validity limit for all certs, or just "short-lived certs"? And is there a new no-OCSP-requirement for all certs, or just "short-lived certs"?
normal validity limit is unchanged and CRL is now required, OCSP is now optional.
short-lived certs are limited to 10days and doesn't require any revocation method.
Thanks, that seems like a pretty noteworthy change!
after I re-read the change, I realize CA with only short-lived certificates still have to generate CRL, but as they don't need to revoke it anyway, it can be always empty one.
That's kind of funny; do you think the ballot authors intended that result? A certificate authority could just intentionally host an empty CRL file forever?
If having a CRL is mandatory, but revoking isn't, the CRL wil be empty forever indeed.
An addendum for that very specific situation might be helpful I guess Makes for a shorter certificate if the CRL isn't required to be embedded.
I think that is intended, as there is nothing technical that binds a CA is only able to sign short-lifed certs, so if there is a way to revoke those hypocritical longish life certificates.