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

Thu Sep 3 09:55:38 MST 2020

I think that's unnecessarily hostile, to suggest I'm shutting down
discussion by asking questions and sharing opinions, and I hope we can be
better than that.

When modelling the threat of ROCA, I fail to see how such a threat is
possible, given our existing requirements. Rather than providing a
point-by-point takedown of some implicit argument you haven't made, and in
the hopes I'm misunderstanding something in your argument, I simply asked
you to provide more details about how you see the gap. Which, again, I ask
you to do: Can you be concrete about how you see something like that
complying with our existing requirements.

On Thu, Sep 3, 2020 at 12:48 PM Tim Hollebeek <tim.hollebeek at digicert.com>
wrote:

> I think the ROCA vulnerability shows pretty clearly that even generation
> by secure hardware can have its issues, so I think it’s premature to
> attempt to shut down the discussion by pointing to all the pomp and
> ceremony around ICA generation.
>
>
>
> -Tim
>
>
>
> *From:* Ryan Sleevi <sleevi at google.com>
> *Sent:* Thursday, September 3, 2020 12:45 PM
> *To:* Tim Hollebeek <tim.hollebeek at digicert.com>; CA/B Forum Server
> Certificate WG Public Discussion List <servercert-wg at cabforum.org>
> *Cc:* Christopher Kemmerer <chris at ssl.com>
> *Subject:* Re: [Servercert-wg] Proposed ballot: Minimum expectations
> regarding weak keys
>
>
>
> 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/451438f9/attachment.html>