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

[Ryan Sleevi]

Tim,

While in principle, I agree that it would be extremely unfortunate, I don't
see the same gap as you. That is, it seems like that's an issue already
controlled for with respect to key generation and protection requirements.
Could you more concretely describe (perhaps using past issues, i.e. those
that CAs would be looking for) a scenario that would make it through the
existing controls?

As you note, the fact that these are not Subscriber keys is extremely
relevant: the CA has controls (for self-generated) and assurances (for 3P
CA generated, via audit reports and the requirements) on key generation
that don't apply to Subscriber certs. As such, I'm having trouble seeing
the same risk, and if there is any (from Roots or Sub CAs), it seems like
we can and should tackle that through the ceremonies/generation time,
rather than at signing time. So I don't support tweaking this for ICAs, now
or in the future, but am open to understanding more about the problems you
see, so we can look for a more systemic fix, if the existing controls
aren't sufficient.

On Thu, Sep 3, 2020 at 12:33 PM Tim Hollebeek via Servercert-wg <
servercert-wg at cabforum.org> wrote:

> One of the things we’ve noticed before is the fact that these requirements
> are in the section for Subscriber keys, therefore there are no weak key
> check requirements for roots and ICAs.
>
>
>
> We think that’s worth fixing.  If CAs have to implement these checks for
> subscriber certificates, it should be pretty straightforward to run these
> checks when creating ICAs as well.
>
>
>
> The requirements for ICAs may need some tweaking, since there are some
> substantial differences in use cases, but I wanted to find out if there is
> any interest from others on fixing this loophole as well, either in this
> ballot or another one.
>
>
>
> It would be extremely unfortunate if a certification authority issued an
> ICA with a key that is known to be compromised, for example.
>
>
>
> -Tim
>
>
>
> *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).
>
> 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
>
> =====
>
> 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).
>
> 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 or
> equivalent.
>
> (ii) In the case of Debian weak keys (https://wiki.debian.org/SSLkeys),
> the CA SHALL reject at least keys generated by the flawed OpenSSL version
> with the 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
>
>
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> ~~~~~ 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/20200903/f1eff904/attachment.html>