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

Mon May 2 16:12:56 UTC 2022

On Mon, May 2, 2022 at 11:25 AM Karina Sirota via Servercert-wg <
servercert-wg at cabforum.org> wrote:

> There are some primary concerns about this-  mainly, how would a CA be
> aware of gathering the information mentioned in most of the methods below?
>

At a minimum, problem reports that credibly demonstrate this information.
Equally, a broadcast to the CA/Browser Forum Members list (e.g. for
security relevant disclosures) could also be argued as the CA being made
aware.

> Can we get more specific about the methods that expose private keys or how
> a CA should gather this information: “b) In the case of Debian weak keys (
> https://wiki.debian.org/SSLkeys
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.debian.org%2FSSLkeys&data=05%7C01%7Ckarina.sirota%40microsoft.com%7C94d75ad129bc49ce855a08da1f2c38b0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856574642543179%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ATNh%2BnLhaXmkh8bFEh6LVti4l5wVi%2FGnnvy2fm32bio%3D&reserved=0>),
> the CA SHALL reject at least keys generated by the flawed OpenSSL version
> with the combination of the following parameters: i) Big-endian 32-bit,
> little-endian 32-bit, and little-endian 64-bit architecture; ii) Process ID
> of 0 to 32767, inclusive; iii) All RSA Public Key lengths supported by the
> CA up to and including 4096 bits; iv) rnd, nornd, and noreadrnd OpenSSL
> random file state“
>

This can be empirically tested/compared (as the discussion on the list).

> and "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;"
>

