from:"Entschew, Enrico via Servercert\-wg"

Re: [Servercert-wg] Voting Period Begins - Ballot SC-067 V3: "Require domain validation and CAA checks to be performed from multiple Network Perspectives"

2024-07-22 Thread Entschew, Enrico via Servercert-wg

D-Trust votes „YES“ on Ballot SC-067 V3.

 

Thanks,

Enrico

 

Von: Servercert-wg  Im Auftrag von Chris 
Clements via Servercert-wg
Gesendet: Monday, July 15, 2024 5:30 PM
An: CA/B Forum Server Certificate WG Public Discussion List 

Betreff: [Servercert-wg] Voting Period Begins - Ballot SC-067 V3: "Require 
domain validation and CAA checks to be performed from multiple Network 
Perspectives"

 

Purpose of Ballot SC-067 V3:

 

This Ballot proposes updates to the Baseline Requirements for the Issuance and 
Management of Publicly-Trusted TLS Server Certificates (i.e., TLS BRs) related 
to “Multi-Perspective Issuance Corroboration” (“MPIC”).

 

Background:

 

- MPIC refers to performing domain validation and CAA checks from multiple 
Network Perspectives before certificate issuance, as described within the 
Ballot for the applicable validation methods in TLS BR Sections 3.2.2.4 and 
3.2.2.5.

- Not all methods described in TLS BR Sections 3.2.2.4 and 3.2.2.5 will require 
using MPIC.

- This work was most recently motivated by research presented at Face-to-Face 
58 [1] by Princeton University, but has been discussed for years prior as well.

- The goal of this proposal is to make it more difficult for adversaries to 
successfully launch equally-specific prefix attacks against the domain 
validation processes described in the TLS BRs.

- Additional background information can be found in an update shared at 
Face-to-Face 60 [2].

 

Benefits of Adoption:

 

- Recent publicly-documented attacks have used BGP hijacks to fool domain 
control validation and obtain malicious certificates, which led to the 
impersonation of HTTPS websites [3][4].

- Routing security defenses (e.g., RPKI) can mitigate the risk of global BGP 
attacks, but localized, equally-specific BGP attacks still pose a significant 
threat to the Web PKI [5][6].

- Corroborating domain control validation checks from multiple network 
perspectives (i.e., MPIC) spread across the Internet substantially reduces the 
threat posed by equally-specific BGP attacks, ensuring the integrity of domain 
validation and issuance decisions [5][7][8].

- Existing deployments of MPIC at the scale of millions of certificates a day 
demonstrate the feasibility of this technique at Internet scale [7][9].

 

Intellectual Property (IP) Disclosure:

 

- While not a Server Certificate Working Group Member, researchers from 
Princeton University presented at Face-to-Face 58, provided academic expertise, 
and highlighted publicly-available peer-reviewed research to support Members in 
drafting this ballot.

- The Princeton University researchers indicate that they have not filed for 
any patents relating to their MPIC work and do not plan to do so in the future.

- Princeton University has indicated that it is unable to agree to the 
CA/Browser Forum IPR agreement because it could encumber inventions invented by 
researchers not involved in the development of MPIC or with the CA/B Forum.

- Princeton University has instead provided the attached IPR statement. 
Pursuant to the IPR statement, Princeton University has granted a worldwide 
royalty free license to the intellectual property in MPIC developed by the 
researchers and has made representations regarding its lack of knowledge of any 
other Princeton intellectual property needed to implement MPIC.

- The attached IPR statement has not changed since disclosed in Discussion 
Round 1.

- For clarity, Princeton University’s IPR statement is NOT intended to replace 
the Forum’s IPR agreement or allow Princeton to participate in the Forum in any 
capacity.

- Members seeking legal advice regarding this ballot should consult their own 
counsel.

 

Proposal Revision History:

 

- Pre-Ballot Release #1 (work team artifacts and broader Validation 
Subcommittee collaboration) [10]

- Pre-Ballot Release #2 [11]

 

Previous versions of this Ballot:

 

- Ballot Release #1 [12] (comparing Version 2 to Version 1) [13]. Note, some of 
the changes represented in the comparison are updates made by other ballots 
that have since passed (e.g., SC-069).

- Ballot Release #2 [14] (comparing Version 3 to Version 2) [15]. Note, some of 
the changes represented in the comparison are updates made by other ballots 
that have since passed (e.g., SC-072).

 

References:

[1]  

 
https://cabforum.org/wp-content/uploads/13-CAB-Forum-face-to-face-multiple-vantage-points.pdf

