Chunghwa Telecom votes YES on Ballot SC-067 V3
Best regards,
Chunghwa Telecom Co., Ltd.,
Tsung-Min Kuo, Ph.D.
From: Servercert-wg <[email protected]> On Behalf Of Chris
Clements via Servercert-wg
Sent: Monday, July 15, 2024 11:30 PM
To: CA/B Forum Server Certificate WG Public Discussion List
<[email protected]>
Subject: [外部郵件][Servercert-wg] Voting 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 (57 days)
- Start: 2024-05-20 14:30:00 UTC
- End: 2024-07-15 15:29:59 UTC
Vote for approval (7 days)
- Start: 2024-07-15 15:30:00 UTC
- End: 2024-07-22 15:30:00 UTC
本信件可能包含中華電信股份有限公司機密資訊,非指定之收件者,請勿蒐集、處理或利用本信件內容,並請銷毀此信件.
如為指定收件者,應確實保護郵件中本公司之營業機密及個人資料,不得任意傳佈或揭露,並應自行確認本郵件之附檔與超連結之安全性,以共同善盡資訊安全與個資保護責任.
Please be advised that this email message (including any attachments) contains
confidential information and may be legally privileged. If you are not the
intended recipient, please destroy this message and all attachments from your
system and do not further collect, process, or use them. Chunghwa Telecom and
all its subsidiaries and associated companies shall not be liable for the
improper or incomplete transmission of the information contained in this email
nor for any delay in its receipt or damage to your system. If you are the
intended recipient, please protect the confidential and/or personal information
contained in this email with due care. Any unauthorized use, disclosure or
distribution of this message in whole or in part is strictly prohibited. Also,
please self-inspect attachments and hyperlinks contained in this email to
ensure the information security and to protect personal information.
_______________________________________________
Servercert-wg mailing list
[email protected]
https://lists.cabforum.org/mailman/listinfo/servercert-wg
