https://www.chromium.org/Home/chromium-security/root-ca-policy/moving-forward-together/
https://www.digicert.com/blog/googles-moving-forward-together-proposals-for-root-ca-policy
12 Likes
Awesome!
Now chop off another 0, delete revocation, and I'll be happy as a clam. 
6 Likes
Or one could just change the units of Days to Hours or Minutes. 
3 Likes
The math is pretty much a straight line [omitting any non-renewals/testing/mistakes/massive revocations]:
- cut the scheduled renewal time in half = double the daily renewal rate [60d down to 30d]
- cut the scheduled renewal time by ten = multiply the daily renewal rate by ten [60d down to 6d]
I'm sure Google is well prepared to up their daily rate [they are (over)funded]
So, what's the current daily limit for LE?
Could LE go any lower than 90 days?
[and should it?]
5 Likes
Google definitely could. I don't know about LE -- mostly thinking about CT logs, not issuance capacity. But if resources currently spent on revocation were dedicated to issuance (as we wouldn't need revocation with such short lifetimes) I bet it'll be within reach for most major CAs.
2 Likes
I would personally love to go to a shorter length than 90 days, especially if it means no OCSP.
Mozilla doesn't check OCSP for certificates under 10 days already. If we could get a CA/B forum ballot and root program updates which allow us to stop serving OCSP for 10-day-or-less certificates, we would definitely jump on that. I am not very well tied into the forum, so I don't know how well that will be accepted by various root programs or other CAs.
We'd free up signing capacity and API bandwidth from OCSP, so those aspects shouldn't be a problem.
Storage would be the major bottleneck, both for CT and our own databases. We're already pushing the limits of our MariaDB-based CA datastore, and we need to shard horizontally. That will be a fairly major project, but should be mostly invisible outside of LE.
Let's Encrypt can scale our own CT logs up too, but we also need other CT operators to scale as well. We're the biggest CA and we have to be careful to not overload other logs -- We've seen in the past when one log goes down, our rebalanced traffic can cause more logs to suffer.
9 Likes
I was surprised to learn of that a few months/years ago. It took a lot of digging to learn about that 10 day span.
From what I've read on this subject, I don't think you'd have much pushback. IIRC, Mozilla implemented their 10 day policy after realizing the realities of the global TLS ecosystem against the other requirements of the Baseline Rules. I think I read one someone involved saying the odds of catching something sooner were incredibly low and not worth the oversized performance hit. None of the major browsers seem to like the OCSP system (Google and Microsoft included), and developed propriety systems around it to "push" info on revoked certificates to clients at an accelerated pace.
4 Likes
By default all certificates issued by Google Trust Services are good for up to 90 days; however, ACME allows for clients to request certificates with different validity periods. Using this capability we allow the requestor to get certificates that are good for as little as 1 day, though we would not recommend using anything less than 3 days due to concerns over clock skew and certificate validity overlap.
I can see there will be big headache for a certificate with such a short lifetime. The problem I face is bureaucracy, which renewing a certificate can have a 2-week wait for approval procedure and wait in the support queue, and the internet-facing server is NOT ALLOWED to have outgoing internet access (You read it right, it accepts traffic from internet, but the server itself is not allowed to have outgoing internet access. Therefore ACME is not possible, cert renewal must be done manually)...
You can fix this by using DNS validation instead of HTTP validation, then renewing on another machine and scripting the deployment that server. Where a manual process is absolutely required you can make the final script run part just be part of the weekly maintenance window.
ACME allows for clients to specify when they want certs to expire but this is usually ignored by the CA (Google Trust Service does honour requests for short expiry, Let's Encrypt currently doesn't), so it would make sense for certs to still be allowed to be 90 days, but also support short lifetimes where the client wants that.
3 Likes
While it's true they have lots of money they may not be entirely prepared to pour it into certs - they did make recent major cuts to their team for managing ACME etc ("trust services"), which is disappointing.
3 Likes
This is impossible either. The problem is I don't have full access to the appliance concerned, I can upload the cert (and only can only be done manually), but actual cert deployment need a support ticket and need supervisor approval and wait on support queue...
I would say the platform concerned is probably designed to be anti-automatic and anti-agile...
Things have a way of becoming possible over time! The existing process does sound antiquated but it's not so unusual. Raise it as a concern then continue as normal, cert expiry is a good catalyst for change.
4 Likes
hmm...
Challenge accepted!
A. Please be more detailed on exactly what traffic it can accept
B. Please be more detailed on exactly what can be uploaded [and where]
And...
This seems to be straying OT - maybe it should be moved to another one.
4 Likes
btw there are clients that use hardcoded days (like 30 days before expire) for renewal timer.
whose client will start to renew everyday if cert life is too short because, well, there are short amount of days left to renew.
2 Likes
it is a WAF appliance, which only forwards port 80 and 443 traffic to backend. And note that the backend server cannot access internet either.
I can upload the cert and key to the WAF appliance through its web interface, but actually assigning the cert+key pair to the virtual WAF instance needs a support ticket.
Anyway as you mentioned this is OT. I just want to share my concern about my actual headache will face when short lifetime will be imposed.
Please allow me talking about an ideal world just for a moment. What about the load of OCSP service, if all TLS server endpoints would take seriously the task of providing OCSP stapling?
2 Likes
almost no change as LE sign and caches ocsp response of all cert every 3 days currently anyway, and kess traffic for responder but they are caned anyway
3 Likes
And what about OCSP signing only on cache miss?
Sorry, I was too fast asking question, it would not help in practice.
2nd EDIT: Do not sign the certificate every 3 days. Sign it at creation time, and cache it. Serve it from the cache with short validity time (~1 day). Change the cache only if the OCSP status of a cert changed, for example revocation.
2 Likes
I mean LE doesn't create oscp responses on demand, but always have response with more than half its lifetime (7days iirc) prepared
3 Likes