Fix relative links in non-archive Markdown

Author: dadrian

content/apply-for-inclusion.md

@@ -12,13 +12,13 @@ title: Apply for Inclusion
 
 ## Last updated: 2025-02-15
 
-The Chrome Root Program Policy defines the [minimum requirements](policy.md) that must be met by Certification Authority (CA) Owners for both initial and continued inclusion in the Chrome Root Store.
+The Chrome Root Program Policy defines the [minimum requirements](policy) that must be met by Certification Authority (CA) Owners for both initial and continued inclusion in the Chrome Root Store.
 
 Google includes or removes self-signed root CA certificates in the Chrome Root Store as it deems appropriate at its sole discretion. The selection and ongoing inclusion of CA certificates is done to enhance the security of Chrome and promote interoperability. CA certificates that do not provide a broad service to all browser users will not be added to, or may be removed from the Chrome Root Store. CA certificates included in the Chrome Root Store must provide value to Chrome end users that exceeds the risk of their continued inclusion.
 
 ### Inclusion Processing
 
-The Chrome Root Program and corresponding Root Store processes inclusion requests and requests for changes through the Common CA Database (CCADB). CA Owners who satisfy all of the requirements in the Chrome Root Program [Policy](policy.md) may apply.
+The Chrome Root Program and corresponding Root Store processes inclusion requests and requests for changes through the Common CA Database (CCADB). CA Owners who satisfy all of the requirements in the Chrome Root Program [Policy](policy) may apply.
 
 The application process includes:
 
@@ -46,7 +46,7 @@ Illustrative behaviors demonstrating value include:
 *   supporting customers in multiple geographic markets and in multiple native languages.
 *   freely-available guidance, help articles, or FAQ to support the user community in requesting/renewing certificates or configuring TLS.
 *   not relying on “cached" domain validation information during certificate issuance.
