> I don't think there's *any* result from all this that everyone would > consider desirable -- otherwise we wouldn't need to have this conversation. + 1 to that.
> 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. 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? > What were the criteria by which DigiCert decided which customers to grant > exceptions to? My default assumption is "whichever ones will cost us the > most money, on a risk-of-departure-weighted basis, if we revoke their > misissued certs", so if DigiCert's criteria was different, I'd be keen to > have my assumption changed. Based on the number of certificates, the reasons the customer identified they couldn't make change, and whether revocation would take down a critical site. It actually isn't tied to $ at all. The largest issuer of certificates isn't on the exception list. Honestly, it came down to which ones were the most mad at me for telling them I am going to revoke their certs. I also filed the incident reports in that order. > 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. > As an aside, on the subject of "there's no CVSS score for this", let me fix > that up, with the official WombleSecure(TM)(R)(Patent Pending) CVSS for > "your certs are getting revoked": https://clicktime.symantec.com/a/1/yUHHbekYeF5I1ApCiRHB3c4GRi5h119CZduhXSUjcHQ=?d=jjXJ8wGMEM-BgSpW3_vhyQL0sXCIhGbj3gBpMQofOamgauLb68trqD6rFgW1WlGMp2x8t2VFcaY0DBIxDVgeeB1NTgFMApldbJMcAgO-QzAYKleHGSG1QMDssL8YiuasGm7sy54zIql5pGoFC32z-FPTIi19g1UDgwcBY97oowWvIdYn96-dpAc9Bgo0beU6KZJB4GgT4nsTYZfQEPWR6iJovigq7cka80r2jfU6Ef-FnpegGAkDENlMwnIoHo4ti6V0kNC1BnXX92EeVaD_XCRNLlzHjHvbe0_9OrBDSAOuXH7r90tkFNs5Jf15Y9tnE-nNgpNo-7ATwrZ6C-AfpSHr9tX-RnCPFHoSUEIJ9az2IiiMo_si4rA2uaMaKtjN1Ziuk7XNO9s%3D&u=https%3A%2F%2Fwww.first.org%2Fcvss%2Fcalculator%2F3.0%23CVSS%3A3.0%2FAV%3AN%2FAC%3AL%2FPR%3AN%2FUI%3AN%2FS%3AU%2FC%3AN%2FI%3AN%2FA%3AH%2FE%3AH%2FRL%3AO%2FRC%3AC%2FAR%3AH%2FMAV%3AN%2FMAC%3AL%2FMPR%3AN%2FMUI%3AN%2FMS%3AU%2FMC%3AN%2FMI%3AN%2FMA%3AH 7.5 base, 7.2 temporal, and 8.9 environmental. All those scores are in the "high" band. "Availability" *is* one of the sides of the security triangle, after all. Lol - thanks. I'll be sure to share this with them. > 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. > A similar question applies, even more forcefully, to DigiCert itself. > Clearly, whatever you've done so far didn't work, because these customers of > yours didn't heed whatever warnings and caveats you provided, and built > themselves systems and processes that are unable to comply with their > agreements to DigiCert (and, by extension, relying parties). See above. Also see my response to Ryan on the migration from legacy Symantec systems. > 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. 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. > Hence, I'd be interested in hearing what DigiCert's actual plans are, > because if it were my call, *that* would be the single biggest factor in > determining the disposition of an event like this. That errors occur is > regrettable, but it's when they happen repeatedly that it becomes > indefensible. True, but I think there should always be a discussion of risks involved in a course of action. Blind obedience to RFCs isn't a good idea. A worse idea is to not follow them because you don't want to. An even worser worse idea is to challenge every rule you don't like from the CAB forum. Not sure the balance, but I think my answer next time is "Revoke, no exception" rather than "Let me see what the browser community thinks". _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://clicktime.symantec.com/a/1/Jd9aOCU0Y-jXTwNlEa00EncPIIJo69Sdp69qqPsHGHU=?d=jjXJ8wGMEM-BgSpW3_vhyQL0sXCIhGbj3gBpMQofOamgauLb68trqD6rFgW1WlGMp2x8t2VFcaY0DBIxDVgeeB1NTgFMApldbJMcAgO-QzAYKleHGSG1QMDssL8YiuasGm7sy54zIql5pGoFC32z-FPTIi19g1UDgwcBY97oowWvIdYn96-dpAc9Bgo0beU6KZJB4GgT4nsTYZfQEPWR6iJovigq7cka80r2jfU6Ef-FnpegGAkDENlMwnIoHo4ti6V0kNC1BnXX92EeVaD_XCRNLlzHjHvbe0_9OrBDSAOuXH7r90tkFNs5Jf15Y9tnE-nNgpNo-7ATwrZ6C-AfpSHr9tX-RnCPFHoSUEIJ9az2IiiMo_si4rA2uaMaKtjN1Ziuk7XNO9s%3D&u=https%3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-security-policy
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
