[Servercert-wg] Discussion Period Begins - Ballot SC-067 V3: "Require domain validation and CAA checks to be performed from multiple Network Perspectives"

Tue Jul 2 12:26:28 UTC 2024

Hi Doug,

A response
<https://archive.cabforum.org/pipermail/servercert-wg/2024-June/004705.html>
was provided to the list on 6/27.

Thanks,
Ryan

On Tue, Jul 2, 2024 at 7:42 AM Doug Beattie via Servercert-wg <
servercert-wg at cabforum.org> wrote:

> Hi Chris,
>
>
>
> I sent over a question the other day but not sure it made it though the
> mail system, or maybe I did it the wrong way.  Here it is again:
>
>
>
> ----------------------------
>
> 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 <servercert-wg-bounces at cabforum.org> *On Behalf Of *Chris
> Clements via Servercert-wg
> *Sent:* Monday, July 1, 2024 4:43 PM
> *To:* So, Nicol <nicol.so at commscope.com>; 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"
>
>
>
> All,
>
> We have considered the communication from CommScope dated May 30, 2024.
>
> We would like to proceed with a vote on Ballot SC-067 V3 on July 15, 2024.
> If any SCWG participant has questions regarding the communication or the
> referenced patent, we encourage them to seek legal counsel.
>
> Thank you
> -Chris
>
>
>
> On Thu, May 30, 2024 at 4:50 PM So, Nicol via Servercert-wg <
> servercert-wg at cabforum.org> wrote:
>
> I’ve come to be aware of a granted US patent that *seems* relevant to the
> subject matter of Ballot SC-067 V3. The patent is US 11700263 B2 [1]. I
> don’t know whether the patent has been considered in previous discussions
> in the CA/B Forum or the SCWG, but I thought I should bring it to the
> attention of SCWG members, in case it has not.
>
>
>
> If the patent has not been considered previously, I propose that we extend
> the discussion period of this ballot so that members have an opportunity to
> consult with their legal counsel for advice.
>
>
>
> CommScope expresses no opinion on the patent, including but not limited to
> its validity and whether it covers the practices introduced in Ballot
> SC-067 V3.
>
>
>
> Best regards,
>
> Nicol So
>
> CommScope
>
>
>
> [1] https://patents.google.com/patent/US11700263B2/en
>
>
>
> *From:* Servercert-wg <servercert-wg-bounces at cabforum.org> *On Behalf Of *Chris
> Clements via Servercert-wg
> *Sent:* Monday, May 20, 2024 10:30 AM
> *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
>
> [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
>
> [14] https://github.com/cabforum/servercert/pull/507
>
> [15]
> 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
>
>
>
>
> *— 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
>
> _______________________________________________
> 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/20240702/6aab535a/attachment-0001.html>