# Encypher C2PA Certification Practice Statement

**Version:** 2.1
**Effective Date:** August 9, 2026
**Status:** Active

## 1. Introduction

### 1.1 Overview

This Certification Practice Statement (CPS) describes the operational procedures used by Encypher Corp. to manage the Encypher C2PA Certificate Authority. This CPS implements the requirements of the Encypher C2PA Certificate Policy (CP) v2.1.

For the operational distinction between API keys, service profiles, claim-signing certificates, BYOK credentials, publisher attribution, and CAWG named actors, see [Signing Identity and Certificate Operations](signing-identity-and-certificate-operations.md). The CP and this CPS remain normative for the Encypher C2PA CA.

### 1.2 Scope

This CPS covers all operations of the Encypher CA hierarchy:

- Encypher C2PA Root CA 2026
- Encypher C2PA Issuing CA 2026
- End-entity certificates issued for C2PA claim signing

## 2. Key Generation Procedures

### 2.1 Algorithm and Key Size

All CA and end-entity keys use ECDSA on the P-384 curve (secp384r1). This provides approximately 192 bits of security strength, exceeding the C2PA minimum requirement.

### 2.2 Key Generation Environment

All CA keys are generated inside GCP Cloud KMS with HSM protection level (FIPS 140-2 Level 3). Key material never leaves the HSM boundary. Production hosted claim-signing keys are generated in the same way: a non-exportable P-384 key created inside the KMS HSM boundary, certified by the Issuing CA, and used for signing only inside that boundary (Section 6.2). Encypher generates no subscriber signing key in software.

- **Algorithm:** ECDSA on P-384 (ec-sign-p384-sha384)
- **Protection level:** HSM (FIPS 140-2 Level 3, CAVP validated)
- **KMS provider:** Google Cloud Key Management Service
- **Key generation:** Performed by the HSM during key creation
- **Entropy:** HSM internal CSPRNG (NIST SP 800-90A compliant)

### 2.3 Key Ceremony

The KMS-backed key ceremony follows this procedure:

1. Operator identifies themselves, records ceremony start time and witness names
2. Verify GCP KMS keyring contains HSM-backed root-ca-key, issuing-ca-key, ocsp-signing-key, root-ocsp-signing-key, tsa-issuing-ca-key, tsa-signing-key, and the platform claim-signing key used for production hosted signing (CP Sections 6.1.1, 6.1.2, and 6.3)
3. Retrieve and fingerprint the public keys from KMS
4. Generate Root CA self-signed certificate (20-year validity, signed via KMS)
5. Generate Issuing CA certificate (5-year validity, signed by Root CA via KMS)
6. Generate OCSP signing certificate (1-year validity, signed by Issuing CA via KMS)
7. Generate TSA Issuing CA certificate (5-year validity, signed by Root CA via KMS), then generate the TSA signing certificate (1-year validity, signed by TSA Issuing CA via KMS)
8. Generate initial empty CRLs for the Root CA, claim-signing Issuing CA, and TSA Issuing CA (signed by their respective KMS keys)
9. Compute and record SHA-256 fingerprints of all certificates
10. Export certificate PEMs and CRL PEMs (no private key material exported)
11. Record ceremony completion with all artifact fingerprints and KMS key version names

The platform claim-signing key is part of the HSM-backed key inventory verified in step 2, and its private half is generated inside and never leaves the KMS HSM boundary. This hierarchy ceremony neither issues nor completes the production claim-signing leaf: verification and provisioning of that key and its leaf are subject to the separate witnessed production claim-signing leaf issuance ceremony (gate O4), performed under the same isolation, ca-admin access, witness, and artifact-recording controls. Until that ceremony is executed and recorded, no production claim-signing leaf exists over this key and production signing remains fail-closed.

A supplemental root OCSP ceremony reuses the exact existing Root CA certificate and does not rerun the hierarchy ceremony. Under the same isolation, ca-admin access, witness, and artifact-recording controls as other Root CA operations, the operator verifies that the Root CA public key matches root-ca-key, signs only the delegated Root OCSP responder certificate over root-ocsp-signing-key, verifies the Root CA fingerprint is unchanged, and records both key versions and certificate fingerprints.

The ceremony record includes: ceremony ID, timestamp, operator name, machine hostname, KMS project/location/keyring, key version resource names for all keys, all certificate fingerprints and serial numbers, and witness names. The record is persisted as JSON alongside the certificate artifacts.

