[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 11:41:55 UTC 2024

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 <http://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 <http://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 <mailto: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 <mailto: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 <mailto: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 <mailto: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/a067e3cf/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 8445 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20240702/a067e3cf/attachment-0001.p7s>