Clarification on multiple RIR requirement for MPIC

[Christophe Bonjean]

Dear all,

 

We would like to clarify the expectations for the multiple Regional Internet Registry component in section 3.2.2.9 Multi-Perspective Issuance Corroboration of the TLS BRs:

 

Requirement

Effective March 15, 2026, the CA MUST implement Multi-Perspective Issuance Corroboration using at least three (3) remote Network Perspectives. The CA MUST ensure that the requirements defined in Quorum Requirements Table are satisfied, and the remote Network Perspectives that corroborate the Primary Network Perspective fall within the service regions of at least two (2) distinct Regional Internet Registries. If the requirements are not satisfied, then the CA MUST NOT proceed with issuance of the Certificate.

 

Clarification

The origin of the “two distinct Regional Internet Registries” seems to be https://github.com/ryancdickson/staging/pull/6#discussion_r1246083078 with this context “I think the one caveat with a definition based on RIRs is to make sure to clarify that we are referring to perspectives being located in the geographic regions being served by those RIRs, not necessarily operating out of address space allocated by those different RIRs. For example, Amazon is a US company and has large address blocks allocated by ARIN but these blocks are carved up and BGP routed to different data centers around the world. I think an AWS deployment based on data centers in various regions that fall under different RIRs is acceptable because each data center is using local providers and peers in that region for its Internet connectivity (even though if you run whois on the source IP of these different vantage points it will always come back as ARIN).”

 

While the intention of the comment is clear, without the context of this discussion on github, the requirement may also be read as “remote Network Perspectives must operate out of address space allocated by two (2) distinct RIRs”.

 

We would like to seek guidance whether “located in geographic regions served by those RIRs, but not necessarily operating from address space by those RIRs” is the commonly accepted reading by the community and meets the intent of this requirement?

 

Kind regards,

 

Christophe

 

[Arvid Vermote]

Arvid Vermote reacted to your message:

---

From: 'Christophe Bonjean' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Sent: Monday, March 2, 2026 12:06:43 PM
To: 'Dimitris Zacharopoulos (HARICA)' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Subject: [Servercert-wg] Clarification on multiple RIR requirement for MPIC

 

--
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/KUXPR03MB94798CA5CB50BB9C65927351E57EA%40KUXPR03MB9479.apcprd03.prod.outlook.com.

[Aaron Gable]

Yes, the "service regions" of Regional Internet Registries are the geographic regions which those registries operate. Each RIR authoritatively documents the extent of its service region, e.g. ARIN or LACNIC.

Aaron

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/SE1PPF080775CC16428CA9AC70D47E72944997EA%40SE1PPF080775CC1.apcprd03.prod.outlook.com.

[Henry Birge-Lee]

Hi all,

I personally think the language is clear from a technical perspective. "service regions" is a well-established term (see https://www.nro.net/about/rirs/ ) meaning the physical areas the RIRs serve which is documented clearly by each RIR. I don't think a reasonable interpretation would confuse the service region with the managed IP space.

With that said, I don't think adding "but not necessarily operating from address space by those RIRs" poses much risk, but I personally don't feel it is needed.

I guess there may be some amount of cognitive bias that could lead to misinterpretation since people more often associate RIRs with what addresses they manage not what land they serve.

Best,

Henry

[Dimitris Zacharopoulos (HARICA)]

On 3/2/2026 9:43 PM, Henry Birge-Lee wrote:

Hi all,

I personally think the language is clear from a technical perspective. "service regions" is a well-established term (see https://www.nro.net/about/rirs/ ) meaning the physical areas the RIRs serve which is documented clearly by each RIR. I don't think a reasonable interpretation would confuse the service region with the managed IP space.

With that said, I don't think adding "but not necessarily operating from address space by those RIRs" poses much risk, but I personally don't feel it is needed.

I guess there may be some amount of cognitive bias that could lead to misinterpretation since people more often associate RIRs with what addresses they manage not what land they serve.

Hi Henry,

I recall as part of the discussions that the decision to use the term RIR was exactly to require IP space allocated by those RIRs for two reasons:

1. Simplicity (using remote perspectives served by different RIRs clearly meets the requirement for distance)
2. Auditability (using IP addresses from different RIRs demonstrates that.... different RIRs are actively being used)

Christophe is right to highlight this issue as ambiguous. I don't know what the right answer is. If a cloud provider uses one RIR to allocate addresses globally, is that sufficient to minimize the risk of equally-specific prefix BGP attacks just as good as using two RIRs with different IP address allocations?

Perhaps one additional consideration for using two different RIRs was that each RIR has different policies for their Network Operators, hoping that one would be stricter than the other.

In any case, this should probably be clarified sooner than later.

Thanks Christophe for raising the issue.

Dimitris.

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/d7ce68fc-3fbb-47bc-87e6-af56a251770cn%40groups.cabforum.org.

[Aaron Gable]

Dimitris,

My memory differs from yours. The reason to use RIR was that we explicitly wanted geographic diversity (because interconnects vary much more based on geography than based on allocated IP range), but didn't want to get into the mess of defining things like "what is a content" or "what continent is Country X in" ourselves.

Aaron

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/75fb34b8-c3bb-4bb6-9839-c6463a84a165%40harica.gr.

[Aaron Gable]

Apologies, I pressed "send" before I included historical evidence.

Here is the GitHub comment in which the desire for a "two continent" requirement is discussed: https://github.com/ryancdickson/staging/pull/6#discussion_r1230066187

Below that, Michael Slaughter expresses concern about defining what a continent is: https://github.com/ryancdickson/staging/pull/6#discussion_r1232326672

And as a result, we settle on using RIR service regions: https://github.com/ryancdickson/staging/pull/6#discussion_r1246083078

Thanks,

Aaron

[Henry Birge-Lee]

Hi all,

Aaron's comments matches my memory as well.

People take RIR space and use them in regions all around the globe. I don't think the RIR holder of the original prefix allocation is a good indicator of routing diversity. Also, physical location of the infrastructure tracks much more closely to how things are routed than any type of administrative data.

In research I did we confirmed that even MPIC systems that exist in a single cloud provider have routing diversity sufficient to protect them from BGP attacks so long as there is physical diversity:

https://dl.acm.org/doi/10.1145/3730567.3764495

Best,

Henry

[Dimitris Zacharopoulos]

Thank you for the clarifications Aaron and Henry, as long as the diversity is sufficient I don't see any issue with using the address space of one RIR from multiple continents.

To avoid any doubts, I recommend updating the BRs to clarify in a future clean-up and clarifications ballot.


Best,

DZ.

Mar 3, 2026 20:25:34 Henry Birge-Lee <henryb...@gmail.com>:

…

--
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/d7ce68fc-3fbb-47bc-87e6-af56a251770cn%40groups.cabforum.org.

--
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/75fb34b8-c3bb-4bb6-9839-c6463a84a165%40harica.gr.

--
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/CAGxVKU4HUtfGyZPzzUt5H5-BShB_uxyvr7c6PxnZdRSzPw%3Dgwg%40mail.gmail.com.