On Tuesday, October 18, 2016 at 10:52:19 AM UTC-7, Rob Stradling wrote:
> AIUI, it's permissible to "un-revoke" any certificate via OCSP, but it's
> only permissible to "un-revoke" a certificate via CRL if it was revoked
> with the reason code certificateHold.
Which "permissible" are we talking about? BRs or 5280?
While 5280 allows certificateHold, the BRs do not - see 4.9.13:
The Repository MUST NOT include entries that indicate that a Certificate is
This tries to make it very clear that you shouldn't "un-revoke" a certificate,
using 5280 language. This frequently comes up when performing CP/CPS reviews
for European CAs, since many use a unified CP/CPS to cover both TLS/SSL and
other forms (e.g. e-signature certificates), and is flagged as a Bad (because
it may be a violation of the BRs)
But let's take a little step back here - to me, this suggests a bit of
ambiguity with respect to the BRs' notion of revocation. That is, we might
think of revocation as a conceptual thing - a certificate is either revoked or
it's not, and once it's revoked, it should not be unrevoked. However, how that
revocation is communicated is done via Repositories - provided via CRLs and
OCSP, for sure, but we've certainly seen CAs provide other forms of
repositories. If you think back to India CCA, for example, they had a
repository where you could look up by serial number and see the status, via a
web page. And we see request CAs revoke by entering revocation information into
Salesforce - ostensibly, another form of Repository.
So what we see with GlobalSign incident is that the Repository had issues, not
reflective of the conceptual Revocation that was performed. That is, the
software hosting the Repository improperly returned some certificates as
revoked, even though GlobalSign had not "revoked" them. That is, at least based
on my understanding of the incident report, it seems to be an issue with an
OCSP responder fed via CRLs, and the issue was the responder software.
Every CA is required to retain an unmodifiable audit log of these Revocations,
which may be independent of the Repository representation. That is, *something*
has to feed the CRL for generation - most frequently a 'backing' database,
rather than 'chaining' CRLs from the past.
This is all subtle semantics, and I'm concerned that it may allow CAs to 'game'
the system, but at least with respect to GlobalSign, that's how I view this
incident and it's relation to the BRs. In my view, if a CA "revokes" a
certificate in their underlying system, they MUST NOT unrevoke, on the basis of
4.9.13. Similarly, they're expected to communicate that revocation detail via
It's possible in the future that future Repositories will encounter similar
desync events with the backing store, much like GlobalSign's did. I think each
of those represent an Incident - a failure of the Repository is potentially a
failure of 2.1 of the BRs. I do not believe it's in the best interest of the
ecosystem to suggest that CAs can "unrevoke" certificates, but I also
understand issues and bugs happen - and we should treat such incidents as such,
and evaluate on a case-by-case basis and evaluate the CA's communications,
explanations, frequency, and practices to determine whether this represents a
risk to Mozilla users.
dev-security-policy mailing list