I read Jeremy’s last response before posting my comment. Dear Ryan,
It would help a great deal, if you tone down your constant insults towards the entire CA world. Questioning whether you should trust any CA is a bridge too far. Instead, why don’t you try to focus on specific issues with specific CAs, or specific issues with most CAs. I don’t think you have a specific issue with every CA in the world. If specific CAs fail to do what you think is appropriate for browser vendors, perhaps you need to implement new, or improve existing audits? Propose solutions, implement checks and execute better reviews. Then iterate until everyone gets it right. I could write a book on how Google is the least “trustworthy” browser vendor on the planet. I could write another book about how Google is constantly contradicting its own advice and best practices. One example is where Google tells us to focus on the part of the URL that matters most - the domain name. But over here we have AMP, where URLs go to die a slow painful death within Google’s closed system, adding no value to the world outside of advertising. The list is endless when it comes to the lack of respect for people’s privacy from *some* browser vendors. Not all browsers are evil. Not all CAs are evil. So, please can you get off your high horse and stick to facts and propose solutions instead of constantly making personal insults and bringing up problems without implementing new processes to address same. Can we just keep in mind that we’re all trying to do our job. No company is perfect. No process is perfect. No technology solution is perfect. Peace! - Paul p.s. I don’t work for a CA and never have. And I believe there are many weaknesses that could can should be better addressed. > On Oct 7, 2019, at 5:45 PM, Ryan Sleevi via dev-security-policy > <dev-security-policy@lists.mozilla.org> wrote: > > On Mon, Oct 7, 2019 at 7:06 PM Jeremy Rowley <jeremy.row...@digicert.com> > wrote: > >> Interesting. I can't tell with the Netlock certificate, but the other >> three non-EKU intermediates look like replacements for intermediates that >> were issued before the policy date and then reissued after the compliance >> date. The industry has established that renewal and new issuance are >> identical (source?), but we know some CAs treat these as different >> instances. > > > Source: Literally every time a CA tries to use it as an excuse? :) > > My question is how we move past “CAs provide excuses”, and at what point > the same excuses fall flat? > > While that's not an excuse, I can see why a CA could have issues with a >> renewal compared to new issuance as changing the profile may break the >> underlying CA. > > > That was Quovadis’s explanation, although with no detail to support that it > would break something, simply that they don’t review the things they sign. > Yes, I’m frustrated that CAs continue to struggle with anything that is not > entirely supervised. What’s the point of trusting a CA then? > > However, there's probably something better than "trust" vs. "distrust" or >> "revoke" v "non-revoke", especially when it comes to an intermediate. I >> guess the question is what is the primary goal for Mozilla? Protect users? >> Enforce compliance? They are not mutually exclusive objectives of course, >> but the primary drive may influence how to treat issuing CA non-compliance >> vs. end-entity compliance. > > > I think a minimum goal is to ensure the CAs they trust are competent and > take their job seriously, fully aware of the risk they pose. I am more > concerned about issues like this which CAs like QuoVadis acknowledges they > would not cause. > > The suggestion of a spectrum of responses fundamentally suggests root > stores should eat the risk caused by CAs flagrant violations. I want to > understand why browsers should continue to be left holding the bag, and why > every effort at compliance seems to fall on how much the browsers push. > > Of the four, only Quovadis has responded to the incident with real >> information, and none of them have filed the required format or given >> sufficient information. Is it too early to say what happens before there is >> more information about what went wrong? Key ceremonies are, unfortunately, >> very manual beasts. You can automate a lot of it with scripting tools, but >> the process of taking a key out, performing a ceremony, and putting things >> a way is not automated due to the off-line root and FIPS 140-3 >> requirements. > > > Yes, I think it’s appropriate to defer discussing what should happen to > these specific CAs. However, I don’t think it’s too early to begin to try > and understand why it continues to be so easy to find massive amounts of > misissuance, and why policies that are clearly communicated and require > affirmative consent is something CAs are still messing up. It suggests > trying to improve things by strengthening requirements isn’t helping as > much as needed, and perhaps more consistent distrusting is a better > solution. > > In any event, having CAs share the challenges is how we do better. > Understanding how the CAs not affected prevent these issues is equally > important. We NEED CAs to be better here, so what’s the missing part about > why it’s working for some and failing for others? > > I know it seems extreme to suggest to start distrusting CAs over this, but > every single time, it seems there’s a CA communication, affirmative > consent, and then failure. The most recent failure to disclose CAs is > equally disappointing and frustrating, and it’s not clear we have CAs > adequately prepared to comply with 2.7, no matter how much we try. > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