-*   leveraging operational practices consistent with those described in [Moving Forward, Together](moving-forward-together.md) at the time of application submission. For example, reliably issuing TLS server authentication certificates that are valid for a much shorter period of time than the maximum validity allowed by the Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates.
+*   leveraging operational practices consistent with those described in [Moving Forward, Together](moving-forward-together) at the time of application submission. For example, reliably issuing TLS server authentication certificates that are valid for a much shorter period of time than the maximum validity allowed by the Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates.
 *   supporting the Automatic Certificate Management Environment (ACME) protocol and the ACME Renewal Information (ARI) extension, complemented by technical controls that encourage cryptographic agility.
 *   responsibly operating [Certificate Transparency](https://googlechrome.github.io/CertificateTransparency/) log(s) qualified in Chrome.
 
@@ -58,7 +58,7 @@ CA Owners should not anticipate receiving application coaching beyond what is sp
 
 ### Inclusion Rejection
 
-The Chrome Root Program will reject inclusion requests where an applicant does not meet the minimum requirements defined by the Chrome Root Program [Policy](policy.md) or the application is deemed incomplete or inaccurate.
+The Chrome Root Program will reject inclusion requests where an applicant does not meet the minimum requirements defined by the Chrome Root Program [Policy](index) or the application is deemed incomplete or inaccurate.
 
 The Chrome Root Program may reject requests for inclusion into the Chrome Root Store as deemed appropriate, and is not obligated to justify any inclusion decision.
 
@@ -70,7 +70,7 @@ Illustrative factors for application rejection may include:
 *   where the corresponding CA Owner has ever been:
     *   determined to have acted in an untrustworthy manner or created unnecessary ecosystem risk, or
     *   associated with a certificate that was previously distrusted by Chrome or any other public root program.
-*   has an incident history that does not convey the [factors](policy.md#51-incident-reports) significant to Chrome.
+*   has an incident history that does not convey the [factors](index#51-incident-reports) significant to Chrome.
 *   completion of a CCADB root inclusion public discussion that casts doubt over the CA Owners security, honesty or reliability.
 *   discovery of false or misleading information provided by the CA Owner.
 *   significant delays in response from the CA Owner when seeking additional or clarifying information.

content/index.md

@@ -61,7 +61,7 @@ The Chrome Root Program Policy below establishes the minimum requirements for CA
 
 ### Apply for Inclusion
 
-CA Owners that satisfy the requirements defined in the policy below may apply for self-signed root CA certificate inclusion in the Chrome Root Store using [these](apply-for-inclusion.md) instructions.
+CA Owners that satisfy the requirements defined in the policy below may apply for self-signed root CA certificate inclusion in the Chrome Root Store using [these](apply-for-inclusion) instructions.
 
 ### Chrome's Ongoing Commitment to Transport Security
 
@@ -78,7 +78,7 @@ Chrome maintains a variety of mechanisms to protect its users from certificates
 
 The "Moving Forward, Together" initiative envisions a future Web PKI that includes modern, reliable, highly agile, purpose-driven PKIs with an emphasis on automation, simplicity, and security.
 
-Learn more about priorities and initiatives that may influence future versions of this policy [here](moving-forward-together.md). Please note "Moving Forward, Together" is future looking and does not describe normative requirements.
+Learn more about priorities and initiatives that may influence future versions of this policy [here](moving-forward-together). Please note "Moving Forward, Together" is future looking and does not describe normative requirements.
 
 ### Additional Information
 

content/moving-forward-together.md

@@ -25,7 +25,7 @@ With those goals in mind, the Chrome Root Program continues to explore introduci
 
 ## Understanding "Moving Forward, Together" initiatives
 
-The initiatives described on this page are distinct from the requirements detailed in the [Chrome Root Program Policy](policy.md). These initiatives are proposals for exploration. They are not requirements.
+The initiatives described on this page are distinct from the requirements detailed in the [Chrome Root Program Policy](index). These initiatives are proposals for exploration. They are not requirements.
 
 Some proposals may change during our review process, after considering community feedback, or studying the ecosystem impacts and tradeoffs of adoption. Others may not be adopted at all.
 
@@ -65,7 +65,7 @@ This helps ensure our decisions are informed by real-world data, observed Chrome
 
 Certificates issued by publicly-trusted CA Owners (i.e., those included in various product and operating system trust stores) serve a variety of use cases including TLS server authentication, TLS client authentication, secure email (e.g., signed and encrypted email), document signing, code signing, and others. Up until about five years ago, it was common to see some or all of these use cases served from a single PKI hierarchy. While this approach offered flexibility to some stakeholders, there is inherent complexity of balancing multiple, sometimes competing use cases and requirements, especially as the CA/Browser Forum created additional sets of standards focused on use cases beyond TLS.
 
-Beginning in September 2022, the Chrome Root Program [codified](policy-archive/policy-version-1-1.md#4-dedicated-tls-pki-hierarchies) its commitment to simplicity by requiring applicant PKI hierarchies to the Chrome Root Store focus only on serving TLS use cases. However, while this approach promotes future simplicity, not all CA certificates included in the Chrome Root Store are aligned on this principle. To do so, and to completely realize the benefits of the transition to TLS-dedicated hierarchies, we intend to remove "multi-purpose" root CA certificates, or those CA certificates not dedicated to TLS server authentication use cases, from the Chrome Root Store.
+Beginning in September 2022, the Chrome Root Program [codified](policy-archive/policy-version-1-1#4-dedicated-tls-pki-hierarchies) its commitment to simplicity by requiring applicant PKI hierarchies to the Chrome Root Store focus only on serving TLS use cases. However, while this approach promotes future simplicity, not all CA certificates included in the Chrome Root Store are aligned on this principle. To do so, and to completely realize the benefits of the transition to TLS-dedicated hierarchies, we intend to remove "multi-purpose" root CA certificates, or those CA certificates not dedicated to TLS server authentication use cases, from the Chrome Root Store.
 
 **Why it matters:**
 
@@ -163,7 +163,7 @@ The Chrome Root Program participated in drafting CA/Browser Forum [Ballot SC-075
 
 **Theme:** "Encouraging modern infrastructures and agility"
 
-In Chrome Root Program Policy 1.5, we [landed](policy-archive/policy-version-1-5.md#root-ca-term-limit) changes that set a maximum "term-limit" (i.e., period of inclusion) for root CA certificates included in the Chrome Root Store to 15 years.
+In Chrome Root Program Policy 1.5, we [landed](policy-archive/policy-version-1-5#root-ca-term-limit) changes that set a maximum "term-limit" (i.e., period of inclusion) for root CA certificates included in the Chrome Root Store to 15 years.
 
 While we still prefer a more agile approach, and may again explore this in the future, we encourage CA Owners to explore how they can adopt more frequent root rotation.