# Verimago Certificate Policy and Certification Practice Statement (CP/CPS)

| Field | Value |
|---|---|
| **Document title** | Verimago Certificate Policy and Certification Practice Statement |
| **Version** | 1.0 |
| **Status** | Effective |
| **Effective date** | 2026-07-31 |
| **Organization** | Verimago LLC |
| **Publication URL** | https://verimago.com/pki/cp-cps |
| **PKI repository** | https://verimago.com/pki/ |
| **CA publication host** | http://ca.verimago.io/ |
| **Contact** | pki@verimago.com |
| **Structure** | RFC 3647 |

This document is the combined **Certificate Policy (CP)** and **Certification Practice Statement (CPS)** for the Verimago Public Key Infrastructure. It describes the policies that govern issuance of Verimago C2PA Claim Signing Certificates and the practices Verimago LLC employs to implement those policies.

Verimago intends the PKI services described here to conform to the applicable requirements of:

- **C2PA Certificate Policy v0.1** (2025-06-02), OID `1.3.6.1.4.1.62558.1.1`
- **C2PA Generator Product Security Requirements v0.1** (2025-06-02), as applicable to enrolled Generator Products
- **RFC 5280**, **RFC 6960**, **RFC 3647**, **RFC 2119**

This CP/CPS does **not** supersede the C2PA Certificate Policy. Where this document is silent, the C2PA Certificate Policy controls. Where this document is more specific, Verimago’s practices implement the C2PA requirements for Verimago’s PKI.

---

## Document history

| Version | Date | Change |
|---|---|---|
| 1.0 | 2026-07-31 | Initial publication. Reflects the trust-listed Verimago Root CA / Claim Signing Issuing CA chain (ceremony 2026-05-15), steady-state CRL/OCSP operations, and dual-control key management. |

---

## 1. Introduction

### 1.1 Overview

Verimago LLC operates a Certificate Authority that issues X.509 certificates used by Verimago Generator Products to cryptographically sign C2PA Claims (Content Credentials) on photos, video, and other digital assets.

The Verimago PKI consists of:

1. **Verimago Root CA** — self-signed trust anchor
2. **Verimago Claim Signing Issuing CA** — subordinate CA that issues end-entity claim-signing certificates and the OCSP responder certificate
3. **Claim Signing Leaf certificates** — end-entity certificates used by Verimago Camera and related Generator Products (Assurance Level 1 and Assurance Level 2)
4. **OCSP Responder certificate** — used solely to sign RFC 6960 OCSP responses

Verimago does **not** issue certificates for TLS/SSL, code signing, S/MIME, document signing as a primary purpose, or any use outside C2PA claim signing and associated CA/OCSP operations.

### 1.2 Document name and identification

| Item | Value |
|---|---|
| Document | Verimago Certificate Policy and Certification Practice Statement |
| Version | 1.0 |
| C2PA policy OID asserted in certificates | `1.3.6.1.4.1.62558.1.1` |
| Verimago document OID | Reserved for future IANA enterprise arc assignment; document identity is by title, version, and publication URL |

### 1.3 PKI participants

| Role | Description |
|---|---|
| **CA Operator / Policy Authority** | Verimago LLC. Owns policy, operates the Root and Issuing CAs, publishes status information, and maintains this CP/CPS. |
| **Registration Authority (RA)** | Verimago LLC. Performs subscriber identity and product validation for certificate enrollment. RA functions are not delegated to third parties. |
| **Subscribers** | Organizations and individuals enrolled for Verimago Claim Signing Certificates for use in approved Generator Products (publishers, creators, and Verimago first-party Camera apps). |
| **Relying Parties** | Entities that validate Verimago-signed Content Credentials, including C2PA-conformant validators that consume the C2PA Trust List. |
| **Trusted Roles** | Lead Operator and Approver (dual-control operators for CA key ceremonies and root-sensitive operations); Independent Witness (observes ceremonies; does not operate CA systems). |
| **Repository** | Public PKI documentation at `https://verimago.com/pki/` and CA publication endpoints at `http://ca.verimago.io/`. |

### 1.4 Certificate usage

#### 1.4.1 Appropriate uses

