Thanks Arvid! I think these are good starting points for discussion!
On Wed, Mar 4, 2020 at 8:48 AM Arvid Vermote <arvid....@globalsign.com
> 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 22.214.171.124?
> 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
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
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
> - 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.