[2]  

 
https://drive.google.com/file/d/1LTwtAwHXcSaPVSsqKQztNJrV2ozHJ7ZL/view?usp=drive_link
 

[3]  

 
https://medium.com/s2wblog/post-mortem-of-klayswap-incident-through-bgp-hijacking-en-3ed7e33de600
 

[4]   
https://www.coi

Re: [Servercert-wg] [Voting Begins] Ballot SC-75 v3 - Pre-sign linting

2024-06-24 Thread Entschew, Enrico via Servercert-wg

D-Trust votes „YES“ on SC-75 v3.

 

Thanks, 

Enrico

 

Von: Servercert-wg  Im Auftrag von Dimitris 
Zacharopoulos (HARICA) via Servercert-wg
Gesendet: Wednesday, June 19, 2024 12:13 PM
An: CA/B Forum Server Certificate WG Public Discussion List 

Betreff: [Servercert-wg] [Voting Begins] Ballot SC-75 v3 - Pre-sign linting

 

Voting begins for this ballot.


SC-75 v3 Pre-sign linting


Summary


There have been numerous compliance incidents publicly disclosed by CAs in 
which they failed to comply with the technical requirements described in 
standards associated with the issuance and management of publicly-trusted TLS 
Certificates. However, the industry has developed open-source tools, linters, 
that are free to use and can help CAs avoid certificate misissuance. Using such 
linters before issuing a precertificate from a Publicly-Trusted CA 
(pre-issuance linting) can prevent the mis-issuance in a wide variety of cases.

The following motion has been proposed by Dimitris Zacharopoulos of HARICA and 
endorsed by Corey Bonnell of Digicert and Ben Wilson of Mozilla.

You can view the GitHub pull request representing this ballot here 
 . 


Motion Begins


MODIFY the "Baseline Requirements for the Issuance and Management of 
Publicly-Trusted TLS Server Certificates" based on Version 2.0.5 as specified 
in the following redline:

*   
https://github.com/cabforum/servercert/compare/20af1b271f2b689344ae353d3e78dc6b772199db...d809c41bc063109e15d46bfe1b5ad6403d823381
 


Motion Ends


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


Discussion (at least 7 days)


*   Start time: 2024-06-12 06:30:00 UTC
*   End time: on or after 2024-06-19 06:30:00 UTC


Vote for approval (7 days)


*   Start time: 2024-06-19 10:00:00 UTC
*   End time: 2024-06-26 10:00:00 UTC

 

--- Begin Message ---
D-Trust votes „YES“ on SC-75 v3.

 

Thanks, 

Enrico

 

Von: Servercert-wg  Im Auftrag von Dimitris 
Zacharopoulos (HARICA) via Servercert-wg
Gesendet: Wednesday, June 19, 2024 12:13 PM
An: CA/B Forum Server Certificate WG Public Discussion List 

Betreff: [Servercert-wg] [Voting Begins] Ballot SC-75 v3 - Pre-sign linting

 

Voting begins for this ballot.


SC-75 v3 Pre-sign linting


Summary


There have been numerous compliance incidents publicly disclosed by CAs in 
which they failed to comply with the technical requirements described in 
standards associated with the issuance and management of publicly-trusted TLS 
Certificates. However, the industry has developed open-source tools, linters, 
that are free to use and can help CAs avoid certificate misissuance. Using such 
linters before issuing a precertificate from a Publicly-Trusted CA 
(pre-issuance linting) can prevent the mis-issuance in a wide variety of cases.

The following motion has been proposed by Dimitris Zacharopoulos of HARICA and 
endorsed by Corey Bonnell of Digicert and Ben Wilson of Mozilla.

You can view the GitHub pull request representing this ballot here 
 . 


Motion Begins


MODIFY the "Baseline Requirements for the Issuance and Management of 
Publicly-Trusted TLS Server Certificates" based on Version 2.0.5 as specified 
in the following redline:

*   
https://github.com/cabforum/servercert/compare/20af1b271f2b689344ae353d3e78dc6b772199db...d809c41bc063109e15d46bfe1b5ad6403d823381
 


Motion Ends


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


Discussion (at least 7 days)


*   Start time: 2024-06-12 06:30:00 UTC
*   End time: on or after 2024-06-19 06:30:00 UTC


Vote for approval (7 days)


*   Start time: 2024-06-19 10:00:00 UTC
*   End time: 2024-06-26 10:00:00 UTC

 



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

Re: [Servercert-wg] Voting Period Begins - Ballot SC-073: Compromised and Weak Keys

2024-05-02 Thread Entschew, Enrico via Servercert-wg

