Encypher C2PA Certificate Policy

Version: 2.1 Effective Date: August 9, 2026 OID: 1.3.6.1.4.1.62558.1.1 Status: Active

1. Introduction

1.1 Overview

This Certificate Policy (CP) defines the requirements governing the lifecycle of X.509 certificates issued by the Encypher Certificate Authority (CA) for C2PA content provenance signing. The policy applies to all certificates in the Encypher CA hierarchy, from root CA to end-entity certificates.

The Encypher CA issues certificates primarily for C2PA claim signing (OID 1.3.6.1.4.1.62558.2.1), enabling organizations to sign content provenance manifests that validate against the C2PA Trust List.

Plain-language identity and operations guidance is maintained in Signing Identity and Certificate Operations. That guide does not alter this policy.

1.2 Document Name and Identification

Title: Encypher C2PA Certificate Policy
Version: 2.1
OID: 1.3.6.1.4.1.62558.1.1
Registration Authority: Encypher Corp.

1.3 PKI Participants

1.3.1 Certificate Authority

Encypher Corp. operates the following CA hierarchy:

Encypher C2PA Root CA 2026 - Offline root CA, used only in approved ceremonies, including the isolated supplemental ceremony that signs the delegated Root OCSP responder certificate
Encypher C2PA Issuing CA 2026 - Online issuing CA

1.3.2 Registration Authority

Encypher Corp. acts as the Registration Authority (RA) for certificate requests. For self-service DV AL1 (Section 3.2.2), RA validation is automated and deterministic over verified evidence (Section 3.2.3), never caller-supplied and not routine manual review. Current exception routing is limited to the configured exact-FQDN hold in Section 3.2.4; because no end-to-end human disposition workflow exists, a held application cannot issue. Implementing and approving that workflow is an activation prerequisite.

1.3.3 Subscribers

Subscribers are organizations that receive end-entity certificates for C2PA claim signing. Before certificate issuance, an authenticated Encypher account owner or administrator, with organization membership verified server-side and authorized to bind the Subscriber, must affirmatively accept the exact versions of the Subscriber Agreement, this CP, and the CPS that govern the issuance. Subscribers must also comply with the obligations defined in Sections 4.5 and 4.8.

1.3.4 Relying Parties

Relying parties are any entities that validate C2PA manifests signed with certificates issued under this policy. Relying parties should verify certificates against the C2PA Trust List and check revocation status via OCSP or CRL.

1.4 Certificate Usage

Certificates issued under this policy are authorized for:

C2PA claim signing (content provenance manifests)
Document signing (digital content authentication)

Certificates issued under this policy must not be used for:

TLS/SSL server authentication
Code signing
S/MIME encryption (key transport or key agreement)
Any purpose not explicitly authorized

1.5 Policy Administration

Organization: Encypher Corp. Address: PENDING GATE O2. The legal business street address is not yet confirmed and is deliberately not stated. Written correspondence is accepted at the contact below until O2 is closed. Contact: ca@encypher.com CPS Location: https://ca.encypher.com/repository/cps

A value marked PENDING GATE is an open obligation, not a stated fact. The register of open obligations, including O2, is the Encypher CA Governance Documentation Set.

2. Publication and Repository Responsibilities

2.1 Repositories

Encypher maintains the following public repositories:

CP: https://ca.encypher.com/repository/certificate-policy
CPS: https://ca.encypher.com/repository/cps
Subscriber Agreement: https://ca.encypher.com/repository/subscriber-agreement
Root CA Certificate: https://ca.encypher.com/repository/root-ca.crt
Issuing CA Certificate: https://ca.encypher.com/repository/issuing-ca.crt
TSA Issuing CA Certificate: https://ca.encypher.com/repository/tsa-issuing-ca.crt
Root CA CRL: https://ca.encypher.com/crl/root-ca.crl
Issuing CA CRL: https://ca.encypher.com/crl/issuing-ca.crl
TSA Issuing CA CRL: https://ca.encypher.com/crl/tsa-issuing-ca.crl
OCSP: https://ca.encypher.com/ocsp

2.2 Publication of Certificate Information

Certificates and CRLs are published immediately upon generation. Policy documents are updated when changes are approved.

2.3 Time or Frequency of Publication

CRL (Issuing CA): Every 7 days, or within 24 hours of a revocation
CRL (Root CA): Annually
OCSP responses: Real-time