I'm not sure I follow? This would be the CA consulting their own list of
compromised keys (e.g. as they're required to retain records for)

>
>
> There are concerns that CAs wouldn’t be able to get the visibility into
> the subscriber’s key generation process to verify this.
>
>
>
> For "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;", can we also clean up the language to be clear that the
> CA cannot issue only for the compromised key? The way this is phrased
> sounds like it could also mean that a CA should not issue ANYTHING to a
> subscriber who previously have a key compromise, which I don’t believe is
> the goal here.
>
>
>
>
>
> Best,
>
> Karina
>
>
>
> *Ka*rina *Sirota* | Security Program Manager 2
>
> Trusted Root Program, Trust Governance and Resilience
>
>
>
> *After-hours responses neither required nor expected. *
>
>
>
>
>
>
>
>
>
> *From:* Servercert-wg <servercert-wg-bounces at cabforum.org> *On Behalf Of *Chris
> Kemmerer via Servercert-wg
> *Sent:* Friday, April 15, 2022 5:07 PM
> *To:* Martijn Katerbarg <martijn.katerbarg at sectigo.com>; CA/B Forum
> Server Certificate WG Public Discussion List <servercert-wg at cabforum.org>
> *Subject:* Re: [Servercert-wg] [EXTERNAL]-Re: SCXX Ballot proposal:
> Debian Weak keys
>
>
>
> Thanks for your suggestion, Martijn. We ourselves wouldn't object to this
> addition, though we'd certainly like to poll the community on their
> thoughts.
>
> We see that the vulnerability you address has been assigned
> https://nvd.nist.gov/vuln/detail/CVE-2022-26320
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fnvd.nist.gov%2Fvuln%2Fdetail%2FCVE-2022-26320&data=05%7C01%7Ckarina.sirota%40microsoft.com%7C94d75ad129bc49ce855a08da1f2c38b0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856574642543179%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=prmP%2BEnjpTv5UE9elnyOWm9zGi0jQFZ4Pl%2BQhX9%2Fbig%3D&reserved=0>,
> with https://fermatattack.secvuln.info/
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffermatattack.secvuln.info%2F&data=05%7C01%7Ckarina.sirota%40microsoft.com%7C94d75ad129bc49ce855a08da1f2c38b0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856574642543179%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=XWYdDEfOGcQ5ahAGCyRl7o%2BoJnUjmYsULjoefO%2Fex%2B8%3D&reserved=0>
> looking like the main resource for this issue. We also note (per that
> latter site) that Let's Encrypt has updated Boulder to check for this
> vulnerability (https://github.com/letsencrypt/boulder/pull/5853
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fletsencrypt%2Fboulder%2Fpull%2F5853&data=05%7C01%7Ckarina.sirota%40microsoft.com%7C94d75ad129bc49ce855a08da1f2c38b0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856574642543179%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=sNfdCK05Ti1ahvBy9DSAVROj%2BJKux7GUFB0NS0BC4sg%3D&reserved=0>
> ).
>
> The Debian weak key and ROCA vulnerabilities have been known lo these many
> years (although not all CAs had sufficient safeguards in place, and the
> sections of the BRs provided less than comprehensive guidance on what those
> safeguards should be - hence this ballot  initiative).
>
> Since CVE-2022-26320 was only published March 14 2022, one alternative
> would be would be to defer a decision on the Fermat attack language to
> another, later ballot, but we again invite community input on incorporating
> this suggestion into our current proposed ballot.
>
> One practical question (not addressed in our current language) would be
> the deadline for CAs to add the checks required in this ballot, with our
> thought being to place it in the nearer term (some few months after ballot
> passage/review) but not immediately upon adoption of the ballot. This
> particularly is of interest for any changes/checks required for
> CVE-2022-26320, but in our view any deadline should be considered to apply
> to all vulnerabilities addressed in this ballot.
>
> Thanks,
>
> Chris K
>
> On 4/5/2022 4:53 AM, Martijn Katerbarg wrote:
>
> Hi Chris,
>
>
>
> I would like to propose an additional check to the proposed language so it
> includes checking for the Close Primes vulnerability. For this I’d like to
> propose we add to 6.1.1.3 (4):
>
>
> “c) In the case of Close Primes vulnerability, the CA SHALL reject weak
> keys identified within 100 rounds using Fermat’s factorization method”
>
>
>
> Martijn
>
>
>
> *From:* Servercert-wg <servercert-wg-bounces at cabforum.org>
> <servercert-wg-bounces at cabforum.org> *On Behalf Of *Chris Kemmerer via
> Servercert-wg
> *Sent:* Thursday, 31 March 2022 16:43
> *To:* Jaime Hablutzel via Servercert-wg <servercert-wg at cabforum.org>
> <servercert-wg at cabforum.org>
> *Subject:* Re: [Servercert-wg] [EXTERNAL]-Re: 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.
>
>
>
> We are pleased to return to discussion of this proposed ballot, which
> we've reprinted immediately below.
>
> Based on the discussion thus far, we've addressed Corey's point by adding
> the * bolded *line re: which modulus/exponents a CA MUST check. (We
> generally agree with Jaime's suggestion that CAs *should *check the
> modulus only but don't see it as crucial to explicitly state this in the
> ballot.)
>
> We've also updated the version in the proposal.
>
> If this ballot proceeds the next available designation would be SC55.
>
> Many thanks,
>
> Chris K
>
>
> =====
>
> --- Motion Begins ---
>
>
> This ballot modifies the “Baseline Requirements for the Issuance and
> Management of Publicly-Trusted Certificates” as follows, based on Version
> 1.8.2:
>
>
> 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.debian.org%2FSSLkeys&data=05%7C01%7Ckarina.sirota%40microsoft.com%7C94d75ad129bc49ce855a08da1f2c38b0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856574642543179%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ATNh%2BnLhaXmkh8bFEh6LVti4l5wVi%2FGnnvy2fm32bio%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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.debian.org%2FSSLkeys&data=05%7C01%7Ckarina.sirota%40microsoft.com%7C94d75ad129bc49ce855a08da1f2c38b0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856574642543179%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ATNh%2BnLhaXmkh8bFEh6LVti4l5wVi%2FGnnvy2fm32bio%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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcrocs-muni%2Froca&data=05%7C01%7Ckarina.sirota%40microsoft.com%7C94d75ad129bc49ce855a08da1f2c38b0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856574642543179%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=7UfsVU%2BiqjZOWsJ8n2JokRUxQTeiPgzOFX%2FjdMpuuXo%3D&reserved=0>
> or equivalent.
> b) In the case of Debian weak keys (https://wiki.debian.org/SSLkeys
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.debian.org%2FSSLkeys&data=05%7C01%7Ckarina.sirota%40microsoft.com%7C94d75ad129bc49ce855a08da1f2c38b0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856574642543179%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ATNh%2BnLhaXmkh8bFEh6LVti4l5wVi%2FGnnvy2fm32bio%3D&reserved=0>),
> the CA SHALL reject at least keys generated by the flawed OpenSSL version
> with the combination of the following parameters:
>
> i) Big-endian 32-bit, little-endian 32-bit, and little-endian 64-bit
> architecture;
> ii) Process ID of 0 to 32767, inclusive;
> iii) All RSA Public Key lengths supported by the CA up to and including
> 4096 bits;
> iv) rnd, nornd, and noreadrnd OpenSSL random file state.
>
> For Debian weak keys not covered above, the CA SHALL take actions to
> minimize the probability of certificate issuance.
>
> *CAs MUST check for Debian weak keys for all RSA modulus lengths and
> exponents that they accept.*
>
> --- Motion Ends ---
>
> =====
>
> On 10/28/2021 3:55 PM, Jaime Hablutzel via Servercert-wg wrote:
>
> It could be helpful to be a little bit more explicit on the fact that the
> required check is against the modulus only as it could avoid developers
> to implement this check against full public keys, which can lead to:
>
>    1. Some CAs could unknowingly embark themselves in the onerous task of
>    generating the affected key pairs for each different public exponent, which
>    is not really required.
>    2. Because of the higher amount of work required for
>    supporting/maintaining the check in this way, some CAs might mistakenly
>    omit checking some subscriber keys, e.g. they might have in their
>    blocklists only the affected public keys with the public exponent set to
>    65537, even when they (unintentionally) support subscriber keys with other
>    values for the public exponent.
>
>
>
> On Thu, 28 Oct 2021 at 03:02 Rob Stradling <rob at sectigo.com> wrote:
>
> > I think we can merely state that CAs must check for Debian weak keys for
> all RSA modulus lengths and exponents that they accept. Using a comparison
> of the modulus (or its hash) is essentially an implementation detail that
> we don’t need to explicitly mandate.
>
>
>
> Thanks Corey.  That makes sense.
>
>
> ------------------------------
>
> *From:* Corey Bonnell
> *Sent:* Wednesday, October 27, 2021 18:43
> *To:* Rob Stradling; Jaime Hablutzel; CA/B Forum Server Certificate WG
> Public Discussion List
> *Cc:* Christopher Kemmerer
> *Subject:* RE: [EXTERNAL]-Re: [Servercert-wg] SCXX Ballot proposal:
> Debian Weak keys
>
>
>
> > Hi Jaime.  Ooh, you're right!  The affected OpenSSL versions generate
> the same predictable moduli regardless of the public exponent value.
>
>
>
> Yes, that’s great to know; thanks for pointing it out.
>
>
>
> > What's the best way to capture all this in the ballot?
>
>
>
> I think we can merely state that CAs must check for Debian weak keys for
> all RSA modulus lengths and exponents that they accept. Using a comparison
> of the modulus (or its hash) is essentially an implementation detail that
> we don’t need to explicitly mandate.
>
>
>
> Thanks,
>
> Corey
>
>
>
> *From:* Rob Stradling <rob at sectigo.com>
> *Sent:* Wednesday, October 27, 2021 5:31 AM
> *To:* Jaime Hablutzel <jhablutz at WISEKEY.COM>; CA/B Forum Server
> Certificate WG Public Discussion List <servercert-wg at cabforum.org>
> *Cc:* Corey Bonnell <Corey.Bonnell at digicert.com>; Christopher Kemmerer <
> chris at ssl.com>
> *Subject:* Re: [EXTERNAL]-Re: [Servercert-wg] SCXX Ballot proposal:
> Debian Weak keys
>
>
>
> Hi Jaime.  Ooh, you're right!  The affected OpenSSL versions generate the
> same predictable moduli regardless of the public exponent value.
>
>
>
> So yes, the optimal approach seems to be for CAs to use Debian weak key
> blocklists that are based on only the RSA modulus.
>
>
>
> Corey's point applies if a CA chooses instead to implement a Debian weak
> key blocklist of (for example) SubjectPublicKeyInfos with public exponent
> 65537.
>
>
>
> What's the best way to capture all this in the ballot?
>
>
> ------------------------------
>
> *From:* Jaime Hablutzel
> *Sent:* Sunday, October 24, 2021 23:25
> *To:* Rob Stradling; CA/B Forum Server Certificate WG Public Discussion
> List
> *Cc:* Corey Bonnell; Christopher Kemmerer
> *Subject:* Re: [EXTERNAL]-Re: [Servercert-wg] SCXX Ballot proposal:
> Debian Weak keys
>
>
>
> Hi, I might be (very) wrong here, but, shouldn’t blocklists be based only
> on the RSA modulus for different key sizes so validation implementations
> match the module only irrespective of whatever the public exponent is? or
> does the affected prime generation random source seed from the public
> exponent too?
>
>
>
> On 22 Oct 2021, at 08:58, Rob Stradling via Servercert-wg <
> servercert-wg at cabforum.org> wrote:
>
>
>
> > ...my opinion is that we should introduce a new requirement such that
> CAs must check for Debian weak keys for all RSA modulus lengths and
> exponents that they accept. CAs are uniquely positioned to prevent the
> usage of these weak keys in the web PKI, so there is a security benefit in
> mandating such universal checks.
>
>
>
> Hi Corey.  Yeah, OK.  You've persuaded me.
>
>
>
> FWIW, my tools at https://github.com/CVE-2008-0166
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__github.com_CVE-2D2008-2D0166%26d%3DDwMGaQ%26c%3DeuGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM%26r%3D-bX5hBm1IdRDykQ-dBR8tsFRCM4v1VXUyG7RZa2WqPY%26m%3DfMDCutmeJbXlHHWIZLMy2UAZB79bm_AVGAAADmUsNAE%26s%3DgZAtYdIgwjZ_F9FpjPlUFmh9SQve9WXOyzZCTDLhsH4%26e%3D&data=05%7C01%7Ckarina.sirota%40microsoft.com%7C94d75ad129bc49ce855a08da1f2c38b0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856574642543179%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=11SI7Pny1qyNvMx34GeEnrGJ5U8t6xo%2BdS6dcIyGREM%3D&reserved=0> only
> support 65537 at the moment.  I guess I'll just have to wait and see if
> anyone asks for other public exponent values to be supported.  🙂
>
>
> ------------------------------
>
> *From:* Corey Bonnell
> *Sent:* Tuesday, October 19, 2021 19:48
> *To:* Rob Stradling; Christopher Kemmerer; CA/B Forum Server Certificate
> WG Public Discussion List
> *Subject:* RE: [Servercert-wg] SCXX Ballot proposal: Debian Weak keys
>
>
>
> Hi Rob,
>
> Comments inline.
>
>
>
> > AFAICT, in the affected Debian OpenSSL versions:
>
>   - "openssl req -newkey" had a hardcoded public exponent of 65537 (see
> https://github.com/openssl/openssl/blob/OpenSSL_0_9_8f/apps/req.c#L768
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__github.com_openssl_openssl_blob_OpenSSL-5F0-5F9-5F8f_apps_req.c-23L768%26d%3DDwMGaQ%26c%3DeuGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM%26r%3D-bX5hBm1IdRDykQ-dBR8tsFRCM4v1VXUyG7RZa2WqPY%26m%3DfMDCutmeJbXlHHWIZLMy2UAZB79bm_AVGAAADmUsNAE%26s%3DVu5UXlPv7euZNJXCO15ReMLK_k5MyC3YaUliVn6DQcU%26e%3D&data=05%7C01%7Ckarina.sirota%40microsoft.com%7C94d75ad129bc49ce855a08da1f2c38b0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856574642543179%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ZjC2zw7GWCs4fcgMZjfl6A7oa7Ws5FgVsgPt9TOIku0%3D&reserved=0>
> ).
>
>   - "openssl genrsa" defaulted to 65537, but provided a "-3" command-line
> option to use a public exponent of 3 instead (see
> https://github.com/openssl/openssl/blob/OpenSSL_0_9_8f/apps/genrsa.c
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__github.com_openssl_openssl_blob_OpenSSL-5F0-5F9-5F8f_apps_genrsa.c%26d%3DDwMGaQ%26c%3DeuGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM%26r%3D-bX5hBm1IdRDykQ-dBR8tsFRCM4v1VXUyG7RZa2WqPY%26m%3DfMDCutmeJbXlHHWIZLMy2UAZB79bm_AVGAAADmUsNAE%26s%3DMXbwubefERoNQfWd4kC0f7rxRrBl5yB1YZ2Y3OmPQoo%26e%3D&data=05%7C01%7Ckarina.sirota%40microsoft.com%7C94d75ad129bc49ce855a08da1f2c38b0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856574642543179%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2BVkZ9MX9YerJS91NzUJl0kIMPEGBbiJ%2FHhHwTRw0Oa4%3D&reserved=0>
> ).
>
>
>
> As you point out, the command-line tooling bundled with OpenSSL 0,9.8
> generally restricted the allowed exponent. However, the RSA key generation
> API allowed any exponent to be specified [1], so it is possible that a
> custom application passed exponent values besides 3 or 65537 to the RSA key
> generation function.
>
>
>
> > Are there any good reasons to continue to permit the public exponent 3 ?
>
>
>
> Judging from Censys, it appears that there are some publicly trusted
> certificates containing RSA keys with an exponent of 3, so there will
> presumably be a (minor) ecosystem impact if an exponent value of 3 were
> banned. That being said, exponents smaller than 65537 are outside the
> SHOULD-level exponent range since BR v1.1.3 (now in section 6.1.6) so
> perhaps it’s time to consider strengthening the SHOULD to a MUST. Probably
> such a change would be outside the scope of this ballot, though.
>
>
>
> > The "openssl-vulnkey" tool that Debian used to ship only provided
> blocklists for keys with public exponents of 65537, so should we take that
> as a sign that CAs needn't perform a Debian weak key check when the public
> exponent is anything other than 65537 ?
>
>
>
> While the precedent set by accepted remediations for incidents surrounding
> Debian weak keys has been for CAs to check the lists distributed in the
> openssl-blacklist Debian package, my opinion is that we should introduce a
> new requirement such that CAs must check for Debian weak keys for all RSA
> modulus lengths and exponents that they accept. CAs are uniquely positioned
> to prevent the usage of these weak keys in the web PKI, so there is a
> security benefit in mandating such universal checks.
>
>
>
> Thanks,
>
> Corey
>
>
>
> [1]
> https://github.com/openssl/openssl/blob/OpenSSL_0_9_8f/crypto/rsa/rsa_gen.c#L78
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__github.com_openssl_openssl_blob_OpenSSL-5F0-5F9-5F8f_crypto_rsa_rsa-5Fgen.c-23L78%26d%3DDwMGaQ%26c%3DeuGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM%26r%3D-bX5hBm1IdRDykQ-dBR8tsFRCM4v1VXUyG7RZa2WqPY%26m%3DfMDCutmeJbXlHHWIZLMy2UAZB79bm_AVGAAADmUsNAE%26s%3DBZt9wGuErHLlj4PgA-Q_BWX-TmBE7NrL_QZcjyFCmLs%26e%3D&data=05%7C01%7Ckarina.sirota%40microsoft.com%7C94d75ad129bc49ce855a08da1f2c38b0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856574642543179%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Oth7ho%2BL68o2w6vXRUdwVrgwbOM29wfmFDqGC7iSmXY%3D&reserved=0>
>
>
>
> *From:* Rob Stradling <rob at sectigo.com>
> *Sent:* Tuesday, October 19, 2021 11:31 AM
> *To:* Christopher Kemmerer <chris at ssl.com>; CA/B Forum Server Certificate
> WG Public Discussion List <servercert-wg at cabforum.org>; Corey Bonnell <
> Corey.Bonnell at digicert.com>
> *Subject:* Re: [Servercert-wg] SCXX Ballot proposal: Debian Weak keys
>
>
>
> Hi Corey.
>
>
>
> AFAICT, in the affected Debian OpenSSL versions:
>
>   - "openssl req -newkey" had a hardcoded public exponent of 65537 (see
> https://github.com/openssl/openssl/blob/OpenSSL_0_9_8f/apps/req.c#L768
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__github.com_openssl_openssl_blob_OpenSSL-5F0-5F9-5F8f_apps_req.c-23L768%26d%3DDwMGaQ%26c%3DeuGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM%26r%3D-bX5hBm1IdRDykQ-dBR8tsFRCM4v1VXUyG7RZa2WqPY%26m%3DfMDCutmeJbXlHHWIZLMy2UAZB79bm_AVGAAADmUsNAE%26s%3DVu5UXlPv7euZNJXCO15ReMLK_k5MyC3YaUliVn6DQcU%26e%3D&data=05%7C01%7Ckarina.sirota%40microsoft.com%7C94d75ad129bc49ce855a08da1f2c38b0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856574642593164%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=T%2FLmr%2FIypBm5ip5cewpVKYgyu3erniREIZEkchQTYjo%3D&reserved=0>
> ).
>
>   - "openssl genrsa" defaulted to 65537, but provided a "-3" command-line
> option to use a public exponent of 3 instead (see
> https://github.com/openssl/openssl/blob/OpenSSL_0_9_8f/apps/genrsa.c
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__github.com_openssl_openssl_blob_OpenSSL-5F0-5F9-5F8f_apps_genrsa.c%26d%3DDwMGaQ%26c%3DeuGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM%26r%3D-bX5hBm1IdRDykQ-dBR8tsFRCM4v1VXUyG7RZa2WqPY%26m%3DfMDCutmeJbXlHHWIZLMy2UAZB79bm_AVGAAADmUsNAE%26s%3DMXbwubefERoNQfWd4kC0f7rxRrBl5yB1YZ2Y3OmPQoo%26e%3D&data=05%7C01%7Ckarina.sirota%40microsoft.com%7C94d75ad129bc49ce855a08da1f2c38b0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856574642593164%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=UuS2bPXQQ5zH5eQtdoP7HMVEcpSVDP7Rjt%2FNItIdygs%3D&reserved=0>
> ).
>
>
>
> Are there any good reasons to continue to permit the public exponent 3 ?
>
>
>
> The "openssl-vulnkey" tool that Debian used to ship only provided
> blocklists for keys with public exponents of 65537, so should we take that
> as a sign that CAs needn't perform a Debian weak key check when the public
> exponent is anything other than 65537 ?
>
>
> ------------------------------
>
> *From:* Servercert-wg <servercert-wg-bounces at cabforum.org> on behalf of
> Corey Bonnell via Servercert-wg <servercert-wg at cabforum.org>
> *Sent:* 19 October 2021 15:31
> *To:* Christopher Kemmerer <chris at ssl.com>; CA/B Forum Server Certificate
> WG Public Discussion List <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.
>
>
>
> Hi Chris,
>
> Apologies for the late reply. I noticed that the current proposed language
> has no guidance regarding RSA exponents. I think it would be useful to
> specify the expectations in this regard (whether the CA must check for weak
> keys for all key lengths and exponent combinations accepted/supported by
> the CA, or if checking weak key lists for only exponents 3 and 65537 is
> sufficient, etc.).
>
>
>
> Thanks,
>
> Corey
>
>
>
> *From:* Servercert-wg <servercert-wg-bounces at cabforum.org> *On Behalf Of *Christopher
> Kemmerer via Servercert-wg
> *Sent:* Friday, October 15, 2021 10:33 AM
> *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
>
>
>
> 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/
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__nam04.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fsecure.sectigo.com-252Fdebian-5Fweak-5Fkeys-252F-26data-3D04-257C01-257Crob-2540sectigo.com-257Ca8c9d97cd4114ebf508708d9930d343d-257C0e9c48946caa465d96604b6968b49fb7-257C0-257C0-257C637702508987811664-257CUnknown-257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0-253D-257C2000-26sdata-3DBknvgeWEnZ4pvV0PZHrsqaYgYgzgs4wad1Y3lmy1FWk-253D-26reserved-3D0%26d%3DDwMGaQ%26c%3DeuGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM%26r%3D-bX5hBm1IdRDykQ-dBR8tsFRCM4v1VXUyG7RZa2WqPY%26m%3DfMDCutmeJbXlHHWIZLMy2UAZB79bm_AVGAAADmUsNAE%26s%3DzzVoaIwOBGmJbK59JUU8ZW6-rpOfDM9LW4-DOaggMQQ%26e%3D&data=05%7C01%7Ckarina.sirota%40microsoft.com%7C94d75ad129bc49ce855a08da1f2c38b0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856574642593164%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=BGMgoeDsxZxjLThXAhw1r9WObqfYZZ8S%2FVVVSyZYUak%3D&reserved=0>.
> 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> <rob at sectigo.com>
> *Sent:* 23 September 2021 19:17
> *To:* Christopher Kemmerer <chris at ssl.com> <chris at ssl.com>; Dimitris
> Zacharopoulos (HARICA) <dzacharo at harica.gr> <dzacharo at harica.gr>; CA/B
> Forum Server Certificate WG Public Discussion List
> <servercert-wg at cabforum.org> <servercert-wg at cabforum.org>; Jacob
> Hoffman-Andrews <jsha at letsencrypt.org> <jsha at letsencrypt.org>; Rob
> Stradling<rob at sectigo.com> <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
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__nam04.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fgithub.com-252FCVE-2D2008-2D0166-26data-3D04-257C01-257Crob-2540sectigo.com-257Ca8c9d97cd4114ebf508708d9930d343d-257C0e9c48946caa465d96604b6968b49fb7-257C0-257C0-257C637702508987811664-257CUnknown-257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0-253D-257C2000-26sdata-3DhEYtpXP81bOYFl0bdDSzbg8zxn7gozJ2bXAzE3ZPLwQ-253D-26reserved-3D0%26d%3DDwMGaQ%26c%3DeuGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM%26r%3D-bX5hBm1IdRDykQ-dBR8tsFRCM4v1VXUyG7RZa2WqPY%26m%3DfMDCutmeJbXlHHWIZLMy2UAZB79bm_AVGAAADmUsNAE%26s%3DCZuzMqYs2tJKnr9PUCkV8xEr-EQLZuEnpygT0nUUNYQ%26e%3D&data=05%7C01%7Ckarina.sirota%40microsoft.com%7C94d75ad129bc49ce855a08da1f2c38b0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856574642593164%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=f4ALHzn5E6dxITiOFVpfX4c%2BUAIfgvp669PPLb6BcLk%3D&reserved=0>
>  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>
> <servercert-wg-bounces at cabforum.org> on behalf of Rob Stradling via
> Servercert-wg <servercert-wg at cabforum.org> <servercert-wg at cabforum.org>
> *Sent:* 13 May 2021 15:42
> *To:* Christopher Kemmerer <chris at ssl.com> <chris at ssl.com>; Dimitris
> Zacharopoulos (HARICA) <dzacharo at harica.gr> <dzacharo at harica.gr>; CA/B
> Forum Server Certificate WG Public Discussion List
> <servercert-wg at cabforum.org> <servercert-wg at cabforum.org>; Jacob
> Hoffman-Andrews <jsha at letsencrypt.org> <jsha at letsencrypt.org>
> *Subject:* Re: [Servercert-wg] SCXX Ballot proposal: Debian Weak keys
>
>
>
> CAUTION: This email originated from outside of the organization. Do not
> click links or open attachments unless you recognize the sender and know
> the content is safe.
>
>
>
> > 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__nam04.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fgithub.com-252FCVE-2D2008-2D0166-26data-3D04-257C01-257Crob-2540sectigo.com-257Ca8c9d97cd4114ebf508708d9930d343d-257C0e9c48946caa465d96604b6968b49fb7-257C0-257C0-257C637702508987821618-257CUnknown-257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0-253D-257C2000-26sdata-3D34YXT3egxh7Xtc5k5gqy8idcbz9cgokAIz7o8Xwbh94-253D-26reserved-3D0%26d%3DDwMGaQ%26c%3DeuGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM%26r%3D-bX5hBm1IdRDykQ-dBR8tsFRCM4v1VXUyG7RZa2WqPY%26m%3DfMDCutmeJbXlHHWIZLMy2UAZB79bm_AVGAAADmUsNAE%26s%3DtaqinDAOLRdSvETy9ob78hR_-KPxttqWcUNY_M86mTY%26e%3D&data=05%7C01%7Ckarina.sirota%40microsoft.com%7C94d75ad129bc49ce855a08da1f2c38b0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856574642593164%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=km7JdYBArwmQ%2FyoEXSjTlTIkrg9qQ17jeGPvmUWimEk%3D&reserved=0>
>  repositories.
>
>
> ------------------------------
>
> *From:* Christopher Kemmerer <chris at ssl.com> <chris at ssl.com>
> *Sent:* 13 May 2021 15:12
> *To:* Rob Stradling <rob at sectigo.com> <rob at sectigo.com>; Dimitris
> Zacharopoulos (HARICA) <dzacharo at harica.gr> <dzacharo at harica.gr>; CA/B
> Forum Server Certificate WG Public Discussion List
> <servercert-wg at cabforum.org> <servercert-wg at cabforum.org>; Jacob
> Hoffman-Andrews <jsha at letsencrypt.org> <jsha at letsencrypt.org>
> *Subject:* Re: [Servercert-wg] SCXX Ballot proposal: Debian Weak keys
>
>
>
> CAUTION: This email originated from outside of the organization. Do not
> click links or open attachments unless you recognize the sender and know
> the content is safe.
>
>
>
> Hello,
>
> We deeply appreciate the useful discussion in this thread regarding this
> issue. We especially applaud the efforts of HARICA and Sectigo to
> independently generate more comprehensive lists of potentially affected
> Debian weak keys. As Rob Stradling observed through his crt.sh research
> (20210107,
> https://gist.github.com/robstradling/a5590b6a13218fe561dcb5d5c67932c5
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__nam04.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fgist.github.com-252Frobstradling-252Fa5590b6a13218fe561dcb5d5c67932c5-26data-3D04-257C01-257Crob-2540sectigo.com-257Ca8c9d97cd4114ebf508708d9930d343d-257C0e9c48946caa465d96604b6968b49fb7-257C0-257C0-257C637702508987821618-257CUnknown-257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0-253D-257C2000-26sdata-3DQXz4cOmARv-252Fg8-252FJF2NNEW2-252BSbjHJu1pv8X6vjLCx7io-253D-26reserved-3D0%26d%3DDwMGaQ%26c%3DeuGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM%26r%3D-bX5hBm1IdRDykQ-dBR8tsFRCM4v1VXUyG7RZa2WqPY%26m%3DfMDCutmeJbXlHHWIZLMy2UAZB79bm_AVGAAADmUsNAE%26s%3DEARvfcpJ6O_cJ0KioLW9U0gNj00u2-_njjGSKcTRtE8%26e%3D&data=05%7C01%7Ckarina.sirota%40microsoft.com%7C94d75ad129bc49ce855a08da1f2c38b0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856574642593164%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2Fw0jtGtNYpy%2Fk%2Ffbu0qq4W75umKZL%2FgihNlJhAaHdhw%3D&reserved=0>)
> of the five most utilized algorithm/key size populations, two are ECC (so
> not impacted by the Debian weak key issue) and three are RSA (2048, 4096,
> and 3072 bit length, in that order).
>
> As of their most recent messages it appears that these two organizations
> have independently generated comprehensive lists identifying all RSA-2048
> and -4096 bit length keys. (We understand RSA-3072 length keys are also
> available.) This offers the possibility that complete lists, if accepted as
> authoritative, could be accessed by the community to help prevent
> exploitation of this vulnerability.
>
> It was also noted (by the representative from Let's Encrypt) that the ROCA
> vulnerability is presently identified through use of a tool supported
> externally. It was suggested that this resource be archived in a manner
> that ensures availability. (Our proposed language points to "
> https://github.com/crocs-muni/
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__nam04.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fgithub.com-252Fcrocs-2Dmuni-252F-26data-3D04-257C01-257Crob-2540sectigo.com-257Ca8c9d97cd4114ebf508708d9930d343d-257C0e9c48946caa465d96604b6968b49fb7-257C0-257C0-257C637702508987831575-257CUnknown-257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0-253D-257C2000-26sdata-3DZQMlATqs-252BM7Vr3aIgjdrH06gaOrkgAPTbMkM4gcSROs-253D-26reserved-3D0%26d%3DDwMGaQ%26c%3DeuGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM%26r%3D-bX5hBm1IdRDykQ-dBR8tsFRCM4v1VXUyG7RZa2WqPY%26m%3DfMDCutmeJbXlHHWIZLMy2UAZB79bm_AVGAAADmUsNAE%26s%3DgoTnhfES-zV16ifNjJ90Y_GUk39wftGwqMJiZKuw5aY%26e%3D&data=05%7C01%7Ckarina.sirota%40microsoft.com%7C94d75ad129bc49ce855a08da1f2c38b0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856574642593164%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=dTFDusV%2FMHpFPIr1eWZ8mREATuC5MnZn%2FJ%2BauJtx21c%3D&reserved=0>roca
> or equivalent.")
>
> We think our present ballot language (reproduced at the end of this
> message) provides appropriately focused guidance to CAs. If available, we'd
> certainly like to also see the HARICA/Sectigo lists (which CAs could use
> for the majority of Debian weak key use cases) captured somewhere in this
> ballot language. We are agnostic as to 1) where exactly these resources
> might be maintained and 2) where this ballot places directions to these
> resources - an annex to the current requirements, a separate CA/BF guidance
> document or within Sections 4.9.1.1/6.1.1.3
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F4.9.1.1%2F6.1.1.3&data=05%7C01%7Ckarina.sirota%40microsoft.com%7C94d75ad129bc49ce855a08da1f2c38b0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856574642593164%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=iT2v17IxPRIKft8oE0gZppeY2GN4QR0sDhkA7ydZGNc%3D&reserved=0>
> .
>
> Our intent is to ensure that 1) clear, accurate guidance on CA
> expectations is provided and 2) any resources assisting CAs in meeting
> these expectations are fully described, publicly available (somewhere) and
> with reliable links provided. The language below, we feel, meets the first
> requirement. We'd appreciate input on how to best meet the second. (Note
> that SSL.com
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttp-3A__ssl.com_%26d%3DDwMGaQ%26c%3DeuGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM%26r%3Dj-4qIhXvNMe9dfS8B8CWq0sSP-IOQRNSRmpjiPXIFZw%26m%3DJnxStoHpP62BM2-15Vtby3qBQbCdQrSyCNPjVNH_IS8%26s%3DSGnteTNpPS1X4ickvt5qbC2WDrpValWXK42R9uvwO04%26e%3D&data=05%7C01%7Ckarina.sirota%40microsoft.com%7C94d75ad129bc49ce855a08da1f2c38b0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856574642593164%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Md402CkKLuMhPQ2vODsG3LBIbFXj2oMfpwswhqW5s7A%3D&reserved=0> would
> be happy to support the community by hosting any of these as publicly
> accessible resources, whether solo or alongside other organizations.)
>
> Chris K
>
> SSL.com
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttp-3A__ssl.com_%26d%3DDwMGaQ%26c%3DeuGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM%26r%3Dj-4qIhXvNMe9dfS8B8CWq0sSP-IOQRNSRmpjiPXIFZw%26m%3DJnxStoHpP62BM2-15Vtby3qBQbCdQrSyCNPjVNH_IS8%26s%3DSGnteTNpPS1X4ickvt5qbC2WDrpValWXK42R9uvwO04%26e%3D&data=05%7C01%7Ckarina.sirota%40microsoft.com%7C94d75ad129bc49ce855a08da1f2c38b0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856574642593164%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Md402CkKLuMhPQ2vODsG3LBIbFXj2oMfpwswhqW5s7A%3D&reserved=0>
>
> =====
>
>
>
> --- 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__nam04.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwiki.debian.org-252FSSLkeys-26data-3D04-257C01-257Crob-2540sectigo.com-257Ca8c9d97cd4114ebf508708d9930d343d-257C0e9c48946caa465d96604b6968b49fb7-257C0-257C0-257C637702508987831575-257CUnknown-257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0-253D-257C2000-26sdata-3DpXeTXYoS8oYMQteThIRSdhISQokGG4nL-252BHSymGxAwPg-253D-26reserved-3D0%26d%3DDwMGaQ%26c%3DeuGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM%26r%3D-bX5hBm1IdRDykQ-dBR8tsFRCM4v1VXUyG7RZa2WqPY%26m%3DfMDCutmeJbXlHHWIZLMy2UAZB79bm_AVGAAADmUsNAE%26s%3DZtytHt-KbbrRxo2oN_oCa2ihhQEPcupL52pOSa3xs9U%26e%3D&data=05%7C01%7Ckarina.sirota%40microsoft.com%7C94d75ad129bc49ce855a08da1f2c38b0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856574642593164%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ez10XaxDaL25e6wSHf48ERSqnbxnd2X4%2FozFwrWaDNA%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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__nam04.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwiki.debian.org-252FSSLkeys-26data-3D04-257C01-257Crob-2540sectigo.com-257Ca8c9d97cd4114ebf508708d9930d343d-257C0e9c48946caa465d96604b6968b49fb7-257C0-257C0-257C637702508987831575-257CUnknown-257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0-253D-257C2000-26sdata-3DpXeTXYoS8oYMQteThIRSdhISQokGG4nL-252BHSymGxAwPg-253D-26reserved-3D0%26d%3DDwMGaQ%26c%3DeuGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM%26r%3D-bX5hBm1IdRDykQ-dBR8tsFRCM4v1VXUyG7RZa2WqPY%26m%3DfMDCutmeJbXlHHWIZLMy2UAZB79bm_AVGAAADmUsNAE%26s%3DZtytHt-KbbrRxo2oN_oCa2ihhQEPcupL52pOSa3xs9U%26e%3D&data=05%7C01%7Ckarina.sirota%40microsoft.com%7C94d75ad129bc49ce855a08da1f2c38b0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856574642643154%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2ByMNXcOE%2FqkZuKvqzEjK18noUoVafR55WJRIDFTieEM%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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__nam04.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fgithub.com-252Fcrocs-2Dmuni-252Froca-26data-3D04-257C01-257Crob-2540sectigo.com-257Ca8c9d97cd4114ebf508708d9930d343d-257C0e9c48946caa465d96604b6968b49fb7-257C0-257C0-257C637702508987841531-257CUnknown-257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0-253D-257C2000-26sdata-3DpVWa4-252Fu9mO6gfEAN2FHOMx83i-252FGSUcG-252BfzyDoHm1xKs-253D-26reserved-3D0%26d%3DDwMGaQ%26c%3DeuGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM%26r%3D-bX5hBm1IdRDykQ-dBR8tsFRCM4v1VXUyG7RZa2WqPY%26m%3DfMDCutmeJbXlHHWIZLMy2UAZB79bm_AVGAAADmUsNAE%26s%3D6j9rei_kmtaqpNr-93i7Jp1C7q5YNaJtJJ2z3Rn5FzE%26e%3D&data=05%7C01%7Ckarina.sirota%40microsoft.com%7C94d75ad129bc49ce855a08da1f2c38b0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856574642643154%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Kpr7zVhhPGCAnGS5lP8HBIQsjTCoIrNohPqdsU1PJlE%3D&reserved=0> or
> equivalent.
>
> b) In the case of Debian weak keys (https://wiki.debian.org/SSLkeys
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__nam04.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwiki.debian.org-252FSSLkeys-26data-3D04-257C01-257Crob-2540sectigo.com-257Ca8c9d97cd4114ebf508708d9930d343d-257C0e9c48946caa465d96604b6968b49fb7-257C0-257C0-257C637702508987841531-257CUnknown-257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0-253D-257C2000-26sdata-3DfJSWwzvoeepBzwSexsg-252FFSKZKusdynxlt-252F1gItUiii0-253D-26reserved-3D0%26d%3DDwMGaQ%26c%3DeuGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM%26r%3D-bX5hBm1IdRDykQ-dBR8tsFRCM4v1VXUyG7RZa2WqPY%26m%3DfMDCutmeJbXlHHWIZLMy2UAZB79bm_AVGAAADmUsNAE%26s%3D7VJmjfUviaQVQ3rIxm7xE-dFcYL1TLUk2yNWY4hFx0U%26e%3D&data=05%7C01%7Ckarina.sirota%40microsoft.com%7C94d75ad129bc49ce855a08da1f2c38b0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856574642643154%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=2ZaTPeUPtigylDIuwYq0zUYAEC4JyGL4hrminV3rQ%2BI%3D&reserved=0>),
> the CA SHALL reject at least keys generated by the flawed OpenSSL version
> with the combination of the following parameters:
>
>
>
> i) Big-endian 32-bit, little-endian 32-bit, and little-endian 64-bit
> architecture;
>
> ii) Process ID of 0 to 32767, inclusive;
>
> iii) All RSA Public Key lengths supported by the CA up to and including
> 4096 bits;
>
> iv) rnd, nornd, and noreadrnd OpenSSL random file state.
>
>
>
> For Debian weak keys not covered above, the CA SHALL take actions to
> minimize the probability of certificate issuance.
>
>
>
> --- Motion Ends ---
>
> On 1/18/2021 3:34 PM, Rob Stradling wrote:
>
> > I'm mid-way through generating the RSA-4096 keys.
>
>
>
> The RSA-4096 private keys and blocklists are now in
> https://github.com/CVE-2008-0166/private_keys
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__nam04.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fgithub.com-252FCVE-2D2008-2D0166-252Fprivate-5Fkeys-26data-3D04-257C01-257Crob-2540sectigo.com-257Ca8c9d97cd4114ebf508708d9930d343d-257C0e9c48946caa465d96604b6968b49fb7-257C0-257C0-257C637702508987851488-257CUnknown-257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0-253D-257C2000-26sdata-3Dt2XnHbMAXRIJHGzz-252BLi4gptSfi957l-252Fkz5fcaUc4PxA-253D-26reserved-3D0%26d%3DDwMGaQ%26c%3DeuGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM%26r%3D-bX5hBm1IdRDykQ-dBR8tsFRCM4v1VXUyG7RZa2WqPY%26m%3DfMDCutmeJbXlHHWIZLMy2UAZB79bm_AVGAAADmUsNAE%26s%3DiSbz-XCr-uFk_7Y8gJ0DA2ii9QYdRcBI5WcrvGeE55Q%26e%3D&data=05%7C01%7Ckarina.sirota%40microsoft.com%7C94d75ad129bc49ce855a08da1f2c38b0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856574642643154%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=qhpx0PdMEhqyXSAWlZ6L3TYZNeHK7Q8N2%2BbRCIo%2B14o%3D&reserved=0>
>  andhttps://github.com/CVE-2008-0166/openssl_blocklists
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__nam04.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fgithub.com-252FCVE-2D2008-2D0166-252Fopenssl-5Fblocklists-26data-3D04-257C01-257Crob-2540sectigo.com-257Ca8c9d97cd4114ebf508708d9930d343d-257C0e9c48946caa465d96604b6968b49fb7-257C0-257C0-257C637702508987851488-257CUnknown-257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0-253D-257C2000-26sdata-3D-252B-252Fmznq3F0GbWZjrE1G08DqSXBOxYTLtIF1l7pLatjoU-253D-26reserved-3D0%26d%3DDwMGaQ%26c%3DeuGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM%26r%3D-bX5hBm1IdRDykQ-dBR8tsFRCM4v1VXUyG%25207RZa2WqPY%26m%3DfMDCutmeJbXlHHWIZLMy2UAZB79bm_AVGAAADmUsNAE%26s%3D-tHYY-qeEG6kULte0FSWXNcttvh6n3BUnjh8PTDXi-c%26e%3D&data=05%7C01%7Ckarina.sirota%40microsoft.com%7C94d75ad129bc49ce855a08da1f2c38b0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856574642643154%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=72z%2B4M4Kl%2BWZ%2B%2FuZXJFSC262CzC9BJf7NKHKd37n%2FUA%3D&reserved=0>
> .
>
>
>
> The RSA-2048 and RSA-4096 private keys in
> https://github.com/HARICA-official/debian-weak-keys
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__nam04.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fgithub.com-252FHARICA-2Dofficial-252Fdebian-2Dweak-2Dkeys-26data-3D04-257C01-257Crob-2540sectigo.com-257Ca8c9d97cd4114ebf508708d9930d343d-257C0e9c48946caa465d96604b6968b49fb7-257C0-257C0-257C637702508987861437-257CUnknown-257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0-253D-257C2000-26sdata-3DFb5kG1Ob413KX19BP-252B37xpIahSiKi2FIZ5NfuZ-252FkuPU-253D-26reserved-3D0%26d%3DDwMGaQ%26c%3DeuGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM%26r%3D-bX5hBm1IdRDykQ-dBR8tsFRCM4v1VXUyG7RZa2WqPY%26m%3DfMDCutmeJbXlHHWIZLMy2UAZB79bm_AVGAAADmUsNAE%26s%3D_lfhBqavAtNpmBCedDWRhR5JY_praNbAngJx0m7i14E%26e%3D&data=05%7C01%7Ckarina.sirota%40microsoft.com%7C94d75ad129bc49ce855a08da1f2c38b0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856574642643154%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2FV%2FOPEwTmARBYx8286yAEtZ0kNXq%2Bqw8vo66EkVNqXo%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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__nam04.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fgithub.com-252FCVE-2D2008-2D0166-252Fprivate-5Fkeys-26data-3D04-257C01-257Crob-2540sectigo.com-257Ca8c9d97cd4114ebf508708d9930d343d-257C0e9c48946caa465d96604b6968b49fb7-257C0-257C0-257C637702508987861437-257CUnknown-257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0-253D-257C2000-26sdata-3DoDDkulWGG70BklQLLMR0GsX-252FRIy20y-252FKtw9gGijGyhE-253D-26reserved-3D0%26d%3DDwMGaQ%26c%3DeuGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM%26r%3D-bX5hBm1IdRDykQ-dBR8tsFRCM4v1VXUyG7RZa2WqPY%26m%3DfMDCutmeJbXlHHWIZLMy2UAZB79bm_AVGAAADmUsNAE%26s%3DyAkqXLZo2IvXlCZvKvbFvweWp1zicZGNjpQ-S6gHQbY%26e%3D&data=05%7C01%7Ckarina.sirota%40microsoft.com%7C94d75ad129bc49ce855a08da1f2c38b0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856574642643154%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=wzRI2fBqwnYt%2FItJ3qX1EnqMruvoyr1Fb1IflYPURsQ%3D&reserved=0>
> .
>
>
> ------------------------------
>
> *From:* Dimitris Zacharopoulos (HARICA) <dzacharo at harica.gr>
> <dzacharo at harica.gr>
> *Sent:* 14 January 2021 18:39
> *To:* Rob Stradling <rob at sectigo.com> <rob at sectigo.com>; CA/B Forum
> Server Certificate WG Public Discussion List <servercert-wg at cabforum.org>
> <servercert-wg at cabforum.org>; Jacob Hoffman-Andrews <jsha at letsencrypt.org>
> <jsha at letsencrypt.org>; Christopher Kemmerer <chris at ssl.com>
> <chris at ssl.com>
> *Subject:* Re: [Servercert-wg] SCXX Ballot proposal: Debian Weak keys
>
>
>
> CAUTION: This email originated from outside of the organization. Do not
> click links or open attachments unless you recognize the sender and know
> the content is safe.
>
>
>
>
>
> On 14/1/2021 12:30 π.μ., Rob Stradling wrote:
>
> Thanks Dmitris.
>
>
>
> So far I've generated the RSA-2048 and RSA-3072 keys using
> https://github.com/CVE-2008-0166/key_generator
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__nam04.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fgithub.com-252FCVE-2D2008-2D0166-252Fkey-5Fgenerator-26data-3D04-257C01-257Crob-2540sectigo.com-257Ca8c9d97cd4114ebf508708d9930d343d-257C0e9c48946caa465d96604b6968b49fb7-257C0-257C0-257C637702508987871399-257CUnknown-257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0-253D-257C2000-26sdata-3D4kKGwenlWGRmGjkIWofWWWnykgyNAgmJj1knMJ9PFz4-253D-26reserved-3D0%26d%3DDwMGaQ%26c%3DeuGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM%26r%3D-bX5hBm1IdRDykQ-dBR8tsFRCM4v1VXUyG7RZa2WqPY%26m%3DfMDCutmeJbXlHHWIZLMy2UAZB79bm_AVGAAADmUsNAE%26s%3DNAsWm8iu6UPJcqogRr7ZHylAINg9o87jFWyCbM_GxlE%26e%3D&data=05%7C01%7Ckarina.sirota%40microsoft.com%7C94d75ad129bc49ce855a08da1f2c38b0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856574642643154%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=qjyWlVO1o%2FrROa3gXqui5d8a9kqQRk22tTx84ZY07%2FM%3D&reserved=0> and
> uploaded them to https://github.com/CVE-2008-0166/private_keys
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__nam04.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fgithub.com-252FCVE-2D2008-2D0166-252Fprivate-5Fkeys-26data-3D04-257C01-257Crob-2540sectigo.com-257Ca8c9d97cd4114ebf508708d9930d343d-257C0e9c48946caa465d96604b6968b49fb7-257C0-257C0-257C637702508987871399-257CUnknown-257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0-253D-257C2000-26sdata-3DDS2Fb707J-252BWD3UlBsOMtUWBl-252B5JkoU3S9twMJn8eSps-253D-26reserved-3D0%26d%3DDwMGaQ%26c%3DeuGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM%26r%3D-bX5hBm1IdRDykQ-dBR8tsFRCM4v1VXUyG7RZa2WqPY%26m%3DfMDCutmeJbXlHHWIZLMy2UAZB79bm_AVGAAADmUsNAE%26s%3DwLahGmkoShePVAd3354Vg-KIUIG_bUnevY1465It5Jk%26e%3D&data=05%7C01%7Ckarina.sirota%40microsoft.com%7C94d75ad129bc49ce855a08da1f2c38b0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856574642643154%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=e3lcjB%2F9ZttUW%2FYPEBXLkBWgFf6RLkePGpRIcTNitFk%3D&reserved=0>,
> and I've generated the corresponding blocklists and uploaded them to
> https://github.com/CVE-2008-0166/openssl_blocklists
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__nam04.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fgithub.com-252FCVE-2D2008-2D0166-252Fopenssl-5Fblocklists-26data-3D04-257C01-257Crob-2540sectigo.com-257Ca8c9d97cd4114ebf508708d9930d343d-257C0e9c48946caa465d96604b6968b49fb7-257C0-257C0-257C637702508987871399-257CUnknown-257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0-253D-257C2000-26sdata-3DJtYLdAD8pwpvivoIfMXAeEjofoK0FqoijWEb4Sc9OV4-253D-26reserved-3D0%26d%3DDwMGaQ%26c%3DeuGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM%26r%3D-bX5hBm1IdRDykQ-dBR8tsFRCM4v1VXUyG7RZa2WqPY%26m%3DfMDCutmeJbXlHHWIZLMy2UAZB79bm_AVGAAADmUsNAE%26s%3DNrxlbUT4xWxoifiZhepNwMg-9wFwdQwvVmKKxNVBuk8%26e%3D&data=05%7C01%7Ckarina.sirota%40microsoft.com%7C94d75ad129bc49ce855a08da1f2c38b0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856574642643154%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=NjtpOmBLveMOTMJiM%2B5tC7elvIFzqDIKW%2FPKl6Si7mY%3D&reserved=0>.
> My RSA-2048 blocklists exactly match the ones from the original Debian
> openssl-blacklist package.
>
> I'm mid-way through generating the RSA-4096 keys.
>
>
>
> Let's compare keys when we're both done.  🙂
>
>
> Certainly :-) the RSA-2048 keys already match the fingerprints from the
> openssl-blacklist Debian package.
>
> We did this work several months ago but never found the time to make it
> publicly available. We managed to break down the big task and run jobs in
> parallel which made things a bit more interesting.
>
> It's nice we did this independently, I guess it increases the accuracy
> level of the resulted keys :)
>
>
> Cheers,
> Dimitris.
>
>
> ------------------------------
>
> *From:* Dimitris Zacharopoulos (HARICA) <dzacharo at harica.gr>
> <dzacharo at harica.gr>
> *Sent:* 13 January 2021 21:49
> *To:* Rob Stradling <rob at sectigo.com> <rob at sectigo.com>; CA/B Forum
> Server Certificate WG Public Discussion List <servercert-wg at cabforum.org>
> <servercert-wg at cabforum.org>; Jacob Hoffman-Andrews <jsha at letsencrypt.org>
> <jsha at letsencrypt.org>; Christopher Kemmerer <chris at ssl.com>
> <chris at ssl.com>
> *Subject:* Re: [Servercert-wg] SCXX Ballot proposal: Debian Weak keys
>
>
>
> CAUTION: This email originated from outside of the organization. Do not
> click links or open attachments unless you recognize the sender and know
> the content is safe.
>
>
>
> Dear friends,
>
> HARICA has generated the weak keys (RSA 2048 and 4096 bit lengths) from
> the vulnerable openssl package. We will generate 3072 bit keys as well and
> add them soon. The methodology is described in the following GitHub repo
> along with the produced keys:
>
>    1. https://github.com/HARICA-official/debian-weak-keys
>    <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__nam04.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fgithub.com-252FHARICA-2Dofficial-252Fdebian-2Dweak-2Dkeys-26data-3D04-257C01-257Crob-2540sectigo.com-257Ca8c9d97cd4114ebf508708d9930d343d-257C0e9c48946caa465d96604b6968b49fb7-257C0-257C0-257C637702508987881346-257CUnknown-257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0-253D-257C2000-26sdata-3D61WsoKxsDa5-252FjBab75Y-252FZG4PbcoE3RVkCWg-252BsfY2Aww-253D-26reserved-3D0%26d%3DDwMGaQ%26c%3DeuGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM%26r%3D-bX5hBm1IdRDykQ-dBR8tsFRCM4v1VXUyG7RZa2WqPY%26m%3DfMDCutmeJbXlHHWIZLMy2UAZB79bm_AVGAAADmUsNAE%26s%3DdWL9G_dD07M3-kQ4faHXjdMzoGF9wF5hEGlN2IrPwiA%26e%3D&data=05%7C01%7Ckarina.sirota%40microsoft.com%7C94d75ad129bc49ce855a08da1f2c38b0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856574642643154%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=wTp7hC4TVyAVCSTNxMHyLDqN%2BKvJkFQCmg%2B6ZTasB3w%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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__nam04.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fgist.github.com-252Frobstradling-252Fa5590b6a13218fe561dcb5d5c67932c5-26data-3D04-257C01-257Crob-2540sectigo.com-257Ca8c9d97cd4114ebf508708d9930d343d-257C0e9c48946caa465d96604b6968b49fb7-257C0-257C0-257C637702508987881346-257CUnknown-257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0-253D-257C2000-26sdata-3D4qveGxYahVQ6FbihVosw69bsGUs7hG1ytgI6YLxqYbY-253D-26reserved-3D0%26d%3DDwMGaQ%26c%3DeuGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM%26r%3D-bX5hBm1IdRDykQ-dBR8tsFRCM4v1VXUyG7RZa2WqPY%26m%3DfMDCutmeJbXlHHWIZLMy2UAZB79bm_AVGAAADmUsNAE%26s%3D0JiuTeERFFPZRGiB5foBRJZ5kJjHk51DCLjQbBVwSxc%26e%3D&data=05%7C01%7Ckarina.sirota%40microsoft.com%7C94d75ad129bc49ce855a08da1f2c38b0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856574642693143%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=zqTIP%2FEEaaEkPpEkebTry5iotrCbskoX36sI2WAkrZY%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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__nam04.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fnvlpubs.nist.gov-252Fnistpubs-252FSpecialPublications-252FNIST.SP.800-2D57pt1r5.pdf-26data-3D04-257C01-257Crob-2540sectigo.com-257Ca8c9d97cd4114ebf508708d9930d343d-257C0e9c48946caa465d96604b6968b49fb7-257C0-257C0-257C637702508987891313-257CUnknown-257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0-253D-257C2000-26sdata-3DrG1bgcAgL7P3RtCaCJ0cZTcYPkcUhTlsR4J6ulGFgso-253D-26reserved-3D0%26d%3DDwMGaQ%26c%3DeuGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM%26r%3D-bX5hBm1IdRDykQ-dBR8tsFRCM4v1VXUyG7RZa2WqPY%26m%3DfMDCutmeJbXlHHWIZLMy2UAZB79bm_AVGAAADmUsNAE%26s%3DzehaaELHzHzxLDM3dCTeAYaSLMufH4svdbHT74RDcq0%26e%3D&data=05%7C01%7Ckarina.sirota%40microsoft.com%7C94d75ad129bc49ce855a08da1f2c38b0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856574642693143%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=0o0Plw5xgK%2BX79E9qnhIhRzI4N1Nieg1wzC1ogUS6as%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.pd
> f
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__nam04.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww.sogis.eu-252Fdocuments-252Fcc-252Fcrypto-252FSOGIS-2DAgreed-2DCryptographic-2DMechanisms-2D1.2.pdf-26data-3D04-257C01-257Crob-2540sectigo.com-257Ca8c9d97cd4114ebf508708d9930d343d-257C0e9c48946caa465d96604b6968b49fb7-257C0-257C0-257C637702508987891313-257CUnknown-257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0-253D-257C2000-26sdata-3DgCbutfTj362g-252BHqbrbYgcpm5etqbhCvUFpp8E2UYinE-253D-26reserved-3D0%26d%3DDwMGaQ%26c%3DeuGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM%26r%3D-bX5hBm1IdRDykQ-dBR8tsFRCM4v1VXUyG7RZa2WqPY%26m%3DfMDCutmeJbXlHHWIZLMy2UAZB79bm_AVGAAADmUsNAE%26s%3D2FZ19CpL6_a-dWd0zh1d-4HiMpn4pWyZ0lsH3f1k140%26e%3D&data=05%7C01%7Ckarina.sirota%40microsoft.com%7C94d75ad129bc49ce855a08da1f2c38b0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856574642693143%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=019WU3DYLHSYoFyljNzRrTE97m41TL%2B%2BP8e7ePlsxJA%3D&reserved=0> permits
> RSA-2048 only until the end of 2025.  It is of course possible that quantum
> computing will render RSA obsolete before Subscribers need to think about
> which larger RSA keysize they want to migrate to; however, it seems prudent
> to also plan for the possibility that RSA will survive and that some other
> RSA keysize(s) might become popular.
>
>
> ------------------------------
>
> *From:* Servercert-wg <servercert-wg-bounces at cabforum.org>
> <servercert-wg-bounces at cabforum.org> on behalf of Rob Stradling via
> Servercert-wg <servercert-wg at cabforum.org> <servercert-wg at cabforum.org>
> *Sent:* 06 January 2021 16:08
> *To:* Jacob Hoffman-Andrews <jsha at letsencrypt.org> <jsha at letsencrypt.org>;
> Christopher Kemmerer <chris at ssl.com> <chris at ssl.com>; CA/B Forum Server
> Certificate WG Public Discussion List <servercert-wg at cabforum.org>
> <servercert-wg at cabforum.org>
> *Subject:* Re: [Servercert-wg] SCXX Ballot proposal: Debian Weak keys
>
>
>
> CAUTION: This email originated from outside of the organization. Do not
> click links or open attachments unless you recognize the sender and know
> the content is safe.
>
>
>
>
> _______________________________________________
>
> Servercert-wg mailing list
>
> Servercert-wg at cabforum.org
>
> https://lists.cabforum.org/mailman/listinfo/servercert-wg <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.cabforum.org%2Fmailman%2Flistinfo%2Fservercert-wg&data=05%7C01%7Ckarina.sirota%40microsoft.com%7C94d75ad129bc49ce855a08da1f2c38b0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856574642693143%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=D82FfVq0lK9ogBytNGrkTC6y6RsOYiQXJ09%2FZB92chU%3D&reserved=0>
>
> _______________________________________________
> Servercert-wg mailing list
> Servercert-wg at cabforum.org
> https://lists.cabforum.org/mailman/listinfo/servercert-wg
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20220502/a71ff960/attachment-0001.html>