D-Trust votes „YES“ on SC-073.

 

Thanks,

Enrico

 

Von: Servercert-wg  Im Auftrag von Wayne 
Thayer via Servercert-wg
Gesendet: Friday, April 26, 2024 2:00 AM
An: CA/B Forum Server Certificate WG Public Discussion List 

Betreff: [Servercert-wg] Voting Period Begins - Ballot SC-073: Compromised and 
Weak Keys

 

Purpose of Ballot SC-073

This ballot proposes updates to the Baseline Requirements for the Issuance and 
Management of Publicly-Trusted TLS Server Certificates related to weak and 
compromised private keys. These changes lie primarily in Section 6.1.1.3 
 :

·   6.1.1.3(4) clarifies that, for the purpose of this requirement, CAs 
shall be made aware of compromised keys using their existing notification 
mechanism(s).

·   6.1.1.3(5) improves guidance for CAs around the detection of weak keys. 
Should this ballot pass, these changes become effective on November 15, 2024.

Notes:

·   This ballot builds on the extensive work done by SSL.com in creating 
ballot SC-59v2 Weak Key Guidance. SSL.com’s contributions are appreciated.

·   Thanks to Rob Stradling of Sectigo for the generation and publication 
of the set of Debian weak keys referenced in this ballot.

·   The Debian weak keys requirements have been discussed extensively, 
including in the following threads:  
 
https://lists.cabforum.org/pipermail/servercert-wg/2024-March/004291.html and  
 
https://lists.cabforum.org/pipermail/servercert-wg/2024-April/004422.html 

·   This ballot does not appear to conflict with any other ballots that are 
currently under discussion.

 

The following motion has been proposed by Wayne Thayer of Fastly, and endorsed 
by Brittany Randall of GoDaddy and Bruce Morton of Entrust.

— Motion Begins —

This ballot modifies the “Baseline Requirements for the Issuance and Management 
of Publicly-Trusted Certificates” (“Baseline Requirements”), based on Version 
2.0.3.

MODIFY the Baseline Requirements for the Issuance and Management of 
Publicly-Trusted TLS Server Certificates as specified in the following Redline:

Here is a link to the immutable GitHub redline:  

 
https://github.com/cabforum/servercert/compare/a65402cff89affe1fc0a1f0e49807c7e42e1608a...bee10c8e4a56815bffd59fab12cbd4044baa7cc0
 

— Motion Ends —

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

Discussion (7+ days)

·   Start time: 2024-04-18 00:00:00 UTC

·   End time: 2024-04-26 00:00:00 UTC

Vote for approval (7 days)

·   Start time: 2024-04-26 00:00:00 UTC

*   End time: 2024-05-03 00:00:00 UTC

--- Begin Message ---
D-Trust votes „YES“ on SC-073.

 

Thanks,

Enrico

 

Von: Servercert-wg  Im Auftrag von Wayne 
Thayer via Servercert-wg
Gesendet: Friday, April 26, 2024 2:00 AM
An: CA/B Forum Server Certificate WG Public Discussion List 

Betreff: [Servercert-wg] Voting Period Begins - Ballot SC-073: Compromised and 
Weak Keys

 

Purpose of Ballot SC-073

This ballot proposes updates to the Baseline Requirements for the Issuance and 
Management of Publicly-Trusted TLS Server Certificates related to weak and 
compromised private keys. These changes lie primarily in Section 6.1.1.3 
 :

·   6.1.1.3(4) clarifies that, for the purpose of this requirement, CAs 
shall be made aware of compromised keys using their existing notification 
mechanism(s).

·   6.1.1.3(5) improves guidance for CAs around the detection of weak keys. 
Should this ballot pass, these changes become effective on November 15, 2024.

Notes:

·   This ballot builds on the extensive work done by SSL.com in creating 
ballot SC-59v2 Weak Key Guidance. SSL.com’s contributions are appreciated.

·   Thanks to Rob Stradling of Sectigo for the generation and publication 
of the set of Debian weak keys referenced in this ballot.

·   The Debian weak keys requirements have been discussed extensively, 
including in the following threads:  
 
https://lists.cabforum.org/pipermail/servercert-wg/2024-March/004291.html and  
 
https://lists.cabforum.org/pipermail/servercert-wg/2024-April/004422.html 

·   This ballot does not appear to conflict with any other ballots that are 
currently under discussion.

 

The following motion has been proposed by Wayne Thayer of Fastly, and endorsed 
by Brittany Randall of GoDaddy and Bruce Morton of Entrust.

— Motion Begins —