- Signing C2PA Claims / Content Credentials with a Verimago-issued claim-signing leaf
- CA signing of subordinate CA certificates, end-entity certificates, and CRLs as profiled in §7
- OCSP response signing by the designated OCSP responder certificate

#### 1.4.2 Prohibited uses

- Any purpose outside C2PA claim signing and CA/OCSP operations defined in this CP/CPS
- Use of CA private keys outside FIPS-validated cryptographic modules (§6)
- Unilateral root or intermediate key use by a single individual (§5, §6)

### 1.5 Policy administration

| Item | Value |
|---|---|
| Organization | Verimago LLC |
| Contact | pki@verimago.com |
| Legal | legal@verimago.com |
| Approval | Changes to this CP/CPS require approval by the Lead Operator and acknowledgement by the Approver before becoming Effective |
| Publication | New Effective versions are published at `https://verimago.com/pki/cp-cps` before reliance |

### 1.6 Definitions and acronyms

**AL1 / AL2** — C2PA Assurance Level 1 / Assurance Level 2 for claim-signing leaves.  
**CA** — Certification Authority.  
**CP** — Certificate Policy.  
**CPS** — Certification Practice Statement.  
**CRL** — Certificate Revocation List.  
**HSM** — Hardware Security Module.  
**OCSP** — Online Certificate Status Protocol (RFC 6960).  
**Subscriber** — Entity that is issued a Verimago claim-signing certificate.  
**Trusted Role** — Role authorized to perform sensitive CA operations under dual control.

Normative language follows RFC 2119: SHALL, SHALL NOT, SHOULD, MAY.

---

## 2. Publication and repository responsibilities

### 2.1 Repositories

Verimago maintains:

| Repository | Contents | URL |
|---|---|---|
| PKI documentation | This CP/CPS, repository index | `https://verimago.com/pki/` |
| CA publication | Root and intermediate PEMs, CRLs, OCSP | `http://ca.verimago.io/` |

AIA and CDP URIs embedded in certificates use the `http://` scheme as required by C2PA certificate profiles.

### 2.2 Publication of certification information

Verimago publishes:

| Object | Path |
|---|---|
| Root CA certificate | `http://ca.verimago.io/certs/root.pem` |
| Intermediate CA certificate | `http://ca.verimago.io/certs/intermediate.pem` |
| Intermediate CRL (root-signed) | `http://ca.verimago.io/crl/intermediate.crl` |
| Claim-signing CRL (intermediate-signed) | `http://ca.verimago.io/crl/claim-signing.crl` |
| OCSP | `http://ca.verimago.io/ocsp` |

### 2.3 Time or frequency of publication

| Artifact | Cadence |
|---|---|
| CP/CPS | Upon Effective approval of a new version |
| CRLs | Re-signed at least **weekly**; also on demand upon revocation |
| CRL `nextUpdate` | **90 days** from `thisUpdate` (resilience buffer; weekly re-signing keeps `thisUpdate` current) |
| OCSP | On demand; responses include a `nextUpdate` window consistent with operational configuration (default on the order of hours) |
| CA certificates | At issuance / ceremony; not routinely replaced |

### 2.4 Access controls on repositories

Read access to published PEMs, CRLs, OCSP, and this CP/CPS is unrestricted. Write access to publication infrastructure is limited to authorized Verimago operations personnel and automated systems under role-based access control with multi-factor authentication. Modifications are logged.

---

## 3. Identification and authentication

### 3.1 Naming

#### 3.1.1 Types of names

Certificates use X.500 Distinguished Names. Current chain subjects:

| Certificate | Subject DN |
|---|---|
| Root CA | `C=US, ST=Washington, O=Verimago LLC, CN=Verimago Root CA` |
| Claim Signing Issuing CA | `C=US, ST=Washington, O=Verimago LLC, CN=Verimago Claim Signing Issuing CA` |
| Claim Signing Leaf | `C=US, ST=Washington, O=Verimago LLC, CN=Verimago Camera` (Generator Product leaves may use product-specific CNs consistent with enrollment) |

#### 3.1.2 Need for names to be meaningful

Organization (`O`) and country (`C`) reflect Verimago LLC’s legal identity for CA certificates. Leaf CNs identify the Generator Product or enrolled subscriber context.