2.4 Access Controls on Repositories

All repository items listed in 2.1 are publicly accessible without authentication.

3. Identification and Authentication

3.1 Naming

3.1.1 Types of Names

All certificates contain an X.500 Distinguished Name in the Subject field. Self-service Domain-Validated AL1 end-entity certificates carry only the validated fully qualified domain name in the Common Name (CN). Encypher-managed end-entity certificates used for hosted signing and organization provisioning carry the managed-service Subject described below. CA hierarchy certificates carry Encypher's own organizational Distinguished Name.

3.1.2 Name Meanings

Self-service Domain-Validated AL1 end-entity certificates assert only:

CN (Common Name): the exact validated fully qualified domain name (FQDN) whose control the Subscriber demonstrated, derived by Encypher from the domain-control evidence and never accepted from the client.

No Organization (O), Country (C), State or Province (ST), or Locality (L) attribute is asserted in a self-service Domain-Validated AL1 end-entity certificate, because Encypher does not validate the Subscriber's legal name, country, or place of incorporation. Encypher-managed leaves instead assert C=US, O=<organization account display name>, and an Encypher-selected CN for hosted signing or organization provisioning. The O value is copied from the Encypher organization account and is authorized through the exact organization-bound assent and Registration Authority records required for that managed operation; it is not independently verified against government, corporate-registry, or other legal-identity evidence and must not be read as a legal-organization-validated identity. CA hierarchy certificates (Root, Issuing CA, OCSP, and TSA) carry Encypher's own organizational subject and are outside both subscriber-leaf naming scopes.

3.2 Initial Identity Validation

3.2.1 Method to Prove Possession of Private Key

For self-service enrollment, Subscribers must demonstrate control of the private key corresponding to the public key in the certificate request by submitting a valid Certificate Signing Request (CSR). Per C2PA CP Section 6.1.2, the CA SHALL NOT generate subscriber keypairs. Encypher does not generate, hold, serialize, or transmit subscriber private key material in software for any production signing path. In the separately enabled Hosted Signing Service, the certified key must be a non-exportable P-384 key generated inside the GCP Cloud KMS HSM boundary under Encypher's exclusive service-account control, and all production claim signing must occur inside that boundary (Section 6.3). For such a key, key possession is established by that HSM custody and by the KMS-attested public key retrieved for certification, not by a Subscriber-supplied CSR; no private key material exists outside the HSM boundary to be exported, delivered, or destroyed. The non-production software helper described in Section 6.3 certifies only a caller-supplied P-384 public key and never generates a keypair on the Subscriber's behalf.

3.2.2 Authentication of Organization Identity

Encypher issues end-entity certificates at C2PA Assurance Level 1 (AL1) through two operational paths:

Domain-Validated AL1 (DV AL1) is the only self-service subscriber enrollment profile and is used by the automated dashboard enrollment flow. Encypher validates only (a) authentication and owner or administrator membership of the requester in the Subscriber's Encypher organization account, established server-side, and (b) the Subscriber's control of each exact fully qualified domain name (FQDN) named in the request, using the automated challenges in Section 3.2.3. The Subject is CN=<validated FQDN> only, derived by Encypher from the validated domain evidence and never accepted from the client. Encypher does not verify, and makes no representation as to, the Subscriber's legal existence, legal name, corporate registration, country, or any attribute beyond demonstrated domain control and authenticated account membership.
Encypher-Managed AL1 is the operational profile for hosted signing and organization provisioning. It is not available through self-service enrollment. A hosted-signing leaf certifies a non-exportable P-384 key held inside the GCP Cloud KMS HSM (Section 6.3); Encypher generates no software subscriber key for it. Encypher selects the managed CN, copies O from the organization account display name, and sets C=US; the managed operation is bound to the exact organization and to the pre-issuance assent and Registration Authority authorization required by Sections 4.3 and 6.2.3. Account membership, organization-bound authorization, and Encypher's operation of the signing or provisioning service are the validation basis for this profile. The account display name is not independently verified as a legal entity name, and this profile does not assert legal existence, incorporation, or legal ownership of that name.

Encypher does not offer a legal-organization-validated, extended-validation, or other legal-identity issuance profile. An exception hold under Section 3.2.4 cannot issue a certificate or convert either profile into a verified legal identity.

