When I initially raised the topic I had two things in mind: - What if a facility can’t be audited?
- If main key management facilities are down can WebPKI CA meet SSLBR 4.9.1.2? As for the inability to audit, a few things come to mind based on the previous shared thoughts: - Inform root programs ASAP if a certain location is in a situation where it cannot be inspected within the three months after the period under audit - File an “exception request” (which requires to be renew regularly to ensure CAs need to continuously justify an incomplete audit) - Complete the audit for all locations that can be audited - Deliver updated report that incorporates the facilities as soon as the facility is back available for inspection Ryan, related to your thought “Similarly, if a CA’s preferred auditors are from a region affected by travel restrictions, but other accredited auditors exist that would be capable, would that be sufficient?” - Auditors are not that flexible on reporting formats and doing a specific subset of a standards on a specific location. - What would the root programs accept in terms of such an ad-hoc report as it will not be an ISAE3000/CSAE3000/SSAE18 format? - Depending on the CA it would also be multiple reports that will be incomplete: WebTrust, SSLBR, EV, (EV) Code Signing - Which controls / criteria should be reported on? Only the ones related to physical security? For the key material security and key management continuity aspect, compared to the controls I would think a typical CA would implement the WebTrust standard is quite brief and vague: - Criterion #3.8 focuses on general CA continuity and availability of technology and information. For key material it focuses on having back-ups. - There is one specific control (#3.8.6) that talks a bit about securing a facility during a disaster None of these controls really talk focused about the importance of or set any timings for having a capability available at original or remote site to perform critical key management activities such as timely ICA revocation. Also generally our opinion is that key material protection requirements in WT are substandard to the level of protection that is required for WebPKI CAs. Based on our internal risk appetite we have implemented additional controls, including but not limited to: - Having key management facilities / capability on different continents in politically stable countries - Having additional locations on top of the above facilities under different political rule to which we can move key material quickly and securely in case of any threat or instability - “Key management facility” means a facility where key material is stored. Credentials to unlock the key management facility and key material are stored in at least two other different locations in close proximity to the key management facility and require the presence of different roles to obtain access. - Rotational key management activities in the different locations to make sure the facilities are and stay operational and plans work when it comes to a BCP execution - A colluded group of at least six trusted role people is required in order to obtain access to key management material From: Ryan Sleevi <r...@sleevi.com> Sent: vrijdag 28 februari 2020 19:32 To: Ryan Sleevi <r...@sleevi.com> Cc: mozilla-dev-security-policy <mozilla-dev-security-pol...@lists.mozilla.org>; Arvid Vermote <arvid.verm...@globalsign.com> Subject: Re: Auditing of CA facilities in lockdown because of an environmental disaster/pandemic Hi Arvid, I wanted to follow-up, and see if you had suggestions or ideas here for appropriate next steps. Understandably, as more countries are affected, this will no doubt continue to be an issue. I think you're spot on for asking early, as you did, and I'm hoping GlobalSign (and others!) might have ideas on appropriate risk mitigation and potential remediation strategies.
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
