On 3/18/20 5:16 PM, Ryan Sleevi wrote:
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] :)
Done
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.
Done
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.
Added the following to the top of the "Minimum Expectations" list:
* Both ETSI and WebTrust Audits 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.
This way we can easily add more sub-bullet points as needed.
I also added a summary to the top of the page
https://wiki.mozilla.org/CA/Audit_Statements
CA Audits are one of the primary mechanisms relied upon by Mozilla to
ensure that a CA is operating securely and in compliance with our
policies. CA audits and audit statements must comply with the following
requirements.
* Section 3.1 of Mozilla's Root Store Policy.
** An Audit Delay is when one or more of the following requirements in
section 3.1.3 cannot be met:
***"Full-surveillance period-of-time audits MUST be conducted and
updated audit information provided no less frequently than annually."
***"... MUST be provided to Mozilla via the CCADB within three months of
the point-in-time date or the end date of the period."
* Section 5.1 of the Common CCADB Policy.
* Section 8 of the CA/Browser Forum Baseline Requirements, if the root
certificate has the Websites (TLS/SSL) trust bit enabled.
Thanks,
Kathleen
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
