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

Tue May 2 15:32:22 UTC 2023

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*?

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.

There is no recognized timestamp at which this 4-hour clock could start.
Having it start when the CA "becomes aware" is obviously bad, as that would
shorten the investigation timeline from 24 hours to 4 hours. 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.

There is a third timestamp that could be used: the revocationDate timestamp
in the CRL entry. 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.

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.

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/b172320a/attachment.html>