On Wed, Dec 26, 2018 at 04:13:40PM +0000, Jeremy Rowley via dev-security-policy wrote: > The trust stores are always free to ignore the CAB Forum mandates and make > their own rules. Mozilla has in the past (see the Mozilla audit > criteria).
Whilst the trust stores *can* make their own rules, my observation is that they generally don't do that except as a last resort, or in exigent circumstances. Whilst I wasn't around when it was created, my understanding is that part of the reason the CA/B forum was created was to try and harmonise trust stores' requirements for CAs, so that CAs could work to a single set of requirements. >From that perspective, I can't imagine it would be in the interests of CAs to encourage trust stores to each do their own thing, in general. > The browsers always decide the risk they want to bear and when that risk > becomes unacceptable. The root question is definitely whether this > particular mis-revocation provision would amount to unacceptable risk to > the browsers. Well, *any* amount of risk is "unacceptable" if there is no corresponding reward to be gained from taking that risk. > I don't think we're asking browsers to take on any risk. You disagree with my suggestion that there is a risk that CAs (as a class; I'm not thinking of DigiCert specifically here) will be less likely to engage in a rigorous analysis of the relevant specifications in the future, if not doing so does not result in any harm to them? You don't think there is any risk to trust stores' reputations from the appearance of giving a free pass to CAs which did not follow the rules? There is no risk of appearing to favour certain CAs over others, by effectively punishing those CAs which *did* play by the rules? Let me pose to you a hypothetical. Imagine, for a moment, that DigiCert holds the line, and revokes on January 15. This is certainly going to make your customers annoyed, I certainly get that. But you do the right thing by the web PKI, for which relying parties thank you. Now, one of your competitors, who has all the scruples of an alley tomcat, can easily find out who those companies are -- even before you revoke, just by searching crt.sh for certs issued by DigiCert / Symantec with an underscore in them. They decide to pull a swift one, and put all their more persuasive salespeople on a blitzkrieg campaign to contact those companies and say "hey, I understand DigiCert's done the dirty on you, and they're making you replace all your certificates and rename all your machines. That's gotta be tough. If you switch all your certificate issuance to us, we'll give you two year certs for the existing names, and you don't have to take the risk of renaming everything and breaking your critical systems." There's a decent chance that at least one of your customers would leap at that chance, because whilst it might be risky to change certs, it's a *lot* less risky than changing certs *and* renaming everything, and they have to change their certs anyway. Having lost a customer to a competitor who has gotten that business by offering them something they really should be offering, would you feel a little miffed if Mozilla, when presented with clear evidence that the rules were being violated, decided to give your shady competitor a pass? I fully expect you would be, and you'd be entirely right to feel that way. I'd be right next to you getting miffed, too. Now, do you think there are any CAs out there which have previously issued underscore-containing certificates, who have already told all their customers, flat-out, that they're getting revoked, and they just need to get on with replacing them? Is there any chance that those CAs have lost a customer as a result of that? Do you think there's any chance that they're watching what is happening at the moment *very* closely, and getting ready to be rather miffed if DigiCert gets a pass on the Janusary 15 deadline, when *they* did the hard yards of telling all their customers their certs were getting revoked, and *they* took the business risk of potentially losing customers? > In fact the opposite. The risk of revocation is a browser outage for that > website. The impacts of *that* risk only effect the trust stores to the degree that users may cease to use the associated browser, for another. It has a far greater impact on the organisation, which is as it should be, as it was the organisation's decision to deploy non-conforming names, and an infrastructure that isn't capable of adhering to the agreements that the organisation made with their CA. > A delay in revocation gives the operator for specifically issued > certificates gives them more time to avoid an outage. Thus, risk is > mitigated. Risk is mitigated for one party, (or two), at the cost of increased risk to another party (trust stores). Typically, in a risk transfer transaction, there is some consideration that goes along with agreeing to take on that risk. Of course, if you don't believe that there is any risk to trust stores by giving CAs a free pass on this, then you'll see the situation differently, but in that case we'll just have to agree to disagree on that point. > The main difference between this event and a compromised key is the > comparative risks and the number. Explaining the key compromise to > executive management for an emergency issue is a lot different of an > exception process than explaining hundreds of certificates that need to be > replaced because of non-descript issue. If we could provide more > description around why this is a bad practice that had to be fixed over > the holidays, you'd see a lot less confusion. Are you talking about explaining to *your* executive management, or the executive management of Organisation One? The explanation to Organisation One's executive management, which I assume would be done by their technical people, should be fairly simple: "the certificates we were issued weren't correct, and they're going to stop working on January 15. We need to replace them before then." That pre-supposes, of course, that CAs are actually going to revoke them. The executive management can dig further into the details if they want, but the long and the short of it is that the certificates are going to stop working on January 15, there's nothing anyone can do to stop that, and they need to be replaced. I assume that CA subscriber agreements are suitably watertight that Organisation One's general counsel will tell them to stop being silly if they talk about legal action. The explanation to your company's executive management might be slightly more fraught, if only because the explanation boils down to, "we dun goofed, boss, and handed out certs we shouldn't have". I have no idea what sort of an organisation DigiCert is, but I can imagine in a suitably toxic organisation that could be a Career Limiting Maneuver. I can only hope that DigiCert isn't one of those. Speaking of explaining things to executive management, though: can you imagine being a CA which *did* play by the rules, and then trying to explain to the Big Bosses why they did the right thing and revoked on time, when their competitors didn't? And there were no negative consequences for those competitors? How much harder would it be for those people to convince their bosses to do the right thing next time? - Matt _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
