Hi folks,
We have discussed delayed revocation a bit internally and wanted to come
back to the community with some thoughts.
We agree that expanding beyond the existing revocation timelines (24 hours
/ 5 days) is undesirable. While we think some exceptional delayed
revocations are necessary as a current practicality, we do want to
eventually sunset this policy. To that end, we’d like to refine our
existing policy so that it is more effective and equitable during the
interim.
We’re skeptical about proposals to pre-identify domains that will require
delayed revocation. We expect that many sites might ask for such
exceptions, and an extensive amount of deliberation would be required in
order to process these requests. Worse, in practice, doubtless some sites
impacted in a revocation event would not have followed the procedure, and
CAs would still be left with a last-minute decision about whether a
revocation will inflict substantial harm.
Instead, we would like to seek the community's feedback on the following
two proposals:
1.
Clarification of existing requirements
We would be more explicit about what would be required for delayed
revocation. Some ideas include:
1.
Explicitly clarifying that CAs must revoke certificates by default,
that any delayed revocation must be the result of an explicit request by
the subscriber, containing the necessary information, and meeting the
requirements under such interim policy;
2.
That subscriber requests contain a clear claim or explanation about
the critical nature of the system and why timely revocation is
not possible
(more detailed requirements to be discussed);
3.
That the requests are signed by a company officer, or similar legal
representative, stating that the information in the request is
accurate to
the best of their knowledge;
4.
That the information contained in the subscriber’s request be
accurate to the CA’s understanding (e.g. not materially contradicted by
other facts known to the CA);
5.
That each granted request be published for the community (and
Mozilla) to scrutinize (allowing CAs to redact PII prior to publication);
and
6.
That CAs be required to produce summary statistics in their reports
(alongside the individual granted requests) detailing how many requests
were received, how many were well-formed, how many were granted, etc.
2.
Consequences of Delayed Revocation
We believe that if a domain hosts critical infrastructure that cannot
tolerate timely revocation, then it is deeply damaging to the web PKI. In
order to help these domains transition to effective certificate management
practices and automated tooling, we propose that domains that are granted
delayed revocation must then be limited to shorter-lifetime certificates as
a consequence of such decision. This also ensures that future revocations
impacting such domains have much less impact.
Concretely, the domains accepted for delayed revocation by a CA are
already public. If this proposal were to be adopted, root programs would
manage a shared list of such domains (e.g. via the CCADB) and require CAs
to limit the lifetimes of certificates issued to these domains (e.g. to 90
days).
We stress that both of these proposals are presented for early feedback,
and we look forward to the community’s thoughts on whether they are likely
to be suitable and effective, and how they might be improved. We would also
look to align these policies across the root programs in order to provide
clarity for the entire community.
Thanks and best wishes,
Ben
--
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/CA%2B1gtaYZWhgfs23hB-Z%3DgEQCybugPrP8W4MSdnX9Y-dyoMoarA%40mail.gmail.com.