Level 1 assurance does not attest to the trustworthiness, accuracy, or lawfulness of signed content. A self-service DV leaf binds a key to an exact domain-controlling, authenticated Subscriber; an Encypher-managed leaf binds the key to the organization account and Encypher-managed operation on the limited basis stated above.

3.2.3 Automated Domain-Control Validation and Evidence

For DV AL1, the Subscriber proves control of each exact FQDN through one or more automated, deterministic challenges:

DNS TXT challenge (preferred): the Subscriber publishes a random, single-use token as a DNS TXT record at _encypher-ca-challenge.<fqdn> with the value encypher-ca-verification=<token>. Encypher resolves the _encypher-ca-challenge TXT record for the exact FQDN, concatenates the character-strings within each TXT resource record before comparison, and confirms an exact token match.
HTTPS well-known challenge (optional): Encypher performs a Server-Side-Request-Forgery-guarded HTTPS GET of https://<fqdn>/.well-known/encypher-ca-challenge and confirms an HTTP 200 response whose body returns the exact token, either as JSON ({"token": "<token>"}) or as plain text.

Each challenge is evaluated programmatically with a deterministic pass or fail result against the exact FQDN; Encypher never strips a www. or any other label and never accepts a wildcard. Domain evidence used for issuance must be exact-FQDN, bound to the same organization and certificate application, current, verified, non-revoked, and within its finite validity period, and is captured as an immutable snapshot. Direct DNS or HTTPS challenge evidence has a finite validity of no more than 398 days (30 days by default) and is re-validated immediately before issuance; expired evidence returns the application to domain re-validation and cannot be used for issuance. An existing verified domain claim may be imported only after these checks and only as an immutable snapshot; a pending or unverified claim is insufficient. Imported evidence is assigned a finite CA validity equal to the earlier of the source claim's own expiry and the policy ceiling (the verification time plus the policy maximum of no more than 398 days); a source claim carrying no expiry is not treated as permanent and instead takes the policy ceiling, and a claim whose effective validity has already lapsed is rejected and cannot be imported. On a passing evaluation, the automated Registration Authority function records an append-only approval bound to the exact organization and certificate application, capturing the validation method (the deterministic predicate satisfied) and the evidence (token, resolved value or response, timestamps, and resolver or source). This record is a deterministic validation decision, not a human endorsement, and is an independent prerequisite to issuance under Section 4.3. Encypher performs no manual, editorial, or discretionary review of routine DV AL1 requests or of signed content.

3.2.4 Exception-Only Human Review

The implemented automated Registration Authority policy places an application in exception_review only when its exact normalized FQDN appears in the operator-configured exception-FQDN set; an exact match in the separately configured denied-FQDN set is denied. Invalid or insufficient domain-control proof is also a denial, not an exception. No human disposition workflow is currently implemented end to end, so an exception-held application cannot advance to issuance. Before activation, Encypher must implement and approve an authenticated, auditable human workflow that may only release the configured hold back to automated evaluation or deny the application; it must never issue a certificate or substitute for deterministic domain validation and assent. Fraud or abuse concerns, sanctions screening, general disputes, anomalous evidence, and high-risk-name review are not presently automated routing triggers and require approved policies, configured detection criteria, and an implemented disposition workflow as activation prerequisites.

3.3 Identification and Authentication for Re-key Requests

Certificate re-keying is not permitted per C2PA CP Section 4.8. This section is not applicable.

3.4 Identification and Authentication for Revocation Requests

Revocation requests are authenticated via:

Authenticated API request from the certificate subscriber
Direct communication with Encypher CA operations

4. Certificate Lifecycle Operational Requirements

4.1 Certificate Application

Organizations apply for certificates through the authenticated Encypher dashboard or API. An application is created by an authenticated account owner or administrator for a specific organization and identifies the domain(s) to be validated, the intended Generator Product, and the intended certificate use. Each application is an idempotent, single-issuance unit; authorization is bound to that exact application and is never inferred from a latest or unrelated record.

4.2 Certificate Application Processing

Encypher processes each self-service application through the automated validation pipeline of Section 3.2: it authenticates the requesting account and owner or administrator membership, evaluates the automated domain-control challenge(s), confirms Generator Product conformity (Section 4.2.1), and records the resulting deterministic Registration Authority approval. Routine DV AL1 applications are processed automatically with no manual review and no business-day processing target. The only implemented exception routing is an exact match against the operator-configured exception-FQDN set described in Section 3.2.4; because human disposition is not yet implemented end to end, a held application cannot issue. The broader review categories identified there are activation prerequisites, not current routing behavior.

