Thanks Arvid! I think these are good starting points for discussion! On Wed, Mar 4, 2020 at 8:48 AM Arvid Vermote <[email protected]> wrote:
> 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 > I'm not sure I understand where the three months comes from. Is this based on the fact that the final report doesn't need to be delivered for up to 3 months from the end of the audit periods? Broadly, I would say "ASAP" without qualifications ;) > - File an “exception request” (which requires to be renew > regularly to ensure CAs need to continuously justify an incomplete audit) > I'm not sure why CAs are so fond of this phrase, but since the horse, now thoroughly glue, continues to need to be beaten... =) Exceptions to the Baseline Requirements cannot and are not granted. They are, without question, incidents and non-compliance. That said, as we've seen repeatedly, it's not that a single incident or non-compliance necessarily leads to distrust. As with all matters of non-compliance, the transparency and detail provided by the CA and the systemic changes proposed or introduced are essential in regaining or retaining trust in the CA. That is, I think you're right that filing an incident report, with the full details about the challenges, would represent the bare minimum of response. I think a step further would be a letter from the auditor, in line with how delays beyond the 3 month period are handled, is also not unreasonable. I also agree that periodic explanations are also important and essential, as it shouldn't be sufficient to file a report saying "nCovid19" and then, say, not provide any updates until the *next* audit period. > - Complete the audit for all locations that can be audited > Agreed :) I'm glad you avoided suggesting holding back the whole audit ;) > - Deliver updated report that incorporates the facilities as soon > as the facility is back available for inspection > The reason why I wanted to gather your feedback is that, as I understand it, this isn't really permitted under the relevant professional standards to restate the audit by expanding the audit scope after a report has been delivered. This is where I think a critical gap in the plan is, and we need to find some solution here for how to address. Would/should we accept an (additional) report regarding *just* those locations? Can the auditor themselves report on the controls with only a partial scope or understanding? Would they need to re-evaluate all of the materials related to the controls? I will say this: As much as possible, a solution needs to avoid an Agreed Upon Procedures Report. That just seems to try and shift all the liability to the Browsers for each and every case, and that isn't a reasonable shift for a free and open program. > 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? > I wasn't looking at the subsetting/adhoc nature. I was more looking at the scenario where (adversarially), a CA uses the fact that their locations are in a non-travel-restricted area, but intentionally chooses an auditor that is in a particularly affected area on the basis that they won't be able to travel to the locations. In those cases, there may be an auditor capable of assessing the affected locations, and the CA is deliberately choosing not to contract with them as a way of delaying/deferring the audit. That may seem less applicable to nCovid19, but I'm broadly trying to find if there are principles we can/should apply that would be reusable, and/or areas up-front we should denote are exceptional. > 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 > Are you looking only at WebTrust for CAs, and not WebTrust for CAs SSL BRs? Principle 3 is more extensive in the SSL BRs with Net Sec. I'm really not sure how to interpret your concerns. I ask, because there's significant details regarding Security Plan and annual risk assessments in the latter, that may be worth looking at part of the disclosure requirements. My apetite for private disclosure is incredibly low, because it lacks transparency, although I can understand why physical security continuity might be reasonably worth treating as an exception, and only allowing disclosure to Root Stores to evaluate, on behalf of their users. I think there's also an element of detailed control reporting, depending on when the Web Trust Task Force is able to release this. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
