trusteddit
Back to PKI Overview
Policy Document

Trusteddit Certificate Policy

Governing C2PA Content Signing Certificates

Version

0.1

Status

DRAFT

Effective Date

TBD

Last Updated

March 2026

Issuing Authority

Trusteddit, a service of SanMarcSoft LLC

OID

[DRAFT -- To be assigned]

Table of Contents

1Introduction

1.1Overview

This Certificate Policy (CP) defines the rules and requirements governing the issuance, management, usage, and revocation of certificates within the Trusteddit Public Key Infrastructure (PKI).

Trusteddit operates as a C2PA-focused intermediate certificate authority (CA), issuing content signing certificates for digital media authentication. These certificates enable content creators, publishers, and media organizations to cryptographically bind provenance metadata to their digital assets in accordance with the Coalition for Content Provenance and Authenticity (C2PA) technical specification.

This CP is structured in accordance with RFC 3647, “Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework.”

Trusteddit does not issue certificates for TLS/SSL, code signing, email (S/MIME), or any purpose other than C2PA content signing and timestamping. Certificates issued under this policy are intended exclusively for use with the C2PA specification and its associated trust model.

1.2Document Name and Identification

Document Title
Trusteddit Certificate Policy
Version
0.1 (DRAFT)
OID
[DRAFT -- To be assigned upon policy finalization]
Publication Location
https://trusteddit.com/pki/certificate-policy

1.3PKI Participants

1.3.1 Certification Authorities

Trusteddit Intermediate CA -- Operated by SanMarcSoft LLC. Issues end-entity certificates for C2PA content signing. The intermediate CA certificate is signed by one or more recognized root CAs to establish trust chain linkage compatible with the C2PA Trust List.

1.3.2 Registration Authorities

Trusteddit serves as its own Registration Authority (RA). The RA function is responsible for verifying the identity of certificate applicants before certificates are issued by the CA.

1.3.3 Subscribers

Subscribers are individuals or organizations that apply for and are issued C2PA content signing certificates by the Trusteddit CA. Subscribers include content creators, media organizations, news agencies, and any entity that wishes to cryptographically sign digital content for provenance verification.

1.3.4 Relying Parties

Relying parties are individuals, organizations, or software applications that verify C2PA content credentials signed with certificates issued by the Trusteddit CA. This includes verification tools, social media platforms, content management systems, and any application implementing C2PA verification.

1.3.5 Other Participants

Time-Stamp Authority (TSA): Trusteddit operates an RFC 3161 compliant TSA to provide trusted timestamps for content signing operations. Timestamps enable signature verification even after the signing certificate has expired, provided the signature was created during the certificate's validity period.

1.4Certificate Usage

1.4.1 Appropriate Certificate Uses

  • Signing C2PA manifests and assertions on digital media (images, video, audio, documents)
  • Authenticating the identity of content creators and publishers within the C2PA ecosystem
  • Establishing provenance chains for digital content
  • Timestamping content signing operations via the TSA

1.4.2 Prohibited Certificate Uses

  • TLS/SSL server or client authentication
  • Code signing for software distribution
  • Email encryption or signing (S/MIME)
  • Any purpose not related to C2PA content authentication
  • Signing content on behalf of another entity without proper authorization

1.5Policy Administration

Organization Administering the Document
SanMarcSoft LLC, operating as Trusteddit
Contact Person
PKI Policy Authority
Email: [email protected]
Person Determining CP/CPS Suitability
The Trusteddit Policy Authority is responsible for determining whether a Certificate Practice Statement conforms to this Certificate Policy.
CP Approval Procedures
This CP is approved by the Trusteddit Policy Authority. Changes to this CP require review and approval by the Policy Authority. Material changes will be communicated to affected parties and published to the repository.

2Publication and Repository Responsibilities

2.1 Repositories

Trusteddit maintains an online repository at https://trusteddit.com/pki/ containing:

  • This Certificate Policy
  • The Certificate Practice Statement
  • Subscriber and Relying Party agreements
  • CA certificates (intermediate and cross-certificates)
  • Certificate Revocation Lists (CRLs)
  • OCSP responder endpoint information

2.2 Publication of Certification Information

Trusteddit publishes the following information in its repository:

  • CP and CPS documents -- published within 24 hours of approval
  • CA certificates -- published immediately upon issuance
  • CRLs -- published according to the schedule defined in the CPS
  • OCSP responses -- available in real-time