## 3. Key Storage and Protection

### 3.1 Root CA Key

- Stored in GCP Cloud KMS with HSM protection level (FIPS 140-2 Level 3)
- Key material never exported or present in plaintext outside the HSM boundary
- Offline except for approved, isolated Root CA ceremonies: signing Issuing CA certificates, signing the Root CA CRL, and signing the delegated Root OCSP responder certificate
- Access restricted to the ca-admin service account during recorded ceremonies with witness and artifact controls

### 3.2 Issuing CA Key

- Stored in GCP Cloud KMS with HSM protection level (FIPS 140-2 Level 3)
- Key material never exported or present in plaintext outside the HSM boundary
- Online: signs end-entity certificates, OCSP signing certs, CRLs
- Access restricted to ca-signing service account (runtime operations)

### 3.3 OCSP Signing Key

- Stored in GCP Cloud KMS with HSM protection level (FIPS 140-2 Level 3)
- Key material never exported or present in plaintext outside the HSM boundary
- Online: signs OCSP responses

### 3.4 TSA Signing Key

- Stored in GCP Cloud KMS with HSM protection level (FIPS 140-2 Level 3)
- Key material never exported or present in plaintext outside the HSM boundary
- Online: signs RFC 3161 timestamp responses
- Single-purpose: TSA signing certificate has only id-kp-timeStamping EKU

## 4. Certificate Issuance Workflow

### 4.1 Request Submission

Subscriber end-entity certificate requests are submitted only through the authenticated Encypher dashboard enrollment flow (the `/ca/applications` enrollment API: application creation, exact-version document acceptance, automated domain-control challenge and verification, Generator Product confirmation, key submission, and submission for issuance). There is no general-purpose or caller-parameterized issuance endpoint; the former internal `POST /ca/certificates/issue` leaf route has been retired, and no route accepts a caller-supplied Common Name, organization, certificate profile, or S/MIME e-mail address for a subscriber leaf.

### 4.2 Identity Validation

Level 1 validation for the self-service Domain-Validated AL1 (DV AL1) dashboard profile is fully automated and deterministic:

1. Authenticate the requesting Encypher dashboard session (verified session JWT) and confirm owner or administrator membership in the exact organization server-side. API keys, service tokens, demo identities, and caller-supplied role, organization, or user fields are rejected.
2. Validate control of each exact fully qualified domain name via an automated, deterministic challenge: a DNS TXT record published at `_encypher-ca-challenge.<fqdn>` with the value `encypher-ca-verification=<token>`, resolved and matched exactly after concatenating the character-strings within each TXT resource record (preferred), and/or a Server-Side-Request-Forgery-guarded HTTPS GET of `https://<fqdn>/.well-known/encypher-ca-challenge` returning the exact token (JSON `{"token": "<token>"}` or plain text) with HTTP 200. Encypher never strips a `www.` or any other label and never accepts a wildcard. Evidence must be exact-FQDN, same-organization, current, verified, non-revoked, and within its finite validity period (no more than 398 days; 30 days by default for direct or imported evidence under current configuration). Imported evidence expires at the earlier of its source expiry and the configured policy ceiling and is rejected if already expired.
3. Confirm the named Generator Product is "conformant" on the C2PA Conforming Products List at or above the requested assurance level, against a server-side, operator-configured Generator Product registry. Encypher ships no self-declared or default product and fails closed unless the configured registry resolves a conformant Generator Product carrying a real Conforming Products List record identifier; that record identifier is required for issuance, is recorded, and is stamped into the issued certificate.
4. Record an append-only Registration Authority approval, performed deterministically by the automated RA service principal (not caller-supplied and not routine manual review), bound to the exact organization and certificate application and capturing the validation method and evidence.

The self-service DV AL1 profile validates only exact-FQDN control and authenticated account membership; it does not verify legal existence or legal name. Its Subject is `CN=<validated FQDN>` only, derived from validated domain evidence rather than accepted from the client. Encypher-managed hosted-signing and organization-provisioning leaves are a separate, non-self-service operational profile. Their Subject is `C=US, O=<organization account display name>, CN=<Encypher-selected value>`; account membership, the exact organization-bound assent and Registration Authority authorization, and Encypher's operation of the managed service are the validation basis. A hosted-signing leaf certifies a non-exportable P-384 key held in the GCP Cloud KMS HSM (Section 6.2), not a key Encypher generated in software. The account display name is not independently checked against legal-entity records and does not assert legal existence, legal name, incorporation, or ownership of the name. Encypher offers no legal-organization-validated or extended-validation profile.

