[Servercert-wg] SC-59 Weak Key Guidance

[Dimitris Zacharopoulos (HARICA)]

Tom,

Considering that most CAs already /should /be checking for Debian weak 
keys, September 15 2023 might not be such a big challenge but I will 
also wait for other Members to comment on the proposed March 15, 2024 
effective date.


Thanks,
Dimitris.



On 26/5/2023 5:37 μ.μ., Tom Zermeno wrote:
>
> Hello Dimitris,
>
> Thank you for the input.  We feel that September 15^th does not 
> provide enough time for CAs to implement these changes, but we are not 
> against the March 15, ^2024 effective date, if there is consensus from 
> the Community.
>
> Thank you,
>
> Tom
>
> SSL.com
>
> *From:*Servercert-wg <servercert-wg-bounces at cabforum.org> *On Behalf 
> Of *Dimitris Zacharopoulos (HARICA) via Servercert-wg
> *Sent:* Friday, May 26, 2023 1:54 AM
> *To:* servercert-wg at cabforum.org
> *Subject:* Re: [Servercert-wg] SC-59 Weak Key Guidance
>
>
> Hi Tom,
>
> Historically, the SCWG has been trying to avoid effective dates during 
> January or December. I recommend using September 15, 2023 or March 15, 
> 2024 as possible effective dates. These two dates seem to be more 
> favorable 
> <https://docs.google.com/presentation/d/1oTGVYqggQpQMR4Lktbu_L6DhuBVJzeuiFGd9EAU1zsE> 
> than others.
>
>
> Thanks,
> Dimitris.
>
> On 25/5/2023 10:51 μ.μ., Tom Zermeno via Servercert-wg wrote:
>
>     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/a0360b61e73476959220dc328e3b68d0224fa0b3...SSLcom:servercert:3b0c6de32595d02fbd96762cda98cdc88addef00
>     <https://github.com/cabforum/servercert/compare/a0360b61e73476959220dc328e3b68d0224fa0b3...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
>
>
>
>     _______________________________________________
>
>     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/20230526/42529ecb/attachment.html>