4.2.1 Generator Product Conformity

Per C2PA CP Section 3.2.3, Encypher issues certificates only for use with a Generator Product listed as "conformant" on the C2PA Conforming Products List, and only at an assurance level at or below that product's recorded maximum. Eligibility is confirmed 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 Conforming Products List record identifier is required for issuance and is recorded in the issued certificate; a syntactically valid identifier alone, or the absence of a record identifier, is not eligibility and blocks issuance.

4.3 Certificate Issuance

Certificates are issued only after two independent prerequisites are satisfied for the exact organization and certificate application: (a) a passing automated Registration Authority validation record (Section 3.2.3), and (b) verified affirmative pre-issuance assent, by an authenticated account owner or administrator, to the exact Subscriber Agreement, CP, and CPS versions and their exact SHA-256 digests governing the issuance. Issuance fails closed unless both records exist, are bound to the same organization and application, match the exact current document bytes, and are revalidated against their immutable database rows immediately before signing; the issued certificate and its combined acceptance-and-RA link are persisted atomically, and OCSP status is published only after that commit. For self-service enrollment, the Subscriber generates its own key pair and submits a CSR (Section 6.1). Encypher does not generate Subscriber key pairs in software; a hosted-signing leaf instead certifies a non-exportable P-384 key that is generated and held inside the GCP Cloud KMS HSM (Section 6.3). The issuing CA signs the certificate with ECDSA using SHA-384 on the P-384 curve.

4.4 Certificate Acceptance

After issuance, Subscribers accept a Certificate by installing or using it with the identified Generator Product. Subscribers have 7 days to report issues with a newly issued Certificate. Certificate acceptance confirms receipt and acceptance of that Certificate and does not form the Subscriber Agreement or replace the affirmative pre-issuance assent required by Section 4.3.

4.5 Key Pair and Certificate Usage

Subscriber obligations: Protect private keys, use certificates only for authorized purposes, notify Encypher of key compromise within 24 hours
Relying party obligations: Verify certificate chain, check revocation status, validate certificate extensions

4.6 Certificate Renewal

Certificate renewal follows the same fully automated process as initial issuance, including fresh automated domain-control validation and a current assent record. Certificates may be renewed up to 30 days before expiration. Domain-control evidence has a finite validity of no more than 398 days (C2PA CP Section 3.4); renewal requires re-validated domain control, and loss of control of a validated domain, or a lapse of the domain-control evidence, results in non-renewal or revocation under Section 4.8.

4.7 Certificate Re-key

Certificate re-keying is not permitted per C2PA CP Section 4.8. Subscribers requiring a new certificate must submit a new application following the full issuance process defined in Sections 4.1 through 4.3.

4.8 Certificate Revocation

4.8.1 Circumstances for Revocation

Encypher performs automated post-issuance revalidation across every issued dashboard enrollment certificate on a recurring schedule, re-checking domain control, Generator Product conformance (including the Conforming Products List record identifier), and the currency and binding of the linked subscriber assent and Registration Authority authorization (including their exact document versions and SHA-256 digests). It revokes a certificate, with OCSP and CRL propagation, when it determines that:

The subscriber's private key is compromised or suspected of compromise
The subscriber's identity information changes or becomes inaccurate
The subscriber loses control of a validated domain, or automated domain-control re-validation fails
The associated Generator Product loses conformant status on the C2PA Conforming Products List or its canonical record identifier changes
The certificate-authorization link is missing, or the required assent or Registration Authority validation is invalid or withdrawn
The current approved document set is inactive, future-effective, malformed, unapproved, or otherwise unavailable for exact-version and digest comparison; this completed false check is authorization_invalid and causes immediate revocation rather than leaving the certificate GOOD for retry
The subscriber violates the subscriber agreement
The certificate was issued in error
The CA's private key is compromised

TSA signing certificates are revocable. A TSA signing certificate revocation is recorded in the isolated CA database and published through the dedicated TSA Issuing CA CRL.

4.8.2 Who Can Request Revocation

The certificate subscriber
Encypher CA operations
Law enforcement with valid legal process

4.8.3 Procedure for Revocation Request

