I have two questions about the Mozilla expectations for CAs who have
delayed revocation beyond the BR limits.

For reference:
https://wiki.mozilla.org/CA/Responding_To_An_Incident#Revocation

My first question concerns the requirements for detail about Subscriber
requests for delayed revocation, which are currently:

   - The decision and rationale for delaying revocation will be disclosed
   in the form of a preliminary incident report immediately; preferably before
   the BR-mandated revocation deadline. The rationale must include detailed
   and substantiated explanations for why the situation is exceptional.
   Responses similar to “we do not deem this non-compliant certificate to be a
   security risk” are not acceptable. When revocation is delayed at the
   request of specific Subscribers, the rationale must be provided on a
   per-Subscriber basis.

Question: should this not require per-certificate detail? A subscriber may
have certificates deployed in some systems that can't tolerate prompt
revocation, but that shouldn't prevent revocation of other certificates on
systems of lesser criticality. The report could group certificates that are
all part of a given critical system, for ease and brevity, but I think we
shouldn't give the impression that the Subscriber is the scope of the
decision to delay revocation, rather than the individual certificates.

My second question concerns the expectation that the CA work with their
auditor and the root programs:

   - Your CA will work with your auditor (and supervisory body, as
   appropriate) and the Root Store(s) that your CA participates in to ensure
   your analysis of the risk and plan of remediation is acceptable.

Question: is the expectation that the CA consults with the auditor and root
programs as part of making the decision to delay, or is it instead meant to
be a post-hoc consultation to get feedback on the risk analysis and
remediation plan that the CA established independently for the incident? If
it's the former, then I think that language should be changed to make that
explicit. If it's the latter, then I think it should be explicit that the
analysis and feedback be posted in the incident bug, so that other CAs and
root community members can learn from the process as well.

If there is agreement on these being worth considering, I'll open
appropriate github issues to discuss the details and make an actual
decision.

Thanks,

Mike

-- 
You received this message because you are subscribed to the Google Groups 
"[email protected]" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CADQzZqt8w5Em8nZc78ML4yQgcPNhBzAoUZjW71vzaa5_JvYb2g%40mail.gmail.com.

Reply via email to