[Servercert-wg] SCXX Ballot proposal: Debian Weak keys

Tue Sep 14 16:14:23 UTC 2021

Is there a missing "and" in the following list?  Can this language be
clarified?

6.1.1.4 Subscriber Key Pair Parameters

The CA SHALL reject keys (per 6.1.1.3(b)) if the following parameters apply:

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;

iv) rnd, nornd, and noreadrnd OpenSSL random file state.

On Thu, Sep 2, 2021 at 2:53 PM Chris Kemmerer via Servercert-wg <
servercert-wg at cabforum.org> wrote:

> Thanks for the endorsement and suggested changes, Rob. The updated
> language below incorporates these, thus adding a Section 6.1.1.4 and moving
> the key parameters therein.
>
> We welcome input from the community and are seeking a second endorser.
>
> Chris K
>
> =====
>
> SCXX Ballot proposal: Debian Weak keys
>
> NOTE: Edited per latest (20210824) RS suggestion, see new section 6.1.1.4.
>
> -----
>
> --- Motion Begins ---
>
> This ballot modifies the “Baseline Requirements for the Issuance and
> Management of Publicly-Trusted Certificates” as follows, based on Version
> 1.7.9:
>
> *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)
>
> *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).
>
> *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 or
> equivalent.
>
> b) In the case of Debian weak keys (https://wiki.debian.org/SSLkeys), the
> CA SHALL reject keys generated by the flawed OpenSSL version with the
> combination of the parameters described in 6.1.1.4.
>
> *ADD:*
>
> 6.1.1.4 Subscriber Key Pair Parameters
>
> The CA SHALL reject keys (per 6.1.1.3(b)) if the following parameters
> apply:
>
> 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;
>
> iv) rnd, nornd, and noreadrnd OpenSSL random file state.
>
> These are some suggested tools that CAs MAY use to obtain lists of Debian
> weak keys:
>
>   - https://github.com/CVE-2008-0166 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 provides a
> generator, for a subset of the parameters listed above, that can take
> advantage of a computer cluster.
>
> --- Motion Ends ---
>
>
> ------------------------------
> *From:* Rob Stradling <rob at sectigo.com>
> *Sent:* Tuesday, August 24, 2021 4:01 PM
> *To:* Chris Kemmerer <chris at ssl.com>; Dimitris Zacharopoulos (HARICA) <
> dzacharo at harica.gr>; CA/B Forum Server Certificate WG Public Discussion
> List <servercert-wg at cabforum.org>; Jacob Hoffman-Andrews <
> jsha at letsencrypt.org>
> *Subject:* Re: [Servercert-wg] SCXX Ballot proposal: Debian Weak keys
>
> Hi Christopher.
>
> > We would still like to determine the best way to direct CAs to the weak
> key populations assembled through the work of yourself and HARICA.
>
> Here's my suggestion...
>
> Change...
> *"b) In the case of Debian weak keys (https://wiki.debian.org/SSLkeys
> <https://wiki.debian.org/SSLkeys>), the CA SHALL reject at least keys
> generated by the flawed OpenSSL version with the combination of the
> following parameters:"*
> ...to...
> *"b) In the case of Debian weak keys (https://wiki.debian.org/SSLkeys
> <https://wiki.debian.org/SSLkeys>), the CA SHALL reject at least keys
> generated by the flawed OpenSSL version with the combination of the
> parameters listed in section 6.1.1.4."*
>
> Move the list of parameters (*"i) Big-endian 32-bit...random file state"*)
> into a new section 6.1.1.4, entitled *"Debian weak keys (CVE-2008-0166)"*.
>
> At the end of the new section 6.1.1.4, add this text...
> *"These are some suggested tools that CAs MAY use to obtain lists of
> Debian weak keys:*
> *  - https://github.com/CVE-2008-0166
> <https://github.com/CVE-2008-0166> 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://github.com/HARICA-official/debian-weak-keys> provides a generator,
> for a subset of the parameters listed above, that can take advantage of a
> computer cluster."*
>
> > We believe this proposal offers clearer guidance on this matter than the
> current BR language, and is an opportunity to make an ecosystem-wide
> improvement in CA practices.
>
> I agree.  I'd be happy to endorse.
>
> > (NOTE: Edited per RS suggestion, updated version number to 1.7.9, but
> still currently directs to debian.org resource)
>
> I think it's still valuable to mention https://wiki.debian.org/SSLkeys.
>
> ------------------------------
> *From:* Christopher Kemmerer <chris at ssl.com>
> *Sent:* 18 August 2021 22:37
> *To:* Rob Stradling <rob at sectigo.com>; Dimitris Zacharopoulos (HARICA) <
> dzacharo at harica.gr>; CA/B Forum Server Certificate WG Public Discussion
> List <servercert-wg at cabforum.org>; Jacob Hoffman-Andrews <
> jsha at letsencrypt.org>
> *Subject:* Re: [Servercert-wg] SCXX Ballot proposal: Debian Weak keys
>
>
> 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 Rob,
>
> Thanks for the useful suggestion. We've amended our proposed ballot
> language accordingly.
>
> We would still like to determine the best way to direct CAs to the weak
> key populations assembled through the work of yourself and HARICA.
>
> On the broader question of how to proceed, we see three options for
> community consideration:
>
> - Carry forward with this proposed ballot;
> - Consider adding this language to a future cleanup ballot; or
> - Declaring that current language and guidance are sufficient.
>
> To recap, the ur-issue is itself from 2006-2008, our initial request for
> input on this matter was made in April 2020 and this ballot language has
> been under (sporadic) discussion since December 2020. Given the narrow
> focus of the issue itself, this could certainly be considered a low
> priority, and thus wrapped into a future cleanup ballot (rather than
> undergoing a separate ballot procedure).
>
> However, we note that the impetus for this ballot discussion was failure
> of a publicly-trusted CA to prevent issuance of a certificate using a
> Debian weak key in March 2020. We aim to ensure this doesn't happen again
> by clear delineation of expected practices (and direction to appropriate
> resources) in our Baseline Requirements.
>
> We believe this proposal offers clearer guidance on this matter than the
> current BR language, and is an opportunity to make an ecosystem-wide
> improvement in CA practices.
>
> We hope to discuss this in our regular call and very much welcome
> community input.
>
> Regards,
>
> Chris K
>
> =====
>
> SCXX Ballot proposal: Debian Weak keys
>
> (NOTE: Edited per RS suggestion, updated version number to 1.7.9, but
> still currently directs to debian.org resource)
>
> =====
>
> --- Motion Begins ---
>
> This ballot modifies the “Baseline Requirements for the Issuance and
> Management of Publicly-Trusted Certificates” as follows, based on Version
> 1.7.9:
>
> 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=04%7C01%7Crob%40sectigo.com%7Ca505320417514683604108d962906fbc%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637649196427569064%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=m74Sjypff4KqXQuZUrdozdOB8N9TmwCh%2F%2BzJpjUwl9w%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=04%7C01%7Crob%40sectigo.com%7Ca505320417514683604108d962906fbc%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637649196427569064%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=m74Sjypff4KqXQuZUrdozdOB8N9TmwCh%2F%2BzJpjUwl9w%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=04%7C01%7Crob%40sectigo.com%7Ca505320417514683604108d962906fbc%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637649196427579016%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=AEwR7%2BOcyMNbJ5kqWebySDmtRO2PqoIFELJc4BD7ESA%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=04%7C01%7Crob%40sectigo.com%7Ca505320417514683604108d962906fbc%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637649196427579016%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=WPJ6yy8T0U3kPKwISrWNjJDP5rIgwcVr6ZsSXAQEYsk%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;
>
> iv) rnd, nornd, and noreadrnd OpenSSL random file state.
>
> --- Motion Ends ---
>
> =====
>
> On 5/13/2021 9:42 AM, Rob Stradling wrote:
>
> > iii) All RSA Public Key lengths supported by the CA up to and including
> 4096 bits;
> > ...
> > For Debian weak keys not covered above, the CA SHALL take actions to
> minimize the probability of certificate issuance.
>
> Hi Christopher.  What sort of "actions" are envisaged here?  If a CA is
> processing a certificate request that contains a (for example) RSA-4088
> public key (i.e., a key size not covered by an available Debian weak list),
> either the CA is going to issue the cert or they're not.  What, concretely,
> does "minimize the probability of certificate issuance" actually mean?
>
> Why not remove that "SHALL" sentence and change point iii to: "iii) All
> RSA Public Key lengths supported by the CA." ?
>
> BTW, in case it helps, I'm about half way through generating a full set of
> RSA-8192 Debian weak keys, which (when complete) I'll add to the
> https://github.com/CVE-2008-0166
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FCVE-2008-0166&data=04%7C01%7Crob%40sectigo.com%7Ca505320417514683604108d962906fbc%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637649196427579016%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=4KW%2B7pMSqy83ufpoU3K3ArV76KZGerZuKn%2FDPUQzH00%3D&reserved=0>
>  repositories.
>
> ------------------------------
> *From:* Christopher Kemmerer <chris at ssl.com> <chris at ssl.com>
> *Sent:* 13 May 2021 15:12
> *To:* Rob Stradling <rob at sectigo.com> <rob at sectigo.com>; Dimitris
> Zacharopoulos (HARICA) <dzacharo at harica.gr> <dzacharo at harica.gr>; CA/B
> Forum Server Certificate WG Public Discussion List
> <servercert-wg at cabforum.org> <servercert-wg at cabforum.org>; Jacob
> Hoffman-Andrews <jsha at letsencrypt.org> <jsha at letsencrypt.org>
> *Subject:* Re: [Servercert-wg] SCXX Ballot proposal: Debian Weak keys
>
> 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,
>
> We deeply appreciate the useful discussion in this thread regarding this
> issue. We especially applaud the efforts of HARICA and Sectigo to
> independently generate more comprehensive lists of potentially affected
> Debian weak keys. As Rob Stradling observed through his crt.sh research
> (20210107,
> https://gist.github.com/robstradling/a5590b6a13218fe561dcb5d5c67932c5
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgist.github.com%2Frobstradling%2Fa5590b6a13218fe561dcb5d5c67932c5&data=04%7C01%7Crob%40sectigo.com%7Ca505320417514683604108d962906fbc%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637649196427588972%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=n08L%2Bixwwtr4CPIVRKVN4hFbUQBCY9Hn1rMxDbr4fxE%3D&reserved=0>)
> of the five most utilized algorithm/key size populations, two are ECC (so
> not impacted by the Debian weak key issue) and three are RSA (2048, 4096,
> and 3072 bit length, in that order).
>
> As of their most recent messages it appears that these two organizations
> have independently generated comprehensive lists identifying all RSA-2048
> and -4096 bit length keys. (We understand RSA-3072 length keys are also
> available.) This offers the possibility that complete lists, if accepted
> as authoritative, could be accessed by the community to help prevent
> exploitation of this vulnerability.
>
> It was also noted (by the representative from Let's Encrypt) that the
> ROCA vulnerability is presently identified through use of a tool supported
> externally. It was suggested that this resource be archived in a manner
> that ensures availability. (Our proposed language points to "
> https://github.com/crocs-muni/
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcrocs-muni%2F&data=04%7C01%7Crob%40sectigo.com%7Ca505320417514683604108d962906fbc%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637649196427588972%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=N6HcZbwZZTdkY5lknnq8deftRy5neQ%2BIISeDzJQzxNs%3D&reserved=0>
> roca or equivalent.")
>
> We think our present ballot language (reproduced at the end of this
> message) provides appropriately focused guidance to CAs. If available,
> we'd certainly like to also see the HARICA/Sectigo lists (which CAs could
> use for the majority of Debian weak key use cases) captured somewhere in
> this ballot language. We are agnostic as to 1) where exactly these
> resources might be maintained and 2) where this ballot places directions to
> these resources - an annex to the current requirements, a separate CA/BF
> guidance document or within Sections 4.9.1.1/6.1.1.3.
>
> Our intent is to ensure that 1) clear, accurate guidance on CA
> expectations is provided and 2) any resources assisting CAs in meeting
> these expectations are fully described, publicly available (somewhere) and
> with reliable links provided. The language below, we feel, meets the first
> requirement. We'd appreciate input on how to best meet the second. (Note
> that SSL.com would be happy to support the community by hosting any of
> these as publicly accessible resources, whether solo or alongside other
> organizations.)
>
> Chris K
>
> SSL.com
>
> =====
>
>
>
> --- Motion Begins ---
>
>
>
>
>
> This ballot modifies the “Baseline Requirements for the Issuance and
> Management of Publicly-Trusted Certificates” as follows, based on Version
> 1.7.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=04%7C01%7Crob%40sectigo.com%7Ca505320417514683604108d962906fbc%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637649196427588972%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=iWW%2BuEA9mcbJeC2ib%2BCqL9kX37UmbZc8vmwedxXYPVk%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=04%7C01%7Crob%40sectigo.com%7Ca505320417514683604108d962906fbc%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637649196427598936%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Ew6NrifPP7aQ%2FpipZPoaVpAbG7f86rD3GNVxH3pXtyo%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=04%7C01%7Crob%40sectigo.com%7Ca505320417514683604108d962906fbc%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637649196427598936%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=zqHEv702oWQ2YA9BB57%2F9QtaMb1FIrSqe5ErCKo83e0%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=04%7C01%7Crob%40sectigo.com%7Ca505320417514683604108d962906fbc%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637649196427608887%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Vf3oSwAp6t5ogXcgdDaIoXh7GRNnMuMye0oAB3t44vE%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.
>
>
>
> For Debian weak keys not covered above, the CA SHALL take actions to
> minimize the probability of certificate issuance.
>
>
>
> --- Motion Ends ---
> On 1/18/2021 3:34 PM, Rob Stradling wrote:
>
> > I'm mid-way through generating the RSA-4096 keys.
>
> The RSA-4096 private keys and blocklists are now in
> https://github.com/CVE-2008-0166/private_keys
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FCVE-2008-0166%2Fprivate_keys&data=04%7C01%7Crob%40sectigo.com%7Ca505320417514683604108d962906fbc%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637649196427608887%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=0znFAjKLax7sMw9zd1dVNwocZ1JRxKXOiLvAzs4vu5I%3D&reserved=0> and
> https://github.com/CVE-2008-0166/openssl_blocklists
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FCVE-2008-0166%2Fopenssl_blocklists&data=04%7C01%7Crob%40sectigo.com%7Ca505320417514683604108d962906fbc%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637649196427608887%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=NOXBe3t1dfJTyboeg%2BFKYZepK%2Fuu84FH5%2BL0P3gQelU%3D&reserved=0>
> .
>
> The RSA-2048 and RSA-4096 private keys in
> 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=04%7C01%7Crob%40sectigo.com%7Ca505320417514683604108d962906fbc%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637649196427618846%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Dhqfdr2dGsccIDXxzX8W3swXYMfkuSdEyofm8IrY6w0%3D&reserved=0> (which
> only covers 2 of the 3 word size / endianness combinations) are identical
> to the equivalents in https://github.com/CVE-2008-0166/private_keys
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FCVE-2008-0166%2Fprivate_keys&data=04%7C01%7Crob%40sectigo.com%7Ca505320417514683604108d962906fbc%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637649196427618846%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=4jGuws7jDh%2FSA0tNHNwYP6WoSL2YHeJsgmNB43el4kw%3D&reserved=0>
> .
>
> ------------------------------
> *From:* Dimitris Zacharopoulos (HARICA) <dzacharo at harica.gr>
> <dzacharo at harica.gr>
> *Sent:* 14 January 2021 18:39
> *To:* Rob Stradling <rob at sectigo.com> <rob at sectigo.com>; CA/B Forum
> Server Certificate WG Public Discussion List <servercert-wg at cabforum.org>
> <servercert-wg at cabforum.org>; Jacob Hoffman-Andrews <jsha at letsencrypt.org>
> <jsha at letsencrypt.org>; Christopher Kemmerer <chris at ssl.com>
> <chris at ssl.com>
> *Subject:* Re: [Servercert-wg] SCXX Ballot proposal: Debian Weak keys
>
> 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.
>
>
>
> On 14/1/2021 12:30 π.μ., Rob Stradling wrote:
>
> Thanks Dmitris.
>
> So far I've generated the RSA-2048 and RSA-3072 keys using
> https://github.com/CVE-2008-0166/key_generator
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FCVE-2008-0166%2Fkey_generator&data=04%7C01%7Crob%40sectigo.com%7Ca505320417514683604108d962906fbc%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637649196427618846%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=X%2FYscZuPRVGJL8QEL20esewX8EBq2XmujevGMoNyc5k%3D&reserved=0> and
> uploaded them to https://github.com/CVE-2008-0166/private_keys
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FCVE-2008-0166%2Fprivate_keys&data=04%7C01%7Crob%40sectigo.com%7Ca505320417514683604108d962906fbc%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637649196427628804%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=M9YAvqYsZBsy7ylSBD2PRWn5FD%2B5e0mAW3g09%2F%2Fi01Q%3D&reserved=0>,
> and I've generated the corresponding blocklists and uploaded them to
> https://github.com/CVE-2008-0166/openssl_blocklists
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FCVE-2008-0166%2Fopenssl_blocklists&data=04%7C01%7Crob%40sectigo.com%7Ca505320417514683604108d962906fbc%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637649196427628804%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=qs90ivAJks%2BHIgRFMo7waVR06sAfeOnVy%2Fd3uvhZwBc%3D&reserved=0>.
> My RSA-2048 blocklists exactly match the ones from the original Debian
> openssl-blacklist package.
> I'm mid-way through generating the RSA-4096 keys.
>
> Let's compare keys when we're both done.  🙂
>
>
> Certainly :-) the RSA-2048 keys already match the fingerprints from the
> openssl-blacklist Debian package.
>
> We did this work several months ago but never found the time to make it
> publicly available. We managed to break down the big task and run jobs in
> parallel which made things a bit more interesting.
>
> It's nice we did this independently, I guess it increases the accuracy
> level of the resulted keys :)
>
>
> Cheers,
> Dimitris.
>
>
> ------------------------------
> *From:* Dimitris Zacharopoulos (HARICA) <dzacharo at harica.gr>
> <dzacharo at harica.gr>
> *Sent:* 13 January 2021 21:49
> *To:* Rob Stradling <rob at sectigo.com> <rob at sectigo.com>; CA/B Forum
> Server Certificate WG Public Discussion List <servercert-wg at cabforum.org>
> <servercert-wg at cabforum.org>; Jacob Hoffman-Andrews <jsha at letsencrypt.org>
> <jsha at letsencrypt.org>; Christopher Kemmerer <chris at ssl.com>
> <chris at ssl.com>
> *Subject:* Re: [Servercert-wg] SCXX Ballot proposal: Debian Weak keys
>
> 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.
>
> Dear friends,
>
> HARICA has generated the weak keys (RSA 2048 and 4096 bit lengths) from
> the vulnerable openssl package. We will generate 3072 bit keys as well and
> add them soon. The methodology is described in the following GitHub repo
> along with the produced keys:
>
>    - 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=04%7C01%7Crob%40sectigo.com%7Ca505320417514683604108d962906fbc%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637649196427638763%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=2LMewzOLNRKgtOoPARP4WDsHJBpwKiVlu8xYOWO4TtI%3D&reserved=0>
>
> Please review and let us know if you spot any issues or problems with our
> approach and methodology.
>
> As always, please use other people's work at your own risk.
>
>
> Dimitris.
>
> On 7/1/2021 2:25 μ.μ., Rob Stradling via Servercert-wg wrote:
>
> I've used crt.sh to produce a survey of key algorithms/sizes in currently
> unexpired, publicly-trusted server certificates:
>
> https://gist.github.com/robstradling/a5590b6a13218fe561dcb5d5c67932c5
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgist.github.com%2Frobstradling%2Fa5590b6a13218fe561dcb5d5c67932c5&data=04%7C01%7Crob%40sectigo.com%7Ca505320417514683604108d962906fbc%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637649196427638763%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=zyp7rN9Ter7PZFrcoOOJpiD%2FXK4i5ywH76X%2BC5d4Yeo%3D&reserved=0>
>
> The four most popular choices are no surprise: RSA-2048, P-256, RSA-4096,
> and P-384.  openssl-blacklist covers RSA-2048 and RSA-4096, and ECC keys
> are implicitly not Debian weak keys.
>
> Fifth most popular is RSA-3072, with over 3 million unexpired,
> publicly-trusted server certs.  openssl-blacklist doesn't cover RSA-3072,
> but ISTM that this is a key size that CAs will want to permit.
>
> Some of the lesser used key sizes are mostly likely due to Subscriber
> typos (e.g., 2408 and 3048 were probably intended to be 2048, 4048 was
> probably intended to be either 2048 or 4096, etc), but some of the other
> ones look like they were deliberately chosen (e.g., 2432 is 2048+384).  Is
> it worth generating Debian weak keys/blocklists for any of these key sizes?
>
>
> https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fnvlpubs.nist.gov%2Fnistpubs%2FSpecialPublications%2FNIST.SP.800-57pt1r5.pdf&data=04%7C01%7Crob%40sectigo.com%7Ca505320417514683604108d962906fbc%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637649196427638763%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3liYc3twFgYbd%2F6JAQ96%2FDoNMMKUFsPlkMznegF77GM%3D&reserved=0> (Table
> 4, p59) permits RSA-2048 until the end of 2030, whereas
> https://www.sogis.eu/documents/cc/crypto/SOGIS-Agreed-Cryptographic-Mechanisms-1.2.pdf
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.sogis.eu%2Fdocuments%2Fcc%2Fcrypto%2FSOGIS-Agreed-Cryptographic-Mechanisms-1.2.pdf&data=04%7C01%7Crob%40sectigo.com%7Ca505320417514683604108d962906fbc%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637649196427648716%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=t8p%2BoIE1SPC8qw1mnFrEeO%2BWHYB%2FVOA3lkU1sef%2ByWU%3D&reserved=0> permits
> RSA-2048 only until the end of 2025.  It is of course possible that quantum
> computing will render RSA obsolete before Subscribers need to think about
> which larger RSA keysize they want to migrate to; however, it seems prudent
> to also plan for the possibility that RSA will survive and that some other
> RSA keysize(s) might become popular.
>
> ------------------------------
> *From:* Servercert-wg <servercert-wg-bounces at cabforum.org>
> <servercert-wg-bounces at cabforum.org> on behalf of Rob Stradling via
> Servercert-wg <servercert-wg at cabforum.org> <servercert-wg at cabforum.org>
> *Sent:* 06 January 2021 16:08
> *To:* Jacob Hoffman-Andrews <jsha at letsencrypt.org> <jsha at letsencrypt.org>;
> Christopher Kemmerer <chris at ssl.com> <chris at ssl.com>; CA/B Forum Server
> Certificate WG Public Discussion List <servercert-wg at cabforum.org>
> <servercert-wg at cabforum.org>
> *Subject:* Re: [Servercert-wg] SCXX Ballot proposal: Debian Weak keys
>
> 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.
>
> Jacob wrote:
> > Lastly, I think we should archive openssl-blacklist, and include in the
> BRs: "A CA may reject the full set of Debian weak keys by rejecting this
> superset of the Debian weak keys:
> >
> > - All RSA public keys with modulus lengths other than 2048 or 4096, and
> > - All RSA public keys with exponents other than 65537, and
>
> Hi Jacob.  65537 (aka 0x10001) is hard-coded here...
>
> https://github.com/openssl/openssl/blob/OpenSSL_0_9_8f/apps/req.c#L768
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenssl%2Fopenssl%2Fblob%2FOpenSSL_0_9_8f%2Fapps%2Freq.c%23L768&data=04%7C01%7Crob%40sectigo.com%7Ca505320417514683604108d962906fbc%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637649196427648716%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=4ROhglN%2FjGObdJvEVKvM90IxeO7IhKtPubHTUBzBkhY%3D&reserved=0>
>
> Would it therefore be fair to say that keys with public exponents other
> than 65537 are implicitly *not* Debian weak keys?
>
> > - All RSA public keys that are detected as vulnerable by the
> openssl-vulnkey program in the openssl-blacklist package version 0.5-3 (see
> addendum), or an equivalent program."
>
> ------------------------------
> *From:* Servercert-wg <servercert-wg-bounces at cabforum.org>
> <servercert-wg-bounces at cabforum.org> on behalf of Jacob Hoffman-Andrews
> via Servercert-wg <servercert-wg at cabforum.org>
> <servercert-wg at cabforum.org>
> *Sent:* 12 December 2020 02:21
> *To:* Christopher Kemmerer <chris at ssl.com> <chris at ssl.com>; CA/B Forum
> Server Certificate WG Public Discussion List <servercert-wg at cabforum.org>
> <servercert-wg at cabforum.org>
> *Subject:* Re: [Servercert-wg] SCXX Ballot proposal: Debian Weak keys
>
> 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.
>
> Thanks for your continued efforts to improve this part of the BRs! Let's
> Encrypt is in theory interested in endorsing, but I think it still needs a
> bit of work. Thanks for incorporating my most recent comments on endianness
> and word size vs 11 platforms.
>
> Goals: We want CAs to consistently not issue certificates for weak keys in
> general, and also in the specific case of Debian and ROCA keys. We want the
> definition of Debian and ROCA keys to be clear and actionable for as long
> as possible - say, at least twenty years.
>
> We have three ways to specify Debian and ROCA keys: With a list, with a
> tool, or with an algorithm*. The original revision of this ballot proposed
> to use a list (
> https://lists.cabforum.org/pipermail/servercert-wg/2020-April/001821.html
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.cabforum.org%2Fpipermail%2Fservercert-wg%2F2020-April%2F001821.html&data=04%7C01%7Crob%40sectigo.com%7Ca505320417514683604108d962906fbc%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637649196427648716%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=YvYqBm1HlforxiPN1zQbeSUf4AW04sLaYCuEjiLfFzA%3D&reserved=0>).
> There were two objections:
>
>  - The list (openssl-blacklist) is subject to change or removal.
>  - The list only covers 2048 and 4096 bit keys.
>
> The current draft proposes specifying a tool for ROCA (
> https://github.com/crocs-muni/roca
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcrocs-muni%2Froca&data=04%7C01%7Crob%40sectigo.com%7Ca505320417514683604108d962906fbc%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637649196427658670%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Ybwh7xp1zVuEj8avYqsDHslP2NrZEzoOPOx4bEI4%2B5I%3D&reserved=0>)
> and an algorithm for Debian keys.
>
> The ROCA tool is subject to change or removal, just like the
> openssl-blacklist package. I propose we instead specify ROCA detection in
> terms of the paper (https://crocs.fi.muni.cz/public/papers/rsa_ccs17
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcrocs.fi.muni.cz%2Fpublic%2Fpapers%2Frsa_ccs17&data=04%7C01%7Crob%40sectigo.com%7Ca505320417514683604108d962906fbc%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637649196427658670%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=6550FZqHPDF6KM3F17d6rKeCfP0Zau%2BGWYwPYal7acY%3D&reserved=0>)
> and ask for permission from the authors to archive an unchanging copy as an
> addendum to the BRs.
>
> For Debian keys, what looks like an algorithm specification is actually a
> tool + algorithm specification. The tool is "OpenSSL 0.9.8c-1 up to
> versions before 0.9.8g-9 on Debian-based operating systems" (per
> CVE-2008-01666 - https://cve.mitre.org/cgi-bin/cvename.cgi?name=2008-0166
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcve.mitre.org%2Fcgi-bin%2Fcvename.cgi%3Fname%3D2008-0166&data=04%7C01%7Crob%40sectigo.com%7Ca505320417514683604108d962906fbc%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637649196427658670%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=QdZIVGYB%2B3jgtU05nS52CnLACgzSkjXmC%2FonOtuWFa4%3D&reserved=0>).
> To ensure an unchanging copy of that, we should archive 3 copies of Debian,
> for the 3 word size + endianness combinations.
>
> The algorithm also needs an additional line: "v) using the command
> 'openssl req -nodes -subj / -newkey rsa:<Public Key length>'" (adapted from
> https://sources.debian.org/data/main/o/openssl-blacklist/0.5-3/examples/gen_certs.sh
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsources.debian.org%2Fdata%2Fmain%2Fo%2Fopenssl-blacklist%2F0.5-3%2Fexamples%2Fgen_certs.sh&data=04%7C01%7Crob%40sectigo.com%7Ca505320417514683604108d962906fbc%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637649196427668630%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=%2FmV%2BEdnUMMSfAiJBQfFxfcq98T5WzVgTj%2Bhqjbt7AJY%3D&reserved=0>).
> Other tools that linked OpenSSL, like openvpn and openssh, generated
> different sets of keys. We can include or exclude openvpn and openssh keys,
> but should thoroughly specify.
>
> Lastly, I think we should archive openssl-blacklist, and include in the
> BRs: "A CA may reject the full set of Debian weak keys by rejecting this
> superset of the Debian weak keys:
>
>  - All RSA public keys with modulus lengths other than 2048 or 4096, and
>  - All RSA public keys with exponents other than 65537, and
>  - All RSA public keys that are detected as vulnerable by the
> openssl-vulnkey program in the openssl-blacklist package version 0.5-3 (see
> addendum), or an equivalent program."
>
> My reasoning: Given the difficulty of correctly setting up old Debian
> versions and generating weak keys for sizes that are not part of
> openssl-blacklist, I expect most CAs will choose this path. Given that, we
> should just say what we mean: the pregenerated list is fine if you restrict
> key sizes, but you don't *have* to restrict key sizes, so long as you have
> an alternate method to ensure you're not issuing for Debian weak keys at
> other sizes.
>
> *I'm considering specifying an algorithm to be functionally equivalent to
> specifying an "outcome," though I recognize this may be too hand-wavy.
>
> _______________________________________________
> Servercert-wg mailing listServercert-wg at cabforum.orghttps://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=04%7C01%7Crob%40sectigo.com%7Ca505320417514683604108d962906fbc%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637649196427668630%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Z77j7m49%2BG5JpAB2aJbLYXkFx2DHsia00M2%2FIRob%2Bqs%3D&reserved=0>
>
>
>
> _______________________________________________
> Servercert-wg mailing list
> 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/20210914/71a0fbbc/attachment-0001.html>