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


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.

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