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 
the Repository.

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

Reply via email to