[Servercert-wg] SCXX Ballot proposal: Debian Weak keys
Christopher Kemmerer
chris at ssl.com
Wed Aug 18 21:37:51 UTC 2021
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)
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 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://github.com/CVE-2008-0166> repositories.
>
> ------------------------------------------------------------------------
> *From:* Christopher Kemmerer <chris at ssl.com>
> *Sent:* 13 May 2021 15:12
> *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,
>
> 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%7C%7Ce2b4b1c02cde4de101b308d91619376c%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637565120954353387%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ZELduxkdVuM%2F8lX%2F0S27vxUfAyIYYywxTUiuQB%2FJUF8%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%7C%7Ce2b4b1c02cde4de101b308d91619376c%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637565120954353387%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=%2B6Bbrw6zOi9Mqg4ufrsCgQr4I2GpiDVyF799GdFZo%2Fc%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.
>
> 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%7C%7Ce2b4b1c02cde4de101b308d91619376c%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637565120954353387%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=8k346qzJCSyDiCSkHRf9hCx3lOT9r0QSQ8LPKmQv1Ic%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%7C%7Ce2b4b1c02cde4de101b308d91619376c%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637565120954363341%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=B%2B7P5Mt6gju%2Fcqk20zgg12bdBBSIjEp9agCWOVtr9dg%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%7C%7Ce2b4b1c02cde4de101b308d91619376c%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637565120954363341%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=OCUNpTPVeCB%2Fz0b4jTfiv6vbvXFwmM5yRq%2BRuCO55ZE%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%7C%7Ce2b4b1c02cde4de101b308d91619376c%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637565120954373299%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3foFsayO%2BPHfuOSBeUHZMMP1Q5oudchTbgcQFGlWy9M%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%7C%7Ce2b4b1c02cde4de101b308d91619376c%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637565120954373299%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=65887HTXWFWaUo0GBNYu8Ctd5S1pW0w%2Buja1HQjjQXU%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%7C%7Ce2b4b1c02cde4de101b308d91619376c%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637565120954373299%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=YsJN75IdoHbB0xxrFmIrcAYDnYzGLutgy%2FA467RtFqk%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%7C%7Ce2b4b1c02cde4de101b308d91619376c%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637565120954383257%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=82IVXFou7B6gTuLVR40v%2BFsnLEFYITrlTZLPdV%2Bp%2BHk%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%7C%7Ce2b4b1c02cde4de101b308d91619376c%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637565120954383257%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=02dPvzXAoQa2QdA5404SWcII6joTEbnX3nQ5mFKHke4%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%7C%7Ce2b4b1c02cde4de101b308d91619376c%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637565120954383257%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=84rUyqFcrGyBzI0U1igsIdRf23MjG%2BmScRniWptlJ7g%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%7C%7Ce2b4b1c02cde4de101b308d91619376c%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637565120954393211%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Ek2DJ%2B%2FzipYDxKYQD4UKZcD21oPgfeGMgFEwbwephjg%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%7C%7Ce2b4b1c02cde4de101b308d91619376c%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637565120954393211%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=351FCX8uuZ44s%2BUzFEmN9wECMZlBH10xHAmbOtF85xo%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%7C%7Ce2b4b1c02cde4de101b308d91619376c%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637565120954403169%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=IhYSEh8Bt%2FODjgmx27nNxsaSW3S8J0znHYJvsJVEHvA%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%7C%7Ce2b4b1c02cde4de101b308d91619376c%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637565120954403169%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=wNwpjeA4bEAp%2FEFOPI%2FyGOc6FW6U6Oqgr1rss1FCDDw%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%7C%7Ce2b4b1c02cde4de101b308d91619376c%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637565120954403169%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=JRYwvgbrG1OuFxzL3b4dV1IdIaIF6NGXH7jkJw%2FQjMM%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%7C%7Ce2b4b1c02cde4de101b308d91619376c%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637565120954413126%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=sjDil3UqhOzc0t4hO5HumENGmxYVqZ4xu56bu42bgKg%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%7C%7Ce2b4b1c02cde4de101b308d91619376c%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637565120954413126%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=x4RdtrOp60DOZcpOymaXECgx9v2kK5%2Bwck3gqhxovAk%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%7C%7Ce2b4b1c02cde4de101b308d91619376c%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637565120954423081%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=rsy9wnrty4nLwQNxakiUnSVDtbAXa%2F8uhRsoWcz4RMY%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%7C%7Ce2b4b1c02cde4de101b308d91619376c%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637565120954423081%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=L7GlRLH4DfxsZkruEioaA97Xy%2Bbl1Ru4caU3zeSSI%2F4%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%7C%7Ce2b4b1c02cde4de101b308d91619376c%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637565120954433037%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=faFx80ndwx3wGDq6lkYKoGzSIKSjx9e2UPS0eNsZp7o%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%7C%7Ce2b4b1c02cde4de101b308d91619376c%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637565120954433037%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=GCbLY7haF2aOY5C3Sa8qM61qnIeRq89%2BsIyWXf6dMPE%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%7C%7Ce2b4b1c02cde4de101b308d91619376c%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637565120954433037%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=zGC8USg1Ws3rjKBdESFCVT2L2UJz9QjyddJtrRkpZQA%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%7C%7Ce2b4b1c02cde4de101b308d91619376c%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637565120954442992%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=whOASQm29RlwypzcfdPuXhaWpdxbLkILLwRr2RXnSFE%3D&reserved=0>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20210818/4f57d7f4/attachment-0001.html>
More information about the Servercert-wg
mailing list