On Fri, Dec 28, 2018 at 03:19:19AM +0000, Jeremy Rowley via dev-security-policy wrote: > > I'm not sure I'd call it "leniency", but I think you're definitely asking > > for "special treatment" -- pre-judgment on a potential incident so you can > > decide whether or not it's worth it (to DigiCert) to deliberately break the > > rules. > > I'm not sure there's a policy against asking for special treatment or > pre-judgment. Like I said, I feel like this is a weird area where I'm not > 100% > sure how to proceed. There's certainly a fuzzy area in the middle between "here is a problem, what should we do?" and the other extreme of "please let me know in advance if we'll be OK with doing this bad thing, because I'd like to decide whether it's worth breaking the rules". I have to say that several of your messages have read far more towards the latter than the former.
Of course, the ability to distinguish is muddied by the need for you to provide specific data about the scope of the problem, which focuses things on just DigiCert, when there is the distinct possibility that other CAs are sitting quietly in the wings, having all the data but not wanting to step into the ring, as it were. > Like how do you raise when you think obedience to rules > is riskier than breaking them? Breaking them then explaining why seems like a > really bad idea. The best I could come up with is ask what to do and see if > the browsers agree. Acknowledged that this would be very bad in most cases, > but I'm not sure where you decide? I think you've followed the best course open to you. Talking about issues is pretty much guaranteed to be better than keeping quiet and hoping for the best (thanks, CT!). Certainly, knowingly breaking the rules and then having it turn up later is terrible -- as Ryan said, that's a quick way to get yourself distrusted. I certainly think that if any other CA comes out with an incident report post-Jan-15 dealing with unrevoked underscore-bearing certificates, the general reaction is going to be along the lines of, "are you <expletive> *kidding* me?!?". > > What were the criteria by which DigiCert decided which customers to grant > > exceptions to? [snip] > Honestly, it came down to which ones were the most mad at me for telling > them I am going to revoke their certs. I can imagine... > > First off, your customers. There is a certain amount of exposition in the > > pharmacy company bug, however I can't say that what's there so far fills me > > with a sense of contentment. You said in your most recent post, "Security > > vulnerabilities are patched based on their rating", and that lacking a CVSS > > it is difficult to get recognition of a problem. Would it be fair to say > > that this narrow approach to security is shared by all/most/some/none of > > the > > other similarly situated customers? > > No, but it's generally how people can get exceptions to the blackout period. > More the norm is around how these certs are rolled out. They fall under three > camps: a) a third party offering the main companies service that requires a > bunch of testing and permissions (probably contractual), b) complicated > policies about changes during/around blackout periods and c) certs actually > used in software that require code changes and deployment to update. Those are useful categories to have, thanks. It's especially handy for CAs to bear in mind when they're communicating with their customers about the risks of deeply embedding data which may need to change at short notice. > > Focusing on the "what about next time?" aspect, which I believe is the most > > important, I'd be interested to know what your customers are planning on > > changing about their systems and processes, such that if a similar event > > happens in the future, the outcome won't be the same. > > After this, I'd like to talk about removing some of the Symantec roots from > Mozilla. A lot of these don't need trust in Mozilla and Chrome. The mix is in > the OS vs. Web ecosystem. They need trust in OS platforms, but Web is more > optional for a lot of the certs. If we have roots that are only trusted in > the two OS platforms (MS and Apple), the risk changes for the web community. I wonder how well that'll work out, given the dominant server platform (Linux, in its many and varied incarnations) generally sources its trust store from Mozilla (for better or worse). Given the highly variable timeline that distros have for updating their trust stores, you might be dealing with the fallout from that one for a *long* time to come. > > Hence, what is it that DigiCert plans to change, such that an equivalent > > result cannot happen in the future, given a similar event? There was one > > rather draconian possibility suggested up-thread, of DigiCert limiting > > itself to 100 days validity, and revoking a number of randomly-chosen > > certificates periodically. That would certainly remove any practical > > possibility of customers not being able to refresh their certificates > > if-and-when, however I can imagine it might be a bit of a shock to the > > system for many of them. > > I don't think that really solves the problem. All that does is migrate people > from one CA to another. Well, it solves the problem of *DigiCert* customers not having change blackouts for four months of the year, although as you say, whether that's because DigiCert customers improve their systems and processes, or whether they stop being DigiCert customers, is important. The key way to mitigate the latter would be to make it an industry-wide expectation. > I don't have a good answer to this other than to > continue investing in automation and discovery systems. As mentioned though, > most of these complexities are with third party policy issues, not technical > issues. I'm unaware of any legal requirement that would prohibit revocation. > I > know there's no technical limitation on our side that prevents issuing and > deploying new certs immediately. Third-party policy problems are, of course, somewhat immune to purely technical solutions, which is why I'm particularly keen to hear from DigiCert (and its customers) on what other measures would be useful to ensure that customer policies can be encouraged in the right direction. - Matt _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
