BRs: Clarify what "revocation" means on a technical level

[sleevi]

Section 4.9.1.1 of the BRs requires:

The CA SHALL revoke a Certificate within 24 hours if one or more of the following occurs:

However, Section 4.9.7 of the BRs states:

For the status of Subscriber Certificates:
If the CA publishes a CRL, then the CA SHALL update and reissue CRLs at least once every seven days, and the value of the nextUpdate field MUST NOT be more than ten days beyond the value of the thisUpdate field.

And Section 4.9.8 states:

4.9.8 Maximum latency for CRLs (if applicable)
No stipulation.

This creates some ambiguity for CAs about what "SHALL revoke" entails. Is it the matter of merely setting a is_revoked bit on the server, or is it the act of publishing new CRLs and OCSP responses to indicate this status? RFC 5280 takes the perspective that 'the repository' is the store of CRLs, and so naturally the expectation is that yes, "SHALL revoke" is the act of publishing new CRLs and OCSP responses and ensuring they're available (c.f. 4.10.2 of the BRs).

However, a secondary question then follows: If a given certificate has both an OCSP AIA and a CRL Distribution Point, are those two systems allowed to be out of sync for any period of time after revocation has occurred? That is, once revoked, does a CA need to immediately generate both a new CRL and a new OCSP response, or can they generate one (e.g. OCSP) but not the other (e.g. CRL)? RFC 6960 notes that OCSP enables more timely obtaining of status information than CRLs, but is that a statement merely about local client caching behaviours, or is it an intrinsic property that the two systems are allowed to diverge?

We should clarify precisely what the expectation of revocation means, and how that flows into the requirements.

A suggested strawman for discussion:

• Revocation is the act of publishing, within the repository, both OCSP (if supported/required) and CRLs (if supported/required) that reflect the status of the certificate.
  • For CAs that use a CDN in front of a CA system, this means that the CDN itself reflects the status to Relying Parties
• That obligations on revocation timelines imply and result in obligations on OCSP and/or CRL publishing

[aarongable]

Just as a note here, one of the causes of confusion here is that the BRs do specify both a timeline for revocation and a timeline for publication (via OCSP or CRL) for Subordinate CA Certificates:

Section 4.9.1.2
The Issuing CA SHALL revoke a Subordinate CA Certificate within seven (7) days if one or
more of the following occurs: ...

Section 4.9.7
For the status of Subordinate CA Certificates:
The CA SHALL update and reissue CRLs at least (i) once every twelve months and (ii)
within 24 hours after revoking a Subordinate CA Certificate...

Section 4.9.10
For the status of Subordinate CA Certificates:
• The CA SHALL update information provided via an Online Certificate Status Protocol (i) at
least every twelve months; and (ii) within 24 hours after revoking a Subordinate CA
Certificate.

However, while the quote from section 4.9.1.2 has an analogue for subscriber certs...

Section 4.9.1.1
The CA SHALL revoke a Certificate within 24 hours if one or more of the following occurs: ...

...no such equivalents exist for the latter two quotes.

In addition to providing a more rigorous definition of "revocation", it would be useful to unify the language regarding subscriber certs and the language regarding intermediate CA certs, such that a CA cannot read too much into the difference between them.

[neildunbar]

Thinking on the CDN for CRL distribution aspect: I think that requiring a cache purge (which, depending on cache architecture) can be an expensive operation on a per-revocation basis would negate much of the utility of a CDN in the first place. It is expected behaviour that a CDN can produce inconsistent responses to a GET operation, unless that CDN has extremely aggressive ICP configuration.

On the point at hand, I think that revocation, realistically, must mean that a verifiable signing operation traceable to the issuing CA must take place, complete with timestamps. Of course, a dishonest CA could backdate a revocation, but there are all sorts of failure modes which occur when facing backdating dishonesty. But flipping a bit in the database is the beginning of the revocation operation - signing of the decision is the point at which that revocation is externally verified, and should be counted as such as satisfying (or not!) the timeliness requirement of the revocation.

[sleevi]

signing of the decision is the point at which that revocation is externally verified, and should be counted as such as satisfying (or not!) the timeliness requirement of the revocation.

This is not the final step of revocation. Revocation is publication at the CDN in a consistent view, an expectation that has been communicated in past incidents. I agree with you that signing is, at minimum, part of the act, but inconsistent CDN views are indistinguishable from not having published. Unless and until such information is globally visible, the CA has not revoked the certificate. If their CDN makes that difficult, then they need to look at other CDN approaches, such as those outlined for immediate cache invalidation.

[neildunbar]

OK - so if the maximum cache time for a revocation relevant artifact (OCSP response, CRL) is set to X hours, then assuming that revocation initiation (meaning signing said artifact and publishing to origin) is done in (24 - X) hours, then revocation can be said to have been completed within 24 hours (per the requirements); would that be a way of satisfying the desire for a world-wide consistent view?

I've not reviewed CDN service level agreements in a while; but having worked for a CDN, I can attest that guaranteeing the effect of global cache purge is not that bulletproof.

Don't get me wrong: it's not the BR's job to protect the CAs from choosing ill suited technologies to perform their tasks. I'm just trying to figure out the best ways of handling the problem. I'm sympathetic to the view that says "revocation is done when the world can see that it's been done", but the reality of CDNs as a method of global distribution adds complexity to that picture.

[sleevi]

would that be a way of satisfying the desire for a world-wide consistent view?

Yup!

the reality of CDNs as a method of global distribution adds complexity to that picture.

Wholly agreed! I think there’s always room for further discussion when attached with specific technical details. For example, the bug I linked to was very useful in diving deeper into the service offerings of a variety of CDNs, and if/how they offer invalidation APIs and their limits. We certainly want to keep within the bounds of reasonable, but it does mean exploring the difference between “this is inconvenient” and “this is difficult” and “this is impossible”. The more we can unpack these technical details, the more we can align on clear and consistent expectations.