[Servercert-wg] SC-59 Weak Key Guidance

[Tom Zermeno]

Purpose of Ballot SC-059 V3 

Several events within the community have led to concerns that the Baseline
Requirements for the Issuance and Management of Publicly-Trusted
Certificates (BRs) lacked a specificity required to properly guide CAs on
matters dealing with the identification and processing of digital
certificates based on private keys considered weak, or easy to ascertain.
In the hopes that elaboration and clarity on the subject would be beneficial
to the community, we are presenting updates to §4.9.1.1(“Reasons for
Revoking a Subscriber Certificate) and §6.1.1.3 (Subscriber Key Pair
Generation) of the BRs. 

The first update is to §4.9.1.1 and is made to expand the scope of easily
computable Private Keys from “Debian weak keys” to “those listed in section
6.1.1.3(5)”.  While the initial language in the BRs did not exclude other
concerns, the use of a single example could be interpreted to mean that
other easily computable Private Keys are few and far between.  The next
update was to §6.1.1.3(5), wherein we added specific actions to be taken for
ROCA vulnerability, Debian weak keys - both RSA and ECDSA – and Close Primes
vulnerability.  We also added a link to suggested tools to be used for
checking weak keys. Finally, an implementation date of December 1, 2023 was
added to allow CAs time to update processes to meet the requirements.  

The following motion has been proposed by Thomas Zermeno of SSL.com and
endorsed by Ben Wilson of Mozilla and Martijn Katerbarg of Sectigo. 

--Motion Begins— 

This ballot is intended to clarify CA responsibilities regarding weak key
vulnerabilities, including specific guidance for Debian weak key, ROCA and
Close Primes attack vulnerabilities, and modifies the “Baseline Requirements
for the Issuance and Management of Publicly-Trusted Certificates” as
follows, based on Version 2.0.0.  
 
Notes: Upon beginning discussion for SC-59, the then-current version of the
BRs was 1.8.4; since that time several ballots have been approved, leading
to the increment of the version to 1.8.7 and eventually 2.0.0, which is the
latest approved version of the BRs.  The changes introduced in SC-59 do not
conflict with any of the recent ballots. As observed with other ballots in
the past, minor administrative updates must be made to the proposed ballot
text before publication such that the appropriate Version # and Change
History are accurately represented (e.g., to indicate these changes will be
represented in Version 2.0.1). 

  

MODIFY the Baseline Requirements as specified in the following Redline:
<https://github.com/cabforum/servercert/compare/a0360b61e73476959220dc328e3b
68d0224fa0b3...SSLcom:servercert:3b0c6de32595d02fbd96762cda98cdc88addef00>
https://github.com/cabforum/servercert/compare/a0360b61e73476959220dc328e3b6
8d0224fa0b3...SSLcom:servercert:3b0c6de32595d02fbd96762cda98cdc88addef00 

  

--Motion Ends— 

This ballot proposes a Final Maintenance Guideline. The procedure for
approval of this ballot is as follows: 

Discussion (11+ days) • Start time: 2023-05-25 19:00:00 UTC • End time:
2023-06-08 18:59:00 UTC 
Vote for approval (7 days) • Start time: TBD • End time: TBD 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20230525/65d30f33/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6868 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20230525/65d30f33/attachment.p7s>