[Servercert-wg] Updating BR 6.1.1.3

[Christopher Kemmerer]

We would like to open discussion on strengthening the following language 
in the Baseline Requirements Section 6.1.1.3. Subscriber Key Pair 
Generation.

It would appear that the language of this section is more or less the 
same as that adopted in Version 1.0 of the BRs (adopted on 22 November 
2011 with an Effective Date of 1 July 2012):

"9.5 Subscriber Public Key
The CA SHALL reject a certificate request if the requested Public Key 
does not meet the requirements set forth in
Appendix A or if it has a known weak Private Key (such as a Debian weak 
key, see http://wiki.debian.org/SSLkeys)."

There seems to be variation among CAs in implementing checks against 
collections of known weak keys. The result has been periodic issuance of 
certificates using weak private keys [1][2][3][4].

It has come to our attention that the existing language is vague enough 
to be subject to multiple interpretations, leading to instances wherein 
a CA may be technically in compliance with the stated requirement but 
may still issue a certificate using a weak Private Key.

All CAs MUST consult blacklists, but if these blacklists are incomplete 
then this will remain an exploitable attack surface.

We would like to recommend a possible update to section 6.1.1.3:

CHANGE:
"The CA SHALL reject a certificate request if the requested Public Key 
does not meet the requirements set forth in Sections 6.1.5 and 6.1.6 or 
if it has a known weak Private Key (such as a Debian weak key, see 
http://wiki.debian.org/SSLkeys)"

TO:
"The CA SHALL reject a certificate request if the requested Public Key 
does not meet the requirements set forth in Sections 6.1.5 and 6.1.6 or 
if it has a known weak Private Key (such as a Debian weak key, see 
http://wiki.debian.org/SSLkeys)". The minimum set for the Debian weak 
keys can be found at 
https://sources.debian.org/data/main/o/openssl-blacklist/0.5-3/."

This would clarify that all CAs SHALL block at least the vulnerable keys 
produced by OpenSSL.

Thank you.

Chris Kemmerer
SSL.com
---------------------------------------

[1] 
https://community.letsencrypt.org/t/2017-09-09-late-weak-key-revocation/42519 
(please direct me to the corresponding bug, if any)
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1620772
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=1435770
[4] https://bugzilla.mozilla.org/show_bug.cgi?id=1472052

=======================================
See also related BR section:

4.9.1.1 Reasons for Revoking a Subscriber Certificate
"The CA SHOULD revoke a certificate within 24 hours and MUST revoke a 
Certificate within 5 days if one or
more of the following occurs:

<snip>

11. The CA is made aware of a demonstrated or proven method that exposes 
the Subscriber's Private Key
to compromise, methods have been developed that can easily calculate it 
based on the Public Key
(such as a Debian weak key, see http://wiki.debian.org/SSLkeys), or if 
there is clear evidence that the
specific method used to generate the Private Key was flawed."
=======================================

-- 
Chris Kemmerer
Manager of Operations
SSL.com

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~ To find the reefs, look ~~~~~~~
~~~~     for the wrecks.    ~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~