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

Wed May 3 08:48:59 UTC 2023

On 3/5/2023 12:01 π.μ., Aaron Gable wrote:
> 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?

Definitely not :-) The BRs are not meant to be overly technically 
prescriptive. The implementation is up to each CA. If a CA doesn't 
choose to store the actual certificate "revocationDate" (the timestamp 
where the CA "marked" the change of certificate status from valid to 
revoked), then the revocationDate of the new revoked certificate entries 
will probably be exactly the same as the "thisUpdate" of the CRL. Other 
CAs that have that capability to store the revocationDate of each entry, 
will be able to signal that certificate revocation timestamp more 
accurately.

In the TLS server ecosystem, this level of accuracy is probably not 
justified because the Relying Party will load a CRL and can totally 
ignore the revocationDate entries. If a certificate serialNumber is 
listed in a CRL, it should not be trusted for authentication; simple :)

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

Agreed. This applies when the CA issues a CRL the moment the certificate 
is "marked" as revoked, or if it considers the issuance of the CRL as 
the "marking" of that revocation decision.

> If they choose not to do so, then it's completely unclear when the 
> proposed 4-hour clock starts.

I explained when the clock starts. A CA would have evidence to show when 
it marked a certain certificate as revoked, and when the CRL containing 
that entry was issued.

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

The BRs are not meant to be more prescriptive than necessary. Some CAs 
might have reasons not to issue CRLs as frequently as 24 hours and would 
be fine to add some additional complexity. In most cases CAs have 
already implemented and tested this additional complexity (issue CRLs at 
least every 7 days but within 24h or much less, if a certificate is 
revoked).

BTW, these controls are all meant to be automated, I don't imagine CAs 
to manually issue CRLs when certificates are revoked. If a CA can 
automate issuance every 24 hours, it can automate issuance upon a 
certificate being revoked.

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

I don't generally support the addition of unnecessary restrictions. I 
try to follow the "save the planet" principles as much as possible :) 
CRL issuance every 24 hours vs 7 days without changing the list of 
revoked certificates in the CRL increases the db size, consumes more 
resources thus energy without any security benefit. Even the call for 
simplicity and automation can be challenged because CAs are already 
required to fulfill and implement a lot more complex processes described 
in the BRs.

A CA is free to issue CRLs every 24 hours or more frequently if they 
cannot implement a workflow that triggers issuance of a CRL when a 
certificate is revoked. Triggering a CRL issuance when a certificate is 
revoked seems to be very basic compared to some much more complex 
requirements that need to be implemented. So I don't think the ecosystem 
is at any risk with keeping the existing language for issuance of CRLs 
every 7 days but issue one within 24h if a certificate is revoked.

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

This cannot apply in all cases described in 4.9.1.1. It would probably 
make sense to apply in cases where the Subscriber requests the 
revocation after proper authentication, in which case the CA probably 
doesn't need to do any investigation.

> But that seems like an orthogonal concern to this ballot. I think we 
> should preserve the current 24 hour timeline.

Please consider that the Baseline Requirements are "Baseline". CAs 
should absolutely try to exceed the described limits and implement 
stricter policies/thresholds in their systems.

Since you agree that there is no security benefit for issuing CRLs with 
the same list of revoked certificates every 24h over every 7 days, we 
could add a SHOULD for issuing CRLs every 24h. If a CA implements a 
workflow that triggers CRL issuance 24h after a certificate is revoked, 
it could continue to issue an unchanged CRL at least every 7 days, as it 
would qualify as "/valid reasons in particular circumstances to ignore a 
particular item/". Thoughts?

Thanks for the great discussion BTW :)

Dimitris.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20230503/18897212/attachment-0001.html>