<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">I'd be very much in agreement with the las sentence about the “SHOULD”, as I guess the intent is to ensure that the revocation of a certificate is reflected in the next CRL, and that CRL is issued before 24h counting after revocation.<div><br></div><div>I’d have a side (and maybe silly) question… how are RP to deal with the “nextUpdate”? Would that mean that the browser would be happy with a cached CRL until the nextUpdate is passed or are the browsers going to implement CRL cache refresh with certain frequency?<br><div><br><div><div><br><blockquote type="cite"><div>On 3 May 2023, at 10:49, Dimitris Zacharopoulos (HARICA) via Servercert-wg <servercert-wg@cabforum.org> wrote:</div><br class="Apple-interchange-newline"><div>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<div>
<br>
<br>
<div class="moz-cite-prefix">On 3/5/2023 12:01 π.μ., Aaron Gable
wrote:<br>
</div>
<blockquote type="cite" cite="mid:CAEmnErenXRrfgV0NDjmvdsNORAawr8WMg5EG7XBVpaqXnWg2ig@mail.gmail.com">
<div dir="ltr">
<div dir="ltr">On Tue, May 2, 2023 at 9:50 AM 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>
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div>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>
</div>
</blockquote>
<div><br>
</div>
<div>Ok, this is a good point, I'd forgotten that we already
have language to this effect in place for Subordinate CA
Certificates. That makes me slightly less reticent, but
certainly does not fully assuage my concerns.</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div> 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>
</div>
</blockquote>
<div><br>
</div>
<div>I was using "becomes aware" as short-hand for the total
set of requirements in 4.9.1.1. In the case where the
Subscriber requests that their own certificate be revoked,
the CA still has 24 hours from that time to do so!</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex"> 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.</blockquote>
<div><br>
</div>
<div>So you'd like to standardize the CA database schema? </div>
</div>
</div>
</blockquote>
<br>
Definitely not :-) The BRs are not meant to be overly technically
prescriptive. The implementation is up to each CA. If a CA doesn't
choose to store the actual certificate "revocationDate" (the
timestamp where the CA "marked" the change of certificate status
from valid to revoked), then the revocationDate of the new revoked
certificate entries will probably be exactly the same as the
"thisUpdate" of the CRL. Other CAs that have that capability to
store the revocationDate of each entry, will be able to signal that
certificate revocation timestamp more accurately.<br>
<br>
In the TLS server ecosystem, this level of accuracy is probably not
justified because the Relying Party will load a CRL and can totally
ignore the revocationDate entries. If a certificate serialNumber is
listed in a CRL, it should not be trusted for authentication; simple
:)<br>
<br>
<br>
<blockquote type="cite" cite="mid:CAEmnErenXRrfgV0NDjmvdsNORAawr8WMg5EG7XBVpaqXnWg2ig@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<div>The point of my illustrative example below was to
demonstrate that a CA does not necessarily have to store a
revocation timestamp in their database in order to be
compliant with your proposed requirement. </div>
</div>
</div>
</blockquote>
<br>
Agreed. This applies when the CA issues a CRL the moment the
certificate is "marked" as revoked, or if it considers the issuance
of the CRL as the "marking" of that revocation decision.<br>
<br>
<blockquote type="cite" cite="mid:CAEmnErenXRrfgV0NDjmvdsNORAawr8WMg5EG7XBVpaqXnWg2ig@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<div>If they choose not to do so, then it's completely unclear
when the proposed 4-hour clock starts.</div>
</div>
</div>
</blockquote>
<br>
I explained when the clock starts. A CA would have evidence to show
when it marked a certain certificate as revoked, and when the CRL
containing that entry was issued.<br>
<br>
<blockquote type="cite" cite="mid:CAEmnErenXRrfgV0NDjmvdsNORAawr8WMg5EG7XBVpaqXnWg2ig@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<div><br>
</div>
<div>On the one hand, you're correct -- I agree that
publishing every 24 hours is not inherently more secure than
publishing every 7 days, in the case that no new
certificates have been revoked.</div>
<div><br>
</div>
<div>But for me, the point is not just security, it's
automation. Publishing CRLs on a set schedule is easier,
safer, and more reliable than publishing CRLs immediately
after certs have been revoked *and also* on a much slower
set schedule just in case nothing has been revoked. If a
requirement such as you propose passes, I guarantee that
many CAs (LE included) will choose to simply publish a CRL
every 3 hours, rather than reactively publish them 4 hours
after a revocation.</div>
</div>
</div>
</blockquote>
<br>
The BRs are not meant to be more prescriptive than necessary. Some
CAs might have reasons not to issue CRLs as frequently as 24 hours
and would be fine to add some additional complexity. In most cases
CAs have already implemented and tested this additional complexity
(issue CRLs at least every 7 days but within 24h or much less, if a
certificate is revoked). <br>
<br>
BTW, these controls are all meant to be automated, I don't imagine
CAs to manually issue CRLs when certificates are revoked. If a CA
can automate issuance every 24 hours, it can automate issuance upon
a certificate being revoked.<br>
<br>
<blockquote type="cite" cite="mid:CAEmnErenXRrfgV0NDjmvdsNORAawr8WMg5EG7XBVpaqXnWg2ig@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<div><br>
</div>
<div>I don't think that this kind of two-tiered, reactive
requirement is healthy for the ecosystem.</div>
</div>
</div>
</blockquote>
<br>
I don't generally support the addition of unnecessary restrictions.
I try to follow the "save the planet" principles as much as possible
:) CRL issuance every 24 hours vs 7 days without changing the list
of revoked certificates in the CRL increases the db size, consumes
more resources thus energy without any security benefit. Even the
call for simplicity and automation can be challenged because CAs are
already required to fulfill and implement a lot more complex
processes described in the BRs.<br>
<br>
A CA is free to issue CRLs every 24 hours or more frequently if they
cannot implement a workflow that triggers issuance of a CRL when a
certificate is revoked. Triggering a CRL issuance when a certificate
is revoked seems to be very basic compared to some much more complex
requirements that need to be implemented. So I don't think the
ecosystem is at any risk with keeping the existing language for
issuance of CRLs every 7 days but issue one within 24h if a
certificate is revoked.<br>
<br>
<br>
<blockquote type="cite" cite="mid:CAEmnErenXRrfgV0NDjmvdsNORAawr8WMg5EG7XBVpaqXnWg2ig@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<div><br>
</div>
<div>If we want to shorten the timeline for revocation under
4.9.1.1 Paragraph 1 from 24 hours to 4 hours, then I'm not
opposed. </div>
</div>
</div>
</blockquote>
<br>
This cannot apply in all cases described in 4.9.1.1. It would
probably make sense to apply in cases where the Subscriber requests
the revocation after proper authentication, in which case the CA
probably doesn't need to do any investigation.<br>
<br>
<blockquote type="cite" cite="mid:CAEmnErenXRrfgV0NDjmvdsNORAawr8WMg5EG7XBVpaqXnWg2ig@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<div>But that seems like an orthogonal concern to this ballot.
I think we should preserve the current 24 hour timeline.</div>
</div>
</div>
</blockquote>
<br>
Please consider that the Baseline Requirements are "Baseline". CAs
should absolutely try to exceed the described limits and implement
stricter policies/thresholds in their systems.<br>
<br>
Since you agree that there is no security benefit for issuing CRLs
with the same list of revoked certificates every 24h over every 7
days, we could add a SHOULD for issuing CRLs every 24h. If a CA
implements a workflow that triggers CRL issuance 24h after a
certificate is revoked, it could continue to issue an unchanged CRL
at least every 7 days, as it would qualify as "<i>valid reasons in
particular circumstances to ignore a particular item</i>".
Thoughts?<br>
<br>
Thanks for the great discussion BTW :)<br>
<br>
Dimitris.<br>
</div>
_______________________________________________<br>Servercert-wg mailing list<br>Servercert-wg@cabforum.org<br>https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.cabforum.org_mailman_listinfo_servercert-2Dwg&d=DwICAg&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=-bX5hBm1IdRDykQ-dBR8tsFRCM4v1VXUyG7RZa2WqPY&m=zhenWr-mjtMI-piMpcVtaOvI1pwP6vzTcwOq5ZkDnyI&s=3rhc6miSu1C4-wb87kChnFEyg5rL4SzLYLkjDEgv9VM&e=<br></div></blockquote></div><br><div>
<meta charset="UTF-8"><div dir="auto" style="text-align: start; text-indent: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div dir="auto" style="text-align: start; text-indent: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div dir="auto" style="text-align: start; text-indent: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div style="text-align: start; text-indent: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div style="text-align: start; text-indent: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div style="text-align: start; text-indent: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div style="text-align: start; text-indent: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div style="text-align: start; text-indent: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div style="text-align: start; text-indent: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div style="text-align: start; text-indent: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><font style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); letter-spacing: normal; text-transform: none; white-space: normal; word-spacing: 0px; text-decoration: none; -webkit-text-stroke-width: 0px; font-size: 12px; font-style: normal; font-variant-ligatures: normal; font-variant-position: normal; font-variant-caps: normal; font-variant-numeric: normal; font-variant-alternates: normal; font-variant-east-asian: normal; font-weight: normal; line-height: normal; text-align: start; text-indent: 0px;"><b><font color="#f62400" style="font-size: 11px;"><br class="Apple-interchange-newline">WISeKey SA<br></font></b></font><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); letter-spacing: normal; text-transform: none; white-space: normal; word-spacing: 0px; text-decoration: none; -webkit-text-stroke-width: 0px; font-variant-ligatures: normal; font-variant-position: normal; font-variant-caps: normal; font-variant-numeric: normal; font-variant-alternates: normal; font-variant-east-asian: normal; line-height: normal; text-align: start; text-indent: 0px;"><font style="color: rgb(0, 0, 0); font-size: 12px; font-weight: normal; font-style: normal;"><span style="font-size: 11px;"><b>Pedro Fuentes<br></b>CSO - Trust Services Manager</span><br><font size="1">Office: + 41 (0) 22 594 30 00<br>Mobile: + 41 (0) </font></font><span style="color: rgb(0, 0, 0); font-size: x-small; font-weight: normal; font-style: normal;">791 274 790</span></div><div style="font-variant-ligatures: normal; font-variant-position: normal; font-variant-numeric: normal; font-variant-alternates: normal; font-variant-east-asian: normal; line-height: normal; text-align: start; text-indent: 0px;"><font style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-transform: none; white-space: normal; word-spacing: 0px; text-decoration: none; -webkit-text-stroke-width: 0px;"><font size="1">Address: </font></font><font size="1">Avenue Louis-Casaï 58 | </font><span style="font-size: x-small;">1216 Cointrin | Switzerland</span></div><div style="font-variant-ligatures: normal; font-variant-position: normal; font-variant-numeric: normal; font-variant-alternates: normal; font-variant-east-asian: normal; line-height: normal; text-align: start; text-indent: 0px;"><font><font size="1" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-transform: none; white-space: normal; word-spacing: 0px; text-decoration: none; -webkit-text-stroke-width: 0px;"><b>Stay connected with <a href="http://www.wisekey.com"><font color="#f62400">WISeKey</font></a><br></b></font></font><span style="caret-color: rgb(0, 0, 0); color: rgb(169, 169, 169); font-size: 10px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-transform: none; white-space: normal; word-spacing: 0px; text-decoration: none; -webkit-text-stroke-width: 0px; orphans: 2; widows: 2;"><br></span></div><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); letter-spacing: normal; text-transform: none; white-space: normal; word-spacing: 0px; text-decoration: none; -webkit-text-stroke-width: 0px; font-size: 12px; font-style: normal; font-variant-ligatures: normal; font-variant-position: normal; font-variant-caps: normal; font-variant-numeric: normal; font-variant-alternates: normal; font-variant-east-asian: normal; font-weight: normal; line-height: normal; text-align: start; text-indent: 0px;"><div style="font-variant-ligatures: normal; font-variant-position: normal; font-variant-numeric: normal; font-variant-alternates: normal; font-variant-east-asian: normal; line-height: normal;"><span style="orphans: 2; widows: 2;"><font size="1" color="#78a600"><b>THIS IS A TRUSTED MAIL</b>: This message is digitally signed with a WISeKey identity. If you get a mail from WISeKey please check the signature to avoid security risks</font></span></div><div style="font-variant-ligatures: normal; font-variant-position: normal; font-variant-numeric: normal; font-variant-alternates: normal; font-variant-east-asian: normal; line-height: normal;"><span style="orphans: 2; widows: 2; font-size: 9px;"><font color="#a9a9a9"><br></font></span></div><div style="font-variant-ligatures: normal; font-variant-position: normal; font-variant-numeric: normal; font-variant-alternates: normal; font-variant-east-asian: normal; line-height: normal;"><div style="orphans: 2; widows: 2;"><font color="#a9a9a9" style="font-size: 9px;"><b>CONFIDENTIALITY: </b>This email and any files transmitted with it can be confidential and it’s intended solely for the use of the individual or entity to which they are addressed. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. If you have received this email in error please notify the sender</font></div><div style="orphans: 2; widows: 2;"><font color="#a9a9a9" style="font-size: 9px;"><br></font></div><div style="orphans: 2; widows: 2;"><font color="#a9a9a9" style="font-size: 9px;"><b>DISCLAIMER: </b>WISeKey does not warrant the accuracy or completeness of this message and does not accept any liability for any errors or omissions herein as this message has been transmitted over a public network. Internet communications cannot be guaranteed to be secure or error-free as information may be intercepted, corrupted, or contain viruses. Attachments to this e-mail are checked for viruses; however, we do not accept any liability for any damage sustained by viruses and therefore you are kindly requested to check for viruses upon receipt.</font></div></div></div></div></div></div></div></div></div></div></div></div></div>
</div>
<br></div></div></div></body></html>