diff --git a/docs/conformance.mdx b/docs/conformance.mdx new file mode 100644 index 0000000..08acbaf --- /dev/null +++ b/docs/conformance.mdx @@ -0,0 +1,60 @@ +--- +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. + +:::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).** +::: + +The C2PA conformance program covers: + +- _Validator products_ that read and validate Content Credentials. +- _Generator products_ that create Content Credentials and add them to a digital asset. +- Certificate authorities (CAs). + +## 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 details, see [C2PA conformance program](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 details, see [C2PA conformance program](https://github.com/c2pa-org/conformance-public/blob/main/docs/current/C2PA%20Conformance%20Program.pdf). + +## 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. diff --git a/docs/signing/get-cert.md b/docs/signing/get-cert.md index 2c4fa19..6393b98 100644 --- a/docs/signing/get-cert.md +++ b/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. diff --git a/docs/trust-list.mdx b/docs/trust-list.mdx index c142ea2..5cc38bb 100644 --- a/docs/trust-list.mdx +++ b/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: