On Thu, Dec 20, 2018 at 4:54 PM Matt Palmer via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> 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? > > I agree that more information is needed here. My hypothetical is that of a critical vulnerability in one of Organization One's systems being discovered on 16-Oct. Does Organization One hold off on patching until Feb? If not, what makes these certificates different? Why is so much coordination required if they are just used in browsers? Was a risk assessment performed to evaluate the possibility of replacing them during the freeze? Are routine changes permitted during the change? If so, why is a certificate replacement not a routine change? 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. > > I've managed to convince myself that the path we're on is not one of Mozilla accepting the risk, but rather one of Mozilla shifting the ensuing incident process from after the risk is taken to before. Assuming that they can provide enough information in advance and we trust that the incident will play out as described, this gives DigiCert the benefit of knowing the likely outcome of the incident investigation. It is still DigiCert deciding to accept the risk - or not - just as would be the case if they chose not to revoke without advance notification and discussion. - Matt > > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