#### 3.1.3 Anonymity or pseudonymity

Anonymous CA certificates are not issued. Subscriber leaves identify the enrolled product/organization context; privacy handling for individual creators is described in Verimago’s Privacy Policy.

#### 3.1.4–3.1.6 Name uniqueness and trademarks

Serial numbers uniquely identify certificates. Subject DN uniqueness is enforced within Verimago’s issuance systems. Trademark disputes are handled under applicable law; Verimago may refuse or revoke certificates that misrepresent identity.

### 3.2 Initial identity validation

#### 3.2.1 Proof of private key possession

Enrollment requires a Certificate Signing Request (CSR) or equivalent proof that the applicant controls the private key corresponding to the public key to be certified. For Verimago first-party Camera apps, key generation occurs in platform secure hardware (device Secure Enclave / StrongBox) under the Generator Product security model.

#### 3.2.2 Authentication of organization identity

Publisher / organization subscribers are validated through Verimago’s publisher enrollment process, including legal existence and authority checks appropriate to the tier (see product enrollment flows). Certificates are not issued until RA approval completes.

#### 3.2.3 Authentication of individual identity

Creator-tier subscribers are validated through Verimago’s creator enrollment process (account identity verification and product binding). Assurance Level asserted in the leaf reflects the validation and attestation properties of the enrolled Generator Product instance.

#### 3.2.4 Non-verified subscriber information

Fields not subject to validation are not placed in certificates, or are limited to values that do not assert unverified identity.

#### 3.2.5 Validation of authority

Requests that bind a certificate to an organization require confirmation that the requester is authorized to act for that organization.

#### 3.2.6 Delegated RA

Verimago does not currently delegate RA functions to third parties.

#### 3.2.7 Validation of software and hardware (Generator Products)

For Assurance Level 2 leaves, enrollment requires evidence consistent with C2PA Generator Product Security Requirements for the Max Assurance Level claimed (including hardware-backed attestation where applicable). Assurance Level OIDs in certificates are defined in §7.

### 3.3–3.5 Renewal, re-key, and revocation authentication

| Request | Authentication |
|---|---|
| Renewal / re-key (routine) | Authenticated subscriber session or re-validation per §3.2 |
| Re-key after revocation | Full re-validation per §3.2 |
| Revocation | Authenticated subscriber request, Verimago Trusted Role action, or Verimago-initiated revocation under §4.9 |

---

## 4. Certificate life-cycle operational requirements

### 4.1 Certificate application

Applications are submitted through Verimago enrollment channels (publisher portal, creator flows, or first-party Generator Product enrollment). Applicants SHALL accept applicable Subscriber terms before issuance.

### 4.2 Certificate application processing

The RA performs identification and authentication per §3. Applications that fail validation are rejected. Processing time depends on tier and completeness of materials; Verimago aims to complete routine creator enrollments promptly and publisher enrollments within the published product SLA.

### 4.3 Certificate issuance

Upon approval:

1. The Issuing CA signs the end-entity certificate using the Issuing CA private key inside the HSM
2. A unique serial number is assigned
3. Certificate status is set to **good** in the OCSP status store
4. The subscriber / Generator Product is notified or provisioned with the certificate

Root CA certificate signing and Issuing CA certificate signing are performed only during a **witnessed key ceremony** under dual control (§6.1).

### 4.4 Certificate acceptance

Use of the certificate to sign Content Credentials, or failure to object within a reasonable period after delivery, constitutes acceptance.

### 4.5 Key pair and certificate usage

Subscribers SHALL:

- Use private keys only for C2PA claim signing as permitted by this CP/CPS and the Subscriber agreement
- Protect private keys consistent with the Assurance Level and Generator Product Security Requirements
- Request revocation promptly upon compromise or cessation of use

Relying Parties SHOULD validate certification paths against the C2PA Trust List (or an equivalent trust configuration), check certificate status via OCSP and/or CRL, and apply C2PA technical validation rules.

### 4.6–4.8 Renewal, re-key, modification

Routine renewal/re-key issues a new certificate for a new or continued key pair after authentication per §3. Certificate modification of asserted identity fields requires re-validation. Expired certificates are not “renewed” in place; a new certificate is issued.

