Update docs for C2PA conformance program

docs/conformance.mdx

@@ -0,0 +1,96 @@
+---
+id: conformance
+title: C2PA conformance program
+---
+
+The [C2PA conformance program](https://c2pa.org/conformance) was launched in mid-2025 to help ensure that products that read and create Content Credentials are compliant with the C2PA Content Credentials specification.
+
+The C2PA conformance program covers:
+
+- [Validator products](#validator-products) that read and validate Content Credentials.
+- [Generator products](#generator-products) that create Content Credentials and add them to a digital asset.
+- [Certificate authorities (CAs)](#certificate-authorities).
+
+:::info
+If you're developing a product that reads or creates Content Credentials, you can apply for the C2PA conformance program. If accepted, the product is added to the [conforming products list](https://github.com/c2pa-org/conformance-public/blob/main/conforming-products/conforming-products-list.json#L302), which indicates it is compliant with the C2PA Content Credentials specification.
+
+**To start the process, fill out C2PA's [expression of interest form](https://docs.google.com/forms/d/e/1FAIpQLScERZH5rKfoeSu3y6gGbkllkyeAhmF0G-kXS0eXpb2vR238Rg/viewform).**
+:::
+
+When you apply to the conformance program, you will:
+
+- Sign a legal agreement with the C2PA.
+- Provide evidence supporting your application such as diagrams and documentation.
+- Work with the conformance program staff to resolve any questions.
+
+## Products
+
+### Validator products
+
+A _validator product_ can read and validate a manifest store for a digital asset.
+A conforming validator product produces correct validation results according to the C2PA Content Credentials specification.
+
+For more information, see [C2PA Conformance Program Documents](https://github.com/c2pa-org/conformance-public/tree/main/docs/current), specifically
+[C2PA conformance program - section 6.1.1, Validator Product Specification Requirements](https://github.com/c2pa-org/conformance-public/blob/main/docs/current/C2PA%20Conformance%20Program.pdf).
+
+### Generator products
+
+A _generator product_ can generate manifest data for a digital asset. A conforming generator product produces manifest data that conforms to the C2PA Content Credentials specification, creates assertions in the asset's active manifest and signs a claim using a valid X.509 certificate on the C2PA trust list.
+
+For more information, see [C2PA Conformance Program Documents](https://github.com/c2pa-org/conformance-public/tree/main/docs/current), specifically:
+
+- [C2PA conformance program - section 6.1.1, Generator Product Specification Requirements](https://github.com/c2pa-org/conformance-public/blob/main/docs/current/C2PA%20Conformance%20Program.pdf)
+- [C2PA Generator Product Security
+  Requirements](https://github.com/c2pa-org/conformance-public/blob/main/docs/current/C2PA%20Generator%20Product%20Security%20Requirements.pdf)
+
+#### Preliminary certificate check
+
+To confirm all the settings in your signing certificate, you can follow the [preliminary certificate check](trust-list.mdx#checking-your-certificate) for the interim trust list to help ensure everything is as expected.
+
+#### Security requirements
+
+When you apply to the conformance program, you must fill out the information required in the **product security architecture template** in Appendix C of the [C2PA Generator Product Security
+Requirements](https://github.com/c2pa-org/conformance-public/blob/main/docs/current/C2PA%20Generator%20Product%20Security%20Requirements.pdf), providing details on:
+
+- The organization submitting the application.
+- The product, its capabilities, and the systems it uses or relies upon.
+- The product's security architecture, including methods for key generation and storage, and protections against various kinds of misconfiguration, abuse, and exploitations.
+
+### Assurance levels
+
+A conforming product's _assurance level_ indicates the level of confidence that claims it signs reflect its intended behavior. A higher assurance level indicates a greater level of confidence. Currently, the conformance program has two assurance levels: level 1 and level 2:
+
+- [C2PA Generator Product Security
+  Requirements](https://github.com/c2pa-org/conformance-public/blob/main/docs/current/C2PA%20Generator%20Product%20Security%20Requirements.pdf) details the security requirements for each assurance level.
+- [C2PA certificate policy - Appendix A](https://github.com/c2pa-org/conformance-public/blob/main/docs/current/C2PA%20Certificate%20Policy.pdf) details the requirements for claim signing certificates for each assurance level.
+
+The assurance level is encoded as the value of a custom X.509 v3 certificate extension in the product's claim signing certificate. The C2PA defines the _max assurance level_ of a generator product based on the security attributes of its overall implementation architecture. The assurance level in the certificate issued to a particular instance of a conforming generator product may be lower than the max assurance level.
+
+## Certificate authorities
+
+The [C2PA certificate policy](https://github.com/c2pa-org/conformance-public/blob/main/docs/current/C2PA%20Certificate%20Policy.pdf) specifies requirements for certificate authorities (CAs) that issue claim signing certificates for use by generator products, and the requirements that those products have to meet when using the certificates.
+
+CAs on the C2PA trust list can issue certificates to conforming generator products under the C2PA conformance program.
+
+## C2PA trust lists
+
+C2PA maintains two trust lists:
+
+- [**C2PA trust list**](https://github.com/c2pa-org/conformance-public/blob/main/trust-list/C2PA-TRUST-LIST.pem): A list of X.509 certificate trust anchors (either root or subordinate certification authorities) that issue certificates to conforming generator products under the C2PA Certificate Policy.
+- [**C2PA time-stamping authority (TSA) trust list**](https://github.com/c2pa-org/conformance-public/blob/main/trust-list/C2PA-TSA-TRUST-LIST.pem): A list of X.509 certificate trust anchors (either root or subordinate certification authorities) that issue time-stamp signing certificates to TSAs.
+
+### Interim trust list retirement
+
+With the introduction of the C2PA trust list, the existing [interim (temporary) trust list](trust-list.mdx) is being retired on the following timeline:
+
+- **Through December 31, 2025**: The [interim trust list](trust-list.mdx) will remain operational. During this time:
+  - The [Verify site](https://contentcredentials.org/verify) will continue to display manifests signed by certificates on the interim trust list as trusted, but with a disclaimer that the manifests were made with an older version of the trust model.
+  - New certificates will continue to be added to the interim trust list when requested.
+  - Product developers are strongly encouraged to apply to the C2PA conformance program and use the official C2PA trust list.
+- **On January 1, 2026**: The interim trust list will be frozen:
+  - No new certificates will be added to the list, and no updates will be made.
+  - Existing certificates will remain valid for legacy support.
+
+Eventually, the certificates on the interim trust list will expire and will not be usable for signing. However, if content was signed during the certificate's validity period, the content will always be considered valid against the legacy trust model.
+
+Validator products are encouraged to begin distinguishing between Content Credentials signed with certificates on the interim trust list (typically tied to Content Credentials specification version version 1.4) and those from conforming products using the official C2PA trust list.

docs/manifest/validation.md

@@ -27,7 +27,7 @@ Don't assume that just because you didn't get an error from the function return
 
 Ingredients are validated when they are imported into an asset and the result is stored in the ingredient's `validation_status` array.
 
-Only errors that are not already recorded in the `validation_status` of an ingredient are reported. See [ValidationStatus](./manifest-ref.mdx#validationstatus) object in Manifest store reference.
+Only errors that are not already recorded in the `validation_status` of an ingredient are reported. See [ValidationStatus](./json-ref/manifest-def.mdx#validationstatus) object in Manifest store reference.
 
 ## Error status codes
 

docs/signing/get-cert.md

@@ -3,14 +3,19 @@ id: get-cert
 title: Getting a signing certificate
 ---
 
-:::note Important
+:::warning Important
 Best practices for handling keys and certificates are beyond the scope of this documentation.  Always protect your private keys with the highest level of security; for example, never share them through insecure channels such as email.
 :::
 
-To sign manifest claims, you must have an X.509 v3 security certificate and key that conform to the requirements laid out in the [C2PA specification](https://c2pa.org/specifications/specifications/2.1/specs/C2PA_Specification.html#x509_certificates).
+To sign manifest claims, you must have an X.509 v3 security certificate and key that conform to the requirements laid out in the [C2PA specification](https://c2pa.org/specifications/specifications/2.1/specs/C2PA_Specification.html#x509_certificates). Additionally, the C2PA program provides a [Certificate Policy](https://github.com/c2pa-org/conformance-public/blob/main/docs/current/C2PA%20Certificate%20Policy.pdf) containing the requirements for a certification authority (CA) to follow when issuing C2PA claim signing certificates and the requirements for the use of such certificates.
+
 
 ## Purchasing a certificate
 
+:::note
+The [C2PA conformance program](https://c2pa.org/conformance/) establishes the requirements governing the issuance of C2PA claim signing certificates for use by product developers.  Through the end of 2025 you can still purchase a certificate from any CA and request to add it to the [interim trust list](trust-list.mdx), but starting in 2026 conforming generator products must use a certificate from a CA on the C2PA trust list.  See [C2PA conformance program](conformance.mdx) for more information.
+:::
+
 The process to purchase a certificate and key is different for each CA: You might be able to simply click a "Buy" button on the CA's website. Or your can make your own key and use it to create a certificate signing request (CSR) that you send to the CA. Regardless of the process, what you get back is a signed certificate that you use to create a certificate chain.
 
 The certificate chain starts with the certificate from the last tool that signed the manifest (known as the "end-entity") followed by the certificate that signed it, and so on, back to the original CA issuer. This enables a validating application to determine that the manifest is valid because the certificate chain goes back to a trusted root certificate authority.
@@ -22,9 +27,7 @@ The C2PA specification requires that an "end entity" signing certificate must be
 - An S/MIME email certificate (`id-kp-emailProtection` EKU). This is usually the simplest and least expensive option.
 - A document signing certificate (`id-kp-documentSigning` EKU). Obtaining these kinds of certificates typically have more stringent requirements (like proving your identity) and costs more.
 
-:::note
 For more details, see [Certificate requirements](#certificate-requirements) below.
-:::
 
 ### Certificate authorities (CAs)
 
@@ -52,6 +55,10 @@ You sign the CSR with your private key; this proves to the CA that you have cont
 
 ## Certificate requirements
 
+:::note
+The information in this section is superseded by the [C2PA certificate policy](https://github.com/c2pa-org/conformance-public/blob/main/docs/current/C2PA%20Certificate%20Policy.pdf) the that establishes the requirements governing the issuance of C2PA claim signing certificates.  
+:::
+
 A signing certificate and key (credentials) must conform to the requirements in the [C2PA specification X.509 Certificates section](https://c2pa.org/specifications/specifications/2.1/specs/C2PA_Specification.html#x509_certificates); specifically, it must:
 
 - Follow the public key infrastructure (PKI) X.509 V3 specification.

docs/trust-list.mdx

@@ -1,10 +1,14 @@
 ---
 id: verify-known-cert-list
-title: Verify tool known certificate list
+title: The interim trust list
 ---
 
 import verify_unknown_source from '../static/img/verify-cc-unknown-source.png';
 
+:::warning Warning
+The process described on this page is deprecated. The C2PA has released its official trust lists, and Verify will be updated to use them soon. See [Deprecation timeline](#deprecation-timeline) for more information.
+:::
+
 The C2PA **[Verify tool](https://contentcredentials.org/verify)** uses a list of _known certificates_ (sometimes referred to as a "trust list") to determine whether a Content Credential was issued by a known source. If an asset's Content Credential was not signed by a known certificate, the Verify tool will display this message:
 
 <img
@@ -14,21 +18,31 @@ The C2PA **[Verify tool](https://contentcredentials.org/verify)** uses a list of
 
 Conversely, if the Content Credential was signed by a known certificate, the Verify tool will display the [name of the certificate owner and time of the claim signature](verify.mdx#title-and-signing-information).
 
+## Deprecation timeline
+
 :::note
-The C2PA intends to publish an official public list of known certificates. Until then, **[Verify](https://contentcredentials.org/verify)** uses a temporary list. The list is subject to change and will be deprecated when C2PA publishes the official list.
+Currently, **[Verify](https://contentcredentials.org/verify)** uses the interim trust list described here (also referred to as the _temporary trust list_), but Verify will be updated soon to use the official [C2PA trust list](conformance.mdx#c2pa-trust-lists).
 :::
 
-## Temporary known certificate list
+The interim trust list (also known as the _temporary trust list_) will remain operational **through December 31, 2025**. During this time, C2PA will continue to accept new certificates following the process described below. At some point, the Verify site will distinguish between Content Credentials from conforming products and those signed using certificates on the interim trust list.
 
-The [contentcredentials.org](https://contentcredentials.org/) site hosts the following files that it uses to [validate signing certificates](https://c2pa.org/specifications/specifications/2.0/specs/C2PA_Specification.html#_c2pa_signers). Together, these files form the _temporary known certificate list_:
+On **January 1, 2026**, the interim trust list will be frozen: C2PA will not add any new entries or make updates. Existing certificates will remain valid, but eventually, those certificates will expire and no longer be usable for signing. However, if content was signed during the certificate's validity period, the content will always be considered valid against the interim trust list.
+
+:::tip
+For more information about conformance, see [C2PA conformance program](conformance.mdx).
+:::
 
-- **The temporary end-entity certificate list** in https://contentcredentials.org/trust/allowed.pem consists of end-entity certificates. If the certificate is on this list, it is considered "known." To reduce bandwidth consumption, a [version with SHA-256 hashes](https://contentcredentials.org/trust/allowed.sha256.txt) of the certificates is also available.
-- **The temporary known anchor list** in https://contentcredentials.org/trust/anchors.pem contains the list of known anchor certificates. If an end-entity [certificate's chain](getting-started.mdx#signing-and-certificates) can be traced back to an anchor certificate on this list, the certificate is considered "known."
-- **The configuration file**, https://contentcredentials.org/trust/store.cfg, specifies the [Extended Key Usage (EKU)](https://datatracker.ietf.org/doc/html/rfc9336) values accepted for end-entity certificates. An end-entity certificate must have at least one of the EKUs in this list to be valid.
+## Interim known certificate list
+
+The Verify site hosts the following files that it uses to [validate signing certificates](https://c2pa.org/specifications/specifications/2.0/specs/C2PA_Specification.html#_c2pa_signers). Together, these files form the _interim known certificate list_:
+
+- [**The interim end-entity certificate list**](https://github.com/contentauth/verify-site/blob/main/static/trust/allowed.pem) consists of end-entity certificates. If the certificate is on this list, it is considered "known." To reduce bandwidth consumption, a version with SHA-256 hashes of the certificates is also available.
+- [**The interim known anchor list**](https://github.com/contentauth/verify-site/blob/main/static/trust/anchors.pem) contains the list of known anchor certificates. If an end-entity [certificate's chain](getting-started.mdx#signing-and-certificates) can be traced back to an anchor certificate on this list, the certificate is considered "known."
+- [**The configuration file**](https://github.com/contentauth/verify-site/blob/main/static/trust/store.cfg) specifies the [Extended Key Usage (EKU)](https://datatracker.ietf.org/doc/html/rfc9336) values accepted for end-entity certificates. An end-entity certificate must have at least one of the EKUs in this list to be valid.
 
 ## Checking your certificate
 
-Before requesting to [add your signing certificate to the known certificate list](#how-to-add-a-certificate-to-the-list), perform a preliminary check to ensure the certificate is configured properly.
+Before requesting to [add your signing certificate to the interim known certificate list](#how-to-add-a-certificate-to-the-list), perform a preliminary check to ensure the certificate is configured properly.
 
 ### Prerequisites
 
@@ -81,13 +95,13 @@ Check your certificate by following these steps:
    Subject: organizationIdentifier=XYZ-7155227, C=US, ST=Delaware, L=Dover, O=Whatever Inc., SN=xxx, GN=xxx, CN=xxx
    ```
 
-## Using the known certificate list
+## Using the interim known certificate list
 
-You can use the C2PA Tool or the CAI JavaScript library to determine whether a certificate is on the temporary known certificate list.
+You can use the C2PA Tool or the CAI JavaScript library to determine whether a certificate is on the interim known certificate list.
 
 ### Using with C2PA Tool
 
-The [C2PA Tool documentation](c2patool/docs/usage.md#configuring-trust-support) explains how to use the temporary known certificate list with the tool.
+The [C2PA Tool documentation](c2patool/docs/usage.md#configuring-trust-support) explains how to use the interim known certificate list with the tool.
 
 ### Using with the JavaScript library
 
@@ -139,9 +153,13 @@ This code is for illustration purposes only. To ensure acceptable performance, p
 
 ## How to add a certificate to the list
 
-If you have an application that is in production and publicly available, you can request to add its signing certificate to the temporary known certificate list.
+If you have an application that is in production and publicly available, you can request to add its signing certificate to the interim known certificate list.
+
+:::warning Warning
+The interim trust list is being deprecated. While you can still request to add your certificate to the list (through the end of 2025), you are strongly encouraged to apply to the C2PA conformance program and use the official C2PA trust list. See [C2PA conformance program](conformance.mdx) for more information.
+:::
 
 Follow these steps:
 
-1. [**Do a preliminary check of your certificate**](#checking-your-certificate) to ensure it meets the requirements for C2PA signing certificates and to be in the Verify temporary certificate list.
+1. [**Do a preliminary check of your certificate**](#checking-your-certificate) to ensure it meets the requirements for C2PA signing certificates and to be in the Verify interim certificate list.
 1. **Submit your request** by emailing `[email protected]`. We will review your request, and if it is approved, we'll ask for more details. Once we receive them and deploy the update to the trust list, you will receive a confirmation email.