Hi Roman, Aaron, The existing ballot text was intended to offer flexibility to adopters and was in response to community feedback on earlier drafts of the ballot (e.g., here <https://lists.cabforum.org/pipermail/validation/2023-June/001904.html>).
While we agree with your perspective re: simplicity, we equally believe CA Owners should be able to evaluate and adopt implementations that work best for them while also achieving the stated security objectives of the ballot. Thanks -Chris On Fri, Jun 28, 2024 at 10:34 AM Aaron Gable via Servercert-wg < [email protected]> wrote: > Let's Encrypt already implements MPIC, including doing CAA checks from all > of our perspectives. Obviously our experience is not universal, but we made > the decision to treat remote CAA checks the exact same as primary ones: > valid for at most 8 hours. Although this does increase the number of remote > CAA checks we perform, it keeps us much more confident in our code and > compliance. > > While I understand the motivation behind allowing remote CAA results to be > cached for an extended period, I personally don't think that the motivation > is strong enough to actually overcome the extra complications that it > brings. I would prefer that all remote results have the same lifetimes as > primary validation data. > > Aaron > > On Fri, Jun 28, 2024, 01:33 Roman Fischer via Servercert-wg < > [email protected]> wrote: > >> Thanks to both Doug and Chris for these examples. >> >> >> >> That makes me wonder: Wouldn't it be simpler (and thus less error-prone) >> to remove the CAA caching and just do the CAA check with each domain >> validation? >> >> >> >> Rgds >> Roman >> >> >> >> *From:* Servercert-wg <[email protected]> *On Behalf Of >> *Chris Clements via Servercert-wg >> *Sent:* Donnerstag, 27. Juni 2024 15:36 >> *To:* Doug Beattie <[email protected]> >> *Cc:* CA/B Forum Server Certificate WG Public Discussion List < >> [email protected]> >> *Subject:* Re: [Servercert-wg] Discussion Period Begins - Ballot SC-067 >> V2: "Require domain validation and CAA checks to be performed from multiple >> Network Perspectives" >> >> >> >> Hi Doug, >> >> >> >> Working through your examples - and adding one additional, below. >> >> >> >> Note: these examples strictly assume the to-be-issued certificates only >> contain the subject dnsName being described (i.e., if www.example.com is >> the named subject, we do not assume the certificate will also include a >> dnsName of example.com). >> >> >> >> - *Day 1: *CA performs MPIC for www.example.com >> >> >> - *Corroborating DCV*: This includes observing a domain validation >> random token from [N] perspectives, as required by quorum expectations. >> - *Corroborating CAA*: This includes observing permission to issue >> when checking CAA from [N] perspectives, as required by quorum >> expectations. >> >> >> >> - *Day 100: *A certificate request is made for *shop.example.com >> <http://shop.example.com/>* from the same applicant >> >> >> - *Corroborating DCV*: This includes observing a domain validation >> random token from [N] perspectives, as required by quorum expectations. >> - *Corroborating CAA*: This MAY NOT be skipped given the >> certificate issued to the customer on Day 1 was for www.example.com >> and shop.example.com is not a subdomain of www.example.com. The >> process must be completed as it is described in the “Day 1" example. >> >> >> >> - *Day 150: *A certificate request is made for x1.www.example.com >> <http://www.x1.example.com/> from the same applicant >> >> >> - *Corroborating DCV*: This includes observing a domain validation >> random token from [N] perspectives, as required by quorum expectations. >> - *Corroborating CAA*: This MAY be skipped given the MPIC CAA >> event on Day 1 for www.example.com and the described 398-day reuse >> period because x1.www.example.com is a subdomain of www.example.com >> . >> >> >> >> - *Day 400: *A certificate request is made for x2.www.example.com >> <http://www.x1.example.com/> >> >> >> - *Corroborating DCV*: This includes observing a domain validation >> random token from [N] perspectives, as required by quorum expectations. >> - *Corroborating CAA*: Prior reuse cache for www.example.com (Day >> 1) is now expired. The CA must observe permission to issue when >> checking >> CAA from [N] perspectives, as required by quorum expectations. >> >> >> >> Hopefully this helps clarify, but let us know if you have any questions. >> >> -Chris >> >> >> P.S., this response has also been copied to the same doc >> <https://docs.google.com/document/d/11V43IrkwGbDvL69hxm2smukJfgZH9Qs0md4CPNdbViw/edit> >> we referenced in response to Christophe in case of any formatting issues >> conveyed through the list. >> >> >> >> On Tue, Jun 25, 2024 at 2:17 PM Doug Beattie <[email protected]> >> wrote: >> >> Hi Chris, >> >> >> >> I was taking a closer look at the ballot and specifically this section on >> caching the remote node CAA checks: >> >> >> >> A CA MAY reuse corroborating evidence for CAA record quorum compliance >> for a maximum of 398 days. After issuing a Certificate to a domain, remote >> Network Perspectives MAY omit retrieving and processing CAA records for the >> same domain or its *subdomains *in subsequent Certificate requests from >> the same Applicant for up to a maximum of 398 days. >> >> >> >> I think understand the first sentence – if you do a full check on a FQDN >> (the value that you will put into the SAN field), then you only need to do >> the normal CAA check for that FQDN from the primary node for 398 days. >> >> >> >> I don’t understand the references to domain and subdomains in the second >> sentence. Can you explain how this should work? >> >> - You do a full MIC check on www.example.com on day 1 >> - You find CAA records with permission to issue on example.com on >> primary and remote nodes so you issue >> - Day 100, customer wants to issue to shop.example.com >> >> >> - This is a subdomain of example.com where we found the records >> permitting issuance on day 1. >> - What checks do we need to do for this request? >> >> >> - Day 150, Applicant wants to issue to x1.www.example.com (a >> subdomain of www.example.com we issued on day 1): >> >> >> - What checks would be required here? >> >> >> >> Maybe I’m reading too much into this… >> >> >> >> Thanks! >> >> >> >> Doug >> >> >> >> *From:* Servercert-wg <[email protected]> *On Behalf Of >> *Chris Clements via Servercert-wg >> *Sent:* Friday, April 26, 2024 1:01 PM >> *To:* CA/B Forum Server Certificate WG Public Discussion List < >> [email protected]> >> *Subject:* [Servercert-wg] Discussion Period Begins - Ballot SC-067 V2: >> "Require domain validation and CAA checks to be performed from multiple >> Network Perspectives" >> >> >> >> *Purpose of Ballot SC-067 V2*: >> >> >> >> 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). >> >> >> >> *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 >> >> [12] https://github.com/cabforum/servercert/pull/487 >> >> [13] >> https://github.com/cabforum/servercert/compare/6d10abda8980c6eb941987d3fc26e753e62858c0..5224983ef0a6f94c18808ea3469e7a5ae35746e5 >> >> >> >> 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..5224983ef0a6f94c18808ea3469e7a5ae35746e5 >> >> >> >> *— Motion Ends —* >> >> >> >> This ballot proposes a Final Maintenance Guideline. The procedure for >> approval of this ballot is as follows: >> >> >> >> *Discussion (at least 14 days)* >> >> - Start: 2024-04-26 17:00:00 UTC >> >> - End no earlier than: 2024-05-10 17:00:00 UTC >> >> >> >> *Vote for approval (7 days)* >> >> - Start: TBD >> >> - End: TBD >> >> >> >> _______________________________________________ >> Servercert-wg mailing list >> [email protected] >> https://lists.cabforum.org/mailman/listinfo/servercert-wg >> > _______________________________________________ > Servercert-wg mailing list > [email protected] > https://lists.cabforum.org/mailman/listinfo/servercert-wg >
_______________________________________________ Servercert-wg mailing list [email protected] https://lists.cabforum.org/mailman/listinfo/servercert-wg
