Hacker News new | ask | show | jobs
by agwa 531 days ago
Google Chrome also takes a hard line when it comes to revocation requirements, and Apple wants to limit certificate lifetimes to 45 days. Although neither have stated a position on random revocations, they are directionally aligned with Mozilla and you will be disappointed if you expect either of them to prioritize server operator convenience over the security of their users.

As for Microsoft, they are simply asleep at the wheel, trusting terrible CAs that do things like misissue a google.com certificate <https://bugzilla.mozilla.org/show_bug.cgi?id=1934361>.

3 comments

Based on what I've seen internally at several $LARGE_CORPs, a 90 day expiration was more than painful enough to cause teams to invest in automation for rotation. I don't know that cutting 90 days to 45 days would help move the needle further.
> I don't know that cutting 90 days to 45 days would help move the needle further.

What does this protect you from? If a private key is stolen from a device? If it went unnoticed for 45 days, the device is probably still compromised, and the threat actor will just steal the new key. If you can automate issuing certificates, you can automate stealing them too.

Sounds like a great way to garner more business for Big PKI.

It mainly helps with stuff like enforcing modern tls + ciphers and various other changes that occur naturally in the ecosystem over time.

You are not wrong about the malware part though. Said undetected malware would continue to be undetected and continue to expose the private bits no matter how (in)frequently you rotate.

>It mainly helps with stuff like enforcing modern tls + ciphers and various other changes that occur naturally in the ecosystem over time.

???

why would you need to issue new certificates for "enforcing modern tls + ciphers and various other changes"? There's nothing preventing you from using a newly minted letsencrypt certificate with sslv3, for instance.

Sure, I misspoke. It's more about the contents of the cert itself (signing keys, deprecation of CN field, etc) than the hosting web server configuration.

Obviously, one can actively choose to go out of their way and do something bone-headed - nothing can stop that.

Don't you think there's a difference between having short certificate lifetimes (which would be clear when the certificate is issued), and randomly revoking perfectly good certificates without warning?
They are not literally the same, but the point of both measures is to encourage automation by server operators, and are strongly opposed by those who would prefer to keep managing certificates manually. My point is - Apple, like Mozilla, doesn't mind inconveniencing server operators if they see a security benefit for users.

(Also, the revocations would not be without warning - mechanisms like ARI can inform server operators prior to revocation so the certificate can be automatically replaced.)

It's also a part of why Let's Encrypt exists as a market force from the other side of this playing field. Now that they've proven heavy automation works and shown they can use it to drive costs down, Apple and Mozilla don't look so crazy asking for the old, expensive behemoths to move faster/smarter/better.
> Google Chrome also takes a hard line when it comes to revocation requirements

Unless you run an enterprise CA, in which case Chrome doesn't check for revocation AT ALL. Google went rogue and made up their own rules. The whole of PKI should be ripped up and not left up to those who can shout loudest.