Trusteddit Certificate Practice Statement

1.1 Overview

This Certificate Practice Statement (CPS) describes the practices and procedures employed by the Trusteddit Certificate Authority (CA) in the issuance, management, revocation, and renewal of C2PA content signing certificates. This CPS implements the requirements set forth in the Trusteddit Certificate Policy (CP).

While the CP defines what the Trusteddit PKI does and the rules governing its operation, this CPS describes how those rules are implemented in practice. This document is structured in accordance with RFC 3647.

The Trusteddit CA is operated by SanMarcSoft LLC and provides C2PA content signing certificates exclusively. The CA does not issue certificates for TLS/SSL, code signing, email, or any other purpose.

1.2 Document Name and Identification

Document Title

Trusteddit Certificate Practice Statement

Version

0.1 (DRAFT)

OID

[DRAFT -- To be assigned upon policy finalization]

Publication Location

https://trusteddit.com/pki/cps

1.3 PKI Participants

See the Certificate Policy, Section 1.3 for a description of PKI participants. This CPS provides additional operational details for each participant role.

1.4 Certificate Usage

This CPS covers the following certificate types issued by the Trusteddit CA:

• C2PA Content Signing Certificates: End-entity certificates enabling subscribers to sign C2PA manifests and assertions on digital media
• OCSP Responder Certificates: Used by the Trusteddit OCSP responder for signing OCSP responses
• TSA Certificates: Used by the Trusteddit Time-Stamp Authority for signing RFC 3161 timestamp tokens

1.5 Policy Administration

This CPS is maintained by the Trusteddit PKI team. Questions, comments, and requests for clarification should be directed to [email protected]. The Trusteddit Policy Authority reviews this CPS for conformance with the Certificate Policy and approves all changes.

2.1 Repository Implementation

The Trusteddit repository is implemented as a publicly accessible HTTPS web server at https://trusteddit.com/pki/. The repository is hosted on cloud infrastructure with high availability guarantees. Repository content is served over TLS with valid certificates.

2.2 Publication Procedures

CP/CPS Documents: Published as web pages at trusteddit.com/pki/. Documents are deployed through an automated CI/CD pipeline from a version-controlled repository. All changes are tracked and auditable.

CRLs: CRLs are generated and published automatically by the CA software. The CRL publication endpoint is specified in the CRL Distribution Points extension of each issued certificate. CRLs are published:

• At least every 24 hours on a scheduled basis
• Immediately upon any certificate revocation

OCSP Responses: The OCSP responder operates continuously and provides real-time certificate status. The OCSP endpoint URL is specified in the Authority Information Access extension of each issued certificate.

2.3 Access Controls

Read access to the repository is unrestricted. Write access is limited to authorized Trusteddit operations personnel using multi-factor authentication and role-based access controls. All modifications to repository content are logged.

3.1 Identity Validation Practices

Trusteddit implements the identity validation requirements defined in the Certificate Policy using the following operational practices:

3.1.1 Organization Validation

For organization subscribers, Trusteddit performs:

1. Legal existence check: Verification against government business registries (e.g., Secretary of State filings, Companies House, commercial register)
2. Operational existence check: Verification that the organization has an active presence (website, phone listing, or physical address)
3. Authority verification: Confirmation via a callback to an independently verified phone number or email address that the applicant is authorized to request certificates on behalf of the organization
4. Domain verification: Verification of control over any domains listed in the certificate request

3.1.2 Individual Validation

For individual subscribers, Trusteddit performs:

