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

Tue May 2 16:50:18 UTC 2023

Hi Aaron,

On 2/5/2023 6:32 μ.μ., Aaron Gable wrote:
> Sorry, I didn't express myself well. My core question about this 
> proposal is: the CA must publish a new CRL within 4 hours *of what*?

Following the same logic as section 4.9.7 for Subordinate CA 
Certificates, I would say that the CA must publish a new CRL within 4 
hours of when the certificate is revoked. See below.

>
> This body generally recognizes two events when it comes to revocation: 
> the time at which the CA "becomes aware" that the certificate needs to 
> be revoked, and the time at which that revocation is globally visible. 
> There is no recognition of a time at which the certificate is "revoked 
> in an internal database" or anything like that.

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)

Agreed that there is no similar language for subscriber certificates. 
So, worse case, a Subscriber requests their certificate to be revoked 
and a new CRL will be issued after 24 hours. The "4 hours" proposal 
improves that. Again, the number came out of thin air. We could reduce 
it to "20 minutes" if people find it more appropriate.

The "globally visible" element is not part of the current BRs. This body 
(the SCWG) doesn't have any specific requirements for that.

>
> There is no recognized timestamp at which this 4-hour clock could start.

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.

> Having it start when the CA "becomes aware" is obviously bad, as that 
> would shorten the investigation timeline from 24 hours to 4 hours.

CAs don't always need to investigate revocation requests. The most 
common revocation cases are the ones where the actual subscriber 
requests their certificate to be revoked in an authenticated manner. In 
that case, no investigation is necessary and no certificate problem 
reports are filed.

Again, in my view the "4 hours" gap describes the time between the CA 
declaring a certificate as revoked and issuing/publishing a CRL that 
states that such a certificate is revoked.

> Having it start when the new revocation information is globally 
> available is impossible, as that would require the CA to have already 
> published the information via another mechanism.

This is based on a wrong assumption about what those "4 hours" were 
intended to be in my proposal, which is leading to incorrect results in 
logic.

>
> There is a third timestamp that could be used: the revocationDate 
> timestamp in the CRL entry.

Exactly! Currently this gap can take as much as 24 hours based on 
4.9.1.1(1). Wouldn't it be better to make that gap smaller?

> But again the argument is at least slightly circular, in that the 
> revocationDate in the CRL doesn't actually exist until the CRL has 
> been published. Before that it's just an entry in a database.

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.

>
> One can even imagine a (fully compliant!) CA which always shares the 
> same timestamp for the thisUpdate of a CRL and the revocationDate of 
> all new entries in that CRL. It would be technically correct, as those 
> certificates are not actually revoked until that CRL is published. And 
> it could publish one such CRL every 24 hours and always be compliant 
> with this proposed requirement.

Based on our continued discussion, at a minimum I believe we must 
clarify the expectations in that section because when reading 4.9.7, the 
language around the revocation of Subordinate CA Certificates creates 
ambiguity about the expectations of what "revoked" means for Subscriber 
Certificates.

The ambiguity of "publish a CRL" can be resolved by changing the 
language to"issue and publish a CRL". Then the "thisUpdate" value must 
be different between CRLs.

In any case, when the list of revoked certificates remains unchanged, 
you seem to agree with me that issuing a new CRL every 24 hours doesn't 
improve security compared to keeping the same CRL published for 7 days.

This ballot definitely opened up several topics in parallel. Revocation 
is always a hot topic to discuss :)

Thanks,
Dimitris.

>
> Aaron
>
> On Tue, May 2, 2023, 02:55 Dimitris Zacharopoulos (HARICA) 
> <dzacharo at harica.gr> wrote:
>
>
>
>     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/78eb4152/attachment-0001.html>