[Servercert-wg] MPIC implementation & protocol / API standardization

Wed Sep 4 08:04:18 UTC 2024

Dear Roman,

HARICA would be interested to collaborate on this.

Best regards,
Dimitris.

On 3/9/2024 11:12 π.μ., Roman Fischer via Servercert-wg wrote:
>
> Dear fellow CA reps,
>
> Together with the vendor of our PKI system, we're now at the point 
> where we either use their code to run as remote perspectives (either 
> on VMs hosted in any of the public cloud providers or VMs running in 
> our datacenters with outbound VPNs that terminate at suitable remote 
> locations) or standardize the protocol / API between the primary 
> (local) perspective and the remotes and then use any other (i.e. open 
> source) implementation of the remote perspective.
>
> We are aware of the Open MPIC initiative which is very valuable. At 
> the moment, they seem to focus on providing a "complete" MPIC solution 
> and their API specification implements a single call to perform the 
> corroboration from multiple perspectives all at once. Also, Open 
> MPIC's choice of AWS Lambda functions for the implementation is – 
> while totally elegant – not in line with our strategy for programming 
> language and cloud usage.
>
> We're currently more focusing on a protocol / API that specifies the 
> call to one remote perspective and an implementation that can be run 
> in a VM/Docker container.
>
> After my last mail, two interested CAs contacted me privately and 
> showed interest in collaboration on the implementation of MPIC. Are 
> there any other CAs working on this and willing to share / collaborate?
>
> Kind regards
> Roman
>
> *From:*Roman Fischer
> *Sent:* Mittwoch, 22. Mai 2024 09:29
> *To:* CA/B Forum Server Certificate WG Public Discussion List 
> <servercert-wg at cabforum.org>
> *Subject:* RE: [Servercert-wg] Discussion Period Begins - Ballot 
> SC-067 V3: "Require domain validation and CAA checks to be performed 
> from multiple Network Perspectives"
>
> Dear colleagues,
>
> We have started internal discussions about possible architectures to 
> implement this new feature. This of course also involves the vendor of 
> our CA system because architecture of the remote perspectives has big 
> impacts on the changes needed in the CA system.
>
> One of the ideas we were brainstorming involves partnering with other 
> CAs to share remote perspectives. Of course this would require some 
> standardized protocol, mutual authentication, contracts, … which I 
> realize is probably as huge an effort as doing it all by yourself. 😉
>
> What are other CAs ideas for implementing this? Please feel free to 
> also contact me directly if you rather not discuss on the list. 😊
>
> Kind regards
> Roman
>
> *From:*Servercert-wg <servercert-wg-bounces at cabforum.org> *On Behalf 
> Of *Chris Clements via Servercert-wg
> *Sent:* Montag, 20. Mai 2024 16:30
> *To:* CA/B Forum Server Certificate WG Public Discussion List 
> <servercert-wg at cabforum.org>
> *Subject:* [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 
> <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>
>
> [12] https://github.com/cabforum/servercert/pull/487 
> <https://github.com/cabforum/servercert/pull/487>
>
> [13] 
> https://github.com/cabforum/servercert/compare/6d10abda8980c6eb941987d3fc26e753e62858c0..5224983ef0a6f94c18808ea3469e7a5ae35746e5 
> <https://github.com/cabforum/servercert/compare/6d10abda8980c6eb941987d3fc26e753e62858c0..5224983ef0a6f94c18808ea3469e7a5ae35746e5>
>
> [14] https://github.com/cabforum/servercert/pull/507 
> <https://github.com/cabforum/servercert/pull/507>
>
> [15] 
> https://github.com/cabforum/servercert/compare/5224983ef0a6f94c18808ea3469e7a5ae35746e5..2dcf1a8fe5fc7b6a864b5767ab1db718bc447463 
> <https://github.com/cabforum/servercert/compare/5224983ef0a6f94c18808ea3469e7a5ae35746e5..2dcf1a8fe5fc7b6a864b5767ab1db718bc447463>
>
> 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.4.
>
> MODIFY the Baseline Requirements as specified in the following Redline:
>
> https://github.com/cabforum/servercert/compare/c4a34fe2292022e0a04ba66b5a85df75907ac2a2..2dcf1a8fe5fc7b6a864b5767ab1db718bc447463 
> <https://github.com/cabforum/servercert/compare/c4a34fe2292022e0a04ba66b5a85df75907ac2a2..2dcf1a8fe5fc7b6a864b5767ab1db718bc447463>
>
> *— Motion Ends —*
>
> This ballot proposes a Final Maintenance Guideline. The procedure for 
> approval of this ballot is as follows:
>
> *Discussion (at least 11 days)*
>
> - Start: 2024-05-20 14:30:00 UTC
>
> - End no earlier than: 2024-05-31 14:30:00 UTC
>
> *Vote for approval (7 days)*
>
> - Start: TBD
>
> - End: TBD
>
>
> _______________________________________________
> Servercert-wg mailing list
> Servercert-wg at cabforum.org
> https://lists.cabforum.org/mailman/listinfo/servercert-wg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20240904/999a9ab3/attachment-0001.html>