The implemented automated RA routes only an exact normalized FQDN in the operator-configured exception-FQDN set to `exception_review`; an exact configured denied FQDN is denied, as is invalid or insufficient proof. No human disposition workflow is implemented end to end, and a held application cannot issue. An authenticated and auditable workflow that can only release the configured hold back to automated evaluation or deny it is an activation prerequisite. Fraud or abuse, sanctions, general disputes, anomalous evidence, and high-risk-name review are not current automated triggers; approved policies, configured criteria, and implemented disposition handling for those categories are also activation prerequisites.

### 4.3 Certificate Generation

Encypher generates two categories of end-entity leaf, both bound to resolved pre-issuance assent and Registration Authority authorization: the self-service Domain-Validated subscriber leaf below, and Encypher-managed leaves (hosted signing and organization provisioning). Per C2PA CP Section 7, the end-entity EKU must contain c2pa-kp-claimSigning plus at least one of id-kp-emailProtection or id-kp-documentSigning; both categories satisfy this with id-kp-documentSigning, and no S/MIME (id-kp-emailProtection / rfc822Name) leaf profile is offered. The self-service Domain-Validated subscriber leaf asserts a Common-Name-only Subject (the validated fully qualified domain name); the Encypher-managed leaves use the managed-leaf subject described in CP Section 6.2.3. In every case Encypher certifies a public key it did not generate a software private key for: the self-service Subscriber supplies a CSR, and a hosted-signing leaf certifies the public key retrieved from the non-exportable KMS HSM key described in Section 6.2.

Before generating a Certificate under either profile, Encypher verifies two independent immutable records for the exact organization and certificate application: (a) a passing Registration Authority validation record (Section 4.2), and (b) the Subscriber organization's affirmative assent, by an authenticated account owner or administrator, to the exact Subscriber Agreement, CP, and CPS versions in force at issuance and their exact SHA-256 digests. Certificate generation fails closed if either record is absent, does not match the exact current document bytes, or cannot be revalidated against its immutable database row immediately before signing. The certificate and its combined acceptance-and-Registration-Authority link are persisted atomically, one committed issuance yields one serial, and OCSP status is published only after that commit.

The managed-leaf `O` value is copied from the organization account record and is meaningful only within the Encypher-managed operation. It is not the result of domain-control validation or independent legal-entity validation. Managed issuance still fails closed unless the exact organization and application have the immutable assent and Registration Authority records described below.

**Domain-Validated Subscriber Leaf (the only self-service profile):**

