Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Version 2: Add Multi-Perspective Domain and CAA Checking Requirements to the BRs #8

Closed
wants to merge 50 commits into from
Closed

Version 2: Add Multi-Perspective Domain and CAA Checking Requirements to the BRs #8

Changes from 9 commits
Commits
Show all changes
50 commits
Select commit Hold shift + click to select a range
d31bb7e
Align with approved "Make OCSP Optional" and additional clean-ups.
ryancdickson Aug 7, 2023
7384a29
Update BR.md
ryancdickson Aug 7, 2023
1ad60e2
Update BR.md
ryancdickson Aug 8, 2023
4b003c0
Update BR.md
ryancdickson Aug 8, 2023
dc33cd3
Update docs/BR.md
ryancdickson Aug 15, 2023
9ee6b11
Update docs/BR.md
ryancdickson Aug 15, 2023
0be1808
Update docs/BR.md
ryancdickson Aug 15, 2023
d71f980
Update docs/BR.md
ryancdickson Aug 15, 2023
3976bd5
Update docs/BR.md
ryancdickson Aug 15, 2023
9e4d84f
Update docs/BR.md
ryancdickson Aug 15, 2023
d460f39
Update docs/BR.md
ryancdickson Aug 15, 2023
86ff14b
Update BR.md
ryancdickson Aug 15, 2023
8e51895
Update BR.md
ryancdickson Aug 15, 2023
56d56b1
Update docs/BR.md
ryancdickson Aug 16, 2023
de1ff61
Update Facility & Service Provider requirements
ryancdickson Sep 28, 2023
e013f27
Update definitions, clarify requirements, re-organize, delay implemen…
ryancdickson Sep 28, 2023
46f6059
Clarify distinctness of perspectives.
ryancdickson Oct 11, 2023
208cdd4
Clarify "Primary Network Perspective"
ryancdickson Oct 11, 2023
b5b3c5a
Clarify retry
ryancdickson Oct 11, 2023
4d658f5
Update docs/BR.md
ryancdickson Oct 13, 2023
cb8ae10
Update docs/BR.md
ryancdickson Oct 13, 2023
8564edb
Update docs/BR.md
ryancdickson Oct 13, 2023
a3a2820
Update docs/BR.md
ryancdickson Oct 13, 2023
fd9e699
Update docs/BR.md
ryancdickson Oct 13, 2023
d00d997
Update docs/BR.md
ryancdickson Oct 13, 2023
df648da
Update docs/BR.md
ryancdickson Oct 13, 2023
458acc4
Update docs/BR.md
ryancdickson Oct 13, 2023
bb7c98a
Update docs/BR.md
ryancdickson Oct 13, 2023
1232a72
Update docs/BR.md
ryancdickson Oct 13, 2023
b423e5c
Apply suggestions from code review
ryancdickson Oct 13, 2023
25ce5a1
Update docs/BR.md
ryancdickson Oct 13, 2023
8808bc6
Update docs/BR.md
ryancdickson Oct 13, 2023
4f53056
Update docs/BR.md
ryancdickson Oct 13, 2023
fd83a4b
Update BR.md
ryancdickson Oct 13, 2023
2f158b2
Update docs/BR.md
ryancdickson Oct 16, 2023
43cc1c2
Remove extraneous CAA references
ryancdickson Oct 16, 2023
ba97963
Update BR.md
ryancdickson Oct 16, 2023
fa0bb58
Update BR.md
ryancdickson Oct 23, 2023
d40f161
Update BR.md
ryancdickson Oct 23, 2023
6bda42e
Explicitly require use of an encrypted channel between CA and NP
ryancdickson Oct 27, 2023
cb88b7d
Clarify separation between Primary and Remote Network Perspectives
ryancdickson Oct 27, 2023
0144a4c
Add context for "determinations"
ryancdickson Oct 30, 2023
60a2e60
Remove Onion Domain Names from scope
ryancdickson Jan 10, 2024
0525044
Address #466
ryancdickson Jan 10, 2024
8315b6a
Carryover - address #466
ryancdickson Jan 10, 2024
8f35b32
Update BR.md
ryancdickson Jan 15, 2024
6cca62b
Update BR.md
ryancdickson Jan 15, 2024
278f3b8
Update BR.md
ryancdickson Jan 15, 2024
5e4bc03
Update BR.md
ryancdickson Jan 15, 2024
54ed662
Update BR.md
ryancdickson Jan 23, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
40 changes: 19 additions & 21 deletions docs/BR.md
View file
Open in desktop
ryancdickson marked this conversation as resolved.
Show resolved Hide resolved
Original file line number Diff line number Diff line change
Expand Up @@ -773,7 +773,7 @@ If a Random Value is used, the CA SHALL provide a Random Value unique to the Cer
ii. if the Applicant submitted the Certificate request, the time frame permitted for reuse of validated information relevant to the Certificate (such as in [Section 4.2.1](#421-performing-identification-and-authentication-functions) of these Guidelines or Section 11.14.3 of the EV Guidelines).

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 challenge information (e.g., Random Value or Request Token) as the Primary Domain Validation Determination; and
- the same challenge information (i.e. Random Value or Request Token) as the Primary Domain Validation Determination; and
- evidence confirming the CA's authority to issue as determined by the Primary CAA Validation, as specified in Section 3.2.2.8.

**Note**: Once the FQDN has been validated using this method, the CA MAY also issue Certificates for other FQDNs that end with all the Domain Labels of the validated FQDN. This method is suitable for validating Wildcard Domain Names.
Expand Down Expand Up @@ -902,7 +902,7 @@ If a Random Value is used, then:
2. The Random Value MUST remain valid for use in a confirming response for no more than 30 days from its creation. The CPS MAY specify a shorter validity period for Random Values, in which case the CA MUST follow its CPS.

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 challenge information (e.g., Random Value or Request Token) as the Primary Domain Validation Determination; and
- the same challenge information (i.e. Random Value or Request Token) as the Primary Domain Validation Determination; and
- evidence confirming the CA's authority to issue as determined by the Primary CAA Validation, as specified in Section 3.2.2.8.

**Note**:
Expand All @@ -925,7 +925,7 @@ If the CA follows redirects, the following apply:
3. Redirects MUST be to resource URLs accessed via Authorized Ports.

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 challenge information (e.g., Random Value or Request Token) as the Primary Domain Validation Determination; and
- the same challenge information (i.e. Random Value or Request Token) as the Primary Domain Validation Determination; and
- evidence confirming the CA's authority to issue as determined by the Primary CAA Validation, as specified in Section 3.2.2.8.

**Note**:
Expand Down Expand Up @@ -963,7 +963,7 @@ If a Random Value is used, the CA SHALL provide a Random Value unique to the cer
ii. if the Applicant submitted the certificate request, the time frame permitted for reuse of validated information relevant to the certificate (such as in [Section 4.2.1](#421-performing-identification-and-authentication-functions) of this document).

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:
ryancdickson marked this conversation as resolved.
Show resolved Hide resolved
- the same challenge information (e.g., Random Value or Request Token) as the Primary Domain Validation Determination; and
- the same challenge information (i.e. Random Value or Request Token) as the Primary Domain Validation Determination; and
- evidence confirming the CA's authority to issue as determined by the Primary CAA Validation, as specified in Section 3.2.2.8.

##### 3.2.2.5.2 Email, Fax, SMS, or Postal Mail to IP Address Contact
Expand Down Expand Up @@ -1067,14 +1067,14 @@ CAs MUST document potential issuances that were prevented by a CAA record in suf

#### 3.2.2.9 Multi-Perspective Issuance Corroboration
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm unable to leave a comment on line 1058 (https://github.com/ryancdickson/staging/pull/8/files#diff-e0ac1bd190515a4f2ec09139d395ef6a8c7e9e5b612957c1f5a2dea80c6a6cfeR1058) since it wasn't modified, so I'll leave it here:

My understanding is that CAs will be able to issue if the lookup failures for both the Primary and Secondary Network Perspectives are consistent. For example, if the Primary Perspective receives a SERVFAIL in response to a CAA lookup for "example.com" and the Secondary Network Perspectives receive the same, then this can be treated as permission to issue (assuming, of course, there's no DNSSEC chain to the ICANN root and the CA infrastructure isn't experiencing issues). However, if the Primary Perspective observes a SERVFAIL and the Secondary Perspectives receive a NOERROR/NXDOMAIN, then this cannot be treated as permission to issue as the Primary and Secondary Perspectives have received differing responses.

Is this correct, or is the expectation different here?

Copy link

@birgelee birgelee Oct 13, 2023 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While this is one interpretation of the text, my original thought was that it would be OK for a CA to proceed with issuance under the second scenario described. Even though the error signals from the different perspectives are distinct, in the absence of a trusted DNSSEC chain, both of these can be treated as permission to issue. Thus, my original interpretation of this was "corroborates" is essentially a binary state and both the primary and secondary perspectives here interpret their DNS response as permission to issue implying issuance can proceed.

While requiring matching error messages or matching responses is clearly a stricter policy, I do not think it adds too much security, and I worry a bit about it introducing false positives. If an adversary has launched a BGP hijack which effects some of a CA's perspectives, it has the liberty of choosing what types of DNS responses it wants to generate and could likely generate responses that match the victims' (bypassing this sameness check). On the benign side, in our last study we noticed discrepancies in DNS configurations when probed from multiple perspectives. Many DNS providers rely heavily on IP anycast so the DNS queries from the different perspectives are often being answered by different servers (which can have different configurations or out-of-date zone files). Thus, while varying error messages may seemingly indicate an attack, I could also see it arising in benign circumstances, and I believe an adversary could avoid this check.

Additionally, we considered differentiating between different types of responses in the domain validation check, but ultimately backed away from it and went more towards reducing each vantage point's response to a binary state which is then processed in the quorum policy. I personally feel for consistency and simplicity it would also make sense to use that reasoning here.

I would be in favor of adding language to clarify that permission to issue is a binary state (i.e., can issue or can't issue) which is then processed by the quorum policy.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Line 1061 of the current draft text says:

Multi-Perspective Issuance Corroboration attempts to corroborate the determinations made by the Primary Network Perspective from multiple additional Network Perspectives

It is my understanding that this explanatory text is stating that the Primary Network Perspective provides the canonical response, and the requisite number of additional Network Perspectives MUST provide the same response to corroborate the response as retrieved by the Primary Network Perspective. My understanding of the rationale is that the Primary Network Perspective is audited under the NetSec audit regime, whereas secondary Network Perspectives need not be audited. Thus, there is a higher level of assurance from the responses provided by the Primary as opposed to secondary Network Perspectives.

Given this rationale, I interpreted the CAA allowance for issuance upon encountering lookup errors as "the requisite number of secondary Network Perspectives must observe the failure observed by the Primary Network Perspective in order to be treated as permission to issue". I think clarifying language is needed if the intended requirement is actually looser.

Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@CBonnell - would better establishing context for "determinations" (and doing so at a sufficient level of detail that's focused on the outcome of the checks) address this concern?

From: Multi-Perspective Issuance Corroboration attempts to corroborate the determinations made by the Primary Network Perspective from multiple additional Network Perspectives before Certificate issuance.

To: Multi-Perspective Issuance Corroboration attempts to corroborate the determinations (i.e., domain validation pass/fail, CAA permission/prohibition) made by the Primary Network Perspective from multiple additional Network Perspectives before Certificate issuance.

Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Update: Added above suggestion in 0144a4c, still waiting for feedback from @CBonnell.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Apologies for missing this; it apparently got lost in a flurry of Github notifications. I don't think the proposed language change would address the difference in interpretation for the "CAA lookup failure" case as discussed above in this comment thread. I interpret the proposed language the same as the previous language: a CAA lookup failure by the Primary Network Perspective while the Secondary Perspectives observe a lookup success cannot be treated as permission to issue, as the Secondary Perspective results do not corroborate the Primary Perspective's lookup failure.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe a solution could be to add @ryancdickson 's language but also put an explicit statement to cover this case in the section on MPIC CAA checking:

When corroborating a CAA check from multiple Network Perspectives, for the result of the CAA check at an additional Network Perspective to count as corroborating the Primary Network Perspective, the CAA check from the additional Network Perspective MUST be interpreted as permission to issue as outlined in Section 3.2.2.8. However, a CA MAY count the response of an additional Network Perspective as corroborating the Primary Network Perspective even if CAA records seen by the additional Network Perspective do not match the records seen by the Primary Network Perspective or one or both of the additional Network Perspective or Primary Network Perspective experience an acceptable CAA record lookup failure as defined in Section 3.2.2.8.

Personally I feel adding language along these lines to explicitly allow this case would sufficiently clarify things in the document. Thinking more on this topic I do feel that some of the confusion comes from the use of the word "corroborate" which implies some level of similarity in responses (which makes sense in the DV context where a similar random token on piece of contact information must be observed). However, for CAA checking I think it makes the most sense to not rely on similarity (particularly with some lookup failures being permission to issue in the CAA context) but instead ensure a sufficient number of network perspectives interpret their lookups as permission to issue. Maybe another approach would be to avoid using the word "corroborate" in the CAA context, but I worry a bit reworking the whole draft with that angle would simply introduce more wording issue.


Multi-Perspective Issuance Corroboration attempts to corroborate the Primary Domain Validation Determination and Primary CAA Determination by re-completing the entirety of the domain validation process from multiple additional geographic Network Perspectives before subscriber certificate issuance. This process can improve protection against equally-specific prefix Border Gateway Protocol (BGP) attacks or hijacks.
Multi-Perspective Issuance Corroboration attempts to corroborate the Primary Domain Validation Determination and Primary CAA Determination (jointly referred to as "primary determinations") by re-completing the entirety of the domain validation process from multiple additional geographic Network Perspectives before subscriber certificate issuance. This process can improve protection against equally-specific prefix Border Gateway Protocol (BGP) attacks or hijacks.

Network Perspectives are considered distinct when the straight-line distance between the two States, Provinces, or Countries they reside in are separated by a distance of at least 500 km.
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.

The network infrastructure providing Internet connectivity to a Network Perspective MAY be administered by the same organization providing the computational services required to operate the Network Perspective.

Each primary and corroborating Network Perspective MUST independently complete the entirety of the following:
- the domain validation process used to establish the Primary Domain Validation Determination (i.e., including DNS lookups for A records), and
- the domain validation process used to establish the Primary Domain Validation Determination (including DNS lookups for A records), and
- the CAA record-checking process used to establish the Primary CAA Determination.

Results or information obtained from one Network Perspective MUST NOT be reused or cached when performing validation through subsequent Network Perspectives (e.g., different Network Perspectives cannot rely on a shared DNS cache to prevent an adversary with control of traffic from one Network Perspective from poisoning the DNS cache used by other Network Perspectives).
Expand All @@ -1087,20 +1087,18 @@ CAs MAY immediately retry Multi-Perspective Issuance Corroboration using the sam

Phased Implementation Timeline:
- *Effective March 15, 2024*, the CA SHOULD implement Multi-Perspective Issuance Corroboration as described in this section.
- *Effective September 15, 2024*, the CA MUST implement Multi-Perspective Issuance Corroboration as described in this section; however, the CA MAY proceed with certificate issuance if either the Primary Domain Validation Determination or Primary CAA Determination is not corroborated as defined in the "# of Network Perspectives and Quorum Requirements" table.
- *Effective March 15, 2025*, the CA MUST implement Multi-Perspective Issuance Corroboration as described in this section. The CA MUST NOT proceed with certificate issuance if either the Primary Domain Validation Determination or Primary CAA Determination is not corroborated as defined in the "# of Network Perspectives and Quorum Requirements" table and the "Defining Corroborating CAA Evidence" table.
- *Effective September 15, 2024*, the CA MUST implement Multi-Perspective Issuance Corroboration as described in this section. However, the CA MAY proceed with certificate issuance if the number of additional Network Perspectives which do not corroborate the primary determinations ("non-corroborations) is greater than the number allowed in the "Quorum Requirements" table. The CA MUST attempt to corroborate the primary determinations from at least two (2) additional Network Perspectives.
ryancdickson marked this conversation as resolved.
Show resolved Hide resolved
- *Effective March 15, 2025*, the CA MUST NOT proceed with certificate issuance if the number of additional Network Perspectives which do not corroborate the primary determinations is greater than the number allowed in the "Quorum Requirements" table.
- *Effective September 15, 2025*, the CA MUST attempt to corroborate the primary determinations from at least three (3) additional Network Perspectives. Additionally, the Network Perspectives that do corroborate the primary determinations MUST fall within the service regions of at least two (2) distinct regional Internet registries.
- *Effective March 15, 2026*, the CA MUST attempt to corroborate the primary determinations from at least four (4) additional Network Perspectives.
- *Effective September 15, 2026*, the CA MUST attempt to corroborate the primary determinations from at least five (5) additional Network Perspectives.

Even though the "# of Network Perspectives and Quorum Requirements" table permits issuance when some Network Perspectives do not corroborate the Primary Domain Validation Determination and Primary CAA Determination, the set of locations of the Network Perspectives that do corroborate the Primary Domain Validation Determination and Primary CAA Determination MUST fall within the service regions of at least two (2) distinct regional Internet registries for a CA to proceed with certificate issuance after September 15, 2025.
Table: Quorum Requirements
Copy link
Owner Author

@ryancdickson ryancdickson Oct 23, 2023 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Validation Subcommittee Comment (summarized): The required number of remote perspectives needs to be clarified.

Response:

The "Quorum Requirements" table describes the maximum number of "non-corroborations" given the number of distinct remote network perspectives used for an MPIC attempt. The end of 3.2.2.9 presents the "Phased Implementation Timeline," which describes implementation milestones that strengthen over time. Over the proposed implementation timeline, quorum requirements increase from undefined (during the period where CAs SHOULD be implementing MPIC but are not otherwise required) to 5+ (beginning in December 2026).

I've tried summarizing the phasing below, with changes across phases highlighted in code block formatting.

Phase 1: June 15, 2024 - December 14, 2024 ("CAs SHOULD implement MPIC"):

  • MUST implement MPIC? No ("SHOULD" not "MUST")
  • Required quorum?: N/A (MPIC not required)
  • MUST block issuance if the quorum is not met: N/A (MPIC not required)
  • Geographic diversity requirements?: N/A (MPIC not required)

Phase 2: December 15, 2024 - June 14, 2025 ("CAs MUST implement MPIC in monitoring mode*"):

  • MUST implement MPIC? Yes
  • Required quorum?: Minimally, 2 remote perspectives must be used. If using less than 6 remote perspectives, 1 non-corroboration is allowed. If using 6 or more remote perspectives, 2 non-corroborations are allowed.
  • MUST block issuance if the quorum is not met: No.
  • Geographic diversity requirements?: Perspectives must be 500km from 1) the primary perspective and 2) all other perspectives used in the quorum.

* Note: "Monitoring Mode" is a nickname for this period. As opposed to "blocking mode" (described in the next milestone), CAs may still issue a certificate if quorum requirements are not met during this period. This period was intended to offer flexibility to CA owners as they stood up this new capability (i.e., allows for fine tuning implementations).

Phase 3: June 15, 2025 - December 14, 2025 ("CAs MUST implement MPIC in blocking mode*"):

  • MUST implement MPIC? Yes
  • Required quorum?: Minimally, 2 remote perspectives must be used. If using less than 6 remote perspectives, 1 non-corroboration is allowed. If using 6 or more remote perspectives, 2 non-corroborations are allowed.
  • MUST block issuance if quorum is not met: Yes.
  • Geographic diversity requirements?: Perspectives must be 500km from 1) the primary perspective and 2) all other perspectives used in the quorum.

* Note: "Blocking Mode" is a nickname. As opposed to "monitoring mode" (described in the last milestone), CAs MUST NOT issue a certificate if quorum requirements are not met from this point forward.

Phase 4: December 15, 2025 - June 14, 2026 (requirements strengthen):

  • MUST implement MPIC? Yes
  • Required quorum?: Minimally, 3 remote perspectives must be used. If using less than 6 remote perspectives, 1 non-corroboration is allowed. If using 6 or more remote perspectives, 2 non-corroborations are allowed.
  • MUST block issuance if the quorum is not met: Yes.
  • Geographic diversity requirements?: Perspectives must be 500km from 1) the primary perspective and 2) all other perspectives used in the quorum. Additionally, corroborating perspectives must fall within the service regions of at least 2 distinct regional Internet registries.

Phase 5: June 15, 2026 - December 14, 2026 (requirements strengthen):

  • MUST implement MPIC? Yes
  • Required quorum?: Minimally, 4 remote perspectives must be used. If using less than 6 remote perspectives, 1 non-corroboration is allowed. If using 6 or more remote perspectives, 2 non-corroborations are allowed.
  • MUST block issuance if the quorum is not met: Yes.
  • Geographic diversity requirements?: Perspectives must be 500km from 1) the primary perspective and 2) all other perspectives used in the quorum. Additionally, corroborating perspectives must fall within the service regions of at least 2 distinct regional Internet registries.