2.3 Time or Frequency of Publication

CP and CPS documents are published upon initial approval and updated as necessary. CRLs are published at least every 24 hours, and immediately upon any certificate revocation. The OCSP responder provides real-time status information.

2.4 Access Controls on Repositories

The repository is publicly accessible for read operations. Write access is restricted to authorized Trusteddit personnel. The repository is protected by appropriate technical controls to prevent unauthorized modification.

3Identification and Authentication

3.1Naming

3.1.1 Types of Names

Certificates issued by Trusteddit use X.500 Distinguished Names (DNs). End-entity certificates include the subscriber's organization name in the Subject field, along with the Common Name (CN) identifying the certificate holder.

3.1.2 Need for Names to Be Meaningful

The Distinguished Name in the certificate subject field must be meaningful and accurately represent the identity of the subscriber. Anonymous or pseudonymous certificates are not issued under this policy.

3.1.3 Anonymity or Pseudonymity of Subscribers

Trusteddit does not issue anonymous or pseudonymous certificates. All subscribers must be identified by their legal name or registered organization name.

3.1.4 Rules for Interpreting Various Name Forms

Distinguished Names are interpreted in accordance with the X.500 standard and applicable RFC specifications (RFC 5280).

3.1.5 Uniqueness of Names

Trusteddit ensures that Distinguished Names are unique within the CA's namespace. No two active certificates will share the same Subject DN unless they represent the same entity.

3.2Initial Identity Validation

3.2.1 Method to Prove Possession of Private Key

Applicants must demonstrate possession of the private key corresponding to the public key submitted for certification. This is accomplished through the submission of a Certificate Signing Request (CSR) signed with the applicant's private key, which the CA validates.

3.2.2 Authentication of Organization Identity

For organization subscribers, Trusteddit validates the organization's identity through:

  • Verification of legal existence using government-issued business records or equivalent documentation
  • Confirmation of the applicant's authority to act on behalf of the organization
  • Verification of the organization's operational existence and contact information

3.2.3 Authentication of Individual Identity

For individual subscribers, Trusteddit validates identity through:

  • Government-issued photo identification document
  • Verification of the individual's association with the stated organization (if applicable)
  • Email domain verification for the contact address

[DRAFT -- To be completed]

Detailed identity proofing procedures, including remote verification methods and acceptable forms of identification, to be specified upon operational deployment.

3.2.4 Non-verified Subscriber Information

Non-verified information, if any, is clearly marked as such within the certificate. Trusteddit makes no representations regarding the accuracy of non-verified information.

3.2.5 Validation of Authority

Trusteddit validates that the certificate applicant has the authority to request the certificate on behalf of the named organization, using documented authorization from an officer or authorized representative.

3.3Identification and Authentication for Re-key Requests

3.3.1 Identification and Authentication for Routine Re-key

Subscribers requesting certificate re-key must authenticate using their existing valid certificate or through re-verification of identity using the procedures described in Section 3.2.

3.3.2 Identification and Authentication for Re-key After Revocation

After revocation, subscribers must undergo the full initial identity validation process as described in Section 3.2 to obtain a new certificate.

3.4Identification and Authentication for Revocation Requests

Revocation requests must be authenticated. Subscribers may request revocation of their own certificates by authenticating to the Trusteddit system using credentials established during certificate issuance. Trusteddit may also initiate revocation based on evidence of key compromise, policy violation, or cessation of operations.

4Certificate Life-Cycle Operational Requirements

4.1Certificate Application

4.1.1 Who Can Submit a Certificate Application

Certificate applications may be submitted by any individual or organization that intends to sign digital content using C2PA-compliant credentials. Applicants must agree to the Trusteddit Subscriber Agreement before a certificate is issued.

4.1.2 Enrollment Process and Responsibilities

The enrollment process includes:

  1. Applicant generates a key pair and submits a CSR to Trusteddit
  2. Applicant provides required identity documentation
  3. Applicant agrees to the Subscriber Agreement
  4. Trusteddit validates the application per Section 3.2
  5. Upon successful validation, the certificate is issued

4.2Certificate Application Processing

4.2.1 Performing Identification and Authentication Functions

Trusteddit performs all identification and authentication functions as described in Section 3. The CA verifies the identity of the applicant, the authority of the applicant to request the certificate, and the applicant's possession of the private key.

4.2.2 Approval or Rejection of Certificate Applications

