[Servercert-wg] Discussion Period Begins - Ballot SC-063: “Make OCSP Optional and Incentivize Automation”

[Dimitris Zacharopoulos (HARICA)]

On 1/5/2023 7:57 μ.μ., Aaron Gable wrote:
> On Thu, Apr 27, 2023, 09:36 Dimitris Zacharopoulos (HARICA) via 
> Servercert-wg <servercert-wg at cabforum.org> wrote:
>
>     If people agree, I would like to keep the language for "online
>     CAs" to issue CRLs at least once every 7 days but issue and
>     publish within 4 hours if a Subscriber Certificate is revoked.
>     That approach would propagate the "revocation message" sooner to
>     Relying Parties and would also remove the unnecessary "cost" of
>     issuing CRLs unnecessarily (i.e. if no revocations take place).
>
>     Thoughts?
>
>
> Although I appreciate the sentiment, I don't think a system like this 
> can be made to work meaningfully.
>
> It's been long established on this list that a certificate is not 
> considered revoked until its new status is globally visible. This has 
> led to many incidents where a CA produced a new OCSP response within 
> the required 24-hour window, but that response wasn't visible (e.g. 
> was hidden behind cached copies of the old response) until after the 
> 24-hour time limit had passed.

Caching issues may affect OCSP responses, CRLs, etc. A CA that revokes a 
certificate needs to properly propagate this new status and invalidate 
the various caching nodes if they use CDNs. However, there is always 
some time (greater than zero) between marking the certificate as revoked 
in the CA database and issuing a CRL.

Currently, the BRs require an Issuing CA to issue and publish a new CRL 
at least once every 7 days even if no Subscriber Certificate is revoked 
from that Issuing CA. Do you see any security gain if a new CRL is 
issued and published every 24 hours, even though the list of revoked 
certificates remains the same? Adding a requirement to issue and publish 
a new CRL within 4 hours (we could even lower that to 1 hour or even 15 
minutes) if a Subscriber Certificate is revoked seems like a good 
improvement that sets a specific target that currently seems to be 
missing from the BRs.


>
> In a world where CAs are not issuing OCSP at all, and are relying 
> solely on CRLs to publish revocation information, your proposal 
> becomes cyclic: The CA must publish their CRL within 4 hours of 
> publishing their CRL.

I'm not following your logic but perhaps I did not communicate the 
proposal very well. Let me try with a specific example.

Assuming there is an Issuing CA that is not issuing OCSP responses and 
it only signs short-lived certificates that are valid for 10 days. 
Assuming that Issuing CA has not revoked any certificates, it will have 
to produce an empty CRL at least every 7 days. Producing an empty CRL 
every 24 hours doesn't improve anything. If it needs to revoke one of 
those short-lived certificates, then it would issue and publish a CRL at 
most within 4-hours (or less if we decide) after the certificate is 
marked revoked. Then, the CRL will have one entry and that CRL will be 
re-issued at least every 7 days. Does that make sense? I don't see any 
disadvantages with this approach.

>
> Perhaps the phrasing could be turned inside out. Something like "when 
> a CRL is published, all new entries must have a revocationDate no more 
> than 4 hours before the CRL's thisUpdate". But that phrasing seems 
> torturous and unclear as to the motivation behind it.

In most cases, the CA will issue the CRL the moment the certificate gets 
revoked, so the /revocationDate /entry will be very close to the 
/thisUpdate /of the CRL. However, in cases where a CA gets a lot of 
revocation requests, it makes sense to "collect" those revocation 
requests for some time (e.g. for 10 minutes) and then issue the CRL. Do 
we have any restrictions in the current BRs to address this CRL issuance 
"delay"?

>
> I would prefer to instead simply make a carve-out for CAs that have 
> not issued any certificates. Simply, the requirements proposed in this 
> ballot should only apply to CRLs whose cRLDistributionPoint has 
> appeared in at least one certificate. If no publicly-trusted cert has 
> ever pointed a client at this CRL URL, then there are no requirements 
> to be publishing CRLs at that URL. Once the CA has begun issuance, 
> then the CRL requirements should continue until it expires.

I believe this carve-out is supported by at least 2 Root Programs 
regarding the disclosure in CCADB. However, we should probably keep in 
mind that in the WebPKI, CRLs are processed by Relying Party software by 
using the CRLDP and indirectly via CCADB ("Full CRL Issued By This CA"). 
With that said, if all Browsers used the CCADB "Full CRL Issued By This 
CA" information to collect and distribute the information about revoked 
certificates to Relying Parties, short-lived certificates would not need 
to have a CRLDP extension nor the AIA OCSP responder URL.


Thanks,
Dimitris.

>
> Aaron
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20230502/61cb046c/attachment.html>