1. Subscriber submits CSR with ECC P-384 public key
2. Build end-entity certificate with extensions per claimSigningLeaf.al1 profile:
   - Subject: CN = validated FQDN only (derived by Encypher; no organization, country, locality, or e-mail attribute)
   - Basic Constraints: CA:FALSE
   - Key Usage: digitalSignature, nonRepudiation
   - Extended Key Usage: c2pa-kp-claimSigning (1.3.6.1.4.1.62558.2.1), id-kp-documentSigning (1.2.840.113583.1.1.5)
   - Certificate Policies: c2pa-certificate-policy (1.3.6.1.4.1.62558.1.1)
   - C2PA Assurance Level: Level 1 (1.3.6.1.4.1.62558.3.10)
   - CPL Record ID: c2pa-cpl-record (1.3.6.1.4.1.62558.4) with UUID (required)
   - AIA: OCSP responder URL (http://), CA Issuers URL (http://)
   - CRL Distribution Points: Issuing CA CRL URL (http://)
   - Validity: max 366 days (C2PA AL1)
3. Sign with Issuing CA key using ECDSA SHA-384
4. Register certificate in status store (OCSP/CRL)
5. Return certificate and chain to subscriber

### 4.4 Certificate Delivery

Self-service DV certificates are delivered via HTTPS API response, and the CA does not generate the self-service Subscriber's keypair; the Subscriber submits a CSR. Encypher generates no subscriber private key in software on any production path, and no private key material is ever delivered to a Subscriber. In the separately enabled Hosted Signing Service, the delivered artifact is the certificate and chain over a non-exportable P-384 key that stays inside the GCP Cloud KMS HSM; production signing with that key occurs inside the HSM boundary and there is no software key to destroy after signing, as described in Section 6.2.

### 4.5 Revalidation

Encypher re-validates every issued enrollment certificate on a periodic schedule that pages through the entire issued set with a stable cursor (no subset is skipped and the oldest applications are not reprocessed in a loop), and also whenever domain-control evidence reaches its finite validity limit (no more than 398 days). Each revalidation re-checks domain control, Generator Product conformance (including the Conforming Products List record identifier), and the currency and binding of the linked subscriber acceptance and Registration Authority authorization against their immutable records and the current approved document versions and digests. Loss of exact-FQDN control, lapse of domain evidence, loss of product conformity, a missing authorization link, or a completed false authorization check causes automated revocation with OCSP and CRL propagation.

The authorization check is false when the governing document set is inactive, future-effective, malformed, unapproved, or otherwise unreadable for exact-version and digest comparison. That condition is recorded as `authorization_invalid` and causes immediate revocation; revalidation does not leave the certificate GOOD or defer the result because document metadata is unavailable.

## 5. Revocation Procedures

### 5.1 Revocation Request Processing

1. Authenticate the revocation request (API auth or manual verification)
2. Validate the reason code
3. Commit certificate status, reason, and revocation time to the isolated CA database
4. Update the local issuer-appropriate OCSP projection from committed status and, for the active TSA leaf, latch local timestamp signing off before CRL publication
5. Reserve the next issuer-scoped CRL number atomically, sign with the existing issuer KMS key, validate the completed artifact, and commit its immutable DER
6. Refresh every Enterprise replica's database-backed OCSP and active TSA revocation projections every 30 seconds
7. Reconciliation republishes any committed revocation that is missing from the current artifact, including after a process crash
8. Log the revocation and publication result

TSA signing certificates use the same durable revocation workflow. Their status is committed and the revoking process is latched off before publication. Other Enterprise replicas converge from the authoritative database within 30 seconds. Each revoked TSA certificate is included in the issuer-scoped CRL signed by the dedicated TSA Issuing CA.

### 5.2 CRL Generation

- Claim-signing and TSA Issuing CA CRLs are signed by their distinct issuer KMS keys using ECDSA SHA-384
- CRL numbers are allocated monotonically and independently per issuer; gaps are allowed and reuse is forbidden
- Authority Key Identifier and signature must match the selected issuer certificate
- NextUpdate follows the CP schedule: 10 days for both online issuing CAs and 400 days for the Root CA
- Enterprise API reads the latest committed CA-database artifact. The keyless public CA service accepts real upstream PEM with or without role labels, validates the root certificate, issuer certificates, and complete pair of online-issuer CRLs, then atomically replaces its in-memory last-known-good bundle
- ca-service readiness requires the root certificate and both online-issuer CRLs. Environment CRLs are cold-start seeds only. Invalid, regressing, or expired artifacts never replace accepted state, an expired artifact is not returned with HTTP 200, and successful cache freshness is capped by both NextUpdate and one day
- The standalone TSA service polls the TSA Issuing CA CRL every 300 seconds by default. Its 8-day maximum staleness falls after the 7-day publication target and before the 10-day CRL expiry; fail-closed readiness and signing stop when no accepted candidate remains within that bound.

### 5.3 OCSP Responder

- Exposed through both the public keyless CA service and the Enterprise API proxy; both interfaces use the same issuer-aware status data and response-signing controls
- Accepts GET and POST requests per RFC 6960
- Uses the Issuing CA-authorized responder and ocsp-signing-key for end-entity certificate status
- Uses the Root CA-authorized responder and root-ocsp-signing-key for Issuing CA certificate status
- Rejects unknown issuer name/key hashes with UNAUTHORIZED before signing
- Response validity: 24 hours (this_update to next_update)
- Supports GOOD, REVOKED, and UNKNOWN status
- Enterprise replicas refresh their database-backed OCSP projection every 30 seconds, bounding convergence after another replica commits a status change.
- OCSP projection replacement is monotonic. An incomplete or ambiguous database result cannot erase an accepted revoked status.

### 5.4 Post-Issuance Revalidation and Automated Revocation Triggers

Encypher revalidates domain control, Generator Product conformance, and the linked assent and Registration Authority authorization for issued enrollment certificates. It revokes for private-key compromise or suspected compromise; missing, expired, revoked, or failed domain-control evidence; loss of conformant status or a changed Conforming Products List record identifier; a missing certificate-authorization link; a completed false authorization check, including inactive, future-effective, malformed, unapproved, or otherwise unreadable current document metadata; issuance error; changed or inaccurate identity information; Subscriber request; or violation of the CP, CPS, or Subscriber Agreement. Automated triggers are processed programmatically, and OCSP and CRL are updated as in Sections 5.1 through 5.3. The OCSP responder publishes GOOD, REVOKED, or UNKNOWN status only; it does not implement suspension.

## 6. Physical and Logical Security Controls

### 6.1 Key Protection

All CA private keys are stored in GCP Cloud KMS with HSM protection level:

- **FIPS 140-2 Level 3:** All keys reside in HSM-backed KMS (Google Cloud KMS HSM)
- **No key export:** Private key material is never exported from the HSM boundary
- **Dual service accounts:** ca-admin has ceremony-only administration; ca-signing has key-level signerVerifier grants on runtime keys
- **Root CA offline:** The runtime identity has no signing grant on root-ca-key; approved, isolated ceremonies use it only for Root CA operations, including signing the delegated Root OCSP responder certificate

### 6.2 Hosted Signing Key Custody and Certificate Validity

Production hosted claim signing must use an HSM-resident key, and its certificates follow the Encypher-managed AL1 validity contract, not a minutes-scale lifetime:

- The hosted signing key is a P-384 key generated inside the GCP Cloud KMS HSM boundary (FIPS 140-2 Level 3) and marked non-exportable; its private key material never leaves that boundary and is never present in Encypher application memory, storage, or transport
- The Issuing CA certifies the public key retrieved from KMS; no private key is transported to the CA, to a Subscriber, or to any other Encypher service
- The Issuing CA issues the certificate within the Encypher-managed AL1 validity range of CP Section 6.2.3 (1-366 days); platform claim-signing leaves are issued at the 366-day default of the platform signer issuance path
- Each production claim signature is computed by the HSM through a KMS signing operation over the certified key
- The signature is timestamped via RFC 3161 TSA (also KMS-backed)
- The timestamp proves the signature was created while the certificate was valid

Because the private key never exists outside the HSM, no software key is generated, held, or destroyed per signing operation; residual exposure is bounded by non-exportable HSM custody, revocable KMS access, and certificate revocation through OCSP and CRL, not by a short certificate lifetime. Encypher does not claim that production hosted-signing certificates reduce the key-compromise window to minutes.

A software helper that certifies a caller-supplied P-384 public key is retained for non-production use only. Its default certificate validity is 10 minutes, and that minutes-scale validity applies only to this non-production caller-held path; it never applies to production hosted KMS claim-signing leaves, which use the managed AL1 range above. The helper certifies only the public key the caller supplies; it never generates a keypair, never serializes a private key, and never returns private key material. The caller generates its own keypair, performs the signing operation, and destroys the private key. The production configuration must refuse this helper, and it must never issue a production hosted-signing certificate or perform a production claim signature.

### 6.3 Infrastructure

- **Compute:** Railway (managed container platform)
- **KMS:** GCP Cloud KMS (us-central1, HSM protection level)
- **Network:** TLS encryption for all API endpoints, network isolation between services
- **TSA time source:** NTP with UTC(k) traceability (Google and Cloudflare NTP servers), drift detection halts timestamping if clock drift exceeds declared accuracy (1 second)

### 6.4 Access Control

- CA admin endpoints require authenticated internal service token
- CRL, OCSP, and TSA endpoints are public (no authentication)
- KMS access controlled by GCP IAM with dedicated service accounts

### 6.5 Audit Logging

- All CA operations logged with timestamps
- Certificate issuance and revocation events recorded
- Key ceremony artifacts preserved (ceremony-record.json with KMS key versions)
- TSA serial numbers and algorithm logged for every timestamp issued
- NTP drift status logged for audit

## 7. RFC 3161 Timestamp Authority

### 7.1 TSA Overview

Encypher operates an RFC 3161 Timestamp Authority using GCP KMS HSM-backed signing keys. The TSA provides cryptographic proof that content signatures were created at a specific time.

### 7.2 TSA Policy

- **Policy OID:** 1.3.6.1.4.1.62558.5.1
- **Accepted hash algorithms:** SHA-256, SHA-384, SHA-512 (per C2PA CP Section 6.7.1)
- **Accuracy:** 1 second declared
- **Signature algorithm:** ECDSA P-384 with SHA-384
- **Key protection:** GCP KMS HSM (FIPS 140-2 Level 3)

### 7.3 TSA Time Source

- System clock synchronized via NTP to Google and Cloudflare time servers
- UTC(k) traceability via NTP pool servers
- Drift detection: the TSA checks system clock drift against NTP every 60 seconds
- If clock drift exceeds the declared accuracy (1 second), timestamp issuance halts automatically per C2PA CP Section 6.7.1 item 4

### 7.4 TSA Certificate

The TSA signing certificate:
- Has id-kp-timeStamping EKU (1.3.6.1.5.5.7.3.8), critical, single-purpose
- Is signed by the dedicated Encypher TSA Issuing CA
- CA:FALSE, not shared with claim signing keys
- CRL Distribution Points: TSA Issuing CA CRL URL
- Is registered in the isolated CA status store and can be revoked through the dedicated TSA Issuing CA CRL

### 7.5 Timestamp Response Format

Timestamp responses conform to RFC 3161 with CMS SignedData wrapper per RFC 5652:
- Version 3 SignedData with SignerInfo containing signed attributes
- Content type: id-smime-ct-TSTInfo (1.2.840.113549.1.9.16.1.4)
- Signed attributes: content-type, message-digest (SHA-384), signing-time
- TSA certificate included in response when requested (certReq=TRUE)

## 8. Disaster Recovery

### 8.1 Key Recovery

- All CA keys reside in GCP KMS HSM - no key backup needed (KMS handles durability)
- Certificate PEMs and ceremony records backed up in Railway environment configuration
- Key ceremony can be re-run to regenerate certificates from the same KMS keys

### 8.2 Service Recovery

- OCSP status and online-issuer CRL source state recover from the isolated CA database.
- Enterprise API restores and validates each latest committed immutable CRL artifact before becoming ready. A missing, ambiguous, or invalid required production artifact blocks readiness.
- The on-prem cold-start readiness order is Enterprise API publisher, ca-service repository, then tsa-service watcher. Enterprise API and ca-service use the same canonical rotated internal CA credential pair.
- ca-service rebuilds its in-memory repository cache only from a root-inclusive complete validated upstream candidate. It may retain a valid last-known-good candidate during a transient outage, but never serves it after `nextUpdate` and never advertises more than one day of freshness.
- Trust consumers restore one validated signing and TSA snapshot from the durable last-known-good file, with required Encypher roots pinned. Verification-service installs the complete runtime pair atomically and rolls back a failed install. Rust consumers obtain both bundles through one paired accessor and reuse only a cache keyed to that snapshot generation.
- Database backups, trust snapshot volumes, and ceremony artifacts follow the standard backup and restore procedure.

## 9. Audit and Compliance

### 9.1 Current Compliance Level

- C2PA Certificate Policy: Level 1 (self-assertion)
- No independent audit (not required for Level 1)

### 9.2 Audit Records

The following events are logged:
- Key ceremony execution
- Certificate issuance (serial number, subject, requester)
- Certificate revocation (serial number, reason, requester)
- CRL generation (CRL number, timestamp)
- OCSP request/response (serial number, status returned)

## 10. Incident Response

Key-compromise and mis-issuance handling (detection, revocation, CRL and OCSP
propagation, and C2PA Steering Committee notification) is governed by the
Encypher C2PA Incident Response Plan at
`docs/c2pa/conformance/incident_response.md`. The revoke runbook it executes is
Section 5 (Revocation Procedures) of this CPS together with the
`POST /ca/certificates/revoke` admin API.

## 11. References

- Encypher C2PA Certificate Policy v2.1 (`docs/ca/certificate-policy.md`)
- RFC 3647 - Internet X.509 PKI Certificate Policy and Certification Practices Framework
- RFC 5280 - Internet X.509 PKI Certificate and CRL Profile
- RFC 6960 - Online Certificate Status Protocol (OCSP)
- C2PA Certificate Policy v0.1
- C2PA Generator Product Security Requirements
- Encypher C2PA Incident Response Plan (`docs/c2pa/conformance/incident_response.md`)
- Encypher CA Governance Documentation Set (`docs/c2pa/conformance/cp_cps/README.md`)