Certificate applications are approved when all identity validation requirements have been satisfied and the applicant has agreed to the Subscriber Agreement. Applications are rejected when identity cannot be verified, documentation is insufficient, or the applicant fails to meet the requirements of this CP.

4.2.3 Time to Process Certificate Applications

Trusteddit endeavors to process certificate applications within five (5) business days of receiving a complete application. Processing time may vary depending on the complexity of identity validation.

4.3Certificate Issuance

4.3.1 CA Actions During Certificate Issuance

Upon approval of a certificate application, the Trusteddit CA:

  1. Generates the certificate using the validated CSR
  2. Signs the certificate with the Trusteddit intermediate CA private key
  3. Assigns a unique serial number to the certificate
  4. Publishes the certificate to the repository and provides it to the subscriber

4.3.2 Notification to Subscriber by the CA of Issuance

Trusteddit notifies the subscriber of certificate issuance via the email address provided during the application process. The notification includes instructions for retrieving the certificate.

4.4Certificate Acceptance

4.4.1 Conduct Constituting Certificate Acceptance

A subscriber is deemed to have accepted a certificate when they download or use the certificate, or fail to object to the certificate content within seven (7) days of issuance notification.

4.4.2 Publication of the Certificate by the CA

The CA publishes all issued certificates in its repository. OCSP responses confirming the certificate status are available immediately upon issuance.

4.4.3 Notification of Certificate Issuance by the CA to Other Entities

Trusteddit does not routinely notify entities other than the subscriber of certificate issuance, unless required by law or contractual obligation.

4.5Key Pair and Certificate Usage

4.5.1 Subscriber Private Key and Certificate Usage

Subscribers must use their private keys and certificates only for C2PA content signing purposes as described in Section 1.4.1. Subscribers are responsible for protecting their private keys in accordance with the Subscriber Agreement.

4.5.2 Relying Party Public Key and Certificate Usage

Relying parties must verify the certificate chain, check certificate revocation status, and confirm the certificate is being used for its intended purpose before relying on a signature. Relying parties should verify C2PA manifests using the full trust chain including the Trusteddit intermediate CA and the applicable root CA.

4.6Certificate Renewal

Certificate renewal (issuance of a new certificate with the same key pair and subject information) is supported when the subscriber's identity information remains current. Renewal requires that the existing certificate has not been revoked and the identity information has been re-validated within the time period specified in the CPS.

[DRAFT -- To be completed]

Specific renewal procedures, timing windows, and re-validation requirements to be detailed upon operational deployment.

4.7Certificate Re-key

Certificate re-key (issuance of a new certificate with a new key pair) follows the procedures described in Section 3.3 for identification and authentication. The subscriber generates a new key pair and submits a new CSR.

4.8Certificate Modification

Certificate modification (changing certificate information other than the public key) requires revocation of the existing certificate and issuance of a new certificate. Identity re-validation is required per Section 3.2.

4.9Certificate Revocation and Suspension

4.9.1 Circumstances for Revocation

A certificate shall be revoked when any of the following conditions occur:

  • The subscriber's private key has been compromised or is suspected of being compromised
  • The information in the certificate is no longer accurate
  • The subscriber has violated the terms of the Subscriber Agreement or this CP
  • The subscriber requests revocation
  • The CA ceases operations
  • Required by applicable law or regulation
  • The certificate was issued in error or through fraudulent means

4.9.2 Who Can Request Revocation

The subscriber, the Trusteddit CA, or any party with evidence of key compromise or policy violation may request certificate revocation.

4.9.3 Procedure for Revocation Request

Revocation requests must be submitted via authenticated channels. The requester must provide the certificate serial number and reason for revocation. Identity is authenticated per Section 3.4.

4.9.4 Revocation Request Grace Period

Subscribers must notify Trusteddit of any suspected key compromise or grounds for revocation without unreasonable delay, and in no event later than twenty-four (24) hours after discovery.

4.9.5 Time Within Which CA Must Process Revocation Request

Trusteddit processes revocation requests within four (4) hours for key compromise and within twenty-four (24) hours for all other reasons. The CRL is updated immediately upon revocation.

4.9.6 Certificate Suspension

Trusteddit does not support certificate suspension. Certificates are either valid or revoked.

4.10Certificate Status Services

