<div dir="auto"><div>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*?<div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">Aaron</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, May 2, 2023, 02:55 Dimitris Zacharopoulos (HARICA) <<a href="mailto:dzacharo@harica.gr">dzacharo@harica.gr</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<br>
<br>
<div>On 1/5/2023 7:57 μ.μ., Aaron Gable
wrote:<br>
</div>
<blockquote type="cite">
<div dir="auto">
<div>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Thu, Apr 27, 2023,
09:36 Dimitris Zacharopoulos (HARICA) via Servercert-wg
<<a href="mailto:servercert-wg@cabforum.org" target="_blank" rel="noreferrer">servercert-wg@cabforum.org</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<p>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).<br>
</p>
Thoughts?<br>
</div>
</blockquote>
</div>
</div>
<div dir="auto"><br>
</div>
<div dir="auto">Although I appreciate the sentiment, I don't
think a system like this can be made to work meaningfully.</div>
<div dir="auto"><br>
</div>
<div dir="auto">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.</div>
</div>
</blockquote>
<br>
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.<br>
<br>
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.<br>
<br>
<br>
<blockquote type="cite">
<div dir="auto">
<div dir="auto"><br>
</div>
<div dir="auto">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.</div>
</div>
</blockquote>
<br>
I'm not following your logic but perhaps I did not communicate the
proposal very well. Let me try with a specific example.<br>
<br>
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.<br>
<br>
<blockquote type="cite">
<div dir="auto">
<div dir="auto"><br>
</div>
<div dir="auto">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.</div>
</div>
</blockquote>
<br>
In most cases, the CA will issue the CRL the moment the certificate
gets revoked, so the <i>revocationDate </i>entry will be very
close to the <i>thisUpdate </i>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"?<br>
<br>
<blockquote type="cite">
<div dir="auto">
<div dir="auto"><br>
</div>
<div dir="auto">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.</div>
</div>
</blockquote>
<br>
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.<br>
<br>
<br>
Thanks,<br>
Dimitris.<br>
<br>
<blockquote type="cite">
<div dir="auto">
<div dir="auto"><br>
</div>
<div dir="auto">Aaron</div>
<div dir="auto">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote>
</div>
</div>
</div>
</blockquote>
<br>
</div>
</blockquote></div></div></div>