[Servercert-wg] SC-59 Weak Key Guidance

Martijn Katerbarg martijn.katerbarg at sectigo.com
Fri May 26 17:29:19 UTC 2023

> But that’s not that bad and we could do that instead if people think November 15 and January 15 are unlikely to be used in practice.

I would also think that if a ballot were to propose such a date, any of those people could object during the official process.

From: Servercert-wg <servercert-wg-bounces at cabforum.org> on behalf of Tim Hollebeek via Servercert-wg <servercert-wg at cabforum.org>
Sent: Friday, May 26, 2023 6:31:47 pm
To: Clint Wilson <clintw at apple.com>
Cc: ServerCert CA/BF <servercert-wg at cabforum.org>
Subject: Re: [Servercert-wg] SC-59 Weak Key Guidance

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

The advantage of odd months is it includes November 15 and January 15, which give you two dates that are about as close to the winter holidays as possible, but not too close.  The disadvantage is that some people seem to think those dates are still a bit too close, and want to avoid November, December, and January entirely.

Even months sans December 15 does perhaps give you five usable dates, but the winter holiday gap is longer (October 15 to February 15).  But that’s not that bad and we could do that instead if people think November 15 and January 15 are unlikely to be used in practice.


From: Clint Wilson <clintw at apple.com>
Sent: Friday, May 26, 2023 12:25 PM
To: Tim Hollebeek <tim.hollebeek at digicert.com>
Cc: ServerCert CA/BF <servercert-wg at cabforum.org>; Tom Zermeno <tom at ssl.com>
Subject: Re: [Servercert-wg] SC-59 Weak Key Guidance

Yeah I’m not sure precisely why my preference switched from odd to even months, but I think it was based on a comment at some point that people wanted to avoid November as well as December (due to holiday shutdown-type things), which perhaps I extrapolated out further than the comment intended… regardless, even or odd months I could go either way. But limiting to two dates per year is more than a step too far in my mind.


On May 26, 2023, at 9:19 AM, Tim Hollebeek <tim.hollebeek at digicert.com<mailto:tim.hollebeek at digicert.com>> wrote:

There have been a couple people discussing a limit of two per year, but those people are going beyond what I’ve been trying to get people to do, which as a reminder, is the 15th day of odd months.  Easy to remember, and misses most major holidays.  Clint appears to have a different parity preference from my original proposal 😊  I don’t really care, as long as we have 6 instead of 366 possibilities.  By having a date available every other month, no deadline ever has to move more than about 30 days to find an acceptable date, and there are very few cases where 30 days difference in effective date actually matters in practice.


From: Servercert-wg <servercert-wg-bounces at cabforum.org<mailto:servercert-wg-bounces at cabforum.org>> On Behalf Of Clint Wilson via Servercert-wg
Sent: Friday, May 26, 2023 11:45 AM
To: Tom Zermeno <tom at ssl.com<mailto:tom at ssl.com>>; ServerCert CA/BF <servercert-wg at cabforum.org<mailto:servercert-wg at cabforum.org>>
Subject: Re: [Servercert-wg] SC-59 Weak Key Guidance

Hi Tom, Dimitris,

I continue to be opposed to the SCWG trying to limit effective dates to 2 per year. I think it’s entirely reasonable to align on a day of the month (I think the 15th has broadly been the only one I’ve heard proposed). I think it’s reasonable to try to avoid January and December. I also think there may be value in trying to reduce the overall number of effective dates somewhat. The dates I’m personally in favor of aligning on are February, April, June, August, and October 15th.

If there’s a particular penchant towards March and September, however, then I’d be unopposed to March, May, July, September, and November 15th.

For this ballot in particular, I think October 15 or November 15 2023 are feasible targets for implementing these changes and would greatly prefer closing this issue (open now for more than 3 years) sooner than later, especially given the number of incidents we’ve seen in the last years related to weak key vulnerabilities and CAs issuing certificates with weak keys.


On May 26, 2023, at 7:37 AM, Tom Zermeno via Servercert-wg <servercert-wg at cabforum.org<mailto:servercert-wg at cabforum.org>> wrote:

Hello Dimitris,

Thank you for the input.  We feel that September 15th 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,


From: Servercert-wg <servercert-wg-bounces at cabforum.org<mailto: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<mailto: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://url.avanan.click/v2/___https:/docs.google.com/presentation/d/1oTGVYqggQpQMR4Lktbu_L6DhuBVJzeuiFGd9EAU1zsE___.YXAzOmRpZ2ljZXJ0OmE6bzozMmEwZjBiOWE3OGI4Mzg1M2JmYTg0MzJmNmQxNWU0Nzo2OjNhZDU6ZGYwZmJlNGYyMzU2OGZhMzM5MTRiNDliNDM5OWVjMTk5ZTNjNGZmODhhZDA1MjRkYzZkZmY4MzMxZjZiNjkwZjpoOkY> than others.

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 §“Reasons for Revoking a Subscriber Certificate) and § (Subscriber Key Pair Generation) of the BRs.

The first update is to § and is made to expand the scope of easily computable Private Keys from “Debian weak keys” to “those listed in section”.  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 §, 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<https://url.avanan.click/v2/___http:/ssl.com/___.YXAzOmRpZ2ljZXJ0OmE6bzozMmEwZjBiOWE3OGI4Mzg1M2JmYTg0MzJmNmQxNWU0Nzo2OmFiNzE6MDc5MWRkN2IwNzFjY2Q1N2JkZDJlZDg4ZmViNTI4OTA0ZDRkOGRiNjA2NzYzNmQ3MmZlYjgzNzk3YmQ2OGNlMDpoOkY> 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://url.avanan.click/v2/___https:/github.com/cabforum/servercert/compare/a0360b61e73476959220dc328e3b68d0224fa0b3...SSLcom:servercert:3b0c6de32595d02fbd96762cda98cdc88addef00___.YXAzOmRpZ2ljZXJ0OmE6bzozMmEwZjBiOWE3OGI4Mzg1M2JmYTg0MzJmNmQxNWU0Nzo2OjliZGQ6NjZkMTllYjUxZjYzMzZlMDZlOTUyMGQzNWU3NmFhMWYxOTNhYzg4ZGMyYWRlZWE5NGE3NWZlYTk3MTkzNjZhYzpoOkY>

--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<mailto:Servercert-wg at cabforum.org>


Servercert-wg mailing list
Servercert-wg at cabforum.org<mailto:Servercert-wg at cabforum.org>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20230526/21f2273f/attachment-0001.html>

More information about the Servercert-wg mailing list