### 4.9 Certificate revocation and suspension

#### 4.9.1 Circumstances for revocation

Verimago SHALL revoke a certificate when:

- Private key compromise is known or reasonably suspected
- The certificate was issued in error or based on false information
- The subscriber requests revocation
- The subscriber agreement is terminated for cause
- The Generator Product instance is no longer authorized
- Continued use would violate this CP/CPS or the C2PA Certificate Policy

#### 4.9.2 Who can request revocation

The subscriber, Verimago Trusted Roles, and Verimago acting on confirmed compromise reports.

#### 4.9.3 Procedure

1. Authenticate the request
2. Record the serial, revocation time, reason, and CRL scope in the CA revocation record
3. Publish an updated CRL
4. Update the OCSP status store so subsequent OCSP responses report `revoked`

Internal procedure detail (including the repository path of the revocation record and the refresh workflow) is maintained in Verimago’s CA steady-state operations runbook.

#### 4.9.4–4.9.5 Timing

Consistent with the C2PA Certificate Policy, Verimago SHALL process a validated revocation request within **72 hours**. Verimago’s operational target for confirmed key compromise is faster when feasible. Emergency CRL publication is performed via on-demand refresh; weekly scheduled re-signing ensures routine freshness.

#### 4.9.7–4.9.8 CRL issuance frequency

| Item | Policy |
|---|---|
| Scheduled re-sign | At least weekly |
| On-demand re-sign | Upon revocation or operator dispatch |
| `nextUpdate` | 90 days from `thisUpdate` |
| Independent monitor | Automated health check fails if either CRL has fewer than 14 days of validity remaining |

#### 4.9.9–4.9.10 OCSP

OCSP is available at `http://ca.verimago.io/ocsp`. Relying Parties and Generator Products SHOULD check status when online status information is available, consistent with the C2PA Technical Specification.

#### 4.9.13 Suspension

Verimago does **not** use certificate suspension. Certificates are either valid or revoked.

### 4.10 Certificate status services

| Service | Availability target | Notes |
|---|---|---|
| OCSP | Continuous | RFC 6960 GET/POST |
| CRL | Continuous via CA publication host | Weekly refresh + on-demand |
| PEM publication | Continuous | Root and intermediate |

### 4.11 End of subscription

Upon end of subscription, Verimago may revoke remaining certificates and ceases new issuance for that subscriber until re-enrollment.

### 4.12 Key escrow and recovery

CA private keys are **not** escrowed in plaintext and are **not** archived outside HSM-backed custody. Subscriber claim-signing keys for Camera apps are generated and held in platform secure hardware and are not escrowed by Verimago.

---

## 5. Facility, management, and operational controls

### 5.1 Physical and environmental controls

CA private keys are generated and used inside **FIPS 140-3 Level 3** (or FIPS 140-2 Level 3 equivalent) certified Hardware Security Modules operated in a cloud-secured environment. Physical security of HSM equipment is provided by the HSM service’s certified controls. Ceremony and administrative access to CA systems is performed from hardened jump hosts with restricted network posture.

### 5.2 Procedural controls

#### 5.2.1 Trusted roles

| Role | Responsibilities |
|---|---|
| Lead Operator | Runs ceremonies and CA operational procedures; maintains this CP/CPS |
| Approver | Provides the second control for ceremony / root-sensitive approvals; observes |
| Independent Witness | Observes ceremonies; confirms checkpoints; does not operate systems |

#### 5.2.2 Separation of duties / dual control

No single individual can unilaterally perform Root CA key generation, Root CA certificate signing, or Issuing CA key generation. Dual control is enforced by a combination of:

1. Separate operator identities with split IAM privileges
2. Time-bounded approval windows that require the Approver before Root/Issuing signing can proceed
3. Witnessed ceremony procedures with recorded checkpoints
4. Immutable audit logs of approval and signing events

#### 5.2.3 Identification and authentication for trusted roles

Trusted Role access requires multi-factor authentication and use of designated operator accounts (not shared personal accounts).

### 5.3 Personnel controls

