Hi Martijn, Thank you for your review and comments, especially as suggested commits!
This is helpful feedback in clarifying the expectations of the Ballot, and we’ve responded to them directly on GitHub [1]. We also staged [2] these updates in and a separate branch [3] to avoid any confusion with the in-progress discussion period. Feedback on these proposed updates are welcome. The new branch will serve as the basis for a subsequent round of Public Discussion once this one closes. Thanks again! -Chris (on behalf of the Chrome Root Program) [1] https://github.com/cabforum/servercert/pull/487/files [2] https://github.com/ChristopherRC/servercert/compare/SC-067-Version-1..ChristopherRC:servercert:SC-067-Version-2?expand=1 [3] https://github.com/ChristopherRC/servercert/tree/SC-067-Version-2 On Wed, Apr 3, 2024 at 4:01 AM Martijn Katerbarg < [email protected]> wrote: > Hi Chris, > > Thank you for getting this ballot out. After having gone through the > language more detailed, I have a few comments. I’ve added these to the > Github PR, but will list them here additionally for visibility. > > > > - Minor nit: > https://github.com/cabforum/servercert/pull/487#discussion_r1549074735 > - I’m not native english, so I may be wrong on this one, but it > seems to me like this “from” should be a “by”. > - I can imagine CAs may want to differentiate their checks for CAA > lookups vs those for Domain Control, as such I would recommend this > “and/or”: > https://github.com/cabforum/servercert/pull/487#discussion_r1549076900 > - Section 3.2.2.9 paragraph 2 currently reads, or can be read in such > a way that a single response from a Network Perspective needs to contain > both the necessary information to asses (a) *and* (b) in that > paragraph. I can imagine CAs wanting to use 2 different calls for that, > thus resulting in 2 different responses, both confirming different checks. > I’ve added a suggestion here, but I’m not fully happy with that language > either. If someone else has a better suggestion, please comment. > I thought about making the “and” at the end of (a) an “and/or”, but > that may then result in CAs believing they only need to confirm either > Domain Control or CAA alltogether, which is not desirable. > - Another minor one, but relevant: > https://github.com/cabforum/servercert/pull/487/files#r1549101349 It > seems like re-use should also allow for the domain itself to be able to > re-use data. > > > Regards, > > Martijn > > > > > > *From: *Servercert-wg <[email protected]> on behalf of > Chris Clements via Servercert-wg <[email protected]> > *Date: *Wednesday, 20 March 2024 at 21:20 > *To: *Dimitris Zacharopoulos (HARICA) <[email protected]>, CA/B Forum > Server Certificate WG Public Discussion List <[email protected]> > *Subject: *Re: [Servercert-wg] Discussion Period Begins - Ballot SC-067 > V1: "Require domain validation and CAA checks to be performed from multiple > Network Perspectives” > > 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. > > > > Hi Dimitris, > > > > Your suggestion to extend the discussion period to at least 30 days sounds > very reasonable and fair to us. I am providing an updated preamble below > that extends the current discussion and makes no other changes. > > > > > > *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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcabforum.org%2Fwp-content%2Fuploads%2F13-CAB-Forum-face-to-face-multiple-vantage-points.pdf&data=05%7C02%7Cmartijn.katerbarg%40sectigo.com%7C351c2b0d57d94d1e225a08dc491a9f54%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638465628230417253%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=GoX5Lbu9SFpKRc1rISxdAuK7VJvYyDEagL1FwvMqnCA%3D&reserved=0> > > [2] > https://drive.google.com/file/d/1LTwtAwHXcSaPVSsqKQztNJrV2ozHJ7ZL/view?usp=drive_link > <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdrive.google.com%2Ffile%2Fd%2F1LTwtAwHXcSaPVSsqKQztNJrV2ozHJ7ZL%2Fview%3Fusp%3Ddrive_link&data=05%7C02%7Cmartijn.katerbarg%40sectigo.com%7C351c2b0d57d94d1e225a08dc491a9f54%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638465628230427471%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=67N%2Bzjb413rZd5EoEBJxanGoGrzAuXugTPMXbvcv%2BoI%3D&reserved=0> > > > [3] > https://medium.com/s2wblog/post-mortem-of-klayswap-incident-through-bgp-hijacking-en-3ed7e33de600 > <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmedium.com%2Fs2wblog%2Fpost-mortem-of-klayswap-incident-through-bgp-hijacking-en-3ed7e33de600&data=05%7C02%7Cmartijn.katerbarg%40sectigo.com%7C351c2b0d57d94d1e225a08dc491a9f54%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638465628230434584%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=56zKEthdTZLDQHEBjMJlm7M9EdnsQCXbEuokDw63lf8%3D&reserved=0> > > > [4] https://www.coinbase.com/blog/celer-bridge-incident-analysis > <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.coinbase.com%2Fblog%2Fceler-bridge-incident-analysis&data=05%7C02%7Cmartijn.katerbarg%40sectigo.com%7C351c2b0d57d94d1e225a08dc491a9f54%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638465628230440923%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=XE6439%2F24MaEeGbHQPU%2BgHd99%2Fa%2Bp86qUIY2u26ESR8%3D&reserved=0> > > > [5] > https://www.usenix.org/conference/usenixsecurity23/presentation/cimaszewski > <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.usenix.org%2Fconference%2Fusenixsecurity23%2Fpresentation%2Fcimaszewski&data=05%7C02%7Cmartijn.katerbarg%40sectigo.com%7C351c2b0d57d94d1e225a08dc491a9f54%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638465628230447223%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=JUM%2FaN6fWHHowr2W9KbqIhfg0P1Tm30Kx8klEIJ%2FV4k%3D&reserved=0> > > > [6] > https://www.blackhat.com/docs/us-15/materials/us-15-Gavrichenkov-Breaking-HTTPS-With-BGP-Hijacking-wp.pdf > <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.blackhat.com%2Fdocs%2Fus-15%2Fmaterials%2Fus-15-Gavrichenkov-Breaking-HTTPS-With-BGP-Hijacking-wp.pdf&data=05%7C02%7Cmartijn.katerbarg%40sectigo.com%7C351c2b0d57d94d1e225a08dc491a9f54%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638465628230452773%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=%2BKTqv6mLNjqvr9TJ3xSM8XD%2FICfoGiKqoZdaKT%2FVRtI%3D&reserved=0> > > > [7] > https://www.usenix.org/conference/usenixsecurity21/presentation/birge-lee > <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.usenix.org%2Fconference%2Fusenixsecurity21%2Fpresentation%2Fbirge-lee&data=05%7C02%7Cmartijn.katerbarg%40sectigo.com%7C351c2b0d57d94d1e225a08dc491a9f54%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638465628230458401%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=uG%2F%2BZU4A2g5xK1tom4JLBKhFLzDgmnReTdig01rqW20%3D&reserved=0> > > > [8] > https://www.usenix.org/conference/usenixsecurity18/presentation/birge-lee > <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.usenix.org%2Fconference%2Fusenixsecurity18%2Fpresentation%2Fbirge-lee&data=05%7C02%7Cmartijn.katerbarg%40sectigo.com%7C351c2b0d57d94d1e225a08dc491a9f54%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638465628230463868%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=Sn%2BixjQn94EbiLbBVP7IiNIJJHOEzA%2BZUn2wPD57e9A%3D&reserved=0> > > > [9] > https://security.googleblog.com/2023/05/google-trust-services-acme-api_0503894189.html > <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsecurity.googleblog.com%2F2023%2F05%2Fgoogle-trust-services-acme-api_0503894189.html&data=05%7C02%7Cmartijn.katerbarg%40sectigo.com%7C351c2b0d57d94d1e225a08dc491a9f54%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638465628230469305%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=sp00Gv5b6A%2B8%2Fjp%2BqJ1KHyXx4QifJVKXmmkBc42Y2%2Bs%3D&reserved=0> > > > [10] https://github.com/ryancdickson/staging/pull/6 > <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fryancdickson%2Fstaging%2Fpull%2F6&data=05%7C02%7Cmartijn.katerbarg%40sectigo.com%7C351c2b0d57d94d1e225a08dc491a9f54%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638465628230475067%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=zQgtc7MvlOlKiH6f2GzteKaZG5ZyBrYPCrhPsFHbqHI%3D&reserved=0> > > > [11] https://github.com/ryancdickson/staging/pull/8 > <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fryancdickson%2Fstaging%2Fpull%2F8&data=05%7C02%7Cmartijn.katerbarg%40sectigo.com%7C351c2b0d57d94d1e225a08dc491a9f54%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638465628230480284%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=qnupbwuMcOtQcw%2FhMx0PYmmejyjQonGr90Xvjaa1oE4%3D&reserved=0> > > > > > 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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcabforum%2Fservercert%2Fcompare%2F41f01640748fa612386f8b1a3031cd1bff3d4f35..6d10abda8980c6eb941987d3fc26e753e62858c0&data=05%7C02%7Cmartijn.katerbarg%40sectigo.com%7C351c2b0d57d94d1e225a08dc491a9f54%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638465628230485479%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=ANXwEeN5k5oU5S5eBIcwALiRXdJMdX6p17aZklae48c%3D&reserved=0> > > > > > *— Motion Ends —* > > > > This ballot proposes a Final Maintenance Guideline. The procedure for > approval of this ballot is as follows: > > > > *Discussion (at least 30 days)* > > - Start: 2024-03-18 15:30:00 UTC > > - End no earlier than: 2024-04-17 15:30:00 UTC > > > > *Vote for approval (7 days)* > > - Start: TBD > > - End: TBD > > > > > > On Tue, Mar 19, 2024 at 11:00 AM Dimitris Zacharopoulos (HARICA) via > Servercert-wg <[email protected]> wrote: > > Hi Chris, > > On 18/3/2024 5:32 μ.μ., Chris Clements via Servercert-wg wrote: > > *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. > > > This is the first time the Forum and a Chartered Working Group goes > through a ballot with essential contributions coming from a non-Member. At > the last F2F meeting, we discussed about possibly allowing fewer days for > the IPR review in certain cases, and many Members felt that this would > create problems because legal departments need time to review these > documents. My interpretation is that Organizations that participate in the > Forum are very sensitive when it comes to IP issues. > > I would therefore suggest that the discussion period takes *at least 30 > days* (similar to the time it takes for the IPR review period to end for > Maintenance Guidelines), so that Members have time to provide information > to their legal departments regarding the commitment by Princeton from > January 11, 2024, and see if there are any objections or concerns raised. > All members will ultimately have to accept the proposed IPR solution > offered by Princeton before the ballot enters its voting period. I hope > this sounds reasonable and fair. > > At the same time, we can continue discussing the proposed language that > updates the BRs. > > Other Members that are sensitive on this matter can also speak up about > this suggested process so we can proceed with caution and minimize the IP > risks. > > > Thank you, > Dimitris. > > _______________________________________________ > Servercert-wg mailing list > [email protected] > https://lists.cabforum.org/mailman/listinfo/servercert-wg > <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.cabforum.org%2Fmailman%2Flistinfo%2Fservercert-wg&data=05%7C02%7Cmartijn.katerbarg%40sectigo.com%7C351c2b0d57d94d1e225a08dc491a9f54%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638465628230492660%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=jZ8MBQ4l0cHamgNbuRy3NjWc34gpTaKmVdABBIzfhX4%3D&reserved=0> > >
_______________________________________________ Servercert-wg mailing list [email protected] https://lists.cabforum.org/mailman/listinfo/servercert-wg