Trusteddit provides certificate status information through:

  • OCSP Responder: Real-time certificate status queries available at the OCSP endpoint specified in issued certificates (Authority Information Access extension)
  • CRL Distribution: Certificate Revocation Lists published at the CRL Distribution Points specified in issued certificates, updated at least every 24 hours

4.11End of Subscription

A subscription ends when the certificate expires, is revoked, or the subscriber terminates the Subscriber Agreement. Upon end of subscription, the subscriber must cease using the private key for signing new content. Previously signed content remains verifiable through the trust chain and timestamping.

4.12Key Escrow and Recovery

Trusteddit does not provide key escrow services for subscriber private keys. Subscribers are solely responsible for the secure storage and backup of their own private keys. The CA does not possess, and has never possessed, copies of subscriber private keys.

5Facility, Management, and Operational Controls

5.1 Physical Controls

The Trusteddit CA infrastructure is deployed using containerized (Docker-based) services hosted in secure environments. Physical access to systems hosting CA operations is restricted to authorized personnel.

[DRAFT -- To be completed]

Detailed physical security controls, including facility descriptions, access control mechanisms, power and environmental controls, and disaster recovery provisions, to be specified upon HSM migration and operational deployment at an auditable facility.

5.2 Procedural Controls

5.2.1 Trusted Roles

Trusted roles within the Trusteddit CA include:

  • CA Administrator: Responsible for CA configuration, certificate issuance, and revocation operations
  • Security Officer: Responsible for security policy enforcement and audit log review
  • System Administrator: Responsible for infrastructure maintenance and monitoring

5.2.2 Number of Persons Required Per Task

Critical CA operations (CA key generation, CA certificate issuance, CRL signing) require multi-person control. No single individual can independently perform these operations.

[DRAFT -- To be completed]

Specific multi-person control requirements and separation of duties to be defined in a subsequent revision of this policy.

5.3 Personnel Controls

All personnel in trusted roles undergo background verification and are required to maintain ongoing training in PKI operations and security practices.

[DRAFT -- To be completed]

Detailed personnel controls, including background check procedures, training requirements, sanctions for unauthorized actions, and contractor controls, to be specified.

5.4 Audit Logging Procedures

Trusteddit maintains comprehensive audit logs for all CA operations, including:

  • Certificate requests, issuance, and revocation events
  • Authentication and access control events
  • CA key lifecycle events
  • System configuration changes
  • Physical and logical access events

Audit logs are retained for a minimum of seven (7) years and are protected against unauthorized modification or deletion.

5.5 Records Archival

All records related to certificate lifecycle events are archived for a minimum of seven (7) years following the expiration or revocation of the certificate. Archives include certificate application data, identity validation records, issued certificates, revocation records, and audit logs.

5.6 Key Changeover

The Trusteddit intermediate CA key has a defined lifetime. Before expiration, a new CA key pair is generated and a new CA certificate is issued. The transition is coordinated to ensure continued trust chain validity. The old CA key continues to sign CRLs and OCSP responses for previously issued certificates until all such certificates have expired or been revoked.

5.7 Compromise and Disaster Recovery

[DRAFT -- To be completed]

Detailed business continuity, disaster recovery, and incident response procedures to be documented. Key areas include: CA key compromise notification procedures, infrastructure recovery procedures, backup and restoration processes, and communication plans.

5.8 CA or RA Termination

In the event of CA termination, Trusteddit will:

  1. Provide at least 90 days advance notice to all active subscribers
  2. Revoke all outstanding certificates
  3. Publish a final CRL covering all certificates
  4. Destroy or archive the CA private key in accordance with security requirements
  5. Transfer repository maintenance responsibilities to a designated successor or archive the repository contents for the required retention period

6Technical Security Controls

6.1 Key Pair Generation and Installation

6.1.1 Key Pair Generation

CA Key Pairs: The Trusteddit intermediate CA key pair is generated using a cryptographically secure random number generator. Upon HSM migration (planned Q2 2026), CA keys will be generated within a FIPS 140-2 Level 3 (or higher) Hardware Security Module during a formal key ceremony.

Subscriber Key Pairs: Subscribers generate their own key pairs using cryptographically secure methods. The CA verifies proof of possession through CSR validation.

6.1.2 Private Key Delivery to Subscriber

Trusteddit does not generate or deliver subscriber private keys. Subscribers are responsible for generating their own key pairs.

6.1.3 Public Key Delivery to Certificate Issuer