Phase 6: December 15, 2026 (requirements strengthen):

  • MUST implement MPIC? Yes
  • Required quorum?: Minimally, 5 remote perspectives must be used. If using less than 6 remote perspectives, 1 non-corroboration is allowed. If using 6 or more remote perspectives, 2 non-corroborations are allowed.
  • MUST block issuance if the quorum is not met: Yes.
  • Geographic diversity requirements?: Perspectives must be 500km from 1) the primary perspective and 2) all other perspectives used in the quorum. Additionally, corroborating perspectives must fall within the service regions of at least 2 distinct regional Internet registries.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. if a remote perspective didn't replied back at all, (timeout/connection failed) would it considered it made non-corroboration reply or we don't consider it as used and not counted for quorum nor non-corroborations?
  2. Is Primary Perspective counted for at least 2 RIR among corroborating perspectives requirement?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Based on past discussions, if a remote perspective is selected to be used but cannot be reached, I believe the intended interpretation is that it "does not corroborate." I feel this simplifies the requirement language by strictly keeping keeping the definition of corroborate as a binary (i.e., either does or does not corroborate with no intermediate state) and presents some robustness against an adversary that is willing to DoS a perspective in an effort to prevent that perspective from detecting its attack. There should be no barrier to a CA, after a filed MPIC attempt, immediately retrying MPIC with a different set of perspectives which can help for handling cases of benign perspectives going offline.

I believe in one of the past github threads there was a discussion about the primary perspective counting towards the 2 RIR count. From what I remember the consensus was that the Primary Perspective does not count and the additional perspectives must be spread over two RIRs. This helps prevent the case of the Primary Perspective being in one RIR and all additional perspectives being concentrated in another.

@orangepizza I am curious to know if you feel additional clarifying language should be added to the draft for these cases.

Copy link

@orangepizza orangepizza Dec 6, 2023 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

at least for multi-RIR requirement, because remote perspectives are corroborating with primary by definition:
non-replying RIR was more a question about if dead perspective counted in X remote perspectives used, or counter need to call another to fill it's slot: an extreme example would be typo in list of remote perspective list made one point a nonexist server: would they passed as a non-corraboration, or it'll make entire process not satisfying MPV requirement?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking over the current language I actually feel the RIR requirement is pretty well clarified as being interpreted this way:
https://github.com/ryancdickson/staging/blob/0144a4c0e544173d22a0f09fd4c45d4a52519992/docs/BR.md?plain=1#L1098C29-L1098C29

*Effective December 15, 2025*, the CA MUST implement Multi-Perspective Issuance Corroboration using at least three (3) remote Network Perspectives. The CA MUST NOT proceed with certificate issuance if the number of non-corroborations is greater than allowed in the Quorum Requirements table and if the remote Network Perspectives that do corroborate the determinations made by the Primary Network perspective do not fall within the service regions of at least two (2) distinct regional Internet registries.