This ballot modifies the “Baseline Requirements for the Issuance and Management 
of Publicly-Trusted Certificates” (“Baseline Requirements”), based

Re: [Servercert-wg] [Voting Period Begins]: SC65: Convert EVGs into RFC 3647 format v2

2024-03-11 Thread Entschew, Enrico via Servercert-wg

D-Trust votes YES on Ballot SC65.

 

Thanks,

Enrico

 

Von: Servercert-wg  Im Auftrag von Inigo
Barreira via Servercert-wg
Gesendet: Monday, March 4, 2024 4:34 PM
An: CA/B Forum Server Certificate WG Public Discussion List

Betreff: [Servercert-wg] [Voting Period Begins]: SC65: Convert EVGs into RFC
3647 format v2

 

Summary: 

The Extended Validation Certificates guidelines (EVGs) were developed and
written in a specific format. Since then, the RFC 3647 has been the basis
(and the de-facto standard) for the CA/Browser Forum to develop other
documents.

This ballot aims to update the EVGs to follow the RFC 3647 format without
changing any content, just moving current sections to those defined in the
RFC 3647. There are no normative requirements changes.

This change also affects the Baseline Requirements for TSL certificates
(BRs) which needs to point to the new sections of the EVGs. Both documents
will be updated according to the latest version published.

This ballot is proposed by Iñigo Barreira (Sectigo) and endorsed by Pedro
Fuentes (OISTE) and Ben Wilson (Mozilla).

--- Motion Begins ---

This ballot modifies the Baseline Requirements for the Issuance and
Management of Publicly-Trusted TLS Certificates" ("TLS Baseline
Requirements"), based on Version 2.0.2 and the Guidelines for the Issuance
and Management of Extended Validation Certificates (EVGs) based on Version
1.8.0. 

MODIFY the TLS EVGs and BRs as specified in the following Redline:

Comparing
90a98dc7c1131eaab01af411968aa7330d315b9b...dedeebfe036fa5a6f0d7ae985ea08317b
a60b8cb · cabforum/servercert (github.com)

--- Motion Ends ---

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

Discussion (at least 7 days)

1.   Start time: 2024-02-20 17:00:00 UTC

2.   End time: not before 2024-03-04 15:00:00 UTC

Vote for approval (7 days)

1.   Start time: 2024-03-04 15:30:00 UTC

2.   End time: 2024-03-11 15:30:00 UTC

 

--- Begin Message ---
D-Trust votes YES on Ballot SC65.

 

Thanks,

Enrico

 

Von: Servercert-wg  Im Auftrag von Inigo
Barreira via Servercert-wg
Gesendet: Monday, March 4, 2024 4:34 PM
An: CA/B Forum Server Certificate WG Public Discussion List

Betreff: [Servercert-wg] [Voting Period Begins]: SC65: Convert EVGs into RFC
3647 format v2

 

Summary: 

The Extended Validation Certificates guidelines (EVGs) were developed and
written in a specific format. Since then, the RFC 3647 has been the basis
(and the de-facto standard) for the CA/Browser Forum to develop other
documents.

This ballot aims to update the EVGs to follow the RFC 3647 format without
changing any content, just moving current sections to those defined in the
RFC 3647. There are no normative requirements changes.

This change also affects the Baseline Requirements for TSL certificates
(BRs) which needs to point to the new sections of the EVGs. Both documents
will be updated according to the latest version published.

This ballot is proposed by Iñigo Barreira (Sectigo) and endorsed by Pedro
Fuentes (OISTE) and Ben Wilson (Mozilla).

--- Motion Begins ---

This ballot modifies the Baseline Requirements for the Issuance and
Management of Publicly-Trusted TLS Certificates" ("TLS Baseline
Requirements"), based on Version 2.0.2 and the Guidelines for the Issuance
and Management of Extended Validation Certificates (EVGs) based on Version
1.8.0. 

MODIFY the TLS EVGs and BRs as specified in the following Redline:

Comparing
90a98dc7c1131eaab01af411968aa7330d315b9b...dedeebfe036fa5a6f0d7ae985ea08317b
a60b8cb · cabforum/servercert (github.com)

--- Motion Ends ---

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

Discussion (at least 7 days)

1.   Start time: 2024-02-20 17:00:00 UTC

2.   End time: not before 2024-03-04 15:00:00 UTC

Vote for approval (7 days)

1.   Start time: 2024-03-04 15:30:00 UTC

2.   End time: 2024-03-11 15:30:00 UTC

 



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

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

2024-03-11 Thread Entschew, Enrico via Servercert-wg

D-Trust votes YES on Ballot SC-69v3.

 

Thanks,

Enrico

 

Von: Servercert-wg  Im Auftrag von Martijn 
Katerbarg via Servercert-wg
Gesendet: Monday, March 4, 2024 11:59 AM
An: CA/B Forum Server Certificate WG Public Discussion List 

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

 

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...d5bd141e14de098ff00c10de7cf500668cbc6843

--- 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-26 07:00:00 UTC

2.   End time: 2024-03-04 11:00:00 UTC

Vote for approval (7 days)

1.  Start time: 2024-03-04 11:00:00 UTC

2.   End time: 2024-03-11 11:00:00 UTC

 

 

--- Begin Message ---
D-Trust votes YES on Ballot SC-69v3.

 

Thanks,

Enrico

 

Von: Servercert-wg  Im Auftrag von Martijn 
Katerbarg via Servercert-wg
Gesendet: Monday, March 4, 2024 11:59 AM
An: CA/B Forum Server Certificate WG Public Discussion List 

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

 

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...d5bd141e14de098ff00c10de7cf500668cbc6843

--- 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-26 07:00:00 UTC

2.   End time: 2024-03-04 11:00:00 UTC

Vote for approval (7 days)

1.  Start time: 2024-03-04 11:00:00 UTC

2.   End time: 2024-03-11 11:00:00 UTC

 

 



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

Re: [Servercert-wg] [Voting Period Begins] SC-070: Clarify the use of DTPs for Domain Control Validation

2024-02-14 Thread Entschew, Enrico via Servercert-wg

D-Trust votes YES on Ballot SC-070.



Thanks,

Enrico



Von: Servercert-wg  Im Auftrag von Aaron 
Gable via Servercert-wg
Gesendet: Tuesday, February 13, 2024 5:57 PM
An: CA/B Forum Server Certificate WG Public Discussion List 

Betreff: [Servercert-wg] [Voting Period Begins] SC-070: Clarify the use of 
DTPs for Domain Control Validation



This new voting period is to fix a typo in the End timestamp of the voting 
period for the previous version of this ballot. The contents of the motion 
itself are identical. My apologies for the confusion.



This ballot aims to clarify the existing language around the use of delegated 
third-parties during domain and IP address control validation. It leaves the 
existing language in place, and adds specifics for the cases of DNS queries, 
WHOIS lookups, and contact with the Domain Name Registrat or IP Address 
Registration Authority.



Additionally, it places these same restrictions on CAA checking, with an 
effective date of 2024-05-15.