Public keys are delivered to the CA via PKCS#10 Certificate Signing Requests (CSRs) transmitted over authenticated, encrypted channels.

6.2 Private Key Protection and Cryptographic Module Engineering Controls

Current: CA private keys are stored in encrypted form on secured infrastructure with access restricted to authorized personnel. Keys are protected by strong passphrase and filesystem-level encryption.

Target (Q2 2026): CA private keys will be generated and stored within a FIPS 140-2 Level 3 HSM. Private keys will never exist outside the HSM in plaintext form.

6.3 Other Aspects of Key Pair Management

CA Certificate Validity Period
Ten (10) years for the intermediate CA certificate
Subscriber Certificate Validity Period
One (1) year maximum for end-entity content signing certificates
TSA Certificate Validity Period
Three (3) years for Time-Stamp Authority certificates

6.4 Activation Data

[DRAFT -- To be completed]

Activation data requirements (PINs, passphrases, biometric data) for CA key access to be specified upon HSM deployment.

6.5 Computer Security Controls

CA systems implement the following security controls:

  • Access control enforced at the operating system and application level
  • Network segmentation isolating CA components from general-purpose systems
  • Intrusion detection and monitoring
  • Regular security patching and vulnerability management
  • Containerized deployment with minimal attack surface

6.6 Life-Cycle Technical Controls

System development, deployment, and maintenance follow secure software development practices. All changes to CA systems are subject to change management procedures including review, testing, and approval.

6.7 Network Security Controls

CA network interfaces are protected by firewalls. Only necessary network ports are open. All administrative access requires encrypted channels (SSH, TLS). OCSP and CRL distribution points are available over HTTPS.

6.8 Time-stamping

Trusteddit operates an RFC 3161 compliant Time-Stamp Authority (TSA). The TSA uses a dedicated signing key and certificate, separate from the CA signing key. Timestamps are signed using SHA-256 or stronger hash algorithms. The TSA clock is synchronized to a trusted time source.

7Certificate, CRL, and OCSP Profiles

7.1 Certificate Profile

All certificates issued by Trusteddit conform to X.509 v3 (RFC 5280). End-entity certificates for C2PA content signing include the following extensions:

  • Key Usage: digitalSignature
  • Extended Key Usage: C2PA content signing OID [as defined by the C2PA specification]
  • Authority Information Access: OCSP responder URL, CA Issuers URL
  • CRL Distribution Points: CRL URL
  • Subject Key Identifier: Per RFC 5280
  • Authority Key Identifier: Per RFC 5280
  • Basic Constraints: CA:FALSE
  • Certificate Policies: Trusteddit CP OID [to be assigned]

7.1.1 Algorithm Requirements

Trusteddit certificates use the following algorithms:

  • Signature Algorithm: ECDSA with SHA-256 (P-256 curve) or SHA-384 (P-384 curve). RSA with SHA-256 (2048-bit minimum) is also supported.
  • Hash Algorithm: SHA-256 minimum for all operations

7.2 CRL Profile

CRLs conform to X.509 v2 CRL format (RFC 5280). CRLs are signed by the CA using the same algorithm as the CA certificate. CRLs include the following fields:

  • Issuer: Trusteddit intermediate CA DN
  • thisUpdate: Time of CRL issuance
  • nextUpdate: No more than 24 hours after thisUpdate
  • revokedCertificates: List of revoked certificate serial numbers with revocation dates and reason codes
  • Authority Key Identifier extension
  • CRL Number extension

7.3 OCSP Profile

The Trusteddit OCSP responder conforms to RFC 6960. OCSP responses are signed by an OCSP responder certificate issued by the Trusteddit intermediate CA. Responses include:

  • Certificate status (good, revoked, or unknown)
  • thisUpdate and nextUpdate times
  • Nonce support for replay prevention

8Compliance Audit and Other Assessments

8.1 Frequency or Circumstances of Assessment

Trusteddit intends to undergo annual compliance audits against the WebTrust for Certification Authorities criteria once operational maturity is achieved. Internal assessments are conducted on an ongoing basis.

8.2 Identity/Qualifications of Assessor

External audits will be performed by a qualified, independent auditor licensed to perform WebTrust for CAs engagements. The auditor must have no conflict of interest with Trusteddit.

8.3 Assessor's Relationship to Assessed Entity

The external auditor must be organizationally independent from Trusteddit and SanMarcSoft LLC.

8.4 Topics Covered by Assessment

