That is a pretty breathtaking example of ivory tower thinking if there ever was one. I really just don't know what else I can say about that kind of proposal.
To put things into perspective, the people behind the browser with < 2.5% market share are acting like they have the biggest swinging dick in the room, and proposing policies with authority, that could potentially screw over 100% of the internet. Think about that for a minute.
The reality is the CAs could tell Mozilla to go pound sand and they would have no recourse. Is there not a governing body for certificate policies with voting members?
CA trust should be handled at the OS vendor level. Mozilla having its own trust anchors is a relic of the past. If CAs refuse to comply, they at worst inconvenience 2.5% of their customers temporarily until they find a better browser.
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.
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.
There are countless companies and groups (but only a handful that serve the vast majority of users) releasing a version of Linux bundled with a GNU userland and other open source niceties, all designed to work together as a system. These are colloquially called "Linux distributions".
Linux distros universally use the Mozilla root store. So if a CA told Mozilla "to go pound sand" as suggested by likeabatterycar, the CA would end up distrusted not only by the "2.5%" of browser users, but by every Linux server.
It's not even the most insane suggestion in the thread. That would be the proposal to require ACME for all certificates. So all your appliances with manual cert installation and devices without direct connection to the internet would break.
>That would be the proposal to require ACME for all certificates. So all your appliances with manual cert installation and devices without direct connection to the internet would break.
Technically ACME supports challenges that work without "direct connection to the internet", eg. DNS.
The goal is to ensure not just that the CA is capable of performing the revocation, but that the CA's customers are capable of accepting it and won't demand the timeline be extended. (As they routinely do today.)
I think the garbage CAs that want to delay certificate revocation way beyond requirements are numerous enough that this proposal won't go ahead. Much easier for them to just do nothing and hope they won't be the next Entrust.
> Would a CA be allowed to pre-notify customers whose certs were randomly selected and {pre/re}-issue them replacements?
If this is permitted, then I see no problem with this plan. It will force people to do what they already should be doing: have a plan in place to rotate certificates in case of revocation.
> The point is that right now revocation is so painful that it’s causing CAs to side with subscriber convenience over the integrity of the web PKI. Sampled, controlled revocations let us identify points of pain before they have security implications, and motivate Subscribers to prepare their systems—whether through automation or not, up to them, I’m not their dad—to tolerate on-time revocation. We care about the likely outcomes of automation, such as tolerance of short revocation or expiry timelines, really, but if BigSlowCo wants to staff a 24-hour cert maintenance squad such that they don’t (successfully) pressure their CA into blowing revocation deadlines, that’s their opex choice. Directly evaluating ecosystem capability around prompt revocation is the only way I can think of to identify areas of danger or weakness before they become issues for the web.
I think Roman Fischer in the thread has it right, 30 certs is a single drop of water the Atlantic. Like there's no wink wink necessary, at that scale it would be flatly irrational to do anything at all to handle being one of these revocations. We're taking about a roughly 0.00001% chance that it's you. Forget some dumb cert revocation logic I would play Russian Roulette with those odds.
But on the flip side those 30 unlucky souls are gonna be pissed. There's so many other less disruptive ways you could do this.
1 in 100k chance of taking down Amazon for say a day means the expected cost to them would be 140k per year based on their daily revenue. So in fact it's worth them hiring someone full time permanently to handle these revocations...
Responding to revocations can be automated, and mature organizations like Amazon are presumably already doing that because revocations can already happen unexpectedly for reasons outside their control.
That is a pretty breathtaking example of ivory tower thinking if there ever was one. I really just don't know what else I can say about that kind of proposal.
To put things into perspective, the people behind the browser with < 2.5% market share are acting like they have the biggest swinging dick in the room, and proposing policies with authority, that could potentially screw over 100% of the internet. Think about that for a minute.
The reality is the CAs could tell Mozilla to go pound sand and they would have no recourse. Is there not a governing body for certificate policies with voting members?
CA trust should be handled at the OS vendor level. Mozilla having its own trust anchors is a relic of the past. If CAs refuse to comply, they at worst inconvenience 2.5% of their customers temporarily until they find a better browser.
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>.
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.
>CA trust should be handled at the OS vendor level.
Who's the "vendor" for Linux? IBM?
The outcome of this idea is Google & Microsoft can MITM all internet traffic.
> Who's the "vendor" for Linux? IBM?
There are countless companies and groups (but only a handful that serve the vast majority of users) releasing a version of Linux bundled with a GNU userland and other open source niceties, all designed to work together as a system. These are colloquially called "Linux distributions".
Linux distros universally use the Mozilla root store. So if a CA told Mozilla "to go pound sand" as suggested by likeabatterycar, the CA would end up distrusted not only by the "2.5%" of browser users, but by every Linux server.
> The outcome of this idea is Google & Microsoft can MITM all internet traffic.
Google, MS, and Apple already handle their own CA trust. So this conspiracy theory would already be true.
This is classic "we don't have a purpose so let's cause problems" thinking. WTF!!
It's not even the most insane suggestion in the thread. That would be the proposal to require ACME for all certificates. So all your appliances with manual cert installation and devices without direct connection to the internet would break.
>That would be the proposal to require ACME for all certificates. So all your appliances with manual cert installation and devices without direct connection to the internet would break.
Technically ACME supports challenges that work without "direct connection to the internet", eg. DNS.
And what about revoking the certificate of mozilla.org 30 times instead?
Their certificate will be automatically replaced 30 times and literally no one will notice or care?
Why don’t they revoke the certificate for a special-use domain, like example.com.
As opposed to 30-random entities.
https://en.m.wikipedia.org/wiki/Special-use_domain_name
The goal is to ensure not just that the CA is capable of performing the revocation, but that the CA's customers are capable of accepting it and won't demand the timeline be extended. (As they routinely do today.)
I think the garbage CAs that want to delay certificate revocation way beyond requirements are numerous enough that this proposal won't go ahead. Much easier for them to just do nothing and hope they won't be the next Entrust.
> Would a CA be allowed to pre-notify customers whose certs were randomly selected and {pre/re}-issue them replacements?
If this is permitted, then I see no problem with this plan. It will force people to do what they already should be doing: have a plan in place to rotate certificates in case of revocation.
> The point is that right now revocation is so painful that it’s causing CAs to side with subscriber convenience over the integrity of the web PKI. Sampled, controlled revocations let us identify points of pain before they have security implications, and motivate Subscribers to prepare their systems—whether through automation or not, up to them, I’m not their dad—to tolerate on-time revocation. We care about the likely outcomes of automation, such as tolerance of short revocation or expiry timelines, really, but if BigSlowCo wants to staff a 24-hour cert maintenance squad such that they don’t (successfully) pressure their CA into blowing revocation deadlines, that’s their opex choice. Directly evaluating ecosystem capability around prompt revocation is the only way I can think of to identify areas of danger or weakness before they become issues for the web.
This is like testing the fire extinguishers.
Why though? What’s the problem this solves?
I think Roman Fischer in the thread has it right, 30 certs is a single drop of water the Atlantic. Like there's no wink wink necessary, at that scale it would be flatly irrational to do anything at all to handle being one of these revocations. We're taking about a roughly 0.00001% chance that it's you. Forget some dumb cert revocation logic I would play Russian Roulette with those odds.
But on the flip side those 30 unlucky souls are gonna be pissed. There's so many other less disruptive ways you could do this.
1 in 100k chance of taking down Amazon for say a day means the expected cost to them would be 140k per year based on their daily revenue. So in fact it's worth them hiring someone full time permanently to handle these revocations...
Responding to revocations can be automated, and mature organizations like Amazon are presumably already doing that because revocations can already happen unexpectedly for reasons outside their control.
that's just rude
Good lord, the PKI infrastructure is a completely batshit clusterfuck.