This seems to clearly state that the 2 RIR service region requirement is 1) only applied to remote Network Perspectives and 2) only applied to perspectives that do corroborate (i.e., non-corroborating perspectives do not count towards diversity).

With this in mind I feel that a dead perspective would count towards X remote perspectives used as long as the CA attempted to reach it, but would not count towards the corroboration count or the 2 distinct RIR requirement. Thus, whether the CA had to initiate a subsequent MPIC request and redial another perspective depends on whether the quorum and the diversity requirement can be satisfied without that perspective.

Is there a particular sentence you would recommend adding to this?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes I just looked this summery and not that part of document: sorry for inconvenience

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no worries. This part of the document recently changed and in past versions I feel this behavior was not as clearly specified


Table: # of Network Perspectives and Quorum Requirements

| # Network Perspectives used | Description of Configuration and Quorum Requirements | Permitted Use |
|--- |------------------------------ |------------------------------ |
| 2 | This configuration relies on two (2) Network Perspectives.<br><br>When this configuration is used, at least one (1) of the Network Perspectives MUST corroborate the Primary Domain Validation Determination and Primary CAA Determination. | This configuration MUST NOT be used after 9/15/2025. |
| 3 | This configuration relies on three (3) Network Perspectives.<br><br>When this configuration is used, at least two (2) of the Network Perspectives MUST corroborate the Primary Domain Validation Determination and Primary CAA Determination. | This configuration MUST NOT be used after 3/15/2026. |
| 4 | This configuration relies on four (4) Network Perspectives.<br><br>When this configuration is used, at least three (3) of the Network Perspectives MUST corroborate the Primary Domain Validation Determination and Primary CAA Determination. | This configuration MUST NOT be used after 9/15/2026. |
| 5 | This configuration relies on five (5) Network Perspectives.<br><br>When this configuration is used, at least four (4) of the Network Perspectives MUST corroborate the Primary Domain Validation Determination and Primary CAA Determination. | - |
| 6+ | This configuration relies on six (6) or more (i.e., "N") Network Perspectives.<br><br>When this configuration is used, at least N-2 Network Perspectives MUST corroborate the Primary Domain Validation Determination and Primary CAA Determination. | - |
| # Network Perspectives Used | # of Allowed non-Corroborations |
| --- | --- |
| 2-5 | 1 |
ryancdickson marked this conversation as resolved.
Show resolved Hide resolved
| 6+ | 2 |

