Hi Roman, Whilst not representing a CA myself I do a lot of work on WebPKI at the Max-Planck Institute for Informatics and I'm happy to offer my time to review proposals and provide an outside perspective.
Thanks, Q Misell ------------------------------ Any statements contained in this email are personal to the author and are not necessarily the statements of the company unless specifically stated. AS207960 Cyfyngedig, having a registered office at 13 Pen-y-lan Terrace, Caerdydd, Cymru, CF23 9EU, trading as Glauca Digital, is a company registered in Wales under № 12417574 <https://find-and-update.company-information.service.gov.uk/company/12417574>, LEI 875500FXNCJPAPF3PD10. ICO register №: ZA782876 <https://ico.org.uk/ESDWebPages/Entry/ZA782876>. UK VAT №: GB378323867. EU VAT №: EU372013983. Turkish VAT №: 0861333524. South Korean VAT №: 522-80-03080. AS207960 Ewrop OÜ, having a registered office at Lääne-Viru maakond, Tapa vald, Porkuni küla, Lossi tn 1, 46001, trading as Glauca Digital, is a company registered in Estonia under № 16755226. Estonian VAT №: EE102625532. Glauca Digital and the Glauca logo are registered trademarks in the UK, under № UK00003718474 and № UK00003718468, respectively. On Tue, 3 Sept 2024 at 10:12, Roman Fischer via Servercert-wg < [email protected]> 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 < > [email protected]> > *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 <[email protected]> *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 < > [email protected]> > *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://e.as207960.net/w4bdyj/503I4I3ZK7lfZK29 > > [2] > https://e.as207960.net/w4bdyj/M4PNVi00gT8vf7Ih > > > [3] > https://e.as207960.net/w4bdyj/iGUzEJV0Id4PufCi > > > [4] https://e.as207960.net/w4bdyj/g3xkzTT8iH59dYwW > > [5] > https://e.as207960.net/w4bdyj/SHHoCsxWkNZZgO33 > > > [6] > https://e.as207960.net/w4bdyj/Odbf9FnGrz3D5BYT > > > [7] > https://e.as207960.net/w4bdyj/MTcigAAJTsidEOBL > > [8] > https://e.as207960.net/w4bdyj/yaxkA6FNhLLUK9e4 > > [9] > https://e.as207960.net/w4bdyj/dYE2pkNx2VK6fnzu > > > [10] https://e.as207960.net/w4bdyj/iOFV0qdSByAvzgrG > > [11] https://e.as207960.net/w4bdyj/6vBLPqGtswg8M6L4 > > [12] https://e.as207960.net/w4bdyj/TOKlOINsiTL8bcFv > > [13] > https://e.as207960.net/w4bdyj/6fiJuFSRMeYPYgp1 > > [14] https://e.as207960.net/w4bdyj/wCcdBQ6SFrZkfip0 > > [15] > https://e.as207960.net/w4bdyj/Q5vBG7xBDSF1mq9A > > > > > 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://e.as207960.net/w4bdyj/B5Pot5cxDVKforko > > > > > *— 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 > [email protected] > https://e.as207960.net/w4bdyj/3uqVwwFkfOw6SPEW >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Servercert-wg mailing list [email protected] https://lists.cabforum.org/mailman/listinfo/servercert-wg
