[Servercert-wg] Proposed ballot: Minimum expectations regarding weak keys

Wed Sep 16 09:23:10 MST 2020

Hi all,

Following on to what Corey said: using the explicit list of 12 platforms,
many of which are virtually inaccessible today and do not have pre-existing
lists of weak keys generated, seems like a suboptimal way to specify this
behavior.

According to contemporaneous research (
https://www.cs.umd.edu/class/fall2017/cmsc818O/papers/private-keys-public.pdf,
PDF link) the set of weak keys generated by a given platform is completely
determined by
a) endianness (big or little),
b) word size (32 or 64 bits), and
c) the other factors included in the draft above (key size, process id, and
behavior regarding the ~/.rnd file)
In addition, at the time there were no supported 64-bit big-endian
architectures, so only three out of the four possible combinations of
factors (a) and (b) are relevant.

I see that a previous draft of this proposal was phrased in exactly this
way:
> ...Big-endian 32-bit, little-endian 32-bit, and little-endian 64-bit
architecture;...
But I do not see any discussion on that previous thread that would have led
to this change. I have seen a few messages which assert that it is
necessary to enumerate all platforms, rather than enumerating word size and
endianness, but have seen none which provide an explanation for why that is
necessary. What motivated this change?

Thanks,
Aaron

On Fri, Sep 4, 2020 at 11:30 AM Corey Bonnell via Servercert-wg <
servercert-wg at cabforum.org> wrote:

> Hi Chris,
>
> I am curious why the clause on exponents as seen on the previous version
> of the draft (
> https://archive.cabforum.org/pipermail/servercert-wg/2020-May/001954.html)
> was removed, as I believe it is a useful clarification alongside the
> modulus lengths.
>
>
>
> Additionally, for the list of architectures, my understanding is that
> different architectures may yield a separate set of keys (
> https://archive.cabforum.org/pipermail/servercert-wg/2020-April/001846.html)
> due to different word widths/widths of the pid_t type and endianness.
> Several of the architectures listed are moribund, which makes this an
> increasingly challenging requirement for CAs as hardware becomes
> increasingly rare. Given this, it may be desirable to target a few of the
> architectures in common use at the time of the vulnerability and restrict
> to those.
>
>
>
> Thanks,
>
> Corey
>
>
>
> *From:* Servercert-wg <servercert-wg-bounces at cabforum.org> *On Behalf Of *Christopher
> Kemmerer via Servercert-wg
> *Sent:* Thursday, September 3, 2020 10:48 AM
> *To:* Doug Beattie via Servercert-wg <servercert-wg at cabforum.org>
> *Subject:* [Servercert-wg] Proposed ballot: Minimum expectations
> regarding weak keys
>
>
>
> Greetings,
>
> We propose the following amendments to language in the CA/B Forum in
> Baseline Requirements, taking into account the proposed changes from SC35:
> Cleanups and Clarifications (as documented in
> https://github.com/cabforum/documents/pull/208
> <https://scanmail.trustwave.com/?c=4062&d=noLR3_BuS9Qf2sEvxoUDMtcjwAl0vJFtxZwSuiVmgg&s=5&u=https%3a%2f%2fgithub%2ecom%2fcabforum%2fdocuments%2fpull%2f208>).
>
>
> The purpose of this ballot is to set minimum expectations for CAs
> regarding industry-proven methods to generate weak private keys, and more
> specifically to ROCA and Debian weak keys. This topic was discussed in
> m.d.s.p. on several occasions and in various CA public incidents.
>
> Regards,
>
> Chris Kemmerer
> SSL.com
> <http://scanmail.trustwave.com/?c=4062&d=noLR3_BuS9Qf2sEvxoUDMtcjwAl0vJFtxclAunBhgA&s=5&u=http%3a%2f%2fSSL%2ecom>
>
> =====
>
> Proposed ballot language:
>
> 4.9.1.1 Reasons for Revoking a Subscriber Certificate
>
>
> *Replace: *
>
> The CA SHALL revoke a Certificate within 24 hours if one or more of the
> following occurs:
>
> […]
>
> 11. The CA is made aware of a demonstrated or proven method that exposes
> the Subscriber's Private Key to compromise or if there is clear evidence
> that the specific method used to generate the Private Key was flawed.
>
> *With *
>
>
> The CA SHALL revoke a Certificate within 24 hours if one or more of the
> following occurs:
>
> […]
>
> 11. The CA is made aware of a demonstrated or proven method that exposes
> the Subscriber's Private Key to compromise;
>
> 12. There is clear evidence that the specific method used to generate the
> Private Key was flawed; or
>
> 13. The certificate was issued with a weak key (such as a Debian weak key,
> see 6.1.1.3).
>
> ---
>
> 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:
>
> The Key Pair does not meet the requirements set forth in Section 6.1.5
> and/or Section 6.1.6;
>
> There is clear evidence that the specific method used to generate the
> Private Key was flawed;
>
> The CA is aware of a demonstrated or proven method that exposes the
> Applicant's Private Key to compromise;
>
> 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;
>
> 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://scanmail.trustwave.com/?c=4062&d=noLR3_BuS9Qf2sEvxoUDMtcjwAl0vJFtxcwTuiRi0A&s=5&u=https%3a%2f%2fwiki%2edebian%2eorg%2fSSLkeys>).
>
>
> If the Subscriber Certificate will contain an extKeyUsage extension
> containing either the values id-kp-serverAuth [RFC5280] or
> anyExtendedKeyUsage [RFC5280], the CA SHALL NOT generate a Key Pair on
> behalf of a Subscriber, and SHALL NOT accept a certificate request using a
> Key Pair previously generated by the CA.
>
> *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. It has an industry demonstrated weak Private Key, in particular:
>
> (i) In the case of ROCA vulnerability, the CA SHALL reject keys identified
> by the tools available at https://github.com/crocs-muni/roca
> <https://scanmail.trustwave.com/?c=4062&d=noLR3_BuS9Qf2sEvxoUDMtcjwAl0vJFtxZkSvSE73w&s=5&u=https%3a%2f%2fgithub%2ecom%2fcrocs-muni%2froca>
> or equivalent.
>
> (ii) In the case of Debian weak keys (https://wiki.debian.org/SSLkeys
> <https://scanmail.trustwave.com/?c=4062&d=noLR3_BuS9Qf2sEvxoUDMtcjwAl0vJFtxcwTuiRi0A&s=5&u=https%3a%2f%2fwiki%2edebian%2eorg%2fSSLkeys>),
> the CA SHALL reject at least keys generated by the flawed OpenSSL version
> with the following parameters:
>   a. Architectures supported by the flawed Debian distribution (alpha,
> arm, armel, hppa, i386, amd64, ia64, mips, mipsel, powerpc, s390, sparc);
>   b. Process ID of 0 to 32767, inclusive;
>   c. All RSA Public Key lengths supported by the CA up to and including
> 4096 bits;
>   d. 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.
>
> If the Subscriber Certificate will contain an extKeyUsage extension
> containing either the values id-kp-serverAuth [RFC5280] or
> anyExtendedKeyUsage [RFC5280], the CA SHALL NOT generate a Key Pair on
> behalf of a Subscriber, and SHALL NOT accept a certificate request using a
> Key Pair previously generated by the CA.
>
> =====
>
> --
>
> Chris Kemmerer
>
> Manager of Operations
>
> SSL.com <http://scanmail.trustwave.com/?c=4062&d=noLR3_BuS9Qf2sEvxoUDMtcjwAl0vJFtxclAunBhgA&s=5&u=http%3a%2f%2fSSL%2ecom>
>
>
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> ~~~~~ To find the reefs, look~~~~~~~~
>
> ~~~~     for the wrecks.    ~~~~~~~~~
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> _______________________________________________
> 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/20200916/c5db5cfd/attachment.html>