Google Proposes Reducing TLS Cert Life Span to 90 Days

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 :wink:

8 Likes

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?

4 Likes

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.

10 Likes

I'm curious how that CT log you guys run will cope :sweat_smile:

But rooting for it to happen soon! (On a cosmic scale)

1 Like

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

3 Likes

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.

5 Likes

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.

8 Likes

Remember, GitHub - cloudflare/ct-log: A low-cost Certificate Transparency log for deployment in the cloud. exists and we can start from there :wink:

5 Likes

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.
3 Likes

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 :slight_smile:

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.

6 Likes

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.

3 Likes

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"?

2 Likes

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.

7 Likes

Thanks, that seems like a pretty noteworthy change!

4 Likes

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.

7 Likes

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?

3 Likes

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 :stuck_out_tongue: Makes for a shorter certificate if the CRL isn't required to be embedded.

2 Likes

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.

4 Likes