(Wearing an individual hat) On Thu, Mar 9, 2017 at 4:18 PM, Jeremy Rowley via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> Although we have a policy > against using live certificates for testing, the policy was not followed in > this case. Can you share why? Can you share what steps you'll be taking to make sure policies are followed in the future? I think we've seen some pretty stark examples about what can happen when a CA doesn't follow its policies for test certificates - from CNNIC to Symantec. > However, I think this discussion raises some very interesting points about > real world scenarios and RFC 5280 that should be addressed. DigiCert > actually has three items that routinely show up on CABLint: > 1) Use of teletext in strings (although this only occurs in > re-issues/duplicates of previously issued certificates) > Is this in the issuer field? Or in the subject information? I can understand if your issuer cert has this issue, but I don't think there's any good reason for this for the subject information. > 2) Too long of fields, primarily the O and OU fields > 3) Use of underscore characters in certs > We've had an open item to fix these issues for a while, but haven't > prioritized them because: > a) From a technical standpoint, the WebPKI supports them, > b) The inclusion of longer names reflects the real world where company > names are often longer than 64 char, especially in Europe and Asia > (translating international names to puny-code rarely results in a nice > short > name), > c) We haven't felt that there are sufficiently significant risks > associated with the issues to spend resources addressing them considering a > and b compared to higher priorities (like our current project of requiring > only 169 validation methods), and > d) Lots of CAs have the same or similar issues under RFC 5280 > according > to CABLint, and those issues don't seem to be garnering a lot of attention > (perhaps because of higher risk issues taking priority). > I gotta admit, this sounds pretty disheartening. "We know we have issues, we've known about them for a while, but we've kept doing it, because we don't think it's a big deal, and everyone else is doing it". The BRs, in part, exist to avoid that judgement call, because we see time and time again where CAs are making that judgement call and it's not ending well. If you don't think it belongs, then why not propose BR changes? If you don't think it's important, then why not propose root policy changes? I appreciate the effort towards only 169 validation methods, but how are we, the relying parties, supposed to know that DigiCert won't, say, deprioritize following the BRs on that because y'all decide it's not a big security issue, and instead want to focus on a new product offering, since (besides whatever revenue benefit it might have), it gets more sites on HTTPS? As for other CAs, shouldn't you be making sure your house is in order first? :) But also, if there are other issues, shouldn't you be pushing for greater disclosure and transparency? We constantly see this correlation between smoke and fire - and if you're seeing smoke, don't you think it should be raised? I appreciate the principled stance you're mention, but I'm sure you can realize the systemic and endemic harm that comes from "Trust us to evaluate whether compliance is right or not" - we know that's absolutely a failed mindset from the past decade of failures. Why isn't the principle "Be above reproach" - which includes improving security as a natural consequence? > In fact, I think security is improved by providing these > certificates because these customers/domains would remain unsecured without > certificates or be forced to truncate/omit important information. I believe > most CAs have reached the same conclusion after considering the large > number > of issues reported through CABLint. > "We should be able to misissue certs, because at least people are on HTTPS" - this is a terrible argument, and I have a tremendous amount of respect for you, but I'm shocked to hear you make it, given your knowledge of the industry. Misissuance of any form is a terrible practice, regardless of the reasons, precisely because it starts us into the subjective realm. > The discussion also raises an interesting question of when issues become > significant enough they need to be addressed on the Mozilla list or require > revocation. For example, one of our cross-signed partners issued a large > number of certificates that lacked the proper OID. Should each of these > certs warrant a discussion and separate revocation decision? Discuss the problem - not the certificates. Discuss what you're doing to address the problem. What caused the issue. How many certificates did it affect? What steps are you taking? When will those be complete? > The browsers > don't do anything with this information so I'm unsure whether them revoking > all the certs (which the cross-signed partner did) and replacing them with > certs having an appropriate policy OID made a huge difference in the state > of security. Should we start a thread on the Mozilla list about each cert > with issues detected in CABLint? Yes! If they're violations of the Baseline Requirements, yes! If you're not sure, yes! If you can't point to a specific reason why it is a false positive - by showing, for example, a misinterpreted or misapplied rule - absolutely! > Even if we assume half are false positives, > that's about 2000 new discussion items for this group. If so, can we > establish a priority ranking by the browsers for these discussions? > Everything? Look, you're representing an organization trusted with the keys for the Internet. Billions - plural - of products rely on you to exercise a duty of care with that trust. Today, that duty of care is measured by how well you follow the Baseline Requirements, and how seriously you take that duty of care. It's great that you feel you're doing a bangup job and these are minor issues, but don't sweep them under the rug. Be transparent. Be honest. Be open. And be willing to acknowledge that things can and do need to change. Are the BRs perfect? No. Are IETF docs perfect? Of course not. But they're the bare minimum, and failure to abide by those rules, especially on a systemic and knowing basis, vastly undermines trust, because it's unclear what other corners you might be willing to cut without telling anyone. And that's a suspicion that you shouldn't stoke by brushing the concerns off as glibly as this seems to. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
