<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
Hi Aaron,<br>
<br>
<div class="moz-cite-prefix">On 2/5/2023 6:32 μ.μ., Aaron Gable
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAEmnEre-D06WPcCjeSt6bW_y=hiWfQ6JBQ2k1qwgqk4s0a-+cA@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<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>
</div>
</blockquote>
<br>
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.<br>
<br>
<blockquote type="cite"
cite="mid:CAEmnEre-D06WPcCjeSt6bW_y=hiWfQ6JBQ2k1qwgqk4s0a-+cA@mail.gmail.com">
<div dir="auto">
<div>
<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>
</div>
</blockquote>
<br>
Here is the current language in 4.9.7:<br>
<br>
<i>"For the status of Subordinate CA Certificates:</i><i><br>
</i><i><br>
</i><i>The CA SHALL update and reissue CRLs at least:</i><i><br>
</i><i><br>
</i><i>i. once every twelve months; and </i><i><br>
</i><i>ii. within 24 hours after revoking a Subordinate CA
Certificate."</i><br>
<br>
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)<br>
<br>
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.<br>
<br>
The "globally visible" element is not part of the current BRs. This
body (the SCWG) doesn't have any specific requirements for that.<br>
<br>
<blockquote type="cite"
cite="mid:CAEmnEre-D06WPcCjeSt6bW_y=hiWfQ6JBQ2k1qwgqk4s0a-+cA@mail.gmail.com">
<div dir="auto">
<div>
<div dir="auto"><br>
</div>
<div dir="auto">There is no recognized timestamp at which this
4-hour clock could start. </div>
</div>
</div>
</blockquote>
<br>
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.<br>
<br>
<blockquote type="cite"
cite="mid:CAEmnEre-D06WPcCjeSt6bW_y=hiWfQ6JBQ2k1qwgqk4s0a-+cA@mail.gmail.com">
<div dir="auto">
<div>
<div dir="auto">Having it start when the CA "becomes aware" is
obviously bad, as that would shorten the investigation
timeline from 24 hours to 4 hours.</div>
</div>
</div>
</blockquote>
<br>
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.<br>
<br>
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.<br>
<br>
<blockquote type="cite"
cite="mid:CAEmnEre-D06WPcCjeSt6bW_y=hiWfQ6JBQ2k1qwgqk4s0a-+cA@mail.gmail.com">
<div dir="auto">
<div>
<div dir="auto"> 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>
</div>
</blockquote>
<br>
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.<br>
<br>
<blockquote type="cite"
cite="mid:CAEmnEre-D06WPcCjeSt6bW_y=hiWfQ6JBQ2k1qwgqk4s0a-+cA@mail.gmail.com">
<div dir="auto">
<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. </div>
</div>
</div>
</blockquote>
<br>
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?<br>
<br>
<blockquote type="cite"
cite="mid:CAEmnEre-D06WPcCjeSt6bW_y=hiWfQ6JBQ2k1qwgqk4s0a-+cA@mail.gmail.com">
<div dir="auto">
<div>
<div dir="auto">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>
</div>
</blockquote>
<br>
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. <br>
<br>
<blockquote type="cite"
cite="mid:CAEmnEre-D06WPcCjeSt6bW_y=hiWfQ6JBQ2k1qwgqk4s0a-+cA@mail.gmail.com">
<div dir="auto">
<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>
</div>
</blockquote>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
This ballot definitely opened up several topics in parallel.
Revocation is always a hot topic to discuss :) <br>
<br>
<br>
Thanks,<br>
Dimitris.<br>
<br>
<br>
<blockquote type="cite"
cite="mid:CAEmnEre-D06WPcCjeSt6bW_y=hiWfQ6JBQ2k1qwgqk4s0a-+cA@mail.gmail.com">
<div dir="auto">
<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" moz-do-not-send="true"
class="moz-txt-link-freetext">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"
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">
<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>
</blockquote>
<br>
</body>
</html>