Greetings Antti, Somehow, our group (working on the Subscriber Agreement/Terms of Use ballot) had selected ballot number 67 on the wiki, but there were two different wiki pages with ballot numbers that people were unaware of (which led to a second selection of #67 by Chris and Ryan). So Dustin, Tadahiko, and I decided to go with SC-071 (the next unallocated one) for our ballot. Ben
On Mon, Mar 18, 2024 at 11:19 PM Backman, Antti via Servercert-wg < servercert-wg@cabforum.org> 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 > > [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.coinbase.com/blog/celer-bridge-incident-analysis > > [5] > 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 > > > [7] > https://www.usenix.org/conference/usenixsecurity21/presentation/birge-lee > > [8] > https://www.usenix.org/conference/usenixsecurity18/presentation/birge-lee > > [9] > https://security.googleblog.com/2023/05/google-trust-services-acme-api_0503894189.html > > > [10] https://github.com/ryancdickson/staging/pull/6 > > [11] 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 > > > > > *— 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
