Hey Matt, The trust stores are always free to ignore the CAB Forum mandates and make their own rules. Mozilla has in the past (see the Mozilla audit criteria exception for other audits outside of Webtrust and ETSI). The root stores are also the entities that determine what happens if the rules are violated. Thus, we're asking what the violation of this revocation timeline results in and whether Mozilla is enforcing the CAB Forum requirement. The browsers always decide the risk they want to bear and when that risk becomes unacceptable. The question we're asking is whether this particular mis-revocation provision would amount to unacceptable risk to the browsers.
I don't think we're asking browsers to take on any risk. In fact the opposite. The risk of revocation is a browser outage for that website. A delay in revocation gives the operator for specifically issued certificates gives them more time to avoid an outage. Thus, risk is mitigated. A poor explanation, but I think we have to identify what the risk is before browsers can say they are taking on anything additional. The "CAs may be doing bad things in the dark" allegation can't be responded to because it's too vague. I'm also troubled to think that might be a concern as our policy is to over-report issues. Plus, that risk is pretty hard to sell to management as an immediate threat requiring replacement of their certificates. This lack of definition on the problem is also the main difference between this event and a compromised key. Explaining key compromise to executive management for an emergency exception to a blackout period is a lot different than explaining why hundreds of certificates require replacement because they contain underscores. I think everyone would benefit (myself included) if I could get more information about why underscore characters themselves present an actual risk. If we could get a statement on that, you'd see a lot less confusion. Jeremy -----Original Message----- From: dev-security-policy <[email protected]> On Behalf Of Matt Palmer via dev-security-policy Sent: Thursday, December 20, 2018 4:54 PM To: [email protected] Subject: Re: Underscore characters 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://clicktime.symantec.com/a/1/Vso73rFeURLZ94HBeuxBLdmk1isdwCRJ1YP > CMFAxstM=?d=I3ucqXub-yr0TW9Ocbs-YTBkM2F0beNtptvGgqlq3YEDH6Fzq26eV5Vign > YLpVcHu_P3Gdnnz-qiPqcKis3N25Fp-2RGfSxyMcVFVUNXL4_EQlFrw0BYTZpuPCQdk5mm > -nSlrDH6uc4OgNw1QYDQACt6RPMqV8qWIioLa1QehqMa3nJlcGcR8b3abEqcOYnxwAZBxE > lxsBIDqHumeVxhaczrPgjNCOobWmoaqVYwIp9ZGyEADoOrpFVhL_p7uYKkSi1JVOAePuQg > WB8Xu_QHkdm22N_ZkxRxbBdD1Jc0xy4YuXr58Tfv96bX0LGUeM69JWT8_jRwCLwOPgMJXW > pRNZec6GRDumz3V2itO4ujx1MRsegZuKhuwUOxc3M0QrEHr734ym37mw%3D%3D&u=https > %3A%2F%2Fbugzilla.mozilla.org%2Fshow_bug.cgi%3Fid%3D1515788 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 [email protected] https://clicktime.symantec.com/a/1/436E5xm6PkMnwWrirZaS8qJCq35SjOIUEdPkC1sIwlA=?d=I3ucqXub-yr0TW9Ocbs-YTBkM2F0beNtptvGgqlq3YEDH6Fzq26eV5VignYLpVcHu_P3Gdnnz-qiPqcKis3N25Fp-2RGfSxyMcVFVUNXL4_EQlFrw0BYTZpuPCQdk5mm-nSlrDH6uc4OgNw1QYDQACt6RPMqV8qWIioLa1QehqMa3nJlcGcR8b3abEqcOYnxwAZBxElxsBIDqHumeVxhaczrPgjNCOobWmoaqVYwIp9ZGyEADoOrpFVhL_p7uYKkSi1JVOAePuQgWB8Xu_QHkdm22N_ZkxRxbBdD1Jc0xy4YuXr58Tfv96bX0LGUeM69JWT8_jRwCLwOPgMJXWpRNZec6GRDumz3V2itO4ujx1MRsegZuKhuwUOxc3M0QrEHr734ym37mw%3D%3D&u=https%3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-security-policy
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
