On Fri, Jul 3, 2020 at 10:04 AM Arvid Vermote <arvid.verm...@globalsign.com> wrote:
> GlobalSign recognizes the reported security issue and associated risk, and > is working on a plan to remediate the impacted CA hierarchies with first > priority on terminating those branches that include issuing CA with private > keys outside of GlobalSign's realm. We will soon share an initial plan on > our Bugzilla ticket https://bugzilla.mozilla.org/show_bug.cgi?id=1649937. > > One question we have for the root store operators specifically is what type > of assurance they are looking for on the key destruction activities. In the > past we've both done key destruction ceremonies without and with (e.g. in > the case of addressing a compliance issue like > https://bugzilla.mozilla.org/show_bug.cgi?id=1591005) an external auditor > witnessing the destruction and issuing an independent ISAE3000 witnessing > report. Since the goal here is to be able to demonstrate, with some reasonable assurance, that this key will not come back and haunt the ecosystem, my intent of the suggestion was yes, an independently witnessed ceremony with an appropriate report to that fact (e.g. ISAE300) The reason for this is that so much of our current design around controls and audits assume that once something is revoked, the key can no longer do harm and is not interesting if it gets compromised. This threat model defeats that assumption, because for the lifetime of the responder certificate(s) associated with that key, it can be misused to revoke itself, or its siblings, and cause pain anew. I suspect that the necessity of destruction ceremony is probably influenced by a variety of factors, such as how long the responder cert is valid for. This is touched on some in RFC 6960. I don’t know what the “right” answer is, but my gut is that any responder cert valid for more than a year from now would benefit from such a report. If it’s less than a year out, and internally operated, that maybe is reasonable to not require a report? I’m not sure where that line is, and this is where the CAs can share their analysis of the facts to better inform and find the “right” balance here. > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
