<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<br>
<br>
<div class="moz-cite-prefix">On 1/5/2023 7:57 μ.μ., Aaron Gable
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAEmnErfG=icB9Pn8ZBsy2A_Y57fzN7NzZs6c_cZDYoiJSH-gKw@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<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"
moz-do-not-send="true" class="moz-txt-link-freetext">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"
cite="mid:CAEmnErfG=icB9Pn8ZBsy2A_Y57fzN7NzZs6c_cZDYoiJSH-gKw@mail.gmail.com">
<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"
cite="mid:CAEmnErfG=icB9Pn8ZBsy2A_Y57fzN7NzZs6c_cZDYoiJSH-gKw@mail.gmail.com">
<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"
cite="mid:CAEmnErfG=icB9Pn8ZBsy2A_Y57fzN7NzZs6c_cZDYoiJSH-gKw@mail.gmail.com">
<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"
cite="mid:CAEmnErfG=icB9Pn8ZBsy2A_Y57fzN7NzZs6c_cZDYoiJSH-gKw@mail.gmail.com">
<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>
</body>
</html>