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

[Tom Zermeno via Servercert-wg]

Wayne,

 

I think it's safest to err on the side of caution and use the explicit wording 
that you proposed.

 

Thanks,

 

Tom

 

From: Wayne Thayer  
Sent: Friday, February 23, 2024 2:45 PM
To: Tom Zermeno 
Cc: CA/B Forum Server Certificate WG Public Discussion List 
; Martijn Katerbarg 
Subject: Re: [Servercert-wg] Compromised/Weak Keys Ballot Proposal

 


You don't often get email from wtha...@gmail.com  . 
Learn why this is important  



Tom,

 

I had originally placed the Debian exception in the sublist of 6.1.1.3(5), but 
Aaron Gable correctly pointed out that it doesn't make sense there because that 
sublist is prefaced with the statement "the following precautions SHALL be 
implemented:" I think it would be logically difficult to interpret the 
exception as belonging with 6.1.1.3(5)(ii) Close Primes, but I do agree that it 
could be clearer. To that end, I've change the indentation of the exception 
sentence in https://github.com/wthayer/servercert/pull/1/files Does that help? 
I could also change the wording to "Debian weak keys 
(https://wiki.debian.org/SSLkeys) are exempt from the requirements of Section 
6.1.1.3(5).

 

Thanks,

 

Wayne

 

On Fri, Feb 23, 2024 at 10:33 AM Tom Zermeno mailto:t...@ssl.com> > wrote:

Wayne,

Regarding the change of the Debian weak keys statement at proposed line 1701: 
is the statement intended to be a sub-clause of the second item in the sublist, 
which would then make Debian weak keys exempt from the Fermat factorization 
method check?  Or, more likely based on the recent discussion, was the 
statement meant to be a third item in the list, which would then exempt Debian 
weak keys from the 5th condition of the list requiring CAs to reject 
certificate requests?

 

My question stems from the abnormal line spacing and indention of the 
statement, which stands out from the surrounding text.

 

Thanks, 

 

Tom

 

From: Servercert-wg mailto:servercert-wg-boun...@cabforum.org> > On Behalf Of Wayne Thayer via 
Servercert-wg
Sent: Friday, February 23, 2024 11:18 AM
To: Martijn Katerbarg mailto:martijn.katerb...@sectigo.com> >
Cc: CA/B Forum Server Certificate WG Public Discussion List 
mailto:servercert-wg@cabforum.org> >
Subject: Re: [Servercert-wg] Compromised/Weak Keys Ballot Proposal

 

Martijn,

 

I would summarize the reasoning for removing the Debian requirements as follows:

- CAs would prefer the greater clarity that would be provided by the weak keys 
ballot that failed last year.

- However, some CAs were of the opinion that the prior ballot imposed more 
explicit requirements for Debian weak key checking rather than just clarifying 
existing requirements. The "new" requirements were viewed as burdensome.

- The Debian vulnerability is more than 15 years old. If an Applicant submits a 
Debian weak key at this point, they almost certainly have bigger security 
issues.

- So the cost of these requirements outweighs the benefits at this point in 
time.

 

I included a few links to the discussion during the prior balot's voting 
period, and there was also discussion at the last SCWG teleconference that 
should be captured in the minutes.

 

Thanks,

 

Wayne

 

On Fri, Feb 23, 2024 at 2:19 AM Martijn Katerbarg 
mailto:martijn.katerb...@sectigo.com> > wrote:

Wayne, 

Apologies if I’ve missed something in discussions, but why exactly are we 
removing the Debian Weak Keys language, and even explicitly mentioned that CAs 
do not need to check for them (anymore)?


Regards,

Martijn

 

From: Servercert-wg mailto:servercert-wg-boun...@cabforum.org> > on behalf of Wayne Thayer via 
Servercert-wg mailto:servercert-wg@cabforum.org> >
Date: Thursday, 22 February 2024 at 20:01
To: CA/B Forum Server Certificate WG Public Discussion List 
mailto:servercert-wg@cabforum.org> >
Subject: Re: [Servercert-wg] Compromised/Weak Keys Ballot Proposal

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.

 

I am seeking a second endorser for this proposal. Below is a draft of the 
ballot language.

 

Thanks,

 

Wayne



**Ballot SC-XX: Compromised / Weak Keys**

This ballot updates BR section 6.1.1.3 to address two issues:

First, the requirements placed on CAs to reject a certificate request if they 
have been “made aware” that the key pair is compromised is vague and open-ended 
in regard to how CAs may be “made aware”. This ballot specifies that CAs be 
“made aware” via their problem reporting mechanism.

Second, this ballot reintroduces the language from [failed] ballot SC-59: Weak 
Key Guidance. However, based on feedback received during the discussion and 
voting period for that ballot, Debian weak key checks are now explicitly out of 
scope.

This ballot is proposed by Wayne Thayer (Fastly) and endorsed by Brittany 
Randall (

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

[Wayne Thayer via Servercert-wg]

Tom,

I had originally placed the Debian exception in the sublist of 6.1.1.3(5),
but Aaron Gable correctly pointed out that it doesn't make sense there
because that sublist is prefaced with the statement "the following
precautions SHALL be implemented:" I think it would be logically difficult
to interpret the exception as belonging with 6.1.1.3(5)(ii) Close Primes,
but I do agree that it could be clearer. To that end, I've change the
indentation of the exception sentence in
https://github.com/wthayer/servercert/pull/1/files Does that help? I could
also change the wording to "Debian weak keys (
https://wiki.debian.org/SSLkeys) are exempt from the requirements of
Section 6.1.1.3(5).

Thanks,

Wayne

On Fri, Feb 23, 2024 at 10:33 AM Tom Zermeno  wrote:

> Wayne,
>
> Regarding the change of the Debian weak keys statement at proposed line
> 1701: is the statement intended to be a sub-clause of the second item in
> the sublist, which would then make Debian weak keys exempt from the Fermat
> factorization method check?  Or, more likely based on the recent
> discussion, was the statement meant to be a third item in the list, which
> would then exempt Debian weak keys from the 5th condition of the list
> requiring CAs to reject certificate requests?
>
>
>
> My question stems from the abnormal line spacing and indention of the
> statement, which stands out from the surrounding text.
>
>
>
> Thanks,
>
>
>
> Tom
>
>
>
> *From:* Servercert-wg  *On Behalf Of 
> *Wayne
> Thayer via Servercert-wg
> *Sent:* Friday, February 23, 2024 11:18 AM
> *To:* Martijn Katerbarg 
> *Cc:* CA/B Forum Server Certificate WG Public Discussion List <
> servercert-wg@cabforum.org>
> *Subject:* Re: [Servercert-wg] Compromised/Weak Keys Ballot Proposal
>
>
>
> Martijn,
>
>
>
> I would summarize the reasoning for removing the Debian requirements as
> follows:
>
> - CAs would prefer the greater clarity that would be provided by the weak
> keys ballot that failed last year.
>
> - However, some CAs were of the opinion that the prior ballot imposed more
> explicit requirements for Debian weak key checking rather than just
> clarifying existing requirements. The "new" requirements were viewed as
> burdensome.
>
> - The Debian vulnerability is more than 15 years old. If an Applicant
> submits a Debian weak key at this point, they almost certainly have bigger
> security issues.
>
> - So the cost of these requirements outweighs the benefits at this point
> in time.
>
>
>
> I included a few links to the discussion during the prior balot's voting
> period, and there was also discussion at the last SCWG teleconference that
> should be captured in the minutes.
>
>
>
> Thanks,
>
>
>
> Wayne
>
>
>
> On Fri, Feb 23, 2024 at 2:19 AM Martijn Katerbarg <
> martijn.katerb...@sectigo.com> wrote:
>
> Wayne,
>
> Apologies if I’ve missed something in discussions, but why exactly are we
> removing the Debian Weak Keys language, and even explicitly mentioned that
> CAs do not need to check for them (anymore)?
>
>
> Regards,
>
> Martijn
>
>
>
> *From: *Servercert-wg  on behalf of
> Wayne Thayer via Servercert-wg 
> *Date: *Thursday, 22 February 2024 at 20:01
> *To: *CA/B Forum Server Certificate WG Public Discussion List <
> servercert-wg@cabforum.org>
> *Subject: *Re: [Servercert-wg] Compromised/Weak Keys Ballot Proposal
>
> 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.
>
>
>
> I am seeking a second endorser for this proposal. Below is a draft of the
> ballot language.
>
>
>
> Thanks,
>
>
>
> Wayne
>
> 
>
> **Ballot SC-XX: Compromised / Weak Keys**
>
> This ballot updates BR section 6.1.1.3 to address two issues:
>
> First, the requirements placed on CAs to reject a certificate request if
> they have been “made aware” that the key pair is compromised is vague and
> open-ended in regard to how CAs may be “made aware”. This ballot specifies
> that CAs be “made aware” via their problem reporting mechanism.
>
> Second, this ballot reintroduces the language from [failed] ballot SC-59:
> Weak Key Guidance. However, based on feedback received during the
> discussion and voting period for that ballot, Debian weak key checks are
> now explicitly out of scope.
>
> This ballot is proposed by Wayne Thayer (Fastly) and endorsed by Brittany
> Randall (GoDaddy) and . You can view and comment on the
> github pull request representing this ballot here:
> https://github.com/wthayer/servercert/pull/1/files
>
> The preceding discussions can be seen here:
>
> * This ballot:
> https://lists.cabforum.org/pipermail/servercert-wg/2024-February/004195.html
> * The prior weak keys ballot:
> https://lists.cabforum.org/pipermail/servercert-wg/2023-July/003820.html
> and
> https://lists.cabforum.org/pipermail/servercert-wg/2023-July/003857.html
> * The “made aware” language in 6.1.1.3:
> https://lists.cabforum.org/pipermail/servercert-wg/2023-Ju

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

[Tom Zermeno via Servercert-wg]

Wayne,

Regarding the change of the Debian weak keys statement at proposed line 1701: 
is the statement intended to be a sub-clause of the second item in the sublist, 
which would then make Debian weak keys exempt from the Fermat factorization 
method check?  Or, more likely based on the recent discussion, was the 
statement meant to be a third item in the list, which would then exempt Debian 
weak keys from the 5th condition of the list requiring CAs to reject 
certificate requests?

 

My question stems from the abnormal line spacing and indention of the 
statement, which stands out from the surrounding text.

 

Thanks, 

 

Tom

 

From: Servercert-wg  On Behalf Of Wayne 
Thayer via Servercert-wg
Sent: Friday, February 23, 2024 11:18 AM
To: Martijn Katerbarg 
Cc: CA/B Forum Server Certificate WG Public Discussion List 

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

 

Martijn,

 

I would summarize the reasoning for removing the Debian requirements as follows:

- CAs would prefer the greater clarity that would be provided by the weak keys 
ballot that failed last year.

- However, some CAs were of the opinion that the prior ballot imposed more 
explicit requirements for Debian weak key checking rather than just clarifying 
existing requirements. The "new" requirements were viewed as burdensome.

- The Debian vulnerability is more than 15 years old. If an Applicant submits a 
Debian weak key at this point, they almost certainly have bigger security 
issues.

- So the cost of these requirements outweighs the benefits at this point in 
time.

 

I included a few links to the discussion during the prior balot's voting 
period, and there was also discussion at the last SCWG teleconference that 
should be captured in the minutes.

 

Thanks,

 

Wayne

 

On Fri, Feb 23, 2024 at 2:19 AM Martijn Katerbarg 
mailto:martijn.katerb...@sectigo.com> > wrote:

Wayne, 

Apologies if I’ve missed something in discussions, but why exactly are we 
removing the Debian Weak Keys language, and even explicitly mentioned that CAs 
do not need to check for them (anymore)?


Regards,

Martijn

 

From: Servercert-wg mailto:servercert-wg-boun...@cabforum.org> > on behalf of Wayne Thayer via 
Servercert-wg mailto:servercert-wg@cabforum.org> >
Date: Thursday, 22 February 2024 at 20:01
To: CA/B Forum Server Certificate WG Public Discussion List 
mailto:servercert-wg@cabforum.org> >
Subject: Re: [Servercert-wg] Compromised/Weak Keys Ballot Proposal

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.

 

I am seeking a second endorser for this proposal. Below is a draft of the 
ballot language.

 

Thanks,

 

Wayne



**Ballot SC-XX: Compromised / Weak Keys**

This ballot updates BR section 6.1.1.3 to address two issues:

First, the requirements placed on CAs to reject a certificate request if they 
have been “made aware” that the key pair is compromised is vague and open-ended 
in regard to how CAs may be “made aware”. This ballot specifies that CAs be 
“made aware” via their problem reporting mechanism.

Second, this ballot reintroduces the language from [failed] ballot SC-59: Weak 
Key Guidance. However, based on feedback received during the discussion and 
voting period for that ballot, Debian weak key checks are now explicitly out of 
scope.

This ballot is proposed by Wayne Thayer (Fastly) and endorsed by Brittany 
Randall (GoDaddy) and . You can view and comment on the github 
pull request representing this ballot here: 
https://github.com/wthayer/servercert/pull/1/files 

The preceding discussions can be seen here:

* This ballot: 
https://lists.cabforum.org/pipermail/servercert-wg/2024-February/004195.html 
* The prior weak keys ballot: 
https://lists.cabforum.org/pipermail/servercert-wg/2023-July/003820.html and 
https://lists.cabforum.org/pipermail/servercert-wg/2023-July/003857.html
* The “made aware” language in 6.1.1.3  :  
https://lists.cabforum.org/pipermail/servercert-wg/2023-July/003902.html


--- Motion Begins ---

This ballot modifies the "Baseline Requirements for the Issuance and Management 
of Publicly-Trusted Certificates" ("Baseline Requirements") based on Version 
2.X.X

MODIFY the Baseline Requirements as specified in the following redline: 


--- Motion Ends ---

Discussion (at least 7 days):

- Start: TBD UTC
- End: TBD UTC

Vote for approval (7 days):

- Start: TBD UTC
- End: TBD UTC

 

On Mon, Feb 12, 2024 at 6:12 PM Wayne Thayer via Servercert-wg 
mailto:servercert-wg@cabforum.org> > wrote:

Thank you fo the feedback Aaron. I agree with both points you made in the PR 
and have updated it to reflect your suggestions.

 

- Wayne

 

On Mon, Feb 12, 2024 at 12:27 PM Aaron Gable mailto:aa...@letsencrypt.org> > wrote:

Thank you Wayne! I think this gets close to the sweet spot for me, personally. 
I've left two small co

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

[Wayne Thayer via Servercert-wg]

Martijn,

I would summarize the reasoning for removing the Debian requirements as
follows:
- CAs would prefer the greater clarity that would be provided by the weak
keys ballot that failed last year.
- However, some CAs were of the opinion that the prior ballot imposed more
explicit requirements for Debian weak key checking rather than just
clarifying existing requirements. The "new" requirements were viewed as
burdensome.
- The Debian vulnerability is more than 15 years old. If an Applicant
submits a Debian weak key at this point, they almost certainly have bigger
security issues.
- So the cost of these requirements outweighs the benefits at this point in
time.

I included a few links to the discussion during the prior balot's voting
period, and there was also discussion at the last SCWG teleconference that
should be captured in the minutes.

Thanks,

Wayne

On Fri, Feb 23, 2024 at 2:19 AM Martijn Katerbarg <
martijn.katerb...@sectigo.com> wrote:

> Wayne,
>
> Apologies if I’ve missed something in discussions, but why exactly are we
> removing the Debian Weak Keys language, and even explicitly mentioned that
> CAs do not need to check for them (anymore)?
>
>
> Regards,
>
> Martijn
>
>
>
> *From: *Servercert-wg  on behalf of
> Wayne Thayer via Servercert-wg 
> *Date: *Thursday, 22 February 2024 at 20:01
> *To: *CA/B Forum Server Certificate WG Public Discussion List <
> servercert-wg@cabforum.org>
> *Subject: *Re: [Servercert-wg] Compromised/Weak Keys Ballot Proposal
>
> 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.
>
>
>
> I am seeking a second endorser for this proposal. Below is a draft of the
> ballot language.
>
>
>
> Thanks,
>
>
>
> Wayne
>
> 
>
> **Ballot SC-XX: Compromised / Weak Keys**
>
> This ballot updates BR section 6.1.1.3 to address two issues:
>
> First, the requirements placed on CAs to reject a certificate request if
> they have been “made aware” that the key pair is compromised is vague and
> open-ended in regard to how CAs may be “made aware”. This ballot specifies
> that CAs be “made aware” via their problem reporting mechanism.
>
> Second, this ballot reintroduces the language from [failed] ballot SC-59:
> Weak Key Guidance. However, based on feedback received during the
> discussion and voting period for that ballot, Debian weak key checks are
> now explicitly out of scope.
>
> This ballot is proposed by Wayne Thayer (Fastly) and endorsed by Brittany
> Randall (GoDaddy) and . You can view and comment on the
> github pull request representing this ballot here:
> https://github.com/wthayer/servercert/pull/1/files
> 
>
> The preceding discussions can be seen here:
>
> * This ballot:
> https://lists.cabforum.org/pipermail/servercert-wg/2024-February/004195.html
> 
> * The prior weak keys ballot:
> https://lists.cabforum.org/pipermail/servercert-wg/2023-July/003820.html
> 
> and
> https://lists.cabforum.org/pipermail/servercert-wg/2023-July/003857.html
> 
> * The “made aware” language in 6.1.1.3
> 

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

[Martijn Katerbarg via Servercert-wg]

Wayne, 

Apologies if I’ve missed something in discussions, but why exactly are we 
removing the Debian Weak Keys language, and even explicitly mentioned that CAs 
do not need to check for them (anymore)? 

Regards,

Martijn 

From: Servercert-wg  on behalf of Wayne 
Thayer via Servercert-wg 
Date: Thursday, 22 February 2024 at 20:01
To: CA/B Forum Server Certificate WG Public Discussion List 

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

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. 


I am seeking a second endorser for this proposal. Below is a draft of the 
ballot language. 



Thanks, 



Wayne 

 

**Ballot SC-XX: Compromised / Weak Keys**

This ballot updates BR section 6.1.1.3 to address two issues:

First, the requirements placed on CAs to reject a certificate request if they 
have been “made aware” that the key pair is compromised is vague and open-ended 
in regard to how CAs may be “made aware”. This ballot specifies that CAs be 
“made aware” via their problem reporting mechanism.

Second, this ballot reintroduces the language from [failed] ballot SC-59: Weak 
Key Guidance. However, based on feedback received during the discussion and 
voting period for that ballot, Debian weak key checks are now explicitly out of 
scope.

This ballot is proposed by Wayne Thayer (Fastly) and endorsed by Brittany 
Randall (GoDaddy) and . You can view and comment on the github 
pull request representing this ballot here: 
https://github.com/wthayer/servercert/pull/1/files 

 

The preceding discussions can be seen here:

* This ballot: 
https://lists.cabforum.org/pipermail/servercert-wg/2024-February/004195.html 

 
* The prior weak keys ballot: 
https://lists.cabforum.org/pipermail/servercert-wg/2023-July/003820.html 

 and https://lists.cabforum.org/pipermail/servercert-wg/2023-July/003857.html 

* The “made aware” language in 6.1.1.3 
:
 https://lists.cabforum.org/pipermail/servercert-wg/2023-July/003902.html 



--- Motion Begins ---

This ballot modifies the "Baseline Requirements for the Issuance and Management 
of Publicly-Trusted Certificates" ("Baseline Requirements") based on Version 
2.X.X

MODIFY the Baseline Requirements as

[Servercert-wg] Results of the Ballot SC-70: Clarify the use of DTPs for Domain Control Validation v2

[Inigo Barreira via Servercert-wg]

 

Hi

 

This is version 2 of the results including the vote from SwissSign.

 

The voting period for SC70 (Clarify the use of DTPs for Domain Control
Validation) has completed, and the ballot has passed.

 

Voting Results

Certificate Issuers

28 votes total, with no abstentions:

*   28 Issuers voting YES: Actalis, Buypass, Certum (Asseco), CFCA,
Chunghwa Telecom, CommScope, D-TRUST, DigiCert, Disig, eMudhra, Entrust,
Fastly, GDCA, GlobalSign, GoDaddy, HARICA, iTrusChina, Izenpe, JPRS, Kamu
SM, Let's Encrypt / ISRG, OISTE, SECOM, Sectigo, SSL.com, SwissSign,Telia
Company, Viking Cloud
*   0 Issuers voting NO
*   0 Issuers ABSTAIN

Certificate Consumers

4 votes total, with no abstentions:

*   4 Consumers voting YES: Apple, Google, Mozilla, Opera
*   0 Consumers voting NO
*   0 Consumers ABSTAIN

Bylaws Requirements

1.  Bylaw 2.3(6) requires:

*   In order for a ballot to be adopted by the Forum, two‐thirds (2/3)
or more of the votes cast by the Voting Members in the Certificate Issuer
category must be in favour of the ballot. This requirement was MET.
*   at least fifty percent (50%) plus one (1) of the votes cast by the
Voting Members in the Certificate Consumer category must be in favour of the
ballot. This requirement was MET.
*   At least one (1) Voting Member in each category must vote in favour
of a ballot for the ballot to be adopted. This requirement was MET.

2.  Bylaw 2.3(7) requires:

*   A ballot result will be considered valid only when more than half of
the number of currently active Voting Members has participated. The number
of currently active Voting Members is the average number of Voting Member
organizations that have participated in the previous three (3) Forum
Meetings and Forum Teleconferences.

*   the quorum was 15 for this ballot. This requirement was MET.

This ballot now enters the IP Rights Review Period to permit members to
review the ballot for relevant IP rights issues. This will be notified in a
separate email.

 

Regards

 

 



smime.p7s
Description: S/MIME cryptographic signature
___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg

Re: [Servercert-wg] [Voting Period Begins]: SC-69v2 Clarify router and firewall logging requirements

[Martijn Katerbarg via Servercert-wg]

Drat! 

Thank you Clint for spotting this. I will recall this voting period and restart 
a discussion period shortly 

From: Clint Wilson 
Date: Thursday, 22 February 2024 at 21:09
To: Martijn Katerbarg , ServerCert CA/BF 

Subject: Re: [Servercert-wg] [Voting Period Begins]: SC-69v2 Clarify router and 
firewall logging requirements 

Hi Martijn, 


This is a nit, but is there an extra quotation mark in line 1556? Sorry for not 
spotting this earlier :( 



Thanks! 

-Clint 



On Feb 22, 2024, at 11:50 AM, Martijn Katerbarg via Servercert-wg 
 wrote: 


Summary: 
This ballot aims to clarify what data needs to be logged as part of the 
"Firewall and router activities" logging requirement in the Baseline 
Requirements. 
This ballot is proposed by Martijn Katerbarg (Sectigo) and endorsed by Daniel 
Jeffery (Fastly) and Ben Wilson (Mozilla). 
--- Motion Begins --- 
This ballot modifies the “Baseline Requirements for the Issuance and Management 
of Publicly-Trusted Certificates" ("Baseline Requirements"), based on Version 
2.0.2. 
MODIFY the Baseline Requirements as specified in the following Redline: 
https://github.com/cabforum/servercert/compare/41f01640748fa612386f8b1a3031cd1bff3d4f35...08dcb7c244113cc370c15b725f031d18687a074f
 https://github.com/cabforum/servercert/compare/41f01640748fa612386f8b1a3031cd1bff3d4f35...08dcb7c244113cc370c15b725f031d18687a074f

Click
 to follow link.> 
--- Motion Ends --- 
This ballot proposes a Final Maintenance Guideline. The procedure for approval 
of this ballot is as follows: 
Discussion (at least 7 days) 

1. Start time: 2024-02-15 11:35:00 UTC 
2. End time: 2024-02-22 19:50:00 UTC 
Vote for approval (7 days) 

1. Start time: 2024-02-22 19:50:00 UTC 
2. End time: 2024-02-29 19:50:00 UTC 


___
Servercert-wg mailing list
Servercert-wg@cabforum.org 
https://lists.cabforum.org/mailman/listinfo/servercert-wg 
 









smime.p7s
Description: S/MIME cryptographic signature
___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg