3 ms·
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
by agwa 2y 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 https://bugzilla.mozilla.org/show_bug.cgi?id=1934361>.
- jonas21 2y agoDon'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?
- agwa 2y agoThey 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.)
- WorldMaker 2y agoIt'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.
- likeabatterycar 2y ago> 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.
- alyandon 2y agoBased 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.
- likeabatterycar 2y ago> 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.
- alyandon 2y agoIt 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.
- gruez 2y ago>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.
- alyandon 2y agoSure, 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.