I must admit I'm still not enamored with this use of "has revoked". Despite Dimitris' totally valid point that we already do this for Subordinate CA Certificates, to me it feels like an unfortunate precedent to carry forward. How can a CA be said to "have revoked" something if they haven't published a CRL containing it yet? Also, this phrasing is impossible. Suppose that a CA issues a CRL, and then coasts for 5 days with no revocations being necessary. This is permitted under the "All other conditions" entry. Then, a cert needs to be revoked. But significantly more than 24 hours have already passed since the `thisUpdate` of the previous CRL! So in practice, a CA would be required to issue at least every 24 hours, just in case a new revocation request comes in. These kinds of accidental gotchas are why I'm opposed to a two-tiered system of CRL issuance frequency requirements. We've already demonstrated that it is difficult to write and read (I missed this contradiction on my first two reads of this diff!) requirements like this. We should not be making things more difficult than necessary. I'm still in favor of the previous "CAs issuing Subscriber Certificates SHALL update and reissue CRLs at least once every 24 hours".

Tried to use similar language for Subscriber and CA Certificates for consistency. I also proposed following the NSR style for numbers, especially now that we have so many different numbers in the same subsection. It would be great if we could make a pass through the entire document and apply this style in a future cleanup ballot. ```suggestion CAs issuing Subscriber Certificates: 1. MUST update and publish a new CRL within at least: - seven (7) days if all Certificates include an Authority Information Access extension with an id-ad-ocsp accessMethod (“AIA OCSP pointer”); or - four (4) days in all other cases; 2. MUST update and publish a new CRL within twenty four (24) hours after recording a Certificate as revoked; and 3. MUST include a `nextUpdate` field value that is no more than ten (10) days beyond the value of the `thisUpdate` field. CAs issuing CA Certificates: 1. MUST update and publish a new CRL within at least twelve (12) months; 2. MUST update and publish a new CRL within twenty four (24) hours after recording a Subordinate CA Certificate as revoked; and 3. MUST include a `nextUpdate` field value that is no more than twelve (12) months beyond the value of the `thisUpdate` field. CAs MUST continue issuing CRLs until one of the following is true: - all Subordinate CA Certificates containing the same Subject Public Key are expired or revoked; OR - the corresponding Subordinate CA Private Key is destroyed. ```

I do like this phrasing update. However, it doesn't fully answer my question: Is it acceptable for a CA to operate an OCSP service for only *some* of the non-expired certificates it has issued? For example, a CA might switch from including an AIA OCSP url in its certificates, to including a CRLDP url in its certificates, with no overlap: each Subscriber cert contains only one or the other. Is the CA required to provide OCSP responses, and update those responses no later than four days after the thisUpdate, even for the certificates that do not embed an AIA OCSP url? The previous phrasing ("support on-line revocation status checking using OCSP") and the current phrasing ("signs OCSP responses") both seem to assume that OCSP support is a binary thing: either the CA does it, or it doesn't. This makes sense both in today's world when OCSP is required, and in the potential future when OCSP is wholly optional. It raises questions about the transition period, however. To be clear, I don't think this is insurmountable. For example, a CA could choose to stop including AIA OCSP urls, but continue providing OCSP responses for all certificates until all certificates with an AIA OCSP url have expired, then instantaneously stop providing any OCSP responses at all. But since many CAs will be going through a transition period here, some clarity if possible would be nice.