Revocation requests are submitted via the Encypher API or by contacting ca@encypher.com. Revocation takes effect immediately upon processing.

4.8.4 Revocation Request Grace Period

No grace period. Revocation is processed immediately.

4.8.5 CRL Issuance Frequency

Claim-signing Issuing CA CRL: Every 7 days, NextUpdate within 10 days
TSA Issuing CA CRL: Every 7 days, NextUpdate within 10 days
Root CA CRL: Annually through an approved offline-root ceremony
Emergency CRL: Within 24 hours of revocation The isolated CA database allocates CRL numbers monotonically per online issuer and stores immutable signed DER artifacts. The public repository accepts only issuer-valid, signature-valid, non-regressing, unexpired artifacts. It may serve a last-known-good artifact during a publication outage only until that artifact's NextUpdate.

4.8.6 OCSP

Encypher provides real-time certificate status through two OCSP interfaces backed by the same issuer-aware status data and response-signing controls:

Public CA Service URL: http://ca.encypher.com/ocsp
Enterprise API proxy: issuer-aware OCSP GET and POST interface
Protocol: RFC 6960
Methods: GET and POST
Response signing: Issuer-aware delegated responders, one authorized by the Issuing CA for end-entity status and one authorized by the unchanged Root CA for Issuing CA status
Response validity: 24 hours

5. Facility, Management, and Operational Controls

5.1 Physical Controls

All CA private keys are stored in GCP Cloud KMS with HSM protection level (FIPS 140-2 Level 3). Key material never leaves the HSM boundary. No private key material is exported or present in plaintext outside the HSM.

Root CA key: Offline except during approved, isolated ceremonies via the dedicated ca-admin service account, including the supplemental ceremony that signs the delegated Root OCSP responder certificate
Issuing CA key: Accessible by ca-signing service account for runtime signing operations
OCSP signing key: Accessible by ca-signing service account for OCSP response signing
TSA signing key: Accessible by ca-signing service account for RFC 3161 timestamp signing

5.2 Procedural Controls

Key generation follows documented key ceremony procedures
Certificate issuance requires identity verification
Revocation is logged and auditable

5.3 Personnel Controls

CA operations are restricted to authorized Encypher personnel. Background checks apply per Encypher's standard hiring practices.

5.4 Audit Logging

All CA operations (key generation, certificate issuance, revocation, CRL generation) are logged with timestamps, operator identity, and operation details.

5.5 Records Archival

Certificate records and audit logs are retained for the lifetime of the CA plus 7 years.

6. Technical Security Controls

6.1 Key Pair Generation and Installation

6.1.1 Key Pair Generation

Algorithm: ECDSA on P-384 (secp384r1), ec-sign-p384-sha384 in GCP KMS
Key generation: Performed inside the HSM during KMS key creation
Entropy source: HSM internal CSPRNG (NIST SP 800-90A compliant)
Protection level: HSM (FIPS 140-2 Level 3, CAVP validated)
KMS provider: Google Cloud Key Management Service (us-central1)
Keys generated: 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 (production hosted signing, Sections 6.1.2 and 6.3)

6.1.2 Private Key Protection

All CA private keys are protected by GCP Cloud KMS with HSM protection level:

FIPS 140-2 Level 3: All keys reside in HSM-backed KMS
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 only on runtime keys
Root CA offline: Runtime has no signing grant on root-ca-key; root use is restricted to approved, isolated ceremonies, including issuance of the delegated Root OCSP responder certificate
Signing operations: All cryptographic signing is performed by the HSM via KMS API calls

Production hosted claim-signing keys are subject to the same protections: they must be non-exportable P-384 keys generated inside the KMS HSM boundary, and every production claim signature must be computed by the HSM through a KMS signing operation (Section 6.3). Encypher holds no software-resident private key for any production signing service.

6.2 Certificate Profile

6.2.1 Root CA Certificate

Subject: CN=Encypher C2PA Root CA 2026, OU=CA Division, O=Encypher Corp., L=San Francisco, ST=California, C=US
Algorithm: ECDSA with SHA-384 on P-384
Basic Constraints: CA:TRUE, pathlen:1 (critical)
Key Usage: keyCertSign, cRLSign (critical)
Validity: 20 years

6.2.2 Issuing CA Certificate

Per C2PA claimSigningIssuingCA profile:

Subject: CN=Encypher C2PA Issuing CA 2026, OU=CA Division, O=Encypher Corp., L=San Francisco, ST=California, C=US
Algorithm: ECDSA with SHA-384 on P-384
Basic Constraints: CA:TRUE, pathlen:0 (critical)
Key Usage: keyCertSign, cRLSign (critical)
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)
AIA: OCSP URL, CA Issuers URL
CRL Distribution Points: Root CA CRL URL
Validity: 1827 days (C2PA maximum)

6.2.3 End-Entity Certificate

Per C2PA claimSigningLeaf.al1 profile, the end-entity EKU "must contain c2pa-kp-claimSigning in addition to at least one of id-kp-emailProtection, id-kp-documentSigning." Encypher issues two operational subject shapes, both satisfying this requirement with id-kp-documentSigning and neither using id-kp-emailProtection or an rfc822Name; no S/MIME leaf profile is offered. The only self-service enrollment profile is the Domain-Validated subscriber leaf with a Common-Name-only Subject derived from exact-FQDN control evidence. Encypher-managed leaves are limited to hosted signing and organization provisioning. For a managed leaf, Encypher selects the CN, copies O from the exact organization account display name, sets C=US, and requires the organization-bound assent and Registration Authority authorization for the managed operation. This account-and-service authorization is the validation basis; the O attribute is not independently checked against legal-entity records and is not a legal-organization-validated identity.

Domain-Validated Subscriber Leaf (self-service enrollment):

Subject: CN= only; Encypher derives it from the validated domain evidence and asserts no organization, country, or locality
Algorithm: ECDSA with SHA-384 on P-384
Basic Constraints: CA:FALSE (critical)
Key Usage: digitalSignature, nonRepudiation (critical)
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), non-critical
CPL Record ID: c2pa-cpl-record (1.3.6.1.4.1.62558.4), UTF8String UUID, non-critical (when enrolled in CPL)
AIA: OCSP URL, CA Issuers URL
CRL Distribution Points: Issuing CA CRL URL
Validity: 1-366 days (C2PA AL1 maximum)

Encypher-Managed Leaf (hosted signing and organization provisioning):

Subject: C=US, O=, CN=<Encypher-selected publisher, common name, or organization identifier> (limited to the Encypher-operated hosted-signing or provisioning context; account display name and organization-bound authorization only, not independently validated legal identity)
Algorithm: ECDSA with SHA-384 on P-384
Basic Constraints: CA:FALSE (critical)
Key Usage: digitalSignature, nonRepudiation (critical)
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), non-critical
CPL Record ID: c2pa-cpl-record (1.3.6.1.4.1.62558.4), UTF8String UUID, non-critical (when enrolled in CPL)
AIA: OCSP URL, CA Issuers URL
CRL Distribution Points: Issuing CA CRL URL
Validity: 1-366 days (C2PA AL1 maximum)
Note: a hosted-signing leaf certifies a non-exportable P-384 key that is generated and remains inside the GCP Cloud KMS HSM boundary; its validity is the Encypher-managed AL1 range stated above (1-366 days, issued at the 366-day default for platform claim-signing leaves), not a minutes-scale lifetime. Encypher neither generates nor possesses a software private key for it, and no private key is delivered to the Subscriber (see Section 6.3). Organization-provisioning leaves are Encypher-managed account-identity certificates. Neither subject shape asserts that Encypher verified legal existence, legal name, incorporation, or entitlement to the display name outside the managed-service relationship.

6.2.4 OCSP Signing Certificates

Per C2PA ocspResponderLeaf profile:

Subjects: CN=Encypher C2PA OCSP Responder for end-entity status and CN=Encypher C2PA Root OCSP Responder for Issuing CA status
Authorization: The Issuing CA issues the end-entity responder certificate; the unchanged Root CA issues the Issuing CA responder certificate
Extended Key Usage: id-kp-OCSPSigning (non-critical)
Basic Constraints: CA:FALSE (critical)
OCSP No Check: Present (non-critical)
No AIA: MUST NOT be present
No CRL DP: MUST NOT be present
Validity: 1 year

6.2.5 TSA Signing Certificate

