<div dir="ltr"><div dir="ltr">On Tue, May 2, 2023 at 9:50 AM Dimitris Zacharopoulos (HARICA) <<a href="mailto:dzacharo@harica.gr">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? 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. If they choose not to do so, then it's completely unclear when the proposed 4-hour clock starts.</div><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><br></div><div>I don't think that this kind of two-tiered, reactive requirement is healthy for the ecosystem.</div><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. But that seems like an orthogonal concern to this ballot. I think we should preserve the current 24 hour timeline.</div><div><br></div><div>Aaron</div></div></div>