[Servercert-wg] Redline for SC-59: Weak keys ballot

Rob Stradling rob at sectigo.com
Fri Mar 17 09:56:53 UTC 2023


In July 2022 we learnt [1] that, contrary to popular belief, OpenSSL on Debian circa 2008 was capable of producing vulnerable ECC keys.  Let's Encrypt posted a detailed incident report related to this topic, which is well worth a read.

The draft ballot text currently refers only to RSA keys.  Have the ballot authors considered adding text to address weak Debian ECC keys?


[1] https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/PU2ctmlXUc8/m/_63bBHWfAAAJ

[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1789521

________________________________
From: Servercert-wg <servercert-wg-bounces at cabforum.org> on behalf of Inigo Barreira via Servercert-wg <servercert-wg at cabforum.org>
Sent: 16 March 2023 16:11
To: CA/B Forum Server Certificate WG Public Discussion List <servercert-wg at cabforum.org>
Subject: [Servercert-wg] RV: Redline for SC-59: Weak keys ballot


CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.


Forwarding it to the Sever Certificate WG



De: Smcwg-public <smcwg-public-bounces at cabforum.org> En nombre de Chris Kemmerer via Smcwg-public
Enviado el: jueves, 16 de marzo de 2023 15:46
Para: smcwg-public at cabforum.org
Asunto: [Smcwg-public] Redline for SC-59: Weak keys ballot



CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.



Hello,



A diff for our proposed changes may be found here: https://github.com/cabforum/servercert/compare/2c63814...9ecc201?diff=split<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcabforum%2Fservercert%2Fcompare%2F2c63814...9ecc201%3Fdiff%3Dsplit&data=05%7C01%7Crob%40sectigo.com%7C08fdbbb65b4d49533cd808db26391b8b%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638146414795300553%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=EoNGCR1Ntt2v5L%2BQ6eo2MI3Mt1Q0r61kLql%2Fe4yu%2Fws%3D&reserved=0>

This compares the current BR branch (2c63814) with our latest updates. Ben Wilson and Martijn Katerbarg have offered extremely useful suggestions, some of which we have accommodated and others we offer for discussion. Specifically, in 6.1.1.3:

  *   Our version removes the provision "2. There is clear evidence that the specific method used to generate the Private Key was flawed" as we believe that this case is essentially the same as the next one (i.e. "clear evidence" of a flawed method must lead to awareness of the "demonstrated or proven method")
  *   The four items 4 (b) (i though iv) are inclusive (i.e all parameters combined) and are now joined by an "and"
  *   As this ballot covers various weak key issues, "Debian" has been removed where not specifically required
  *   The directive that "CAs MUST check for Debian weak keys for all RSA modulus lengths and exponents that they accept" was added via discussion in our SCWG calls and in our view reinforces and extends the provision in 4(b). It should be decided if there will be a cutoff point or not. If a CA wants to support 16384-bit RSA keys, do they have to generate first all Debian weak keys of that size or could it be assumed that such Debian weak keys are not expected to have been generated before?
  *   We had included links to specific tools but now see that these (and more!) may be found at https://cabforum.org/resources/tools/<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcabforum.org%2Fresources%2Ftools%2F&data=05%7C01%7Crob%40sectigo.com%7C08fdbbb65b4d49533cd808db26391b8b%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638146414795300553%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Tvn5lvXOCek6%2BlA3AIFp6%2BQdSJN5aXOxmMmi89%2BA99A%3D&reserved=0> under "Check for Bad Private Keys". We have edited the section to direct to this resource.

Regards,

Chris K








-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20230317/b747a365/attachment.html>


More information about the Servercert-wg mailing list