Hi Antti,
The ballot number seems to be ok.
Check out
https://wiki.cabforum.org/books/server-certificate-wg/page/scwg-ballots-wuG
It looks like Ben and Dustin need to get a new number and add a row to
the corresponding table.
Thanks,
Dimitris.
On 19/3/2024 7:19 π.μ., Backman, Antti via Servercert-wg wrote:
Hi Chris
Could there be a numbering clash with this ballot and the one being
worked on by Ben Wilson?
“[Servercert-wg] Draft Ballot SC-067: Applicant, Subscriber and
Subscriber Agreements - Feedback r”
As I am not completely sure how ballot numbering should work out, can
the numbers be recycled or how that pans out?
//Antti
*From: *Servercert-wg <servercert-wg-boun...@cabforum.org> on behalf
of Chris Clements via Servercert-wg <servercert-wg@cabforum.org>
*Date: *Monday, 18. March 2024 at 17.32
*To: *CA/B Forum Server Certificate WG Public Discussion List
<servercert-wg@cabforum.org>
*Subject: *[Servercert-wg] Discussion Period Begins - Ballot SC-067
V1: "Require domain validation and CAA checks to be performed from
multiple Network Perspectives”
*Purpose of Ballot SC-067*:
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.
- 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*:
- N/A, this is the first discussion period.
*References*:
[1]
https://cabforum.org/wp-content/uploads/13-CAB-Forum-face-to-face-multiple-vantage-points.pdf
<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
<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
<https://medium.com/s2wblog/post-mortem-of-klayswap-incident-through-bgp-hijacking-en-3ed7e33de600>
[4] https://www.coinbase.com/blog/celer-bridge-incident-analysis
<https://www.coinbase.com/blog/celer-bridge-incident-analysis>
[5]
https://www.usenix.org/conference/usenixsecurity23/presentation/cimaszewski
<https://www.usenix.org/conference/usenixsecurity23/presentation/cimaszewski>
[6]
https://www.blackhat.com/docs/us-15/materials/us-15-Gavrichenkov-Breaking-HTTPS-With-BGP-Hijacking-wp.pdf
<https://www.blackhat.com/docs/us-15/materials/us-15-Gavrichenkov-Breaking-HTTPS-With-BGP-Hijacking-wp.pdf>
[7]
https://www.usenix.org/conference/usenixsecurity21/presentation/birge-lee
<https://www.usenix.org/conference/usenixsecurity21/presentation/birge-lee>
[8]
https://www.usenix.org/conference/usenixsecurity18/presentation/birge-lee
<https://www.usenix.org/conference/usenixsecurity18/presentation/birge-lee>
[9]
https://security.googleblog.com/2023/05/google-trust-services-acme-api_0503894189.html
<https://security.googleblog.com/2023/05/google-trust-services-acme-api_0503894189.html>
[10] https://github.com/ryancdickson/staging/pull/6
<https://github.com/ryancdickson/staging/pull/6>
[11] https://github.com/ryancdickson/staging/pull/8
<https://github.com/ryancdickson/staging/pull/8>
The following motion has been proposed by Chris Clements and Ryan
Dickson of Google (Chrome Root Program) and endorsed by Aaron Gable
(ISRG / Let’s Encrypt) and Wayne Thayer (Fastly).
*— Motion Begins —*
This ballot modifies the “Baseline Requirements for the Issuance and
Management of Publicly-Trusted TLS Server 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..6d10abda8980c6eb941987d3fc26e753e62858c0
<https://github.com/cabforum/servercert/compare/41f01640748fa612386f8b1a3031cd1bff3d4f35..6d10abda8980c6eb941987d3fc26e753e62858c0>
*— Motion Ends —*
This ballot proposes a Final Maintenance Guideline. The procedure for
approval of this ballot is as follows:
*Discussion (at least 21 days)*
- Start: 2024-03-18 15:30:00 UTC
- End no earlier than: 2024-04-07 15:30:00 UTC
*Vote for approval (7 days)*
- Start: TBD
- End: TBD
_______________________________________________
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg
_______________________________________________
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg