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.

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

SC-067: Require Multi-Perspective Issuance Corroboration (Version 1) #487

Closed
wants to merge 2 commits into from

Conversation

ChristopherRC
Copy link
Contributor

Summary: This is the first version of SC-067, which intends to add "Multi-Perspective Domain Validation" and "Multi-Perspective CAA Checking" (together referred to as “Multi-Perspective Issuance Corroboration”) requirements to the CA/Browser Forum TLS Server Certificate Baseline Requirements. Official public discussion is expected to begin the week after CA/Browser Forum F2F 61.


This Pull Request:

  • compares the latest draft of SC-067 against Version 2.0.2 of the TLS Server Certificate Baseline Requirements.
  • addresses issues and comments made against draft Version 2 (pre-ballot) (clean) of this effort. A separate branch was created to help make changes across versions of the document clear to readers, and due to owner of the earlier versions being on leave.

How can you help?

  • Better: Add comments to this Pull Request.
  • Best: Add suggested edits directly to this Pull Request.

Version History:


Summary of recent updates:

  • Establishes requirements for the use of recursive DNS resolvers for remote Network Perspectives following discussions related to Ballot SC-070.
  • Adds flexibility regarding how Network Perspectives may be operated to corroborate domain control validation.
  • Permits re-use of MPIC CAA quorum for subdomains under certain conditions.
  • Clarifies that Onion Names are outside of scope and exempt from MPIC requirements.
  • Moves CAA-related requirements from Section 2.2 into Section 4.2.2.8 to address issue 466.
  • Shifts back required implementation dates.

Additional Notes:

  • Some changes in this PR represent clean-ups (e.g., smart quotes -> regular quotes) unrelated to the primary scope of this Ballot (Multi-Perspective Issuance Corroboration).
  • "MPDV Work Team" Work Plan (contains useful background and additional context).
  • Previous Validation Subcommittee Update introducing this work.

Additional Resources:

On MPDV:

On the problem space:

Prepare for pre-ballot feedback
Nits (typo and capitalization)
@@ -380,6 +382,10 @@ The Definitions found in the CA/Browser Forum's Network and Certificate System S

**Legal Entity**: An association, corporation, partnership, proprietorship, trust, government entity or other entity with legal standing in a country's legal system.

**Multi-Perspective Issuance Corroboration**: A process by which the determinations made during domain validation and CAA checking by the Primary Network Perspective are corroborated from other Network Perspectives before Certificate issuance.
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
**Multi-Perspective Issuance Corroboration**: A process by which the determinations made during domain validation and CAA checking by the Primary Network Perspective are corroborated from other Network Perspectives before Certificate issuance.
**Multi-Perspective Issuance Corroboration**: A process by which the determinations made during domain validation and CAA checking by the Primary Network Perspective are corroborated by other Network Perspectives before Certificate issuance.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

We have no issues using “by" in place of “from.” The original use of “from" was intended to describe the location from which MPIC lookups take place, but if this is clearer for the community - we’re happy to use it.

We pre-staged this change in ChristopherRC@07f9c3b in preparation for a subsequent round of discussion.

@@ -380,6 +382,10 @@ The Definitions found in the CA/Browser Forum's Network and Certificate System S

**Legal Entity**: An association, corporation, partnership, proprietorship, trust, government entity or other entity with legal standing in a country's legal system.

**Multi-Perspective Issuance Corroboration**: A process by which the determinations made during domain validation and CAA checking by the Primary Network Perspective are corroborated from other Network Perspectives before Certificate issuance.

**Network Perspective**: Related to Multi-Perspective Issuance Corroboration. A system for sending outbound Internet traffic associated with a domain control validation method and CAA check. The location of a Network Perspective is determined by the point where unencapsulated outbound Internet traffic is first handed off to the network infrastructure providing Internet connectivity to that perspective.
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
**Network Perspective**: Related to Multi-Perspective Issuance Corroboration. A system for sending outbound Internet traffic associated with a domain control validation method and CAA check. The location of a Network Perspective is determined by the point where unencapsulated outbound Internet traffic is first handed off to the network infrastructure providing Internet connectivity to that perspective.
**Network Perspective**: Related to Multi-Perspective Issuance Corroboration. A system for sending outbound Internet traffic associated with a domain control validation method and/or CAA check. The location of a Network Perspective is determined by the point where unencapsulated outbound Internet traffic is first handed off to the network infrastructure providing Internet connectivity to that perspective.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This appears to add flexibility to how CA Owners implement MPIC, and we think that’s a good thing. Using specific Network Perspectives for either DCV or CAA checks could create opportunities for operational efficiencies, which we had no intention of limiting.

We pre-staged this change in ChristopherRC@07f9c3b in preparation for a subsequent round of discussion.

Copy link

Choose a reason for hiding this comment

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

This can be read as "well, we did MP for CAA, so we don't need to do it for DV". Is that the intention here?

Copy link
Contributor

Choose a reason for hiding this comment

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

@aaomidi - the definition is intended to serve the most general use case and not inadvertently limit CA Owner flexibility re: implementation.

For example, if we assume I need 5 "successful" DCV/CAA lookups, I should be able to:

  • perform the lookups from 5 Network Perspectives (each perspective evaluates both DCV and CAA), or
  • perform the lookups from 10 Network Perspectives (5 perspectives evaluate DCV, 5 others CAA).

Regardless of the above, the requirements in Section 3.2.2.9 make expectations clear (especially those staged for the next round of discussion) that both DCV and CAA need to be considered.

Comment on lines +1056 to +1059
Each corroborating Network Perspective's response MUST provide the CA with the necessary information to allow it to affirmatively assess:
- a. the presence of the expected 1) Random Value, 2) Request Token, 3) IP Address, or 4) Contact Address, as required by the relied upon validation method specified in Sections 3.2.2.4 and 3.2.2.5; and
- b. the CA's authority to issue to the requested domain(s), as specified in Section 3.2.2.8.

Copy link
Member

Choose a reason for hiding this comment

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

I worry that this can be read as that every response from a network perspective MUST contain both the presense of the Random Value (or likewise for DCV), AND the CAA confirmation.

I expect the intent here is to state that the CA MUST get a confirming response on both of these items prior to the issuance of certificate, however, I can imagine that CAs may want to do this by using two different calls, thus getting 2 different responses, one for DCV confirmation, one for CAA confirmation.

Suggested change
Each corroborating Network Perspective's response MUST provide the CA with the necessary information to allow it to affirmatively assess:
- a. the presence of the expected 1) Random Value, 2) Request Token, 3) IP Address, or 4) Contact Address, as required by the relied upon validation method specified in Sections 3.2.2.4 and 3.2.2.5; and
- b. the CA's authority to issue to the requested domain(s), as specified in Section 3.2.2.8.
Each corroborating Network Perspective's response(s) MUST provide the CA with the necessary information to allow it to affirmatively assess:
- a. the presence of the expected 1) Random Value, 2) Request Token, 3) IP Address, or 4) Contact Address, as required by the relied upon validation method specified in Sections 3.2.2.4 and 3.2.2.5; and
- b. the CA's authority to issue to the requested domain(s), as specified in Section 3.2.2.8.
The CA MAY use either the same set, or different sets of Network Perspectives for Domain Authorization or Control and CAA Record checks

Copy link
Member

Choose a reason for hiding this comment

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

I'm not fully happy with the suggestion either, if it inspires someone for a better solution, please comment

Copy link
Contributor Author

Choose a reason for hiding this comment

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

As described in response to your last comment, we think the added flexibility proposed in this update is positive.

While we have no issues with the proposed language “The CA MAY use either the same set, or different sets of Network Perspectives for Domain Authorization or Control and CAA Record checks.”, we tweaked this a bit as described below.

Do you feel the following adequately addresses your concern re: implementation flexibility, while also making it clear that both domain validation and CAA MPIC checks are expected? The bold language is modified, the rest of the italics are unchanged.

The CA MAY use either the same set, or different sets of Network Perspectives when performing Multi-Perspective Issuance Corroboration for the required 1) Domain Authorization or Control and 2) CAA Record checks.

The set of responses from the relied upon Network Perspectives MUST provide the CA with the necessary information to allow it to affirmatively assess:

a. the presence of the expected 1) Random Value, 2) Request Token, 3) IP Address, or 4) Contact Address, as required by the relied upon validation method specified in Sections 3.2.2.4 and 3.2.2.5; and
b. the CA's authority to issue to the requested domain(s), as specified in Section 3.2.2.8.

While making this change, it seems we need to consider the impact of the “and/or" approach to the Quorum Requirements Table. For example, it seems we’ll need to add something like the following bolded text to make it clear that if not using the same set of perspectives for both DV and CAA checks, two quorums are necessary. We will also do a more holistic review of the ballot text to verify whether other changes need to be made.

The "Quorum Requirements" Table describes quorum requirements related to Multi-Perspective Issuance Corroboration. If the CA does NOT rely on the same set of Network Perspectives for both Domain Authorization or Control and CAA Record checks, the quorum requirements MUST be met for both sets of Network Perspectives (i.e.,the Domain Authorization or Control set and the CAA record check set). 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. Network Perspectives are considered "remote" when they are distinct from the Primary Network Perspective and the other Network Perspectives represented in a quorum.

Do you (or others) have any thoughts on this approach?

We pre-staged these changes in ChristopherRC@07f9c3b in preparation for a subsequent round of discussion.

Copy link
Member

Choose a reason for hiding this comment

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

@ChristopherRC The proposed language above looks great! Thank you


The "Quorum Requirements" Table describes quorum requirements related to Multi-Perspective Issuance Corroboration. 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. Network Perspectives are considered "remote" when they are distinct from the Primary Network Perspective and the other Network Perspectives represented in a quorum.

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 its subdomains in subsequent Certificate requests from the same Applicant for up to a maximum of 398 days.
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
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 its subdomains in subsequent Certificate requests from the same Applicant for up to a maximum of 398 days.
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.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

We consider the suggested change a good clarification.

We pre-staged this change in ChristopherRC@07f9c3b in preparation for a subsequent round of discussion.

| 2-5 | 1 |
| 6+ | 2 |

Remote Network Perspectives performing 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 agree with the spirit of this requirement, but I am concerned that it isn't entirely feasible. I recently spoke to a team that deploys RPKI-invalid route filtering and they mentioned that they may not enable it for certain types of peers. They will also disable it if there is an issue with the filtering system itself or they may grant a temporary exception for a customer. I would assume this is common?

As I currently read the text, the CA would be required to file an incident and halt issuance if any of these exceptions were made. CAs are very unlikely to have an SLA with their network operator to always support RPKI-invalid route filtering.

How should this situation be handled ideally?

Copy link
Contributor

Choose a reason for hiding this comment

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

@jdkasten - thanks for you comment!

Is it safe to assume the specific comment is focused on the following bullet?:

  • [Remote Network Perspectives performing Multi-Perspective Issuance Corroboration MUST]: Forward all Internet traffic via a network or set of networks that filter all RPKI-invalid BGP routes as defined by RFC 6811"

Proposed Update:

If so, what if instead the language was modified to something like the following:

  • [Remote Network Perspectives performing Multi-Perspective Issuance Corroboration MUST]: under normal operating conditions, forward all Internet traffic via a network or set of networks that filter all or some RPKI-invalid BGP routes as defined by RFC 6811.

Feedback on the above is welcome.

Change Justification:

As I understand it, there are two distinct categories of exceptions to RPKI filtering:

  • the first is temporary exceptions where certain peers are identified as potentially having an issue with RPKI ROV enforcement and these sessions are given a temporary exception.
  • the second is that some types of sessions are considered exempt from a network's filtering policy. There are documented cases of networks that filter routes from peers but not from customers (see https://isbgpsafeyet.com/.

The approach proposed above would consider both types of exceptions described above, while also addressing your concern re: risk of blocking issuance when filtering is beyond the CA Owner's control.

FWIW, it would seem there are some tools available that would help CA owners evaluate whether ISPs are performing filtering, for example https://rpkitest.nlnetlabs.net/ from https://nlnetlabs.nl/research/projects/

Choose a reason for hiding this comment

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

Is it safe to assume the specific comment is focused on the following bullet?:

Yes, I had meant to select the text to include that bullet. You interpreted my comment correctly. I apologize for any confusion.

If so, what if instead the language was modified to something like the following:

  • [Remote Network Perspectives performing Multi-Perspective Issuance Corroboration MUST]: under normal operating conditions, forward all Internet traffic via a network or set of networks that filter all or some RPKI-invalid BGP routes as defined by RFC 6811.

Thanks, Ryan! I think your proposal addresses my concerns.

Copy link

Choose a reason for hiding this comment

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

I'm not a network specialist.. how does one meet this MUST requirement?

Copy link
Contributor

@ryancdickson ryancdickson Apr 10, 2024

Choose a reason for hiding this comment

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

@jdkasten - Great, thanks for confirming!

We'll:

  1. stage these changes in https://github.com/ChristopherRC/servercert/blob/SC-067-Version-2/docs/BR.md in preparation for the next round of discussion, and
  2. leave this comment thread open in the event there's any other discussion.

Copy link

@job job Apr 15, 2024

Choose a reason for hiding this comment

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

To elaborate a bit:

The Princeton research team's observation that a proper issuance process execution has a dependency on proper network reachability seems on the nose to me. MPIC to me seems a good mechanism to attempt to overcome various potential issues which may exist in the Internet's routing system substrate, I'm excited to see MPIC advance. Recognizing that proper network reachability is a key ingredient to the issuance process - regardless of MIPC - encouraging all forms of BGP routing hygiene seems very helpful.

Copy link

Choose a reason for hiding this comment

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

Sorry if this question is a bit stupid... I'm not a network engineer. :)

How would a CA implement the MUST requirement
"Network Perspectives performing Multi-Perspective Issuance Corroboration MUST rely upon networks that implement measures to mitigate BGP routing incidents in the global Internet routing system." ?

Would this mean - in laymans-terms - that the networks where the remote perspecitves are located (or - if VPN are allowed - the VPN endpoint is) must implement this BGP mitigations? Or does this apply to all networks the CA is using (incl. their main internet access network as well as transit networks to the remote perspectives)?

Copy link
Contributor

Choose a reason for hiding this comment

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

@romanf - not a "stupid" question. If there's opportunity to clarify these requirements either through discussion or updates to the ballot, they are worth addressing.

I would consider this a more flexible option than what we originally proposed (i.e., "[Remote Network Perspectives performing Multi-Perspective Issuance Corroboration MUST]: under normal operating conditions, forward all Internet traffic via a network or set of networks that filter all or some RPKI-invalid BGP routes as defined by RFC 6811.").

This should be considered more flexible because rather than only focusing on RPKI-invalid route filtering to improve routing security relied upon by the Network Perspectives, it allows consideration for other routing security technologies as described by @job in this comment. That is to say, RPKI-invalid route filtering should not be the only acceptable approach adopted by network operators/ISPs to improve routing security that's described in the ballot.

It's my understanding that if a CA Owner ensured its Network Perspectives relied upon service providers that filter RPKI-invalid routes (like many of those described on isbgpsafeyet.com) - they'd satisfy this expectation.

Feedback from @job and other routing security experts welcome (as I am definitely not one!).

Copy link

Choose a reason for hiding this comment

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

The list at isbgpsafeyet.com is awfully short... and just to double-check: this requirement is only for the remote perspectives, correct? Otherwise I can imagine some CAs getting into deep troubles if the DCs that host their primary perspective can't be connected to any ISP providing the required GBP filtering...

Copy link
Contributor

Choose a reason for hiding this comment

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

Hi Roman,

Hopefully the following addresses your concerns, but if not - please let me know!

  1. The routing security requirements proposed by this ballot only apply to the Network Perspectives performing MPIC. If you feel specific language discussed so far has been unclear in communicating that point, please let us know or (better) suggest edits to improve clarity.

  2. At this time, the list on isbgsafeyet.com contain 148 "safe" ISPs - which appears to include a diverse set of cloud and backbone networks operators. Tip: when looking at the list, it'll default to a list of "major" operators. The list can be expanded by clicking on the "Show all" column header.

  3. Based on the proposed changes from @job's earlier comment, other techniques for limiting the spread of "bogus" routes would also satisfy the proposed requirement. Thus, even ISPs listed as "unsafe" or "partially safe" on isbgpsafeyet.com could still be candidates for MPIC if they implement measures to mitigate BGP routing incidents in the global Internet routing system (see more in the earlier comment).

@romanf
Copy link

romanf commented Apr 8, 2024

I have a question to possible architectural solutions: Would it be acceptable to establish VPN tunnels with exit points in different parts of the world and still keep all the processing in the central location(s)? Would such VPN tunnels be considered "delegated third parties" since the VPN provider could potentially be malicious and exit all the traffic at the same location?

@tobij
Copy link

