Comment by benjiro | Hacker News Reader

Comment by benjiro | Hacker News Reader

Parent Full thread

You know that the original idea was to drop it to 17 days?! And i think that is still on the books.

To be honest, the issue is not the time frame, you can literally have certs being made every day. And there are plenty of ways to automated this. The issue is the CT log providers are going to go ape!

Right now, we are at 24B certificates going back to around 2017 when they really started to grow. There are about 4.5B unique domains, if we reduce this to the amount of certs per domain, its about 2.3B domain certs we currently need.

Now do 2.3B, x 8 renewals ... This is only about 18,4B new certs in CT logs per year. Given how popular LE is, we can assume that the actual growth is maybe 10B per year (those that still use 1 year or multi year + the tons of LE generated ones).

Remember, i said the total going back to 2017 currently is now only 24B ... Yea, we are going to almost double the amount of certs in CT logs, every two years.

And that assumes LE does not move to 17 days, because then i am sure we are doubling the current amount, each year.

Good luck as a CT log provider... fyi, a typical certificate to store is about 4.5kb, we are talking 45TB of space needing per year, and 100TB+ if they really drop it down to 17 days. And we did not talk databases, traffic to the CT logs, etc...

Its broken Jim ... Now imagine for fun, a daily cert, ... 1700TB per year in CT log storage?

A new system will come from Google etc because its going to become unaffordable, even for those companies.

Have you heard the good news of Merkle Tree Certificates[1,2]? They include the transparency cryptography directly in the certificate issuance pipeline. This has multiple benefits, one of them being way smaller transparency logs.

1: https://www.youtube.com/watch?v=uSP9uT_wBDw A great explainer of how they work and why they're better.

2: https://davidben.github.io/merkle-tree-certs/draft-davidben-... The current working draft

Yep ... Saves about 40%, seen one of the implementations. One of the guys posting here from time to time has a working version.

I am a CT log operator and I hands down support short-lived certificates. Automation and short lifetimes solve a lot of the pain points of the WebPKI.

We can solve the storage requirements, it’s fine.

Is there a big use case for permanent CT logs of long-expired certificate?

Tons of information for research, hackers, you name it ... It shows a history of domains, you can find hidden subdomains, still active, revoked etc ...

Do not forget that we had insane long certificates not that long ago.

The main issue is that currently you can not easily revoke certs, so your almost forced to keep a history of certs, and when one has been revoked in the CT logs.

In theory, if everybody is forced to change certs every 47 days, sure, you can invalidated them and permanently remove them. But it requires a ton of automatization on the user side. There is still way too much software that relies on a single year or multi year certificated that is manually added to it. Its also why the fadeout to 47 days, is over a 4 year time periode.

And it still does not change the massive increased in requests to check validation, that hits CT logs providers.

> Tons of information for research, hackers, you name it ... It shows a history of domains, you can find hidden subdomains, still active, revoked etc ...

You can store that kind of information in a lot less space. It doesn't need to be duplicated with each renewal.

> The main issue is that currently you can not easily revoke certs, so your almost forced to keep a history of certs, and when one has been revoked in the CT logs.

This is based on the number of active certificates, which has almost no connection with how long they last.

> There is still way too much software that relies on a single year or multi year certificated that is manually added to it.

Hopefully less and less going forward.

> And it still does not change the massive increased in requests to check validation, that hits CT logs providers.

I'm not really sure how that works but yeah someone needs to pay for that.

Where did you get 17 days from?

There was talking going on in one of the CA/Browser Forum regarding certificate expirations, and how they looked at potentially 17 days. The 45 days was a compromise, but the whole 17 days was never removed from the table, and was still considered as a future option.

Honestly don't recall discussing 17 days, but I could be wrong. 47 days was a 'compromise' in that it's a step-down over a few years rather than a single big-bang event dropping from 397->90/47/less.

Reply on news.ycombinator.com