Audits cover all aspects of this CP and the corresponding CPS, including key management, certificate lifecycle operations, physical and logical security controls, and personnel controls.

8.5 Actions Taken as a Result of Deficiency

Trusteddit addresses any deficiencies identified during audits within a remediation plan and timeline agreed upon with the auditor. Material deficiencies affecting trust must be remediated before continued operation.

8.6 Communication of Results

Audit results are communicated to the Trusteddit Policy Authority. A summary of audit findings and remediation status may be published in the PKI repository. Full audit reports are made available to trust list operators upon request.

[DRAFT -- To be completed]

Audit schedule details to be confirmed in a subsequent revision of this policy.

9Other Business and Legal Matters

9.1 Fees

Trusteddit may charge fees for certificate issuance, renewal, and related services. Fee schedules are published separately and are not part of this CP.

9.2 Financial Responsibility

[DRAFT -- To be completed]

Insurance coverage, professional liability provisions, and financial responsibility details to be specified.

9.3 Confidentiality of Business Information

Subscriber identity validation records and private business information are treated as confidential. Trusteddit does not disclose confidential subscriber information except as required by law, with the subscriber's consent, or as necessary for the operation of the PKI (e.g., certificate content and revocation information).

9.4 Privacy of Personal Information

Trusteddit collects and processes personal information only as necessary for certificate issuance and management. Personal information is handled in accordance with applicable privacy laws. The Trusteddit privacy policy, published separately, describes data collection, use, retention, and disclosure practices in detail.

9.5 Intellectual Property Rights

Trusteddit retains intellectual property rights over its CA certificates, CRLs, OCSP responses, and this CP. Subscribers retain intellectual property rights over their own key pairs and any content signed with their certificates.

9.6 Representations and Warranties

9.6.1 CA Representations and Warranties

Trusteddit warrants that it will:

  • Operate in accordance with this CP and the CPS
  • Perform identity validation of subscribers as described in Section 3
  • Maintain the availability of OCSP and CRL services
  • Revoke certificates in accordance with Section 4.9
  • Protect its private keys in accordance with Section 6

9.6.2 Subscriber Representations and Warranties

See the Subscriber Agreement for detailed subscriber representations and warranties.

9.6.3 Relying Party Representations and Warranties

See the Relying Party Agreement for detailed relying party representations and warranties.

9.7 Disclaimers of Warranties

EXCEPT AS EXPRESSLY STATED IN THIS CP, THE CPS, OR THE APPLICABLE SUBSCRIBER OR RELYING PARTY AGREEMENT, TRUSTEDDIT DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.

9.8 Limitations of Liability

[DRAFT -- To be completed]

Specific liability limitations, caps, and exclusions to be defined in consultation with legal counsel.

9.9 Indemnities

Indemnification obligations are set forth in the Subscriber Agreement and Relying Party Agreement. In general, subscribers indemnify Trusteddit for losses arising from misuse of certificates or inaccurate subscriber information.

9.10 Term and Termination

This CP becomes effective upon publication and remains in effect until superseded by a new version or the Trusteddit CA ceases operations. Termination of the CA is governed by Section 5.8.

9.11 Individual Notices and Communications

Notices to subscribers are sent to the email address registered during the certificate application process. Notices to Trusteddit should be directed to [email protected].

9.12 Amendments

Trusteddit may amend this CP at any time. Material amendments that affect subscriber or relying party obligations will be communicated at least thirty (30) days prior to taking effect. Non-material amendments (corrections, clarifications) take effect upon publication.

9.13 Dispute Resolution Provisions

[DRAFT -- To be completed]

Dispute resolution procedures, governing law, and jurisdiction to be specified in consultation with legal counsel.

9.14 Governing Law

This CP is governed by the laws of the State of New York, United States, without regard to its conflict of laws principles.

9.15 Compliance with Applicable Law

Trusteddit operates in compliance with all applicable laws and regulations. Subscribers and relying parties are responsible for ensuring their use of certificates complies with applicable laws in their jurisdictions.

9.16 Miscellaneous Provisions

If any provision of this CP is found to be unenforceable, the remaining provisions continue in full force and effect. This CP, together with the CPS and the applicable Subscriber or Relying Party Agreement, constitutes the entire agreement between the parties with respect to the subject matter hereof.

Trusteddit Certificate Policy v0.1 DRAFT -- March 2026

A service of SanMarcSoft LLC | [email protected]