[Servercert-wg] SCXX Ballot proposal: Debian Weak keys
Christopher Kemmerer
chris at ssl.com
Mon Sep 20 22:38:46 UTC 2021
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 <mailto: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 <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
> <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
> <https://github.com/crocs-muni/roca> or equivalent.
>
> b) In the case of Debian weak keys
> (https://wiki.debian.org/SSLkeys
> <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
> <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.
>
> --- Motion Ends ---
>
>
> ------------------------------------------------------------------------
> *From:* Rob Stradling <rob at sectigo.com <mailto:rob at sectigo.com>>
> *Sent:* Tuesday, August 24, 2021 4:01 PM
> *To:* Chris Kemmerer <chris at ssl.com <mailto:chris at ssl.com>>;
> Dimitris Zacharopoulos (HARICA) <dzacharo at harica.gr
> <mailto:dzacharo at harica.gr>>; CA/B Forum Server Certificate WG
> Public Discussion List <servercert-wg at cabforum.org
> <mailto:servercert-wg at cabforum.org>>; Jacob Hoffman-Andrews
> <jsha at letsencrypt.org <mailto: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
> <http://debian.org> resource)
>
> I think it's still valuable to mention
> https://wiki.debian.org/SSLkeys <https://wiki.debian.org/SSLkeys>.
>
> ------------------------------------------------------------------------
> *From:* Christopher Kemmerer <chris at ssl.com <mailto:chris at ssl.com>>
> *Sent:* 18 August 2021 22:37
> *To:* Rob Stradling <rob at sectigo.com <mailto:rob at sectigo.com>>;
> Dimitris Zacharopoulos (HARICA) <dzacharo at harica.gr
> <mailto:dzacharo at harica.gr>>; CA/B Forum Server Certificate WG
> Public Discussion List <servercert-wg at cabforum.org
> <mailto:servercert-wg at cabforum.org>>; Jacob Hoffman-Andrews
> <jsha at letsencrypt.org <mailto: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 <http://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> <mailto:chris at ssl.com>
>> *Sent:* 13 May 2021 15:12
>> *To:* Rob Stradling <rob at sectigo.com> <mailto:rob at sectigo.com>;
>> Dimitris Zacharopoulos (HARICA) <dzacharo at harica.gr>
>> <mailto:dzacharo at harica.gr>; CA/B Forum Server Certificate WG
>> Public Discussion List <servercert-wg at cabforum.org>
>> <mailto:servercert-wg at cabforum.org>; Jacob Hoffman-Andrews
>> <jsha at letsencrypt.org> <mailto: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 Sectigoto 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 bitlength, 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 bitlength keys. (We
>> understandRSA-3072 length keysare 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'sEncrypt) 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>rocaor
>> equivalent.")
>>
>> We think our present ballot language (reproduced at the end of
>> this message) provides appropriately focused guidance to CAs. If
>> available, we'dcertainly like to also see the HARICA/Sectigolists
>> (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
>> <http://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'dappreciate 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 accessibleresources, 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 noreadrndOpenSSL 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>
>>> <mailto:dzacharo at harica.gr>
>>> *Sent:* 14 January 2021 18:39
>>> *To:* Rob Stradling <rob at sectigo.com> <mailto:rob at sectigo.com>;
>>> CA/B Forum Server Certificate WG Public Discussion List
>>> <servercert-wg at cabforum.org>
>>> <mailto:servercert-wg at cabforum.org>; Jacob Hoffman-Andrews
>>> <jsha at letsencrypt.org> <mailto:jsha at letsencrypt.org>;
>>> Christopher Kemmerer <chris at ssl.com> <mailto: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>
>>>> <mailto:dzacharo at harica.gr>
>>>> *Sent:* 13 January 2021 21:49
>>>> *To:* Rob Stradling <rob at sectigo.com> <mailto:rob at sectigo.com>;
>>>> CA/B Forum Server Certificate WG Public Discussion List
>>>> <servercert-wg at cabforum.org>
>>>> <mailto:servercert-wg at cabforum.org>; Jacob Hoffman-Andrews
>>>> <jsha at letsencrypt.org> <mailto:jsha at letsencrypt.org>;
>>>> Christopher Kemmerer <chris at ssl.com> <mailto: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>
>>>>> <mailto:servercert-wg-bounces at cabforum.org> on behalf of Rob
>>>>> Stradling via Servercert-wg <servercert-wg at cabforum.org>
>>>>> <mailto:servercert-wg at cabforum.org>
>>>>> *Sent:* 06 January 2021 16:08
>>>>> *To:* Jacob Hoffman-Andrews <jsha at letsencrypt.org>
>>>>> <mailto:jsha at letsencrypt.org>; Christopher 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>
>>>>> *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>
>>>>> <mailto:servercert-wg-bounces at cabforum.org> on behalf of Jacob
>>>>> Hoffman-Andrews via Servercert-wg <servercert-wg at cabforum.org>
>>>>> <mailto:servercert-wg at cabforum.org>
>>>>> *Sent:* 12 December 2020 02:21
>>>>> *To:* Christopher 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>
>>>>> *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 list
>>>>> Servercert-wg at cabforum.org <mailto: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=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 <mailto:Servercert-wg at cabforum.org>
> https://lists.cabforum.org/mailman/listinfo/servercert-wg
> <https://lists.cabforum.org/mailman/listinfo/servercert-wg>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20210920/9af0aa91/attachment-0001.html>
More information about the Servercert-wg
mailing list