This ballot is proposed by Aaron Gable (ISRG / Let's Encrypt) and endorsed by 
Mads Henriksveen (Buypass) and Dimitris Zacharopoulos (HARICA). You can view 
and comment on the github pull request representing this ballot here: 
 
https://github.com/cabforum/servercert/puhttps://lists.cabforum.org/pipermail/servercert-wg/2024-February/004174.htmlll/475



The preceding discussion can be seen here: 
 
https://lists.cabforum.org/pipermail/servercert-wg/2024-February/004174.html



--- 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...00ea6e24c474fd0ab6eecc25cb8eb733fffc60c3



--- Motion Ends ---



Discussion (at least 7 days):

- Start: 2024-02-02 22:30 UTC

- End: 2024-02-12 22:30 UTC



Vote for approval (7 days):

- Start: 2024-02-13 17:00 UTC

- End: 2024-02-20 17:00 UTC



Thanks,

Aaron

--- Begin Message ---
D-Trust votes YES on Ballot SC-070.



Thanks,

Enrico



Von: Servercert-wg  Im Auftrag von Aaron 
Gable via Servercert-wg
Gesendet: Tuesday, February 13, 2024 5:57 PM
An: CA/B Forum Server Certificate WG Public Discussion List 

Betreff: [Servercert-wg] [Voting Period Begins] SC-070: Clarify the use of 
DTPs for Domain Control Validation



This new voting period is to fix a typo in the End timestamp of the voting 
period for the previous version of this ballot. The contents of the motion 
itself are identical. My apologies for the confusion.



This ballot aims to clarify the existing language around the use of delegated 
third-parties during domain and IP address control validation. It leaves the 
existing language in place, and adds specifics for the cases of DNS queries, 
WHOIS lookups, and contact with the Domain Name Registrat or IP Address 
Registration Authority.



Additionally, it places these same restrictions on CAA checking, with an 
effective date of 2024-05-15.



This ballot is proposed by Aaron Gable (ISRG / Let's Encrypt) and endorsed by 
Mads Henriksveen (Buypass) and Dimitris Zacharopoulos (HARICA). You can view 
and comment on the github pull request representing this ballot here: 
 
https://github.com/cabforum/servercert/puhttps://lists.cabforum.org/pipermail/servercert-wg/2024-February/004174.htmlll/475



The preceding discussion can be seen here: 
 
https://lists.cabforum.org/pipermail/servercert-wg/2024-February/004174.html



--- 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...00ea6e24c474fd0ab6eecc25cb8eb733fffc60c3



--- Motion Ends ---



Discussion (at least 7 days):

- Start: 2024-02-02 22:30 UTC

- End: 2024-02-12 22:30 UTC



Vote for approval (7 days):

- Start: 2024-02-13 17:00 UTC

- End: 2024-02-20 17:00 UTC



Thanks,

Aaron



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

Re: [Servercert-wg] Voting Begins for Ballot SC-68: Allow VATEL and VATXI for organizationIdentifier

2024-01-29 Thread Entschew, Enrico via Servercert-wg

D-Trust votes Yes on Ballot SC-68.

 

Thanks,

Enrico

 

Von: Servercert-wg  Im Auftrag von Dimitris 
Zacharopoulos (HARICA) via Servercert-wg
Gesendet: Tuesday, January 23, 2024 10:00 AM
An: CA/B Forum Server Certificate WG Public Discussion List 

Betreff: [Servercert-wg] Voting Begins for Ballot SC-68: Allow VATEL and VATXI 
for organizationIdentifier

 

This email initiates the voting period for ballot SC-68. Please vote.







Purpose of the Ballot

The EV Guidelines have strict rules in the organizationIdentifier values and 
require the country code of all currently-allowed Registration Schemes (NTR, 
VAT, PSD) to follow the ISO 3166-1 for the 2-letter country prefix.

The organizationIdentifier language mainly came from ETSI EN 319 412-1 and then 
the SCWG made several modifications. However, there is an exception for Greece 
specifically for the VAT Registration Scheme that is aligned with Article 215 
of Council Directive 2006/112/EC 
  that allows Greece to use the 
country prefix "EL". In practice, Greece uses the prefix "EL" to identify 
itself next to the VAT number of all Legal Entities 
registered/incorporated/established in Greece, and all other European Countries 
use this prefix to identify Greek VAT numbers. This can easily be verified in 
the VIES VAT number validation website 
  where Greece is 
listed as"EL".

There is also Council Directive 2020/1756 
  amending Directive 2006/112/EC 
that requires the prefix "XI" for the identification of taxable persons in 
Northern Ireland.

This pull request   proposes 
updates to the EV Guidelines to allow those additional prefixes. It also fixes 
some formatting issues.

The following motion has been proposed by Dimitris Zacharopoulos of HARICA and 
endorsed by Ben Wilson of Mozilla and Corey Bonnell of Digicert.

MOTION BEGINS

This ballot modifies the “Guidelines for the Issuance and Management of 
Extended Validation Certificates” (“EV Guidelines”), based on Version 1.8.0.

MODIFY the EV Guidelines as specified in the following Redline: 

*   
https://github.com/cabforum/servercert/compare/da89d0e9700c6dd89a8263526addc39f472bf54c.

MOTION ENDS

The procedure for this ballot is as follows:


Start time (8:00 UTC)

End time (8:00 UTC)


Discussion (at least 7 days)

2024-01-16

2024-01-23


Expected Vote for approval (7 days)

2024-01-23

2024-01-30

 

--- Begin Message ---
D-Trust votes Yes on Ballot SC-68.

 

Thanks,

Enrico

 

Von: Servercert-wg  Im Auftrag von Dimitris 
Zacharopoulos (HARICA) via Servercert-wg
Gesendet: Tuesday, January 23, 2024 10:00 AM
An: CA/B Forum Server Certificate WG Public Discussion List 

Betreff: [Servercert-wg] Voting Begins for Ballot SC-68: Allow VATEL and VATXI 
for organizationIdentifier

 

This email initiates the voting period for ballot SC-68. Please vote.







Purpose of the Ballot

The EV Guidelines have strict rules in the organizationIdentifier values and 
require the country code of all currently-allowed Registration Schemes (NTR, 
VAT, PSD) to follow the ISO 3166-1 for the 2-letter country prefix.

The organizationIdentifier language mainly came from ETSI EN 319 412-1 and then 
the SCWG made several modifications. However, there is an exception for Greece 
specifically for the VAT Registration Scheme that is aligned with Article 215 
of Council Directive 2006/112/EC 
  that allows Greece to use the 
country prefix "EL". In practice, Greece uses the prefix "EL" to identify 
itself next to the VAT number of all Legal Entities 
registered/incorporated/established in Greece, and all other European Countries 
use this prefix to identify Greek VAT numbers. This can easily be verified in 
the VIES VAT number validation website 
  where Greece is 
listed as"EL".

There is also Council Directive 2020/1756 
  amending Directive 2006/112/EC 
that requires the prefix "XI" for the identification of taxable persons in 
Northern Ireland.

This pull request   proposes 
updates to the EV Guidelines to allow those additional prefixes. It also fixes 
some formatting issues.

The following motion has been proposed by Dimitris Zacharopoulos of HARICA and 
endorsed by Ben Wilson of Mozilla and Corey Bonnell of Digicert.

MOTION BEGINS

This ballot modifies the “Guidelines for the Issuance and Management of 
Extended Validation Certificates” (“EV Guidelines”), based on Version 1.8.0.

MODIFY the EV Guidelines as specified in the following Redline: 

*   
https://github.com/cabforum/servercert/compare/da89d0e9700c6dd89a8263526addc39f472bf54c.

MOTION ENDS

The procedure for this ballot is as follows:

Re: [Servercert-wg] VOTE FOR APPROVAL Ballot SC-066: Fall 2023 Clean-up v4

2023-11-21 Thread Entschew, Enrico via Servercert-wg

D-Trust votes YES to SC-066.

 

Thanks,

Enrico

 

Von: Servercert-wg  Im Auftrag von Inigo
Barreira via Servercert-wg
Gesendet: Thursday, November 16, 2023 7:50 PM
An: CA/B Forum Server Certificate WG Public Discussion List

Betreff: [Servercert-wg] VOTE FOR APPROVAL Ballot SC-066: Fall 2023 Clean-up
v4

 

Hi everyone,

 

The voting period for ballot SC66v4 has started. Votes must be cast on the
SCWG public list in accordance with the WG charter and the bylaws.

Voting on SC66v4 concludes on 23 November 2023 at 18:30 UTC.

 

Regards

 

Purpose of Ballot

 

This ballot proposes updates to the Baseline Requirements for the Issuance
and Management of Publicly-Trusted Certificates related to the issues and
typos that have happened due to the different updates of the document. 

 

Notes: 

-  The majority of these issues have been documented in GitHub and
have therefore labeled as cleanup and have been the basis for this update.

-  Some have been provided by emails to the CABF lists and included
in this reviewed version because were typos.

 

The following motion has been proposed by Iñigo Barreira of Sectigo. And,
endorsed by Aaron Gable of Let´s Encrypt and Clint Wilson of Apple.

 

 Motion Begins 

 

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

 

MODIFY the Baseline Requirements as specified in the following Pull Request:


 
 Comparing
90a98dc7c1131eaab01af411968aa7330d315b9b...d8447957753ed973cb036d0afe1672324
3c89998 · cabforum/servercert (github.com)

 

 Motion Ends 

 

 

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

 

Discussion (7 days)

 Start time: 9-11-2023 18:30:00 UTC

 End time: 16-11-2023 18:30:00 UTC

 

Vote for approval (7 days)

 Start time: 16-11-2023 18:30:00 UTC

 End time: 23-11-2023 18:30:00 UTC

 

--- Begin Message ---
D-Trust votes YES to SC-066.

 

Thanks,

Enrico

 

Von: Servercert-wg  Im Auftrag von Inigo
Barreira via Servercert-wg
Gesendet: Thursday, November 16, 2023 7:50 PM
An: CA/B Forum Server Certificate WG Public Discussion List

Betreff: [Servercert-wg] VOTE FOR APPROVAL Ballot SC-066: Fall 2023 Clean-up
v4

 

Hi everyone,

 

The voting period for ballot SC66v4 has started. Votes must be cast on the
SCWG public list in accordance with the WG charter and the bylaws.

Voting on SC66v4 concludes on 23 November 2023 at 18:30 UTC.

 

Regards

 

Purpose of Ballot

 

This ballot proposes updates to the Baseline Requirements for the Issuance
and Management of Publicly-Trusted Certificates related to the issues and
typos that have happened due to the different updates of the document. 

 

Notes: 

-  The majority of these issues have been documented in GitHub and
have therefore labeled as cleanup and have been the basis for this update.

-  Some have been provided by emails to the CABF lists and included
in this reviewed version because were typos.

 

The following motion has been proposed by Iñigo Barreira of Sectigo. And,
endorsed by Aaron Gable of Let´s Encrypt and Clint Wilson of Apple.

 

 Motion Begins 

 

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

 

MODIFY the Baseline Requirements as specified in the following Pull Request:


 
 Comparing
90a98dc7c1131eaab01af411968aa7330d315b9b...d8447957753ed973cb036d0afe1672324
3c89998 · cabforum/servercert (github.com)

 

 Motion Ends 

 

 

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

 

Discussion (7 days)

 Start time: 9-11-2023 18:30:00 UTC

 End time: 16-11-2023 18:30:00 UTC

 

Vote for approval (7 days)

 Start time: 16-11-2023 18:30:00 UTC

 End time: 23-11-2023 18:30:00 UTC

 



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

Re: [Servercert-wg] Voting Period Begins - Ballot SC-063 V4: “Make OCSP Optional, Require CRLs, and Incentivize Automation”

2023-07-13 Thread Entschew, Enrico via Servercert-wg

D-Trust votes YES on Ballot SC-063.

Thanks,

Enrico

Von: Servercert-wg Im Auftrag von Ryan
Dickson via Servercert-wg
Gesendet: Thursday, July 6, 2023 5:59 PM
An: ServerCert CA/BF
Betreff: [Servercert-wg] Voting Period Begins - Ballot SC-063 V4: “Make OCSP
Optional, Require CRLs, and Incentivize Automation”

Purpose of Ballot SC-063

This Ballot proposes updates to the Baseline Requirements for the Issuance and
Management of Publicly-Trusted Certificates related to making Online
Certificate Status Protocol (OCSP) services optional for CAs. This proposal
does not prohibit or otherwise restrict CAs who choose to continue supporting
OCSP from doing so. If CAs continue supporting OCSP, the same requirements
apply as they exist today.

Additionally, this proposal introduces changes related to CRL requirements
including:

· CRLs must conform with the proposed profile.

· CAs must generate and publish either:

oa full and complete, or

oa set of partitioned CRLs (sometimes called “sharded” CRLs), that when
aggregated, represent the equivalent of a full and complete CRL.

· CAs issuing Subscriber Certificates must update and publish a new CRL…

owithin twenty-four (24) hours after recording a Certificate as revoked;
and

oOtherwise:

§ at least every seven (7) days if all Certificates include an Authority
Information Access extension with an id-ad-ocsp accessMethod (“AIA OCSP
pointer”), or

§ at least every four (4) days in all other cases.

Finally, the proposal revisits the concept of a “short-lived” certificate,
introduced in Ballot 153
. As
described in this ballot, short-lived certificates (sometimes called
“short-term certificates” in ETSI

specifications) are:

· optional. CAs will not be required to issue short-lived certificates.
For TLS certificates that do not meet the definition of a short-lived
certificate introduced in this proposed update, the current maximum validity
period of 398 days remains applicable.

· constrained to an initial maximum validity period of ten (10) days.
The proposal stipulates that short-lived certificates issued on or after 15
March 2026 must not have a Validity Period greater than seven (7) days.

· not required to contain a CRLDP or OCSP pointer and are not required
to be revoked. The primary mechanism of certificate invalidation for these
short-lived certificates would be through certificate expiry. CAs may
optionally revoke short-lived certificates. The initial maximum certificate
validity is aligned with the existing maximum values for CRL “nextUpdate” and
OCSP response validity allowed by the BRs today.

Additional background, justification, and considerations are outlined

here.

Proposal Revision History:

· The set of updates resulting from the first round of discussion are
presented here.

· The set of updates resulting from the second round of discussion are
presented here .

· The set of updates resulting from the third round of discussion are
presented here .

The following motion has been proposed by Ryan Dickson and Chris Clements of
Google (Chrome Root Program) and endorsed by Kiran Tummala of Microsoft and Tim
Callan of Sectigo.

— Motion Begins —

This ballot modifies the “Baseline Requirements for the Issuance and Management
of Publicly-Trusted Certificates” (“Baseline Requirements”), based on Version
2.0.0.

MODIFY the Baseline Requirements as specified in the following Redline:

https://github.com/cabforum/servercert/compare/a0360b61e73476959220dc328e3b68d0224fa0b3..b8a0453e59ff342779d5083f2f1f8b8b5930a66a

— Motion Ends —

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

Discussion (13+ days)

· Start time: 2023-06-22 20:30:00 UTC

· End time: 2023-07-06 15:59:59 UTC

Vote for approval (7 days)

· Start time: 2023-07-06 16:00:00 UTC

· End time: 2023-07-13 16:00:00 UTC

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 - Ballot SC-59 v2 "Weak Key Guidance"