Hacker News new | past | comments | ask | show | jobs | submit login

The one that always sticks out is the certs’ extremely short expiration period. The IMHO weak rationale for this was mentioned in another thread here (See jjeaff‘s response upthread).

It would be nice if they simply offered two choices:

1. I love automation! Give me a 90 day certificate.

2. I understand the security trade-offs. Give me a 3 year certificate.




But issuing 3-year certificates would disqualify them as a CA: https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-...


Can you elaborate as to why that would disqualify them? I don't think most of us are intimately familiar with the Baseline Requirements, or want to wade through 60-some pages to figure out your reasoning.


Three years is much too long. Last year Google's Ryan Sleevi basically said this needs to be much shorter, it takes far too long to fix anything properly with such long-lived certs. Ryan pointed out that it they couldn't get traction by agreement then Chrome can totally just be modified to count certs as expiring after 90 days and that's that. Unsurprisingly CAs did not go "OK we'll do what Ryan suggests, 90 days it is" but they also didn't try to stick with the status quo of 39 months and call Ryan's bluff. The compromise that got enough votes was 825 days for all certs after 1 March 2018.

For future reference - the BRs have a section with a timeline, it's great for finding upcoming or recent changes significant enough that the CAs needed a deadline.


So a bunch of centrally controlled monopolies agreed to realign their offerings to maximize profit and gain greater control over end-user.

They also pretend, that compromising 3-months certificate is "ok" (or at least less harmful, than compromising a year-long certificate), when in practice there is no reason to assume so, — 3 months is more than enough for any real-life eavesdropper.


No?

Firstly, CA/B explicitly can't talk about pricing or product offerings, because a group of businesses that collaborate on setting prices or product offerings is called a Cartel and is illegal (the example you're probably thinking of, OPEC, exists because its members are sovereign entities, and thus enjoy total immunity from the law). When they meet in person the CA/B members always begin by reading out the rules that lay out what mustn't be discussed for this reason.

Secondly, the idea is not at all that compromising 3-month certs is "ok". Instead Ryan's focus is on the pace of change. During 2016 CAs agreed to use the Ten Blessed Methods for validation, in 2017 that agreement became a concrete rule (thanks to Mozilla) but a 39 month certificate issued under the prior validation status quo would still be trusted until mid-2020.

Historically what has happened is that there's a grace period, and then CAs are supposed to go back and revoke any certificates still outstanding that break the new rules. But this is error-prone, back in early 2017 you can see the list of violations I found while checking that certificates for now prohibited "internal" names were revoked as required, each CA had excuses for why they'd missed some, but the overall lesson is that things will be mised. So Ryan doesn't want to rely on grace periods, he wants a shorter window of validity for the certificates.

MD5 and SHA-1 is the go-to example for this stuff. We expect already that SHA-2 (e.g. SHA-256 used currently in certificates) will fall the same way as the others, because it's the same construction, so we're going to be doing this again in perhaps 5-10 years. But with 39 month certificates the _minimum_ time from changing the rules to getting rid of the problem is 39 months, if it takes a few months to agree what to do, the total may be closer to 4 years. That's a very long time in cryptographic research, too long to predict what's coming. 90 days would be much better from this perspective.


The maximum validity for a cert was recently changed to two years.


"Why we need to do more to reduce certificate lifetimes”: https://news.ycombinator.com/item?id=16582714




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: