Discussion Period Begins: SC-083v2: Winter 2024-2025 Cleanup Ballot

[Martijn Katerbarg]

Purpose of Ballot

 

This ballot resolves a number of issues to improve the clarity and consistency of these documents. Changes incorporated are listed in the commit log of the pull request, and include:

 

• fix: cabforum#550 Incorrect capitalization of RFC2119 keyword
• fix: cabforum#541 de-capitalize undefined term
• fix: cabforum#539 Exactly one RCPOID
• fix: cabforum#538 Make sure the Policy Restricted profile is the targ…
• fix: cabforum#530, cabforum#529 and cabforum#531 updates
• fix: cabforum#523 update http to https for references
• fix: cabforum#502 Remove extraneous "for either"
• fix: cabforum#481 capitalize Trusted Roles
• fix: cabforum#465 Remove section 2.2 reference
• fix: cabforum#463 Remove extra parenthesis
• fix: cabforum#556 Clarify when MPIC is in scope
• fix: cabforum#557 clarify when a CA can and cannot issue.
• fix: cabforum#272 Clarify "a separate validation for that FQDN"
• fix: cabforum#273 Fix indenting
• fix: cabforum#370 perform CP/CPS updates at least once every 366 days
• fix: cabforum#387 Remove Section 8.4 reference to triennial audit
• fix: Remove States, Provinces or Countries from MPIC distance requirements
• fix: MPIC issuance prohibition clarification
• fix: Clarify usage of non-IDNA2003 usage
• fix: cabforum#498 extKeyUsage criticality correction
• fix: cabforum#505 allow 7 days for initial CRL issuance
• fix: Exclude IP Address from Subject Identity Information scope 
• fix: ESI 319 411-1 correction
• fix: Feedback from Aaron on ACME DCV methods

 

Motion

The following motion has been proposed by Martijn Katerbarg (Sectigo) and endorsed by Corey Bonnell (DigiCert) and Ryan Dickson (Chrome Root Program)

 

Motion Begins

 

MODIFY the "Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates" ("TLS Baseline Requirements") based on Version 2.1.1 as specified in the following redline:

https://github.com/cabforum/servercert/compare/096810820d605d1a2c90a9b10e4ef36ed65bd6cc%E2%80%A66e2df912899620b9893f217a6a3514dd7bd1e324

 

Motion Ends

 

This ballot proposes a Final Maintenance Guideline. The procedure for approval of this ballot is as follows:

 

Discussion (at least 7 days)

 

• Start time: 2024-12-30 10:00 UTC
• End time: Not before 2025-01-08 13:00 UTC

 

Vote for approval (7 days)

 

• Start time: TBD
• End time: TBD

 

 

[Tobias S. Josefowitz]

Hi Martijn,

thanks for this! While going over the changes, I noticed a change that was
made as part of

On Mon, 30 Dec 2024, 'Martijn Katerbarg' via Server Certificate WG (CA/B
Forum) wrote:

> * fix: cabforum#556 Clarify when MPIC is in scope

(https://github.com/cabforum/servercert/commit/0e1cfdebf84ed7cc16661b66fbb1345c15c1f109),
changing 3.2.2.4.8 ("IP Address"). The section currently reads:

| Confirming the Applicant's control over the FQDN by confirming that the
| Applicant controls an IP address returned from a DNS lookup for A or
| AAAA records for the FQDN in accordance with Section 3.2.2.5.
|
| CAs using this method MUST implement Multi-Perspective Issuance
| Corroboration as specified in Section 3.2.2.9. To count as
| corroborating, a Network Perspective MUST observe the same IP address as
| the Primary Network Perspective.

The proposed ballot (and linked commit) change the latter to:

"[...] a Network Perspective MUST observe the same challenge information
(i.e. Random Value or Request Token) as the Primary Network Perspective."

I wonder if this is intentional. The only valid "challenge information" in
this context would be an IP address, and "Random Value" or "Request Token"
are only given as examples and hermeneutics hopefully would lead one to
conclude that they are not actually valid in the context of 3.2.2.4.8. So
this change in the language may not even change what 3.2.2.4.8 requires,
but to me, it seems that this change is simply removing clarity from the
language, and I am not sure why that is something that we would want to
do.

Then there is

> * fix: Remove States, Provinces or Countries from MPIC distance
> requirements

which simply removes the "States, Provinces, or Countries they reside in"
from "Network Perspectives are considered distinct when the straight-line
distance between the two States, Provinces, or Countries they reside in is
at least 500 km.", requiring only 500 km straigt line distance instead.

This requirement has been included in the MPIC Ballot as a proxy for
diverse network perspectives, which is often not met by straight line
distances of 500 km, based upon recommendations by the Princeton
Researchers.

I can easily see that we could relax this requirement to allow for cases
in which it technically is not met but diverse network perspectives are
none the less heavliy likely as suggested by some other factor. Simply
removing the safeguard of "States, Provinces or Countries" in a Cleanup
Ballot however does not seem appropriate to me.

Tobi

[Henry Birge-Lee]

Hi Tobi and all,

I wanted to briefly provide some clarity on the straight line distance requirement topic. I am in favor of removing the language as proposed by the new ballot cleanup.

When I was participating in drafting the ballot language, there was some concern raised that cloud providers sometimes do not fully communicate the exact location of a region's data centers and also several availability zones in the same region that may exist (intentionally) in slightly different geographic locations. To provide robustness in the standard in light of these phenomena, language was proposed to base the 500 km diversity requirement on the states/provinces containing the data centers as opposed to the data centers locations themselves.

To clarify, no research done by my team at Princeton supports state/province level boundaries as providing significantly improved diversity for MPIC when compared to straight-line distance alone. What is supported by our research is that: 1) geographic distance between perspectives allows those perspectives to have distinct Internet routing tables and offer diverse routes and 2) there is measurably improved diversity when comparing perspectives on different continents. These two observations are addressed in the 500km distance and the RIR diversity requirements respectively.