1. Identity document verification: Review of a government-issued photo ID (passport, driver's license, or national ID card)
2. Liveness check: Video call or equivalent remote identity proofing method to confirm the applicant matches the identity document
3. Email verification: Confirmation of control over the email address provided in the application via a challenge-response mechanism

3.2 CSR Validation

Upon receipt of a CSR, the CA performs the following validation steps:

1. Verify the CSR signature using the included public key
2. Confirm the public key meets minimum strength requirements (see Section 6)
3. Verify the Subject DN matches the validated identity information
4. Check for duplicate or conflicting Subject DNs
5. Verify the requested key usage is appropriate for C2PA content signing

3.3 Re-key and Revocation Authentication

Routine re-key: Authenticated via the subscriber's existing valid certificate (TLS client authentication to the CA management portal) or via re-validation per Section 3.1.

Post-revocation re-key: Requires full identity re-validation per Section 3.1.

Revocation requests: Authenticated via credentials established during the enrollment process (account password + second factor) or via a signed revocation request using the certificate's private key.

4.1 Application and Issuance Process

The end-to-end certificate application and issuance process:

1. Subscriber creates an account on the Trusteddit portal and accepts the Subscriber Agreement
2. Subscriber generates a key pair locally and submits a CSR
3. Subscriber submits required identity documentation
4. Trusteddit RA validates the application (identity, authority, CSR)
5. Upon successful validation, the CA operator approves issuance
6. CA software generates the certificate, signs it with the intermediate CA key, and assigns a unique serial number
7. Certificate is published to the repository and status set to “good” in the OCSP responder
8. Subscriber is notified via email with certificate retrieval instructions

4.2 Certificate Validity Periods

The following validity periods are enforced:

4.3 Revocation Practices

4.3.1 Revocation Processing Timeline

• Key compromise: Revocation processed within 4 hours of confirmed report. CRL updated immediately.
• Policy violation / inaccurate information: Revocation processed within 24 hours. CRL updated immediately.
• Subscriber request (non-emergency): Revocation processed within 24 hours of authenticated request.

4.3.2 CRL Issuance Schedule

CRLs are issued on a scheduled basis at least every 24 hours. Emergency CRLs are issued within 1 hour of any revocation event. The nextUpdate field in each CRL is set to no more than 48 hours after thisUpdate to ensure timely refresh by relying parties, with a 24-hour overlap period.

4.3.3 OCSP Update Latency

The OCSP responder reflects revocation status changes within minutes of the revocation event. OCSP responses have a maximum validity period of 24 hours (nextUpdate set to thisUpdate + 24 hours).

4.4 Time-Stamp Authority Operations

The Trusteddit TSA operates as follows:

• Accepts RFC 3161 timestamp requests over HTTPS
• Uses a dedicated TSA signing certificate issued by the Trusteddit intermediate CA
• Signs timestamp tokens using SHA-256 hash algorithm
• Maintains clock synchronization to NTP time sources with accuracy within 1 second of UTC
• Includes a serial number and ordering field in each timestamp token

Timestamps enable long-term signature verification: a C2PA manifest signed with a Trusteddit certificate and timestamped by the TSA remains verifiable even after the signing certificate expires, provided the timestamp proves the signature was created during the certificate's validity period.

5.1 Infrastructure Architecture

The Trusteddit CA is deployed as a set of containerized (Docker-based) services. The architecture includes:

• CA Service: Certificate issuance and management engine, isolated in a dedicated container with no external network access except through the RA
• OCSP Responder: Dedicated container providing real-time certificate status queries
• TSA Service: Dedicated container providing RFC 3161 timestamp services
• CRL Publisher: Automated service generating and publishing CRLs to the distribution point
• RA Portal: Web-based interface for subscriber enrollment and certificate management

5.2 Operational Procedures

5.2.1 Certificate Issuance Workflow

All certificate issuance follows a maker-checker process. The RA validates the application and prepares it for issuance. A CA operator (a different individual from the RA validator) reviews and approves the issuance request. The CA software then performs the cryptographic signing operation.

5.2.2 Monitoring and Alerting

All CA services are monitored for availability and performance. Alerts are generated for:

• Service unavailability or degraded performance
• CRL publication failures or delays
• OCSP responder errors
• Certificate issuance or revocation anomalies
• Unauthorized access attempts

5.3 Audit Log Management

Audit logs are:

• Generated automatically by all CA components
• Stored in append-only log stores to prevent tampering
• Reviewed weekly by the Security Officer
• Retained for a minimum of seven (7) years
• Backed up to geographically separate storage

5.4 Key Ceremony Procedures

6.1 Key Generation Practices

Current Practice (Software Keys):

• CA key pair generated using OpenSSL with CSPRNG (kernel entropy source)
• Private key stored in PEM format, encrypted with AES-256-CBC
• Access restricted to the CA container with filesystem-level permissions (mode 0400, root ownership)

Target Practice (HSM, planned Q2 2026):

• CA key pair generated within a FIPS 140-2 Level 3 HSM during a witnessed key ceremony
• Private key never leaves the HSM boundary in plaintext
• HSM access controlled by operator cards / PINs with M-of-N quorum requirements

6.2 Algorithm and Key Size Requirements

6.3 Network Security

Network security controls implemented for the CA infrastructure:

• CA signing service is not directly accessible from the internet; all interactions occur through the RA portal
• Docker network isolation separates CA, OCSP, TSA, and RA containers
• Firewall rules limit inter-container communication to defined interfaces and ports
• All public-facing services (OCSP, CRL distribution, repository) are served over TLS
• Administrative access requires VPN or SSH tunnel with MFA

6.4 Cryptographic Module Standards

Current: Software-based cryptographic operations using OpenSSL 3.x with FIPS provider enabled where available.

Target: FIPS 140-2 Level 3 validated HSM for all CA signing operations. The specific HSM model and FIPS validation certificate number will be documented upon procurement.

7.1 End-Entity Certificate Profile

C2PA content signing certificates issued by Trusteddit contain the following fields and extensions:

7.2 CRL Profile

See Certificate Policy, Section 7.2 for CRL profile requirements. The CPS implementation follows the specified profile exactly, with CRLs generated by the CA software (OpenSSL / step-ca) and published automatically.

7.3 OCSP Response Profile

OCSP responses conform to RFC 6960 basic response type. The OCSP responder uses a dedicated signing certificate with the id-pkix-ocsp-nocheck extension, allowing relying parties to trust the OCSP response without checking the OCSP responder certificate's own revocation status.

8.1 Audit Plan

Trusteddit maintains an internal compliance program aligned with WebTrust for CAs criteria and engages licensed WebTrust auditors as part of its C2PA Trust List qualification process. Audit reports are published upon completion of each audit cycle.

8.2 Internal Assessments

Internal assessments are conducted quarterly and cover:

• Review of audit logs for anomalies
• Verification of CRL and OCSP service availability
• Confirmation of adherence to operational procedures documented in this CPS
• Testing of backup and recovery procedures
• Review of personnel access and role assignments

Business and legal matters governing the Trusteddit PKI are defined in the Certificate Policy, Section 9. This CPS implements those requirements as follows:

9.1 Subscriber Agreements

All subscribers must accept the Trusteddit Subscriber Agreement prior to certificate issuance. The agreement is presented during the enrollment process on the Trusteddit portal and must be electronically accepted. A copy of the agreement is provided to the subscriber and archived by Trusteddit.

9.2 Relying Party Agreements

The Trusteddit Relying Party Agreement governs the terms under which relying parties may use Trusteddit certificates and PKI services for C2PA verification. The agreement is available in the PKI repository.

9.3 Data Retention

Trusteddit retains the following records for the specified durations:

9.4 Governing Law

This CPS is governed by the laws of the State of New York, United States, consistent with the Certificate Policy.