Trusted Role holders are Verimago personnel (or contracted operators under Verimago direction) designated in writing. Background and suitability checks are applied as appropriate to the role. Operators receive ceremony and steady-state runbook training before participating in production ceremonies.

### 5.4 Audit logging

Verimago logs, at minimum:

- CA key generation and certificate signing ceremonies (transcripts, witness checkpoints, sign-off)
- HSM / KMS cryptographic operations relevant to CA signing (cloud audit logs)
- CRL refresh and publication events
- Revocation record changes
- Privileged access to CA administrative systems

Audit logs are retained for at least **seven (7) years** or the life of the Root CA plus seven years, whichever is longer, unless a longer period is required by law.

### 5.5 Records archival

Ceremony evidence packages (transcripts, key inventory, certificate PEMs, witness attestations, sign-off) are retained as part of the CA’s permanent record.

### 5.6 Key changeover

Root and Issuing CA key changeover requires a new witnessed ceremony. Superseded CA certificates remain published as needed for path validation of previously issued certificates until reliance ends. Trust List updates are coordinated with the C2PA Conformance Program when trust anchors change.

### 5.7 Compromise and disaster recovery

| Scenario | Response |
|---|---|
| Leaf key compromise | Revoke within 72 hours; rotate to a healthy leaf; investigate |
| Issuing CA or Root compromise | Revoke affected CA certificate(s); notify the C2PA Conformance Program; cease issuance; plan replacement genesis ceremony |
| Publication outage | Restore CA publication endpoints; CRL `nextUpdate` buffer and edge caching provide short-term resilience |
| Loss of cloud account control | Treat as potential compromise of operational control; escalate per incident response; prioritize status publication and Trust List communication |

Detailed internal runbooks supplement this section and are not all publicly published.

### 5.8 CA termination

If Verimago terminates CA operations, Verimago SHALL revoke outstanding certificates where practicable, publish final CRLs, notify the C2PA Conformance Program, and preserve records per §5.4–5.5.

---

## 6. Technical security controls

### 6.1 Key pair generation and installation

#### 6.1.1 CA key generation

CA keys SHALL be generated:

- Inside a FIPS 140-3 Level 3 (or FIPS 140-2 Level 3) certified HSM
- Under multi-party control (Lead Operator + Approver)
- With an Independent Witness observing (and/or a complete recording)
- According to a documented ceremony script with participant sign-off and notation of deviations

The trust-listed Verimago Root CA and Claim Signing Issuing CA keys were generated in a witnessed ceremony on **2026-05-15**.

#### 6.1.2 Subscriber key generation

Claim-signing keys for Verimago Camera are generated in platform secure hardware. Other Generator Products SHALL generate keys consistent with their claimed Assurance Level and the C2PA Generator Product Security Requirements.

#### 6.1.3 Key sizes and algorithms

| Key | Algorithm |
|---|---|
| Root CA | ECDSA P-384, signatures with SHA-384 |
| Claim Signing Issuing CA | ECDSA P-384, signatures with SHA-384 |
| Claim Signing Leaves | ECDSA P-384, signatures with SHA-384 |
| OCSP Responder | ECDSA P-384, signatures with SHA-384 |

### 6.2 Private key protection

- CA private keys SHALL remain inside the HSM cryptographic boundary; they SHALL NOT exist in plaintext outside that boundary
- CA private keys SHALL NOT be archived in exportable form
- Activation / use of Root-sensitive operations requires dual control as in §5.2.2
- HSM credentials for automated Issuing CA day-to-day signing (leaf issuance, routine CRL signing, OCSP) are held by operational systems under least privilege, not by individual operators in plaintext

### 6.3 Other aspects of key pair management

| Certificate | Typical validity |
|---|---|
| Root CA | 20 years |
| Claim Signing Issuing CA | ≤ 1827 days (5 years target) |
| Claim Signing Leaf AL1 | ≤ 366 days |
| Claim Signing Leaf AL2 | ≤ 90 days |
| OCSP Responder | Consistent with profile constraints |

### 6.4 Activation data

Operator authentication uses multi-factor authentication. HSM/CU activation data for automated systems is stored in a secrets manager accessible only to authorized CA runtime roles.

### 6.5–6.7 Computer, life-cycle, and network security

