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 <
dev-security-policy@lists.mozilla.org> 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
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
