Suggestions:
1) Rename "Audit Delay" to [audit-delay] and rename "Audit Delay COVID-19"
to [audit-delay] [covid-19] or [audit-delay-covid-19], depending
Rationale: In general, our filters work on word searches, so the brackets
brackets help distinguish the two. To search for "Audit Delay" without
considering COVID-19, the filter would have to be ("Audit" AND "Delay") AND
NOT "COVID-19". The renames help us search for "[audit-delay]" (which would
exclude Covid-19) or "[audit-delay]" AND NOT "[covid-19]", which is...
slightly easier :) This is mostly minor, but also tracks how we handled
[ca-compliance], [auditor-compliance], [delayed-revocation-leaf] and
[delayed-revocation-ca] :)2) Rename "Potential remediations" to "Minimum expectations" Rationale: I worry that "potential remediations" may be seen as an indefinite escape clause. As noted in the discussion of force majeure that you've linked, in general, these clauses generally temporarily suspend certain obligations, but may not indefinitely apply. While this situation continues to evolve, and we will hopefully see a timely global recovery, there exists the non-negligible possibility that it may become necessary at some point in the future to limit or restrict trust in CAs in order to minimize risk to users. These are absolutely case-by-case scenarios, and so this isn't meant to scare CAs or Auditors into engaging in unsafe or risky procedures, but more to highlight that as part of recovery from such scenarios, it may be necessary to figure out how to transition from uncertainy to certainty, such as rolling keys over to new roots/intermediates. Keeping people physically safe is certainly the pressing priority here, and we should be sensitive to that, but I worry that "potential remediations" suggests that such measures might be indefinitely accepted. 3) Clarify ETSI documentation and disclosure requirements Rationale: My concern with the ETSI approach is that Mozilla may not receive the same information the auditor/CAB provides to the CA/TSP. For example, as currently worded, it'd be impossible to discover the limitations that the auditor might have encountered (such as a documentation-only assessment), because that'd be normally addressed in the engagement letter between the CAB/TSP, and beyond them, typically only the Supervisory Body would be party to such details. While your requirements for disclosure are unambiguous, my worry is how many TSPs/CABs using an ETSI scheme have failed to uphold Mozilla's expectations / CCADB expectations, and thus it wouldn't be clear when a TSP was violating policy (e.g. by not having disclosed the situation). Potentially: "Audit letters MUST disclose each location that was included in the scope of the audit, as well as whether the inspection was physically carried out in person" There's probably a MUCH better way to word this, but the concept I'm trying to capture is some positive affirmation by the auditor about what they did. If a Letter doesn't include that, it's a red flag (to reject the audit). If it does, that at least provides clarity and fits back in to the incident report discussion. On Wed, Mar 18, 2020 at 6:58 PM Kathleen Wilson via dev-security-policy < [email protected]> wrote: > All, > > I will greatly appreciate your input on the following new "Audit Delay" > section. > > https://wiki.mozilla.org/CA/Audit_Statements#Audit_Delay > > Thanks, > Kathleen > > PS: I moved the content of > https://wiki.mozilla.org/CA/Audit_Letter_Validation > to > https://wiki.mozilla.org/CA/Audit_Statements > (with a redirect from the old page) > > > _______________________________________________ > dev-security-policy mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
