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

Tue Sep 3 08:28:26 UTC 2024

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 <
servercert-wg at cabforum.org> 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://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
> Servercert-wg at cabforum.org
> https://e.as207960.net/w4bdyj/3uqVwwFkfOw6SPEW
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20240903/ee24e2ce/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4640 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20240903/ee24e2ce/attachment-0001.p7s>