CA administrative systems use hardened hosts, restricted network egress, role-based access, and MFA for privileged remote access. Generator Product and API infrastructure that consume issued leaves are segregated from Root CA key ceremony controls.

### 6.8 Time-stamping

Verimago may use an external RFC 3161 Time-Stamp Authority for Content Credential timestamps. In-house TSA certificates are not required for the claim-signing chain described in this CP/CPS.

---

## 7. Certificate, CRL, and OCSP profiles

Profiles conform to the official C2PA certificate profile schemas. Summary:

### 7.1 Root CA

| Field | Value |
|---|---|
| Subject | `C=US, ST=Washington, O=Verimago LLC, CN=Verimago Root CA` |
| BasicConstraints | critical, CA=TRUE, pathLen=2 |
| KeyUsage | critical, keyCertSign, cRLSign |
| AIA / CDP | Absent |
| Signature | ecdsa-with-SHA384 |

### 7.2 Claim Signing Issuing CA

| Field | Value |
|---|---|
| Subject | `C=US, ST=Washington, O=Verimago LLC, CN=Verimago Claim Signing Issuing CA` |
| BasicConstraints | critical, CA=TRUE, pathLen=0 |
| KeyUsage | critical, keyCertSign, cRLSign |
| EKU | `1.3.6.1.4.1.62558.2.1` (c2pa-kp-claimSigning) and emailProtection and/or documentSigning |
| CertificatePolicies | `1.3.6.1.4.1.62558.1.1` |
| AIA | OCSP `http://ca.verimago.io/ocsp`; caIssuers `http://ca.verimago.io/certs/root.pem` |
| CDP | `http://ca.verimago.io/crl/intermediate.crl` |

### 7.3 Claim Signing Leaves

| Field | AL1 | AL2 |
|---|---|---|
| Max validity | 366 days | 90 days |
| BasicConstraints | critical, CA=FALSE | critical, CA=FALSE |
| KeyUsage | critical, digitalSignature, contentCommitment | same |
| EKU | c2pa-kp-claimSigning + emailProtection or documentSigning | same |
| CertificatePolicies | `1.3.6.1.4.1.62558.1.1` | same |
| Assurance OID | `1.3.6.1.4.1.62558.3.10` | `1.3.6.1.4.1.62558.3.20` |
| AIA | OCSP + caIssuers (http) | same |
| CDP | `http://ca.verimago.io/crl/claim-signing.crl` | same |

### 7.4 OCSP responder certificate

EKU is limited to `id-kp-OCSPSigning`; includes OCSP No Check as required by profile; AIA and CDP are absent on the responder certificate itself.

### 7.5 CRL profile

PKIX CRLs signed with ECDSA P-384 / SHA-384. Empty CRLs are valid when no revocations are on record. Issuing Distribution Point, Authority Key Identifier, and CRL Number extensions are included consistent with generation tooling.

### 7.6 OCSP profile

RFC 6960 responses signed by the OCSP responder private key held in the HSM.

---

## 8. Compliance audit

### 8.1 Frequency

Verimago SHALL maintain continuous internal monitoring of CA publication health (OCSP reachability, CRL validity, PEM publication). Verimago SHOULD obtain an independent third-party audit appropriate to C2PA Certificate Policy §8 (for example, a WebTrust-for-CA or equivalent engagement) on a cadence consistent with Trust List expectations as the program matures.

### 8.2 Identity of auditor

Independent auditors, when engaged, SHALL be qualified for CA/PKI audits and independent of Verimago day-to-day CA operations.

### 8.3 Topics covered

Key management, dual control, ceremony evidence, certificate profiles, revocation/status services, personnel security, logging, and incident response.

### 8.4 Actions taken as a result of deficiency

Material deficiencies are remediated under a documented plan; the C2PA Conformance Program is notified when required by program rules.

### 8.5 Communication of results

Public summaries may be published at the PKI repository. Full audit reports may be shared with the C2PA Conformance Program under applicable confidentiality terms.

---

## 9. Other business and legal matters

### 9.1 Fees

