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

[Aaron Gable]

On Tue, May 2, 2023 at 9:50 AM Dimitris Zacharopoulos (HARICA) <
dzacharo at harica.gr> wrote:

> Here is the current language in 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."*
>
> This clearly states that if a CA revokes a Subordinate CA Certificate, a
> CRL must be issued within 24 hours, otherwise, the CRL must be reissued at
> least once every twelve months. There is a clear gap between the two events
> (revoke and issue the CRL)
>

Ok, this is a good point, I'd forgotten that we already have language to
this effect in place for Subordinate CA Certificates. That makes me
slightly less reticent, but certainly does not fully assuage my concerns.


> What about the case that a Subscriber authenticates to the RA and requests
> a certificate (their certificate) to be revoked? The CA "becomes aware"
> language applies to Certificate Problem Reports and specific use cases
> described in 4.9.1.1.
>

I was using "becomes aware" as short-hand for the total set of requirements
in 4.9.1.1. In the case where the Subscriber requests that their own
certificate be revoked, the CA still has 24 hours from that time to do so!


> This is not circular. The CA keeps the revocationDate timestamp in a
> database, processes as many revocation requests within a certain time
> window (e.g. 10 minutes), and then issues a CRL.


So you'd like to standardize the CA database schema? The point of my
illustrative example below was to demonstrate that a CA does not
necessarily have to store a revocation timestamp in their database in order
to be compliant with your proposed requirement. If they choose not to do
so, then it's completely unclear when the proposed 4-hour clock starts.

On the one hand, you're correct -- I agree that publishing every 24 hours
is not inherently more secure than publishing every 7 days, in the case
that no new certificates have been revoked.

But for me, the point is not just security, it's automation. Publishing
CRLs on a set schedule is easier, safer, and more reliable than publishing
CRLs immediately after certs have been revoked *and also* on a much slower
set schedule just in case nothing has been revoked. If a requirement such
as you propose passes, I guarantee that many CAs (LE included) will choose
to simply publish a CRL every 3 hours, rather than reactively publish them
4 hours after a revocation.

I don't think that this kind of two-tiered, reactive requirement is healthy
for the ecosystem.

If we want to shorten the timeline for revocation under 4.9.1.1 Paragraph 1
from 24 hours to 4 hours, then I'm not opposed. But that seems like an
orthogonal concern to this ballot. I think we should preserve the current
24 hour timeline.

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