Re: [Servercert-wg] Compromised/Weak Keys Ballot Proposal

2024-03-28 Thread Wayne Thayer via Servercert-wg
There was further discussion of this ballot proposal on today's teleconference. It was suggested that rather than omitting any reference to Debian weak keys, the ballot should retain the current language. Unfortunately, the ballot restructures the language in such a way that this is challenging.

Re: [Servercert-wg] [Voting Period Begins]: SC-72 - Delete except to policyQualifiers in EVGs; align with BRs by making them NOT RECOMMENDED

2024-03-28 Thread Tim Hollebeek via Servercert-wg
DigiCert votes YES on SC-72. -Tim From: Servercert-wg On Behalf Of Paul van Brouwershaven via Servercert-wg Sent: Monday, March 25, 2024 8:01 AM To: CA/B Forum Server Certificate WG Public Discussion List Subject: [Servercert-wg] [Voting Period Begins]: SC-72 - Delete except to

Re: [Servercert-wg] [Voting Period Begins]: SC-72 - Delete except to policyQualifiers in EVGs; align with BRs by making them NOT RECOMMENDED

2024-03-28 Thread Scott Rea via Servercert-wg
In case it matters (and for the record, I don’t think referencing a specific thread is/or should be required), but here is our vote again, on the “voting” thread and referencing below the previously sent vote… eMudhra votes "yes" to ballot SC-72  From: Scott Rea

Re: [Servercert-wg] [Voting Period Begins]: SC-72 - Delete except to policyQualifiers in EVGs; align with BRs by making them NOT RECOMMENDED

2024-03-28 Thread Wojciech Trapczyński via Servercert-wg
Certum votes Yes to Ballot SC-72. W dniu 25/03/2024 o 13:00, Paul van Brouwershaven via Servercert-wg pisze: This ballot updates the TLS Extended Validation Guidelines (EVGs) by removing the exceptions to |policyQualifiers|​ in section 9.7, to align them with the Baseline Requirements (BRs).

Re: [Servercert-wg] Compromised/Weak Keys Ballot Proposal

2024-03-28 Thread Mads Egil Henriksveen via Servercert-wg
Hi My main concern has been that CAs are required to include additional controls, including generating possible weak Debian keys for supported key sizes or limit the supported key sizes due to a (more or less) theoretical threat of Debian keys from an OS that presumably should not be in use