Subject: CN=Encypher C2PA TSA Signer, OU=CA Division, O=Encypher Corp.
Issuer: Dedicated TSA Issuing CA with id-kp-timeStamping EKU
Algorithm: ECDSA with SHA-384 on P-384
Basic Constraints: CA:FALSE (critical)
Key Usage: digitalSignature, nonRepudiation (critical)
Extended Key Usage: id-kp-timeStamping (1.3.6.1.5.5.7.3.8) (critical, single-purpose)
Certificate Policies: c2pa-certificate-policy (1.3.6.1.4.1.62558.1.1)
AIA: OCSP URL, CA Issuers URL
CRL Distribution Points: TSA Issuing CA CRL URL
Validity: 1 year
Revocation: Registered in the isolated CA status store and revocable through the dedicated TSA Issuing CA CRL
Key protection: GCP KMS HSM (FIPS 140-2 Level 3)

The TSA signing key is dedicated to timestamping and must not be shared with claim signing keys.

6.3 Hosted Signing Key Custody and Certificate Validity

The Hosted Signing Service must hold its claim-signing key in hardware. Key-compromise exposure is bounded by non-exportable HSM custody, revocable KMS access, and revocation, not by a short certificate 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 the Subscriber, or to any Encypher service
The Issuing CA issues a certificate over that key within the Encypher-managed AL1 validity range of Section 6.2.3 (1-366 days); production platform claim-signing leaves are issued at the 366-day default. Production hosted signing does not use minutes-scale certificate validity
Every production claim signature is computed by the HSM through a KMS signing operation; no production signing is performed over software-resident private key material
The signature is timestamped via RFC 3161 TSA (KMS-backed)
The timestamp proves the signature was created while the certificate was valid

Because the private key never exists outside the HSM, there is no software key to destroy after signing; residual exposure is bounded by non-exportable HSM custody, revocable KMS access, and certificate revocation through OCSP and CRL, not by key deletion and not by a short certificate lifetime. Encypher makes no claim that production hosted-signing certificates reduce the key-compromise window to minutes. A hosted-signing certificate contains the same extensions and assurance level as the standard end-entity certificate defined in Section 6.2.3.

A software helper that certifies a caller-supplied P-384 public key exists 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 follow the Encypher-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 with it, and destroys it. The production configuration must refuse this helper, and it must never be used to issue a production hosted-signing certificate or to perform a production claim signature.

6.4 RFC 3161 Timestamp Authority

6.4.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, which the hosted-signing model of Section 6.3 requires: the timestamp is cryptographic evidence of signing time that a verifier uses to evaluate whether the signing certificate was valid and not revoked at that time, and it supports verification after certificate expiry where the applicable validation policy permits.

6.4.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)

6.4.3 Time Source Requirements

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

6.4.4 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)

7. Certificate, CRL, and OCSP Profiles

Detailed in Section 6.2 above and in the CPS.

8. Compliance Audit and Other Assessments

8.1 Frequency and Circumstances of Assessment

Self-assessment at Level 1 per C2PA Certificate Policy requirements. External audit when pursuing higher assurance levels.

8.2 Assessor Qualifications

Internal review by Encypher engineering and policy staff for Level 1 compliance.

9. Other Business and Legal Matters

9.1 Fees

Certificate issuance fees, if any, are stated in the applicable written order form.

9.2 Liability

Encypher's liability is limited as defined in the subscriber agreement. Encypher does not guarantee the trustworthiness of signed content, only the identity of the signer.

9.3 Governing Law

This CP, and any agreements arising from it (including the Subscriber Agreement), is governed by the laws of the State of Delaware, United States, without regard to conflict-of-laws principles, and the state and federal courts of Delaware have jurisdiction, as required by C2PA Certificate Policy Section 9.14.1.

10. References

RFC 3161 - Internet X.509 PKI Time-Stamp Protocol (TSP)
RFC 3647 - Internet X.509 PKI Certificate Policy and Certification Practices Framework
RFC 5280 - Internet X.509 PKI Certificate and CRL Profile
RFC 5652 - Cryptographic Message Syntax (CMS)
RFC 6960 - Online Certificate Status Protocol (OCSP)
C2PA Certificate Policy v0.1
C2PA Specification 2.4
C2PA Generator Product Security Requirements
CAB Forum Baseline Requirements
Encypher C2PA Certification Practice Statement (docs/ca/certification-practice-statement.md)
Encypher C2PA Incident Response Plan (docs/c2pa/conformance/incident_response.md)
Encypher CA Governance Documentation Set (docs/c2pa/conformance/cp_cps/README.md)