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

Sun Sep 26 17:48:51 UTC 2021

When it's ready, Mozilla will endorse.

On Mon, Sep 20, 2021 at 4:38 PM Christopher Kemmerer <chris at ssl.com> wrote:

> Thanks, Ben. We are reviewing this section (and the entire proposed
> ballot) and revising for clarity.
>
> Chris K
>
> On 9/14/2021 11:14 AM, Ben Wilson wrote:
>
> 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/20210926/9066614c/attachment-0001.html>