[Servercert-wg] [EXTERNAL]-Re: Discussion Period Begins - Ballot SC-063: “Make OCSP Optional and Incentivize Automation”

Wed May 3 09:20:37 UTC 2023

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.

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?

> On 3 May 2023, at 10:49, Dimitris Zacharopoulos (HARICA) via Servercert-wg <servercert-wg at cabforum.org> wrote:
> 
> 
> 
> On 3/5/2023 12:01 π.μ., Aaron Gable wrote:
>> On Tue, May 2, 2023 at 9:50 AM Dimitris Zacharopoulos (HARICA) <dzacharo at harica.gr <mailto:dzacharo at harica.gr>> wrote:
>>> Here is the current language in 4.9.7:
>>> 
>>> "For the status of Subordinate CA Certificates:
>>> 
>>> The CA SHALL update and reissue CRLs at least:
>>> 
>>> i. once every twelve months; and 
>>> ii. within 24 hours after revoking a Subordinate CA Certificate."
>>> 
>>> 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)
>> 
>> 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.
>>  
>>> 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.
>> 
>> 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!
>>  
>>> 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.
>> 
>> So you'd like to standardize the CA database schema?
> 
> 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.
> 
> 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 :)
> 
> 
>> 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.
> 
> 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.
> 
>> If they choose not to do so, then it's completely unclear when the proposed 4-hour clock starts.
> 
> 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.
> 
>> 
>> 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.
>> 
>> 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.
> 
> 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). 
> 
> 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.
> 
>> 
>> I don't think that this kind of two-tiered, reactive requirement is healthy for the ecosystem.
> 
> 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.
> 
> 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.
> 
> 
>> 
>> 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.
> 
> 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.
> 
>> But that seems like an orthogonal concern to this ballot. I think we should preserve the current 24 hour timeline.
> 
> 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.
> 
> 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 "valid reasons in particular circumstances to ignore a particular item". Thoughts?
> 
> Thanks for the great discussion BTW :)
> 
> Dimitris.
> _______________________________________________
> Servercert-wg mailing list
> Servercert-wg at cabforum.org
> 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=

WISeKey SA
Pedro Fuentes
CSO - Trust Services Manager
Office: + 41 (0) 22 594 30 00
Mobile: + 41 (0) 791 274 790
Address: Avenue Louis-Casaï 58 | 1216 Cointrin | Switzerland
Stay connected with WISeKey <http://www.wisekey.com/>

THIS IS A TRUSTED MAIL: This message is digitally signed with a WISeKey identity. If you get a mail from WISeKey please check the signature to avoid security risks

CONFIDENTIALITY: 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

DISCLAIMER: 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20230503/b5b3a912/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3398 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20230503/b5b3a912/attachment-0001.p7s>