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

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

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:

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

1.3 PKI participants

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

1.6 Definitions and acronyms

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

2. Publication and repository responsibilities

2.1 Repositories

Verimago maintains:

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:

2.3 Time or frequency of publication

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:

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

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:

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

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

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

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

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:

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

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

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

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

7.2 Claim Signing Issuing CA

7.3 Claim Signing Leaves

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: [email protected]. Legal: [email protected].

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)

Appendix B — Related Verimago documents (internal / operational)

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