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

[Marco Schambach via Servercert-wg]

IdenTrust votes “Yes” on ballot SC-067 V3

 

Marco S.

TrustID Program Manager 

 

From: Servercert-wg mailto:servercert-wg-boun...@cabforum.org> > On Behalf Of Chris Clements via 
Servercert-wg
Sent: Monday, May 20, 2024 10:30 AM
To: CA/B Forum Server Certificate WG Public Discussion List 
mailto:servercert-wg@cabforum.org> >
Subject: [External][Servercert-wg] Discussion 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]  

 

Re: [Servercert-wg] [Voting Begins] Ballot SC-74 - Clarify CP/CPS structure according to RFC 3647

[Marco Schambach via Servercert-wg]

IdenTrust also changes our vote to “No”  on Ballot SC-74 as the feedback from 
others make sense that this ballot requires further finetuning.

 

Marco S.

TrustID Program Manager 

 

From: Servercert-wg  On Behalf Of Marco 
Schambach via Servercert-wg
Sent: Tuesday, May 7, 2024 10:05 AM
To: Dimitris Zacharopoulos (HARICA) ; CA/B Forum Server 
Certificate WG Public Discussion List 
Subject: [Servercert-wg] [Voting Begins] Ballot SC-74 - Clarify CP/CPS 
structure according to RFC 3647

 

IdenTrust votes “Yes” on Ballot SC-74

 

Marco S.

TrustID Program Manager 

 

From: Servercert-wg mailto:servercert-wg-boun...@cabforum.org> > On Behalf Of Dimitris 
Zacharopoulos (HARICA) via Servercert-wg
Sent: Sunday, May 5, 2024 4:25 AM
To: CA/B Forum Server Certificate WG Public Discussion List 
mailto:servercert-wg@cabforum.org> >
Subject: [External][Servercert-wg] [Voting Begins] Ballot SC-74 - Clarify 
CP/CPS structure according to RFC 3647

 

Voting begins for ballot SC-74.


SC-74 - Clarify CP/CPS structure according to RFC 3647


Summary


The TLS Baseline Requirements require in section 2.2 that:

"The Certificate Policy and/or Certification Practice Statement MUST be 
structured in accordance with RFC 3647 and MUST include all material required 
by RFC 3647."

The intent of this language was to ensure that all CAs' CP and/or CPS documents 
contain a similar structure, making it easier to review and compare against the 
BRs. However, there was some ambiguity as to the actual structure that CAs 
should follow. After several discussions in the SCWG Public Mailing List 
<https://lists.cabforum.org/pipermail/servercert-wg/2023-November/004070.html>  
and F2F meetings, it was agreed that more clarity should be added to the 
existing requirement, pointing to the outline described in section 6 of RFC 
3647.

The following motion has been proposed by Dimitris Zacharopoulos (HARICA) and 
endorsed by Aaron Poulsen (Amazon) and Tim Hollebeek (Digicert). 

You can view the github pull request representing this ballot here 
<https://github.com/cabforum/servercert/pull/503> . 


Motion Begins


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

*   
https://github.com/cabforum/servercert/compare/c4a34fe2292022e0a04ba66b5a85df75907ac2a2...f6a90e2a652fbb7a2d62a976b70f4af3adce8dae
 


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-04-25 16:30:00 UTC
*   End time: on or after 2024-05-02 16:30:00 UTC


Vote for approval (7 days)


*   Start time: 2024-05-05 8:30:00 UTC
*   End time: 2024-05-12 8:30: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

[Servercert-wg] [Voting Begins] Ballot SC-74 - Clarify CP/CPS structure according to RFC 3647

[Marco Schambach via Servercert-wg]

IdenTrust votes “Yes” on Ballot SC-74

 

Marco S.

TrustID Program Manager 

 

From: Servercert-wg  On Behalf Of Dimitris 
Zacharopoulos (HARICA) via Servercert-wg
Sent: Sunday, May 5, 2024 4:25 AM
To: CA/B Forum Server Certificate WG Public Discussion List 

Subject: [External][Servercert-wg] [Voting Begins] Ballot SC-74 - Clarify 
CP/CPS structure according to RFC 3647

 

Voting begins for ballot SC-74.




SC-74 - Clarify CP/CPS structure according to RFC 3647


Summary


The TLS Baseline Requirements require in section 2.2 that:

"The Certificate Policy and/or Certification Practice Statement MUST be 
structured in accordance with RFC 3647 and MUST include all material required 
by RFC 3647."

The intent of this language was to ensure that all CAs' CP and/or CPS documents 
contain a similar structure, making it easier to review and compare against the 
BRs. However, there was some ambiguity as to the actual structure that CAs 
should follow. After several discussions in the SCWG Public Mailing List 
  
and F2F meetings, it was agreed that more clarity should be added to the 
existing requirement, pointing to the outline described in section 6 of RFC 
3647.

The following motion has been proposed by Dimitris Zacharopoulos (HARICA) and 
endorsed by Aaron Poulsen (Amazon) and Tim Hollebeek (Digicert). 

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.4 as specified 
in the following redline:

*   
https://github.com/cabforum/servercert/compare/c4a34fe2292022e0a04ba66b5a85df75907ac2a2...f6a90e2a652fbb7a2d62a976b70f4af3adce8dae
 


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-04-25 16:30:00 UTC
*   End time: on or after 2024-05-02 16:30:00 UTC


Vote for approval (7 days)


*   Start time: 2024-05-05 8:30:00 UTC
*   End time: 2024-05-12 8:30: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

[Servercert-wg] Voting Period Begins - Ballot SC-073: Compromisedand Weak Keys

[Marco Schambach via Servercert-wg]

IdenTrust votes “Yes” to SC-073

 

Marco S.

TrustID Program Manager 

 

From: Servercert-wg  On Behalf Of Wayne 
Thayer via Servercert-wg
Sent: Thursday, April 25, 2024 8:00 PM
To: CA/B Forum Server Certificate WG Public Discussion List 

Subject: [External][Servercert-wg] Voting Period Begins - Ballot SC-073: 
Compromisedand 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



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

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

[Marco Schambach via Servercert-wg]

smime.p7m
Description: S/MIME encrypted message
___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg

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

[Marco Schambach via Servercert-wg]

IdenTrust votes 'Yes' on SC-69v3

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/41f01640748fa612386f8b1a3031c
d1bff3d4f35...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
___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg

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

[Marco Schambach via Servercert-wg]

IdenTrust  votes "yes" to ballot SC-69v3.

 

Marco Schambach

 

 

From: Servercert-wg  On Behalf Of Martijn 
Katerbarg via Servercert-wg
Sent: Monday, February 26, 2024 2:00 AM
To: CA/B Forum Server Certificate WG Public Discussion List 

Subject: [Servercert-wg] [Discussion 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: Not Before 2024-03-04 07:00:00 UTC

Vote for approval (7 days)

1.  Start time: TBD
2.  End time: TBD

 

 



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]: SC65: Convert EVGs into RFC 3647 format v2

[Marco Schambach via Servercert-wg]

smime.p7m
Description: S/MIME encrypted message
___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg