[Servercert-wg] SCXX Ballot - Debian Weak Keys (and related vulnerabilities)
Chris Kemmerer
chris at ssl.com
Tue Jul 26 18:04:16 UTC 2022
Martijn and all,
I agree with you that anything helping CAs comply with requirements
should be made available, and am glad the tools we've been discussing
are already available on the CABF site.
However, the sense of the discussion last Thursday was that the proposal
to refer readers to specific resources in the text of the BRs opens
several questions and potential issues (particularly vetting and
maintenance of links, IIRC) which are best addressed by simply removing
the references from the BRs entirely.
(Note that https://cabforum.org/resources/tools/ includes many items
which the community uses on a daily basis [e.g. crt.sh] but which the
BRs do not specify as tools fit for a given purpose, so this would seem
to be the precedent to follow.)
That said, a more general reference somewhere in the BRs to the /tools
page would seem to be a Good Thing, but probably not in scope for this
ballot.
Chris K
On 7/26/2022 3:24 AM, Martijn Katerbarg wrote:
>
> Chris, All,
>
> I was reading through the minutes of the last meeting to see why the
> references were removed since I was unable to attend.
>
> While I do understand the reasoning, I would recommend adding a
> reference in the language, pointing to the correct section of the
> website that is actually listing the tools.
>
> It looks like we’re already planning to make it more clear on the
> website that these tools belong to this requirement. However, I expect
> most CA’s and other parties wanting to comply with BR requirement to
> read and investigate the BRs, not the Tools page on the CA/B website.
>
> Therefore I’d like to suggest adding the following sentence before the
> Motion Ends line in your proposal:“A non-exhausting list of tools and
> resources capable of assisting to comply with these requirements can
> be found at https://cabforum.org/resources/tools/”
>
> Thanks,
>
> Martijn
>
> *From:*Servercert-wg <servercert-wg-bounces at cabforum.org> *On Behalf
> Of *Chris Kemmerer via Servercert-wg
> *Sent:* Monday, 25 July 2022 18:19
> *To:* Tim Hollebeek <tim.hollebeek at digicert.com>; Aaron Gable
> <aaron at letsencrypt.org>; CA/B Forum Server Certificate WG Public
> Discussion List <servercert-wg at cabforum.org>
> *Cc:* Hanno Böck <hanno at hboeck.de>
> *Subject:* Re: [Servercert-wg] SCXX Ballot - Debian Weak Keys (and
> related vulnerabilities)
>
> 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.
>
> Based on discussion in the SCWG call of July 21 2022, we are 1)
> removing the language directing readers to external "suggested tools"
> and 2) seeking endorsers.
>
> Many thanks to all for the useful input.
>
> Chris K
>
> =====
>
> --- Motion Begins ---
>
> This ballot is intended to clarify CA responsibilities regarding weak
> key vulnerabilities (including specific guidance for Debian weak key,
> ROCA and Fermat attack vulnerabilities) and modifies the “Baseline
> Requirements for the Issuance and Management of Publicly-Trusted
> Certificates” as follows, based on Version 1.8.4:
>
> *Proposed ballot language:*
>
> 4.9.1.1 Reasons for Revoking a Subscriber Certificate
>
> *Replace:*
>
> 4. The CA is made aware of a demonstrated or proven method that can
> easily compute the Subscriber’s Private Key based on the Public Key in
> the Certificate (such as a Debian weak key, see
> https://wiki.debian.org/SSLkeys
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.debian.org%2FSSLkeys&data=05%7C01%7Cmartijn.katerbarg%40sectigo.com%7C70d815a3cc924bf1521f08da6e596262%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637943629075534002%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=2hjyo2PcEKLZFcAcCW%2FmQ7llWWXCNPhYISm2uF3zEIE%3D&reserved=0>)
>
> *With:*
>
> 4. The CA is made aware of a demonstrated or proven method that can
> easily compute the Subscriber’s Private Key (such as those identified
> in 6.1.1.3(4)).
>
> ---
>
> 6.1.1.3. Subscriber Key Pair Generation
>
> *Replace:*
>
> The CA SHALL reject a certificate request if one or more of the
> following conditions are met:
>
> 1. The Key Pair does not meet the requirements set forth in Section
> 6.1.5 and/or Section 6.1.6;
>
> 2. There is clear evidence that the specific method used to generate
> the Private Key was flawed;
>
> 3. The CA is aware of a demonstrated or proven method that exposes the
> Applicant's Private Key to compromise;
>
> 4. The CA has previously been made aware that the Applicant's Private
> Key has suffered a Key Compromise, such as through the provisions of
> Section 4.9.1.1;
>
> 5. The CA is aware of a demonstrated or proven method to easily
> compute the Applicant's Private Key based on the Public Key (such as a
> Debian weak key, see https://wiki.debian.org/SSLkeys
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.debian.org%2FSSLkeys&data=05%7C01%7Cmartijn.katerbarg%40sectigo.com%7C70d815a3cc924bf1521f08da6e596262%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637943629075534002%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=2hjyo2PcEKLZFcAcCW%2FmQ7llWWXCNPhYISm2uF3zEIE%3D&reserved=0>).
>
> *With:*
>
> The CA SHALL reject a certificate request if one or more of the
> following occurs:
>
> 1) The requested Public Key does not meet the requirements set forth
> in Sections 6.1.5 and/or 6.1.6;
>
> 2) The CA is aware of a demonstrated or proven method that exposes the
> Subscriber's Private Key to compromise;
>
> 3) The CA has previously been made aware that the Subscriber's Private
> Key has suffered a Key Compromise, such as through the provisions of
> Section 4.9.1.1;
>
> 4) The Public Key corresponds to an industry demonstrated weak Private
> Key, in particular:
>
> a) In the case of ROCA vulnerability, the CA SHALL reject keys
> identified by the tools available at
> https://github.com/crocs-muni/roca
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcrocs-muni%2Froca&data=05%7C01%7Cmartijn.katerbarg%40sectigo.com%7C70d815a3cc924bf1521f08da6e596262%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637943629075534002%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=W1Pxb77B2WKbKkM92SO5382czGJ8ou04JKiQ0LEGaz0%3D&reserved=0>
> or equivalent.
>
> b) In the case of Debian weak keys (https://wiki.debian.org/SSLkeys
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.debian.org%2FSSLkeys&data=05%7C01%7Cmartijn.katerbarg%40sectigo.com%7C70d815a3cc924bf1521f08da6e596262%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637943629075534002%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=2hjyo2PcEKLZFcAcCW%2FmQ7llWWXCNPhYISm2uF3zEIE%3D&reserved=0>),
> the CA SHALL reject at least keys generated by the flawed OpenSSL
> version with the combination of the following parameters:
>
> i) Big-endian 32-bit, little-endian 32-bit, and little-endian 64-bit
> architecture;
>
> ii) Process ID of 0 to 32767, inclusive;
>
> iii) All RSA Public Key lengths supported by the CA up to and
> including 4096 bits;
>
> iv) rnd, nornd, and noreadrnd OpenSSL random file state.
>
> c) In the case of Close Primes vulnerability, the CA SHALL reject weak
> keys identified within 100 rounds using Fermat’s factorization method
>
> For Debian weak keys not covered above, the CA SHALL take actions to
> minimize the probability of certificate issuance.
>
> CAs MUST check for Debian weak keys for all RSA modulus lengths and
> exponents that they accept.
>
> --- Motion Ends ---
>
>
> =====
>
> On 7/13/2022 3:51 PM, Tim Hollebeek wrote:
>
> I agree with the strategy of stating the requirements and then
> using requirements-free language to reference the ancillary
> resources, but a lowercased 2119 word is still a 2119 word (“These
> words are *often* capitalized” – RFC 2119, emphasis mine).
>
> It’s best to rephrase non-requirements to avoid MUST, SHALL,
> SHOULD, and MAY entirely. As well as required, recommended, and
> optional 😊
>
> Something like: “CAs might find these tools useful”, or even
> something like: “Additional information is available from these
> resources.”
>
> Referencing something does not in any way imply it is free from
> errors or even that it can be used in a BR-compliant way. I give
> you the BR reference to the original RFC 6844 as an example. The
> original RFC 6844 had multiple errors and was rather incompatible
> with the BRs, but got added to the BRs anyway. Oops.
>
> We should make sure the resources we reference are high enough
> quality to be useful, but I think the standard ballot / discussion
> process can handle that.
>
> -Tim
>
> *From:* Servercert-wg <servercert-wg-bounces at cabforum.org>
> <mailto:servercert-wg-bounces at cabforum.org> *On Behalf Of *Aaron
> Gable via Servercert-wg
> *Sent:* Friday, July 8, 2022 12:44 PM
> *To:* Chris Kemmerer <chris at ssl.com> <mailto:chris at ssl.com>; CA/B
> Forum Server Certificate WG Public Discussion List
> <servercert-wg at cabforum.org> <mailto:servercert-wg at cabforum.org>
> *Cc:* Hanno Böck <hanno at hboeck.de> <mailto:hanno at hboeck.de>
> *Subject:* Re: [Servercert-wg] SCXX Ballot - Debian Weak Keys (and
> related vulnerabilities)
>
> It seems to me like the appropriate line to walk would be:
>
> First, state the requirements (such as blocking debian weak keys,
> or blocking ROCA keys) in plain language, much as the current
> ballot does. This makes the requirement that CAs must abide by clear.
>
> Second, provide links to tools that may be helpful. Do not preface
> these links with any normative language, i.e. say "CAs may find
> these tools useful: ...", not "CAs MAY use these tools: ...". This
> serves the purpose of providing easy access to the helpful
> external resources, but without stating that their contents have
> been vetted and fully approved.
>
> Does that makes sense?
>
> Aaron
>
> On Fri, Jul 1, 2022 at 12:13 PM Chris Kemmerer via Servercert-wg
> <servercert-wg at cabforum.org> wrote:
>
> *INTRO*
>
> Thanks to all who participated in the very useful discussion
> regarding this proposed ballot in our June 23 2022 call.
>
> An important point was raised about how to handle external
> links to recommended (but not required) resources. In "Section
> 6.1.1.3. Subscriber Key Pair Generation" of the proposed
> language, we require CAs to reject requests for certificates
> with "industry demonstrated weak Private Keys" (as "SHALL" and
> "MUST" directives), then provide links to "Suggested tools
> that CAs MAY use" to judge requests.
>
> *THE QUESTIONS*
>
> The questions here are:
>
> 1. *If we direct issuers to external resources in CABF
> documents, what level of CABF-level vetting should be
> required or expected for those links?*
> 2. And*is the ballot process itself sufficient vetting for
> such links?*
>
> *OUR ASSUMPTION AND EXISTING LINKS*
>
> We are assuming that for, weak key detection, we DO want to
> provide useful links to help guide certificate issuers (see
> sidebar below). Note that the current BR language already
> includes one such link, to a page maintained by Debian
> (https://wiki.debian.org/SSLkeys
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.debian.org%2FSSLkeys&data=05%7C01%7Cmartijn.katerbarg%40sectigo.com%7C70d815a3cc924bf1521f08da6e596262%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637943629075534002%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=2hjyo2PcEKLZFcAcCW%2FmQ7llWWXCNPhYISm2uF3zEIE%3D&reserved=0>),
> though with a vetted status unknown to us.
>
> Our proposed ballot language also adds a requirement to reject
> keys "identified by the tools available at
> https://github.com/crocs-muni/roca
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcrocs-muni%2Froca&data=05%7C01%7Cmartijn.katerbarg%40sectigo.com%7C70d815a3cc924bf1521f08da6e596262%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637943629075690223%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=MrPVgvf4CvjHpdhGnh%2BcP7P%2BUxkJ%2B20RQPoabQm4dw8%3D&reserved=0>
> or equivalent". As we recall it, this resource was suggested
> by a CABF participant now departed, and again the status of
> vetting for this link is unknown.
>
> For what it's worth, a quick scan of the BRs shows that, apart
> from weak key guidance, we do include links to other external
> resources which are presumably foundational enough to not
> require vetting. These include:
>
> 1. IETF (various RFCs, ex. http://tools.ietf.org/html/rfc5890
> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc5890&data=05%7C01%7Cmartijn.katerbarg%40sectigo.com%7C70d815a3cc924bf1521f08da6e596262%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637943629075690223%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Lbo28F8%2Fx2d306fLSud0u3LiWuVGOphIK6zeo6Ftel0%3D&reserved=0>)
> 2. IANA (registry information, ex.
> https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iana.org%2Fassignments%2Fiana-ipv4-special-registry%2Fiana-ipv4-special-registry.xhtml&data=05%7C01%7Cmartijn.katerbarg%40sectigo.com%7C70d815a3cc924bf1521f08da6e596262%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637943629075690223%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Hz3bMVZMFmBQesBrtTXYnSjnndcY8Mc8xgujEgOr81c%3D&reserved=0>)
> 3. NIST (publications, ex.
> http://csrc.nist.gov/publications/nistpubs/800-89/SP-800-89_November2006.pdf
> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcsrc.nist.gov%2Fpublications%2Fnistpubs%2F800-89%2FSP-800-89_November2006.pdf&data=05%7C01%7Cmartijn.katerbarg%40sectigo.com%7C70d815a3cc924bf1521f08da6e596262%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637943629075690223%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=zpIHS6JVHP8wgHQ%2FlwbgWODg8fKH6EFNT2HpMendpyA%3D&reserved=0>)
> 4. and the Mozilla Foundation (the Public Suffix List,
> https://publicsuffix.org/
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpublicsuffix.org%2F&data=05%7C01%7Cmartijn.katerbarg%40sectigo.com%7C70d815a3cc924bf1521f08da6e596262%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637943629075690223%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Rue2szur3TchDXxc8WW5nnxkf3TCUeffsXVzooucBac%3D&reserved=0>).
>
> *"CROSS-VETTING" OF PROPOSED RESOURCES*
>
> As Dimitris stated in the call, the two other links included
> as resources which MAY be utilized:
>
> 1. https://github.com/CVE-2008-0166
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FCVE-2008-0166&data=05%7C01%7Cmartijn.katerbarg%40sectigo.com%7C70d815a3cc924bf1521f08da6e596262%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637943629075690223%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=bYbObWp1PySlrvcwGeFfqIKnZRarfMJKiE83abTe8yg%3D&reserved=0>
> 2. https://github.com/HARICA-official/debian-weak-keys
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FHARICA-official%2Fdebian-weak-keys&data=05%7C01%7Cmartijn.katerbarg%40sectigo.com%7C70d815a3cc924bf1521f08da6e596262%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637943629075690223%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=zao1ch6I8qObN46RWPrSG9yySNsfMvSSjJ00MLSfh50%3D&reserved=0>
>
> ... have been "cross-vetted" by their respective providers
> (HARICA and Sectigo).
>
> This discussion was spurred by a suggestion from Adriano
> Santoni to consider adding a third resource (Hanno Böck's
> badkeys tool):
>
> 1. https://github.com/badkeys/badkeys
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fbadkeys%2Fbadkeys&data=05%7C01%7Cmartijn.katerbarg%40sectigo.com%7C70d815a3cc924bf1521f08da6e596262%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637943629075690223%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=m4eFeqTReq6FPJN%2BeOai2uSa8WlPyHOBxftn9Nvw5%2BU%3D&reserved=0>
> (web version: https://badkeys.info/
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbadkeys.info%2F&data=05%7C01%7Cmartijn.katerbarg%40sectigo.com%7C70d815a3cc924bf1521f08da6e596262%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637943629075690223%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=sONo3h0BzG79pbUMdTFEBXYpUUoeie%2BBIuG7P2HiYe4%3D&reserved=0>)
>
> ...for which no such CABF-level "cross-vetting" has been
> performed (as far as we know).
>
> We ourselves very much appreciate the effort that went into
> creating these tools and intend to utilize them. However:
>
> *TO RESTATE THE QUESTIONS*
>
> 1. *Is the ballot process itself considered adequate vetting
> for external links in CABF documents?*
> 2. If not, *what vetting would we consider adequate?*
>
> *SIDEBAR: OTHER OPTIONS*
>
> 1. In the June 23 call, an external, CABF-supported resource
> (i.e. a separate web page with appropriate links) was
> considered, discussed, and rejected as likely to increase
> overhead and decrease reliability. Based on this, our
> sense is that *any links deemed useful should indeed be
> included in the actual ballot language itself*.
> 2. And finally, as raised in previous discussions: *Would
> some sort of disclaimer be appropriate for external
> links*, and if so should it extend beyond the 6.1.1.3
> links to cover external resources more generally?
>
> *CLOSING REMARKS*
>
> Thanks.
>
> ------------------------------------------------------------------------
>
> *From:*Servercert-wg <servercert-wg-bounces at cabforum.org> on
> behalf of Adriano Santoni via Servercert-wg
> <servercert-wg at cabforum.org>
> *Sent:* Sunday, June 12, 2022 7:11 PM
> *To:* servercert-wg at cabforum.org <servercert-wg at cabforum.org>
> *Cc:* Hanno Böck <hanno at hboeck.de>
> *Subject:* Re: [Servercert-wg] SCXX Ballot - Debian Weak Keys
> (and related vulnerabilities)
>
> Might a third option be the tool developed by Hanno Boeck?
>
> https://github.com/badkeys/badkeys
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fbadkeys%2Fbadkeys&data=05%7C01%7Cmartijn.katerbarg%40sectigo.com%7C70d815a3cc924bf1521f08da6e596262%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637943629075690223%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=m4eFeqTReq6FPJN%2BeOai2uSa8WlPyHOBxftn9Nvw5%2BU%3D&reserved=0>
>
> From our point of view it's an effective tool.
>
> Adriano
>
> Il 09/06/2022 15:18, Chris Kemmerer via Servercert-wg ha scritto:
>
> Suggested tools that CAs MAY use to obtain lists of Debian
> weak keys include:
>
> - https://github.com/CVE-2008-0166
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FCVE-2008-0166&data=05%7C01%7Cmartijn.katerbarg%40sectigo.com%7C70d815a3cc924bf1521f08da6e596262%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637943629075690223%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=bYbObWp1PySlrvcwGeFfqIKnZRarfMJKiE83abTe8yg%3D&reserved=0>
> provides a generator, for the complete set of parameters
> listed above, that runs on any modern 64-bit Linux system;
> it also provides complete sets of pregenerated keys for
> the most common RSA key sizes.
>
> - https://github.com/HARICA-official/debian-weak-keys
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FHARICA-official%2Fdebian-weak-keys&data=05%7C01%7Cmartijn.katerbarg%40sectigo.com%7C70d815a3cc924bf1521f08da6e596262%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637943629075690223%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=zao1ch6I8qObN46RWPrSG9yySNsfMvSSjJ00MLSfh50%3D&reserved=0>
> provides a generator, for a subset of the parameters
> listed above, that can take advantage of a computer cluster.
>
> _______________________________________________
> Servercert-wg mailing list
> Servercert-wg at cabforum.org
> https://lists.cabforum.org/mailman/listinfo/servercert-wg
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.cabforum.org%2Fmailman%2Flistinfo%2Fservercert-wg&data=05%7C01%7Cmartijn.katerbarg%40sectigo.com%7C70d815a3cc924bf1521f08da6e596262%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637943629075690223%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=EB6%2FDIQzZhpDbJobRVn2dHqskn7r5yIKfZmoMoS%2BKfc%3D&reserved=0>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20220726/7a83461e/attachment-0001.html>
More information about the Servercert-wg
mailing list