[Servercert-wg] SCXX Ballot proposal: Debian Weak keys
Christopher Kemmerer
chris at ssl.com
Fri Oct 15 14:32:34 UTC 2021
Thank you, Rob, and shall watch for that update. Meanwhile we are doing
a final-final pass through our draft language for clarity and will send
it early next week.
Chris K
Meanwhile, we've cycled our draft language through another review and
have made IIRC only one or two minor edits for clarity (h/t BenW).
On 10/14/2021 9:49 AM, Rob Stradling wrote:
> Today I rediscovered that I'd previously generated the RSA-8192
> blocklists back in December 2009, and that they're still available at
> https://secure.sectigo.com/debian_weak_keys/. When I compared the old
> and new RSA-8192 blocklists, I found that ~0.8% of the "rnd" keys are
> different. It looks like, for reasons unknown, the "OpenSSL random
> file state" misbehaved occasionally over the 8 month run that ended
> recently.
>
> I'll report back once I've regenerated and verified the problematic keys.
>
> ------------------------------------------------------------------------
> *From:* Rob Stradling <rob at sectigo.com>
> *Sent:* 23 September 2021 19:17
> *To:* Christopher 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>; Rob Stradling <rob at sectigo.com>
> *Subject:* Re: [Servercert-wg] SCXX Ballot proposal: Debian Weak keys
> > 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 repositories.
>
> It took nearly 8 months (using just a single core of a fairly modest
> CPU), but it finally finished! Repositories updated.
>
> ------------------------------------------------------------------------
> *From:* Servercert-wg <servercert-wg-bounces at cabforum.org> on behalf
> of Rob Stradling via Servercert-wg <servercert-wg at cabforum.org>
> *Sent:* 13 May 2021 15:42
> *To:* Christopher 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
>
> 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.
>
> > 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%7C149793a77768442bd12008d97ebe5652%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637680178217074727%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=zl%2BZrS8yTo8rthH5xmpwlnX3SpoRMsdVE%2FclqalKoQc%3D&reserved=0> 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%7Crob%40sectigo.com%7C149793a77768442bd12008d97ebe5652%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637680178217084682%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=KxcClfliIPLheETc%2FQV480nHSRbTo%2FoEK3XgUAk4Yto%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%7C149793a77768442bd12008d97ebe5652%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637680178217084682%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=PmKVyPxenhak%2B%2BxkCP7%2FhbHQJ805g%2FYcuYLGz0XxQXU%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%7Crob%40sectigo.com%7C149793a77768442bd12008d97ebe5652%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637680178217094639%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=BFBuQxgO8FcG50FeHeHSmrnJjZ6jQHddP5iqg2cwc%2Bw%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%7C149793a77768442bd12008d97ebe5652%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637680178217104593%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=PHaY1K1EU0Kp735Bq9LwL0upowvpAHUqY7VLm7hwfog%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%7C149793a77768442bd12008d97ebe5652%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637680178217104593%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=IbahtE1nhkv01V6tdRcL3%2Be3r3pmow0T7UVY6rWGvRk%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%7C149793a77768442bd12008d97ebe5652%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637680178217114550%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ivYda%2Bw1kFPj2gIcjGeq%2FZLsoi3GDOPiBn%2FnHZ8kflM%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%7C149793a77768442bd12008d97ebe5652%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637680178217114550%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=KWBNwIlyUPcvrvaKg8iPgBQ5FI9pPMluRzaew4zPd%2BI%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%7C149793a77768442bd12008d97ebe5652%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637680178217124508%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3fRkMQs0eFWpwRX6mKOntrHQGooglWuu03LB49ERhCQ%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%7C149793a77768442bd12008d97ebe5652%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637680178217124508%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=UGwMkOD1q1jxIXPHuJJUsCIDwLSDgvWj0hRnu7y1fiY%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%7C149793a77768442bd12008d97ebe5652%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637680178217134467%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=DfRGy7XTHeCCr%2Bvg91ai%2BwJgIJv3cDiZnaF87DjYCHs%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%7C149793a77768442bd12008d97ebe5652%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637680178217134467%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=i8tJYB5eeKFqK1IW7fRfUuZYkU7a0nsa53tO3n2Oe2Y%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%7C149793a77768442bd12008d97ebe5652%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637680178217144421%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=gMWLE%2FC%2FADXIuHQgkf%2BdZaMDM2Fl2p2kY%2FDSHu4STxY%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%7C149793a77768442bd12008d97ebe5652%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637680178217154377%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=bb31TV4W%2FDDFp8OmDvOCvUFCpFtHLgJvDzYtQ7aDu2w%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%7C149793a77768442bd12008d97ebe5652%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637680178217154377%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=MXJsH%2FmY6leMCDewbsU6JbeeEcem0u5rJu8gk9YdqR8%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%7C149793a77768442bd12008d97ebe5652%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637680178217164330%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=xjks4ZUMTP0hJ2FfET89jZDX1t9OjjyKvU7aMtOWk8A%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%7C149793a77768442bd12008d97ebe5652%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637680178217164330%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=8ViOp4z45yyVKMH87lrF0fFZ80huwEtPxw9QyRRzs5I%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%7C149793a77768442bd12008d97ebe5652%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637680178217174300%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=jloaFDmapMElTMrMjq4cq%2BdKKB81F18ieo%2FGdeMeifI%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%7C149793a77768442bd12008d97ebe5652%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637680178217174300%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=4cbYj85QRS4EJCOa3h%2FUeQolfCDnwt%2Bvu4fOrixIK10%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%7C149793a77768442bd12008d97ebe5652%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637680178217184247%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=7Ty5ye8OuF1cEUf%2BDVK8BqWCoQixa%2BLEQXKPGgq8LqE%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%7C149793a77768442bd12008d97ebe5652%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637680178217184247%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=lYRVn%2BlfCxc%2FBEY73QKiH0hQYOVDUDNqJwvWg02TxRg%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%7C149793a77768442bd12008d97ebe5652%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637680178217194202%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=WOygxUjpjBXpHmDwEa5FlrzVOQ%2BGVtuzCvIaYLcVzZs%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%7C149793a77768442bd12008d97ebe5652%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637680178217204157%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=k8TzKB9yaN9M3szAvvYKFwb7SWaAIZtmbh6kTDpRUWI%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%7C149793a77768442bd12008d97ebe5652%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637680178217204157%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=mJbnosdyxAHvzj1zOAcJ7ippJu6sDDNl5fNfg0nEi98%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%7C149793a77768442bd12008d97ebe5652%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637680178217214120%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=6xVg5WENHqAmHV5%2B0vMsLYGqlVkQ3pR92qrJe9G9gag%3D&reserved=0>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20211015/50345bf5/attachment-0001.html>
More information about the Servercert-wg
mailing list