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

Thu Jan 14 18:39:20 UTC 2021

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://github.com/CVE-2008-0166/key_generator> and uploaded them to 
> https://github.com/CVE-2008-0166/private_keys 
> <https://github.com/CVE-2008-0166/private_keys>, and I've generated 
> the corresponding blocklists and uploaded them to 
> https://github.com/CVE-2008-0166/openssl_blocklists 
> <https://github.com/CVE-2008-0166/openssl_blocklists>. 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>
> *Sent:* 13 January 2021 21:49
> *To:* Rob Stradling <rob at sectigo.com>; CA/B Forum Server Certificate 
> WG Public Discussion List <servercert-wg at cabforum.org>; Jacob 
> Hoffman-Andrews <jsha at letsencrypt.org>; Christopher Kemmerer 
> <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%7C5bc6d28ecd024d9e1aef08d8b80d16d7%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637461714596804832%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=audMLzB5wqGuJF1PGABB8klYmr8GF0rncNtPW3BPslk%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%7C5bc6d28ecd024d9e1aef08d8b80d16d7%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637461714596814786%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=QW4H5LZN7f3LCNJGqffpHw3OX8Obmw0NV742YwnF94k%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%7C5bc6d28ecd024d9e1aef08d8b80d16d7%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637461714596814786%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=V8nF05EWIKFSBndH2VlIhjccVdACKR4OCmPtpqhASPw%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%7C5bc6d28ecd024d9e1aef08d8b80d16d7%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637461714596814786%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=RtQozkPbwOcrF5fQvNq3RQW957dcL5cwiU7lngmCAuE%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%7C5bc6d28ecd024d9e1aef08d8b80d16d7%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637461714596824743%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=YsKWoiNT5Y9aqo%2FPVDxvce8h0m7YRUhhtsj1E9qkZds%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%7C5bc6d28ecd024d9e1aef08d8b80d16d7%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637461714596824743%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=fTfVfOjEhh96bTOdGJNF98KA%2BdEPSRxWwHTSgmHfAOI%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%7C5bc6d28ecd024d9e1aef08d8b80d16d7%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637461714596834697%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=50r1OmZzAii3jZuvTKYjwdNxSx8%2FAEvClM%2BO6lFiTAU%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%7C5bc6d28ecd024d9e1aef08d8b80d16d7%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637461714596844650%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=bsUmJu3kpaIFAxT5JI8rfFuZwzhOeX7FQ5ISQOsPz%2Bg%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%7C5bc6d28ecd024d9e1aef08d8b80d16d7%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637461714596844650%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=lX%2Bk0T8e9LM0YxI9mKjRAKdktyILrmyWv%2BQW%2BI7PJXE%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%7C5bc6d28ecd024d9e1aef08d8b80d16d7%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637461714596854611%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=33vBsh3%2BJB9uMLln%2BihOgOF5BkoZxdIcAMY2PCEDz8I%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%7C5bc6d28ecd024d9e1aef08d8b80d16d7%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637461714596854611%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=U9531zk1sf%2BXEiOvCTUa9XHdkpFWHsGQaG%2FB0KrKUbw%3D&reserved=0>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20210114/1f1953bf/attachment-0001.html>