On Thu, Dec 20, 2018 at 10:34:21PM +0000, Jeremy Rowley via dev-security-policy wrote: > Here’s the first of the companies. Figured I’d do one and see if it has the > information you want. > > https://bugzilla.mozilla.org/show_bug.cgi?id=1515788
Complete side-note: when the customer said you couldn't identify them by name, did they know you were going to be linking to a whole pile of certificates with their organizationName in them? <grin> > I think this answers all of your questions (except Ryan’s question about > remediation). Could you let me know if more detail is required or if > you’d like additional info included? The question that comes to my mind most of all is tangentially related to Ryan's question around long-term remediation, but I'll ask it anyway as it's at least somewhat independent. You state in the bug you linked that "[The certificates] can't be replaced before [April 30, 2019] because of the code freeze and the risk of an outage". That is an absolute statement, which I take to mean that there is *no* possibility of certificates being replaced in the freeze period (Oct 15-Feb 1). So, my question is: what would this organization do if they had suffered a key compromise (to take one possible reason for immediate revocation, which happens to be forefront in my mind) on Oct 16? Would this organization continue to use a certificate which uses a known-compromised key until possibly as late as April 30 -- which, if my counting-on-fingers is correct, is approximately six and a half months? Would DigiCert consider not revoking the certificate with a compromised key for that long, if the customer asked them to? Would DigiCert expect trust stores to bless that decision? If the answer to the above questions is "no, of course not!" (as I would sincerely hope they would be), then your absolute statement that the certificates "*can't* be replaced" should probably read something more like "the organization would prefer not to replace the certificates before then, because it is a lot of work and entails some degree of risk". Which takes us back to the calculus of options: 1. DigiCert revokes, organization changes domain names and certs: the organization does lots of work, and takes the risk of Things Going Very Wrong because of domain name and cert changes. 2. DigiCert revokes, organization switches to 30 day certs: the organization does lots of work, and takes the risk of Things Going Very Wrong because of cert changes. 3. DigiCert revokes, organization doesn't swap certs: the organization does lots of work, and takes the risk of Things Going Very Wrong because of revocation checking. 4. DigiCert doesn't revoke, on its own behest: the organization does no work, takes no risk, while DigiCert takes the risk of consequences from trust stores of failing to follow the BRs. 5. DigiCert doesn't revoke, trust stores bless this decision: the organization does no work and takes no risk, DigiCert takes no risk, while trust stores take the risk that CAs' future behaviour is influenced by the appearance that deliberately failing to adhere to the BRs carries little-to-no consequences. Given that the entities which made the decisions which led to the current situation are DigiCert (for allowing issuance of invalid certificates) and this organization (which failed to heed their subscriber agreement and decided to build an infrastructure which cannot be adjusted on the timeframe required under their subscriber agreement), can you explain why it is reasonable for the trust stores -- which appear to have done nothing inappropriate to cause the current state of affairs -- to be the ones taking on *any* of the risk here? Please don't think that I'm not sympathetic to the situation this "Major Pharmacy Benefits Manager" and DigiCert are in -- my day job is keeping production systems up and running, and the idea of having to make fast changes isn't one I enjoy. Running a commercial entity is never made any easier when you have to cause problems for your customers. SC12 is not the phase-out plan *I* would have chosen, were I Benevolent Dictator of the Internet. However, now that it is the plan which has been put in place, following the rules of the game trust stores and CAs have agreed to play by, I find it disconcerting that DigiCert and Organization One want to shift the risk for their decisions onto trust stores. What is the *benefit* to trust stores in taking on that risk, to the undeniable benefit to DigiCert and Organization One? Perhaps, at the end of the day, *that* is the real question to be answered. - Matt _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