To be clear, there are some routing phenomena that are seen at country boundaries (as opposed to state/province boundaries). Some countries have limited egress points (particularly regimes that partake in Internet censorship) to the external Internet potentially causing noticeably different routes from neighboring locations in other countries. However, this effect is not consistent as there are cases of very fluid borders (e.g., Western Europe) that are not as known for this phenomena. Currently, the studies published by our group at Princeton do not specifically address or measure this phenomena and at this time I do not see country-level diversity as a necessary addition to the MPIC requirements.

Furthermore, the previous language has several issues related to both ambiguity and the impact of geopolitics. In its current form, I personally feel the language is ambiguous as to whether it is the centroid or the border of the two states/provinces that must be 500km apart. Either way I don't think the state/province standard is very logical or beneficial. If the centroid of the states/provinces must be 500km apart, then a perspective in Niagara falls New York, USA and a perspective in Niagara falls Ontario Canada would be considered distinct because the province of Ontario is so large that its centroid is moved more than 500km from the center of NY State. If the more conservative approach of using a state/provinces border is considered, then a perspective in Quebec City and New York City would not be considered distinct even though these are separate countries and are 691 km apart geographically.

Thus, I am in favor of removing the state/province language and I feel this stance is backed by the research our group has done to date.

Best,

Henry

--
You received this message because you are subscribed to the Google Groups "Server Certificate WG (CA/B Forum)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to servercert-w...@groups.cabforum.org.
To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/2ecc3c21-3539-5ae2-d1c8-b304a6e09f9c%40opera.com.

[Tobias S. Josefowitz]

Hi Henry,

On Thu, 2 Jan 2025, Henry Birge-Lee wrote:

> I wanted to briefly provide some clarity on the straight line distance
> requirement topic. I am in favor of removing the language as proposed by
> the new ballot cleanup.

Thanks for your perspective, that does in fact address my concerns on the
subject. I am still 50:50 undecided on whether I would have done this as
part of a Cleanup Ballot myself, but with your added perspective I am OK
to roll with it as it is.

Tobi

[Martijn Katerbarg]

Hi Tobias,

 

Thank you for the feedback. And thanks Henry for chiming in.

> The proposed ballot (and linked commit) change the latter to:

 

>"[...] a Network Perspective MUST observe the same challenge information

>(i.e. Random Value or Request Token) as the Primary Network Perspective."

 

>I wonder if this is intentional. The only valid "challenge information" in

>this context would be an IP address, and "Random Value" or "Request Token"

>are only given as examples and hermeneutics hopefully would lead one to

>conclude that they are not actually valid in the context of 3.2.2.4.8. So

>this change in the language may not even change what 3.2.2.4.8 requires,

>but to me, it seems that this change is simply removing clarity from the

>language, and I am not sure why that is something that we would want to

>do.

 

This feedback seems in line with the feedback Aaron gave on a different method. I’ll update this to state “To count as corroborating, a Network Perspective MUST observe the same IP address as the Primary Network Perspective.”, as it used to.

> I am still 50:50 undecided on whether I would have done this as

>part of a Cleanup Ballot myself, but with your added perspective I am OK

>to roll with it as it is.

 

I’d have the same concern if it would set stricter requirements. In this case, unless there’s more pushback, I’ll roll with it as-is.

I’ll launch a v3 due to the latest change on Monday.

 

Regards,

Martijn

 

 

-- 

You received this message because you are subscribed to the Google Groups "Server Certificate WG (CA/B Forum)" group.

To unsubscribe from this group and stop receiving emails from it, send an email to servercert-w...@groups.cabforum.org.

To view this discussion visit https://urldefense.com/v3/__https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/36f8d287-7383-b61f-4ac1-5940389ae1df*40opera.com__;JQ!!J5K_pWsD!3rY-XYrHAHnERCVAAJ865oVYwzfI8_-LAfAoZTMaAR8H1fH1vehchc2uGc9GOUTeT5DnzS36PnYDrkmgsp8$.