Network Perspectives performing Multi-Perspective Issuance Corroboration:

Expand Down Expand Up @@ -1653,9 +1651,9 @@ The CA SHALL record at least the following events:
6. Signing of OCSP Responses (as described in [Section 4.9](#49-certificate-revocation-and-suspension) and [Section 4.10](#410-certificate-status-services)).
7. Multi-Perspective Issuance Corroboration attempts from each Network Perspective, minimally recording the following information:
- an identifier that uniquely identifies the perspective used
ryancdickson marked this conversation as resolved.
Show resolved Hide resolved
- the attempted domain name
- the attempted domain name or IP address
ryancdickson marked this conversation as resolved.
Show resolved Hide resolved
- the result of the attempt (i.e., "DCV pass/fail, CAA allow/disallow")
ryancdickson marked this conversation as resolved.
Show resolved Hide resolved
8. Multi-Perspective Issuance Corroboration quorum results for each attempted domain name represented in a Certificate request (i.e., "3/4" which should be interpreted as "Three (3) out of four (4) attempted Network Perspectives corroborated the Primary Domain Validation Determination and Primary CAA Determination).
8. Multi-Perspective Issuance Corroboration quorum results for each attempted domain name or IP address represented in a Certificate request (i.e., "3/4" which should be interpreted as "Three (3) out of four (4) attempted Network Perspectives corroborated the Primary Domain Validation Determination and Primary CAA Determination).

3. Security events, including:
1. Successful and unsuccessful PKI system access attempts;
Expand Down