Fees for certificates and related services are as published by Verimago (see https://verimago.com/pricing) or as set in enterprise agreements.

### 9.2 Financial responsibility

Verimago maintains commercial operations suitable to its CA service. Specific insurance details are available to qualified parties under NDA upon request.

### 9.3 Confidentiality and privacy

Personal data is handled under Verimago’s Privacy Policy (https://verimago.com/privacy). This CP/CPS is public. Detailed internal security runbooks may remain confidential.

### 9.4 Intellectual property

This CP/CPS is © Verimago LLC. Certificates and published PEMs/CRLs may be freely used for path validation and Content Credential verification. Proprietary ceremony tooling and unpublished operational details remain Verimago intellectual property.

### 9.5 Representations and warranties

Verimago represents that it operates the CA in accordance with this CP/CPS and the applicable requirements of the C2PA Certificate Policy. Subscribers represent that information provided for enrollment is accurate and that private keys are protected consistent with the asserted Assurance Level.

### 9.6 Disclaimers / limitations of liability

Except as required by law or a separate written agreement, Verimago’s liability related to certificates is limited as set forth in Verimago’s Terms of Service (https://verimago.com/terms) and any applicable Subscriber or enterprise agreement. Content Credentials prove cryptographic provenance claims; they do not by themselves prove the truth of depicted events.

### 9.7 Indemnities

Subscriber indemnity obligations are as set forth in applicable Subscriber / Terms agreements.

### 9.8 Term and termination

This CP/CPS remains in effect until superseded by a later Effective version or until CA termination per §5.8.

### 9.9 Individual notices and communications

PKI policy notices: pki@verimago.com. Legal: legal@verimago.com.

### 9.10 Amendments

Verimago may amend this CP/CPS. Material changes receive a new version number, Effective date, and publication at the Publication URL before reliance. Editorial corrections may be made without changing the major version when substance is unchanged.

### 9.11 Dispute resolution / governing law

Disputes are governed as set forth in Verimago’s Terms of Service and applicable agreements. Governing law is as stated in those agreements (Washington, USA, unless otherwise specified).

### 9.12 Compliance with applicable law

Verimago complies with applicable United States law. Export controls applicable to cryptography are observed.

### 9.13 Miscellaneous provisions

If any provision of this CP/CPS is held unenforceable, the remainder remains in effect. This CP/CPS, together with applicable Subscriber agreements and the C2PA Certificate Policy, constitutes the policy framework for the Verimago PKI.

### 9.14 Other provisions

Trust List inclusion of the Verimago Root CA and Claim Signing Issuing CA is determined by the C2PA Conformance Program. Current Trust List status is announced at https://verimago.com/news/c2pa-trust-list.

---

## Appendix A — Quick reference (configured practices)

| Practice | Configured value |
|---|---|
| Legal entity | Verimago LLC |
| Root subject | CN=Verimago Root CA |
| Issuing CA subject | CN=Verimago Claim Signing Issuing CA |
| Policy OID in certs | `1.3.6.1.4.1.62558.1.1` |
| Crypto suite | ECDSA P-384 / SHA-384 |
| HSM | FIPS 140-3 Level 3 |
| Dual control | Lead Operator + Approver (+ Independent Witness for ceremonies) |
| Root genesis | Witnessed ceremony 2026-05-15 |
| OCSP | `http://ca.verimago.io/ocsp` (continuous) |
| CRL re-sign | Weekly + on-demand |
| CRL validity (`nextUpdate`) | 90 days |
| Revocation SLA | ≤ 72 hours from validated request |
| Suspension | Not used |
| CP/CPS URL | https://verimago.com/pki/cp-cps |
| Contact | pki@verimago.com |

## Appendix B — Related Verimago documents (internal / operational)

| Document | Purpose |
|---|---|
| `docs/runbooks/ca-steady-state-operations.md` | Day-to-day CRL/OCSP/revocation runbook |
| `docs/ca-ceremony-runbook.md` | Ceremony script and evidence requirements |
| `docs/c2pa-cert-profile-field-answers.md` | Profile field mapping to official C2PA schemas |
| `docs/C2PA_CA_SUBMISSION_TRACEABILITY.md` | Requirement → artifact traceability |

Internal runbooks may contain infrastructure identifiers not reproduced in this public CP/CPS.