tobij commented Apr 8, 2024

I have a question to possible architectural solutions: Would it be acceptable to establish VPN tunnels with exit points in different parts of the world and still keep all the processing in the central location(s)? Would such VPN tunnels be considered "delegated third parties" since the VPN provider could potentially be malicious and exit all the traffic at the same location?

This is an interesting and indeed possibly relevant question. My first intuitive thought on this would be that it should possibly not be considered allowed under the current language, or at least I would err on the side of it not being allowed as an implementing CA.

However, I think there is no fundamental reason not to allow it if certain constraints are met. For example, I think such a scenario should - if at all - only be allowed if it is the CA that is operating the VPN endpoints, at the same level it would operate more straight forward MPIC implementations, in particular such that the VPN solution is subject to only the same threat model as the straightforward MPIC implementation would be. This could indeed in principle be done by setting up a VPN endpoint in the cloud, but would not (known to) be met in the same way if a CA contracted a VPN endpoint from a third party. This is not to preclude that there might be VPN endpoint types provided by certain CSPs that would approach a straight-forward MPIC implementation in threat and risk model, however that also would be a special case.

@timfromdigicert
Copy link
Contributor

timfromdigicert commented Apr 8, 2024 via email


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). 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. All communications between a remote Network Perspective and the CA MUST take place over an authenticated and encrypted channel relying on modern protocols (e.g., over HTTPS).

A Network Perspective MAY use a recursive DNS resolver that is NOT co-located with the Network Perspective. However, the DNS resolver used by the Network Perspective MUST fall within the same Regional Internet Registry service region as the Network Perspective relying upon it. Furthermore, for any pair of DNS resolvers used on a Multi-Perspective Issuance Corroboration attempt, the straight-line distance between the two States, Provinces, or Countries the DNS resolvers reside in MUST be at least 500 km. The location of a DNS resolver is determined by the point where unencapsulated outbound DNS queries are first handed off to the network infrastructure providing Internet connectivity to that DNS resolver.
Copy link

Choose a reason for hiding this comment

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

Do I understand this paragraph correctly in that if a remote perspective uses a DNS resolver NOT run by the CA itself, this would still be considered a Delegated Third Party and thus be forbidden?

Copy link
Contributor

Choose a reason for hiding this comment

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

@romanf - One important clarification - the proposal does not prohibit Delegated Third Parties from participating in MPIC. MPIC Network Perspectives should be considered as having the potential of blocking issuance, not authorizing it (this conclusion must be derived by the Primary Network Perspective) as described in 3.2.2.4 and 3.2.2.5.

Copy link
Contributor

Choose a reason for hiding this comment

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

@romanf / @tobij / @timfromdigicert

[Sorry for the odd formatting/threading of these messages, I'm responding to these comments directly in GitHub rather than via email.]

Concerning the use of VPNs:

  • My interpretation of the proposal is that use of VPNs would not be considered prohibited.
  • My position is that both 1st (CA-operated) and 3rd party (non-CA operated) VPNs should be permitted. At a network level, a VPN achieves the same effect of causing traffic egress at a different location as actually running validator code at remote vantage perspectives. While care must be taken to ensure that the DNS cache is not shared between different MPIC calls as described required in the proposal, fundamentally, the VPN implementation can achieve the exact same security properties against BGP attacks as remote validators (i.e., those hosted on a cloud VM).
  • It's not clear to me how relying on a VPN provider for MPIC is meaningfully different than when considering how a CA relies on their existing Internet Service Provider for outbound internet connectivity.

Comments and considerations welcome!

Copy link
Contributor

Choose a reason for hiding this comment

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

@ryancdickson I haven't thought about it too much in detail but I think your bullet points are at least in the neighborhood of correct, and would be a great start.

@romanf
Copy link

romanf commented Apr 9, 2024

@tobij Do I understand your point correctly: Your interpretation is that it would be preferrable if a CA rents a bunch of VMs from a Cloud provider and runs a VPN endpoint software on them, than renting the VPN connection?

@tobij
Copy link

tobij commented Apr 9, 2024

@romanf You are correct - this is my point indeed, but I am open to being wrong about my point.

@timfromdigicert
Copy link
Contributor

If the cloud provider can't be trusted, then renting a VM instead of a VPN connection doesn't stop their ability to mess with you.

At the end of the day, what matters is that the DNS for the additional perspective is performed from a geographically diverse location, and that the implementation passes some extremely low security bar (I'm adding that last point to avoid just dropping the VPN entirely). If the wrong VPN or provider or CDN is relied upon, then a CA might find that that result is not achieved, then they're in compliance failure / incident land. They should choose an architecture and solution providers to minimize the chances of that happening, because that's their job. I don't think we can do that part for them.

ChristopherRC added a commit to ChristopherRC/servercert that referenced this pull request Apr 11, 2024

The "Quorum Requirements" Table describes quorum requirements related to Multi-Perspective Issuance Corroboration. 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. Network Perspectives are considered "remote" when they are distinct from the Primary Network Perspective and the other Network Perspectives represented in a quorum.

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 its subdomains in subsequent Certificate requests from the same Applicant for up to a maximum of 398 days.
Copy link
Contributor

Choose a reason for hiding this comment

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

It's not clear to me what this means or how it could impact security.

  • A CA MAY reuse corroborating evidence for CAA record quorum compliance for a maximum of 398 days.

Does this mean that after the first CAA validation of a specific FQDN using MPIC and sufficient remote notes that subsequent CAA checks for that FQDN can be done at only the primary network perspective?

Copy link
Contributor

Choose a reason for hiding this comment

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

Hi Doug!

I often find example scenarios helpful in cases such as this. Please find one below:

Note: for this example, assume DCV data reuse is set to 90 days by the CA.

Today:

  • An applicant requests a certificate for the dNSname "ilovetls.com" using “Agreed-Upon Change to Website - ACME” (TLS BR 3.2.2.4.19).
  • Primary DCV initiated: Their ACME client demonstrates control over the requested domain in accordance with TLS 3.2.2.4.19, and this is verified by the CA from its primary data center.
  • MPIC DCV initiated: The demonstration of control over the requested domain would be corroborated by [N] remote network perspectives in accordance with the proposed TLS BR 3.2.2.9.
  • MPIC CAA initiated: Successful MPIC CAA checks must take place for the requested domain in accordance with the proposed TLS BR 3.2.2.9.
  • Primary CAA check initiated: The CA checks CAA for the the requested domains in accordance with TLS BR 3.2.2.8.
  • Assuming no issues with the above, the certificate is issued.

100 days from now:

  • The same applicant requests another certificate for the dNSname "ilovetls.com" using “Agreed-Upon Change to Website - ACME” (TLS BR 3.2.2.4.19).
  • Primary DCV initiated: Their ACME client demonstrates control over the requested domain in accordance with TLS 3.2.2.4.19, and this is verified by the CA from its primary data center.
  • MPIC DCV initiated: The demonstration of control over the requested domain would be corroborated by [N] remote network perspectives in accordance with the proposed TLS BR 3.2.2.9.
  • MPIC CAA optional: Given it's been less than 398-days since the last successful MPIC CAA check and the same applicant is requesting the certificate, this may be skipped as described in the proposed 3.2.2.9.
  • Primary CAA check initiated: The CA checks CAA for the the requested domains in accordance with TLS BR 3.2.2.8.
  • Assuming no issues with the above, the certificate is issued.

Note: there's flexibility to the sequencing above (e.g., the MPIC lookups for DCV and CAA may take place at the same time), this is just one way of doing it.

To directly address your question: Yes [but only for the remainder of the permitted 398-day reuse period for MPIC CAA data - and if the Applicant is determined to be the same as the original request.]

Does this address your question?

Copy link

Choose a reason for hiding this comment

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

Thanks a lot Ryan for this very illustrative example! I understand where it comes from... it just seems a bit counter-intuitive. ;-) I probably missed the discussion that led to this wording. Any pointers where I can read up?
Thx!

Copy link
Contributor

Choose a reason for hiding this comment

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

@romanf - Of course.

@dzacharo originally provided an example of the potential redundancy of CAA checks here: https://lists.cabforum.org/pipermail/validation/2023-June/001904.html

The resulting proposed language was originally suggested here: ryancdickson#8 (comment)

And... then later refined and further described in this version (Version 1) of the ballot as noted in the “Summary of recent updates: [...] * Permits re-use of MPIC CAA quorum for subdomains under certain conditions. [...]”

@ChristopherRC
Copy link
Contributor Author

Closing in favor of #507

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet