[Servercert-wg] SC-59 Weak Key Guidance v.2 - Discussion Period

Wed Jul 5 21:14:58 UTC 2023

I agree with the ballot author(s) and endorsers. This ballot is focused on addressing gaps in the current BRs related to overall weak key guidance (not just Debian weak key checks). The topic of removing the requirement for Debian weak key checking is separate from what I understand the intent and goal of this ballot to ever have been and should be addressed in its own ballot. 

Is the concern from CAs that the Debian weak key requirements in this ballot are meaningfully different than what they’re doing today, and they’d like to avoid doing that work? If so, can you explain what the difference(s) is and what impact it’s expected to have for your CA? 

FWIW my read of the current situation is that I don’t think there’s consensus to remove Debian weak key checks at this time, but I do think there’s at least rough consensus that it’s a topic worth discussing/pursuing.

Thanks,
-Clint

> On Jul 5, 2023, at 12:44 PM, Tom Zermeno via Servercert-wg <servercert-wg at cabforum.org> wrote:
> 
> Does anyone have any comments to add to this discussion?  Is it worthwhile to consider the removal of DWK checks at this time, or should it be considered at a later date?
>  
> -Tom
>  
> From: Tom Zermeno <tom at ssl.com <mailto:tom at ssl.com>> 
> Sent: Thursday, June 29, 2023 11:55 AM
> To: Christophe Bonjean <christophe.bonjean at globalsign.com <mailto:christophe.bonjean at globalsign.com>>; CA/B Forum Server Certificate WG Public Discussion List <servercert-wg at cabforum.org <mailto:servercert-wg at cabforum.org>>
> Subject: RE: SC-59 Weak Key Guidance v.2 - Discussion Period
>  
> Christophe, 
>  
> The consideration of removing the checks brings up many questions.  As a CA representative, do you feel that the removal of a requirement to check for and revoke Debian Weak Key certificates would pose a risk to relying parties?  Granted, the method has been patched for 15 years and the certificates are almost never seen in the wild, and to generate DWK certificates someone would either have not patched their system in over a decade or specifically gone out of their way to obtain the software versions capable of creating those certs. Should we chalk it up to a “Darwin Award” for the subscribers who accidentally, or ignorantly, fall into that category?  Should CAs still be responsible for the relying parties who will undoubtedly be hurt when the certificate is cracked, or would/could that burden be placed upon the subscriber by an Agreement clause akin to “keep your private key safe”?
>  
> Tom
>  
> From: Christophe Bonjean <christophe.bonjean at globalsign.com <mailto:christophe.bonjean at globalsign.com>> 
> Sent: Thursday, June 29, 2023 7:11 AM
> To: Tom Zermeno <tom at ssl.com <mailto:tom at ssl.com>>; CA/B Forum Server Certificate WG Public Discussion List <servercert-wg at cabforum.org <mailto:servercert-wg at cabforum.org>>
> Subject: RE: SC-59 Weak Key Guidance v.2 - Discussion Period
>  
> Hi Tom
>  
> Thank you for looking into the feedback. 
>  
> With the concerns about Debian weak key checks and revocation, where there is already today doubt about keeping it in a future version of the requirements, with some suggestions to remove it in a next ballot, it seems we would be spending double efforts with first this ballot and a subsequent discussion for a topic that we already know has not fully been clarified. I would suggest we aim to reach a consensus on this before we proceed with this ballot. 
>  
> Christophe
>  
> From: Servercert-wg <servercert-wg-bounces at cabforum.org <mailto:servercert-wg-bounces at cabforum.org>> On Behalf Of Tom Zermeno via Servercert-wg
> Sent: Monday, June 26, 2023 11:53 PM
> To: Tom Zermeno <tom at ssl.com <mailto:tom at ssl.com>>; CA/B Forum Server Certificate WG Public Discussion List <servercert-wg at cabforum.org <mailto:servercert-wg at cabforum.org>>
> Subject: Re: [Servercert-wg] SC-59 Weak Key Guidance v.2 - Discussion Period
>  
>  
> While the ballot does not specifically address the concerns about the value of Debian checks, etc., I felt that the removal of the review should be better considered in a future ballot initiative. SSL.com <http://ssl.com/> believes that an overabundance of caution is beneficial to the community, even if it is a drain on resources. We hope that the ballot, as presented, does not represent an overwhelming burden on CAs. 
> 
> We do agree with the sentiment that most weak-key submissions have been by security researchers, but the occasional customer who is spared the potentially devastating effects of using a weak certificate makes the efforts worthwhile.  We would consider, and possibly agree, to the removal of Debian weak-key checks and the revocation requirements of 4.9.1.1 (4), but we would also likely continue to perform the assessments for the benefits of our customers and relying parties.  However, as stated, we feel that this avenue of discussion is better traveled after the strengthening of current BR requirements for the prevention of modern threats.   
>  
> Thanks,
>  
> Tom
>  
> 
> From: Servercert-wg <servercert-wg-bounces at cabforum.org <mailto:servercert-wg-bounces at cabforum.org>> On Behalf Of Tom Zermeno via Servercert-wg
> Sent: Monday, June 26, 2023 4:35 PM
> To: Infrastructure Bot via Servercert-wg <servercert-wg at cabforum.org <mailto:servercert-wg at cabforum.org>>
> Subject: [Servercert-wg] SC-59 Weak Key Guidance v.2 - Discussion Period
>  
> My apologies to the community for not properly submitting the updated version (v2) of the SC-59 Weak Key Guidance ballot for discussion.  Please disregard the previous call to vote and allow a 7-day period to discuss the changes made to the ballot. 
> 
> Notes:
> 
> Thank you to the participants who voiced opinions and concerns about the previous version of the ballot.  While there were many concerns about the inclusion of the Debian weak keys checks, we have decided to leave the checks in the ballot.  Our reasoning is that we wanted to strengthen the guidance statements, to help CAs ensure compliant certificate generation.  Future reviews of the BRs may cull the requirements, as is required by the needs of the community. 
> We believe that the requested date of November 15, 2023, will allow enough time for Certificate Authorities to enact any changes to their systems to ensure that they perform the weak key checks on all CSRs submitted for TLS certificates. 
> The changes introduced in SC-59 do not conflict with any of the recent ballots. As observed with other ballots in the past, minor administrative updates must be made to the proposed ballot text before publication such that the appropriate Version # and Change History are accurately represented (e.g., to indicate these changes will be represented in Version 2.0.1).  
> The following motion has been proposed by Thomas Zermeno of SSL.com <http://ssl.com/> and has been endorsed by Martijn Katerbarg of Sectigo and Ben Wilson of Mozilla. 
> 
> - Motion Begins -  
> 
> This ballot modifies the “Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates” (“Baseline Requirements”), based on Version 2.0.0. 
> 
> MODIFY the Baseline Requirements as specified in the following Redline: https://github.com/cabforum/servercert/compare/a0360b61e73476959220dc328e3b68d0224fa0b3...SSLcom:servercert:958e6ccac857b826fead6e4bd06d58f4fdd7fa7a  
> 
> - Motion Ends - 
> 
> The procedure for approval of this ballot is as follows:
> 
> Discussion (7 days) 
> 
> • Start time: 2023-06-26 22:00:00 UTC 
> 
> • End time: 2023-07-03 21:59:59 UTC 
> 
> Vote for approval (7 days) 
> 
>   •  Start Time:  TBD
> 
>   •  End Time:   TBD 
> 
>  
> _______________________________________________
> Servercert-wg mailing list
> Servercert-wg at cabforum.org <mailto:Servercert-wg at cabforum.org>
> https://lists.cabforum.org/mailman/listinfo/servercert-wg

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