Proof

Certification Practice Statement

The Certification Practice Statement (CPS) for the Proof public key infrastructure (PKI) system details how it complies with the Proof Certificate Policy and various industry standards—including IETF RFC 3647, WebTrust Principles, CA/Browser Forum requirements, Adobe Approved Trust List, and C2PA specifications—by defining procedural and operational requirements for issuing, managing, and validating digital certificates and time stamp tokens, while excluding private Proof PKI systems that have separate documentation.

Certification Practice Statement

1. Introduction

1.1. Overview

1.1.1. Certificate Policy

The Proof Certificate Policy (CP) defines the procedural and operational requirements for the Proof public key infrastructure (PKI) system. This Certification Practice Statement (CPS) specifies how the Proof PKI system meets those requirements. The CPS applies to all PKI Participants who request, issue, manage, and validate digital certificates and time stamp tokens (TSTs) from the Proof PKI system.

This CPS is consistent with IETF RFC 3647 and is organized to cover security requirements and practices. Sections that do not apply use “Not Applicable” or “No Stipulation.”

The CPS addresses requirements from:

Proof tracks changes to these policies and updates the CP accordingly. Other documents, such as the Relying Party Agreement (RPA), privacy policies, and standard operating procedures (SOPs), are also produced.

This CPS does not apply to private Proof PKI systems, which have their own CPS and related documents.

The Proof Root CA R1 conforms to the current version of the Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates. In case of inconsistency, those Requirements take precedence.

1.1.2. Digital Certificates

The Proof PKI system issues digital certificates to individuals and legal entities to assert their digital identity in electronic transactions (e.g., digitally signing or sealing documents). Proof registers and verifies individuals and legal entities, issues certificates, and allows for revocation or renewal as needed. Certificates are issued in compliance with IETF RFC 5280.

1.1.3. Validation Service

The Proof PKI system provides:

  • Online Certificate Status Protocol (OCSP) responses
  • Certificate Revocation Lists (CRLs)

These allow Relying Parties to check the status of certificates.

1.1.4. System Availability

The Proof PKI system and repositories are maintained for 99.9% availability.

1.2. Document Name and Identification

1.2.1. Certificate Policy Name

The official document name is the Proof Certification Practice Statement. The Policy Management Authority (PMA) approves all changes and maintains version control.

1.2.2. Proof Object Identifiers

Proof has registered an Object Identifier (OID) arc with IANA. Appropriate OIDs are asserted in the Certificate Policy extension of issued certificates.

1.3. PKI Participants

1.3.1. Policy Management Authority

The PMA governs the Proof PKI system, drafts and updates the CPS, approves policies, supervises conformance, and ensures compliance with applicable laws, standards, and program requirements.

1.3.2. Certification Authority

Proof is the Certification Authority (CA) and is responsible for:

  • Creating CA certificates
  • Issuing and managing certificates
  • Operating Validation Authority (VA) systems
  • Publishing CA certificates, CRLs, and PKI documents

1.3.3. Registration Authorities

Proof is the Registration Authority (RA) and is responsible for:

  • Confirming qualification requirements
  • Retaining documentation
  • Authenticating Subscribers
  • Approving certificate and revocation requests
  • Notifying Subscribers about certificate expiry

1.3.4. Subscribers

Subscribers are natural persons who receive individual certificates and are legally bound by terms and conditions. Before verification and issuance, they are Applicants.

1.3.5. Sponsors

Sponsors are representatives of legal entities who receive organizational certificates. Before verification and issuance, they are Applicants.

1.3.6. Relying Parties

Relying Parties are persons or entities that rely on certificates or digital signatures issued by the Proof PKI system. They may check certificate status via CRL or OCSP.

1.3.7. Application Software Suppliers

These may include vendors (e.g., Adobe Acrobat, Mozilla) that trust certificates issued by the CA.

1.3.8. Other Participants

No stipulations.

1.4. Certificate Usage

1.4.1. Appropriate Certificate Uses

Certificates are to be used only as designated by the Key Usage and Extended Key Usage extensions. Relying Parties should evaluate risks before accepting certificates.

1.4.2. Prohibited Certificate Uses

Certificates must not be used for purposes other than those designated in the Key Usage and Extended Key Usage extensions.

1.5. Policy Administration

1.5.1. Organization Administering the Document

The PMA approves and maintains this CPS and related documents.

1.5.2. Contact Person

Questions about the CPS can be addressed to the PMA at pma@proof.com or mailed to:

Notarize Inc. (d.b.a. Proof.com) ATTN: Proof PMA 867 Boylston St. Boston, MA 02116

1.5.3. Person Determining CPS Suitability for the Policy

The PMA determines suitability and ensures conformance of the CPS, and evaluates audit results.

1.5.4. CPS Approval Procedures

The PMA approves the CPS and amendments, decides on amendment notice or OID changes.

1.6. Definitions and Acronyms

See Appendix A (Definitions) and Appendix B (Acronyms and Abbreviations).

2. Publication and Repository Responsibilities

2.1. Repositories

The CA maintains repositories for public access to policies, agreements, CA certificates, and revocation data:

Repositories are maintained for 99.9% availability.

2.2. Publication of Certification Information

The CA publishes:

  • Public CA certificates
  • CRLs with revocation data
  • PKI documents (CPS, RPA, terms and conditions)

Certificates include URIs as distribution points for this information.

2.3. Time or Frequency of Publication

  • New versions of policies and agreements are published within 7 days of approval.
  • Public CA certificates are updated as soon as possible after issuance.
  • CRLs for Root and Intermediate CAs are updated at least annually or upon revocation; Issuing CA CRLs are updated at least every 7 days.
  • Expired certificates are removed from CRLs.

2.4. Access Controls on Repositories

Repositories are publicly available with unrestricted read access. Security controls are implemented to ensure integrity and availability, including prevention of unauthorized write access and protection against DDoS attacks.

3. Identification and Authentication

3.1. Naming

3.1.1. Types of Names

CA certificates have non-null Common Name (CN) attributes in Subject and Issuer Distinguished Name (DN) extensions. Additional attributes (e.g., Country, Organization) may be included and are verified. All attributes comply with ITU X.500.

3.1.2. Need for Names to be Meaningful

The CA verifies and includes meaningful names for persons or entities in CN or Organization (O) attributes.

3.1.3. Anonymity or Pseudonymity of Subscribers

Pseudonyms may be used for legal entities with “doing business as” (d.b.a.) names.

3.1.4. Rules for Interpreting Various Name Forms

DNs are interpreted based on ITU X.500, ASN.1, and IETF RFC 822.

3.1.5. Uniqueness of Names

Name uniqueness is ensured by a combination of attributes in the Subject DN extension.

  • CA Name Uniqueness: Unique CN values for Root and Issuing CAs.
  • Individual Certificate Name Uniqueness: Legal names in CN and email addresses in E attribute.
  • Organizational Certificate Name Uniqueness: Unique CN values.

Name uniqueness is not violated by multiple certificates for the same person or organization.

3.1.6. Recognition, Authentication, and Role of Trademarks

The CA verifies the right to use trade names, trademarks, service names, and d.b.a. names. Certificates may be revoked if information violates this section. Applicants agree their requests do not infringe third-party rights.

3.2. Initial Identity Validation

3.2.1. Method to Prove Possession of Private Key

  • CA private keys are generated and stored on FIPS 140-2 Level 3 HSMs; no proof-of-possession required.
  • Subscribers/Sponsors must generate/store private keys on at least FIPS 140-2 Level 2 HSMs. If they generate their own keys, proof-of-possession is verified via digital signatures on CSRs. If CA generates/stores keys, no proof-of-possession is required.

3.2.2. Authentication of Organization Identity

Legal entity information is verified against Reliable Data Sources. The PMA authorizes these sources.

3.2.3. Authentication of Individual Identity

  • CA verifies PII of Proof personnel for CA Naming Forms.
  • RA verifies and places PII and email addresses of Subscribers/Sponsors in certificates.

3.2.4. Non-Verified Subscriber Information

Only verified PII is used in production. Non-verified PII may be used in non-production environments.

3.2.5. Validation of Authority

RA contacts legal entity executives to validate Sponsors’ authority. Maintains list of approvers for individual certificates with legal entity names.

3.2.6. Criteria for Interoperation

No stipulations.

3.3. Identification and Authentication for Rekey Requests

  • PMA must approve CA Revocation Forms and CA Naming Forms for new CA certificates.
  • RA allows Subscribers/Sponsors to revoke and request new certificates via the RA system with multifactor authentication.

3.3.1. Identification and Authentication for Routine Rekey

Subscribers/Sponsors must login with multifactor authentication to submit revocation and new certificate requests.

3.3.2. Identification and Authentication for Rekey after Revocation

Subscribers/Sponsors must login with multifactor authentication to submit new certificate requests.

3.4. Identification and Authentication for Revocation Requests

  • PMA must approve CA Revocation Forms.
  • Subscribers/Sponsors must login with multifactor authentication to submit revocation requests.
  • CA investigates revocation requests from other parties and acts if justified.

4. Certificate Life Cycle Operational Requirements

4.1. Certificate Application

4.1.1. Who May Submit a Certificate Application

Applicants must meet one of the following:

  • Individual subject of the certificate
  • Authorized representative of a legal entity
  • Authorized personnel for CA certificates
  • Authorized representative of the RA

RA checks Applicants are not on denied persons/business lists or in sanctioned countries.

4.1.2. Enrollment Process and Responsibilities

RA verifies PII and legal entity information before issuing certificates. Applicants must provide sufficient information and documentation.

4.2. Certificate Application Processing

4.2.1. Performing Identification and Authentication Functions

CA/RA identifies and verifies Applicants per CPS and associated policies. Previously verified information may be used for up to 398 days. High Risk Certificate Request procedures are followed as needed.

4.2.2. Approval or Rejection of Certificate Applications

Applications are rejected if:

  • PII or legal entity information is incomplete or unverifiable
  • Correlation with previously rejected or revoked applications/certificates
  • Presence on denied lists or in sanctioned countries

4.2.3. Time to Process Certificate Applications

Applications are processed in commercially reasonable timeframes. CA/RA is not responsible for delays caused by Applicants or events outside their control.

4.3. Certificate Issuance

4.3.1. CA Actions During Certificate Issuance

CA verifies authenticity of requests, requires multi-person control for offline CA certificates, and implements linting for conformity.

4.3.2. Notification to Subscriber by the CA of Issuance of Certificate

CA/RA notifies persons or entities of certificate issuance within two business days.

4.4. Certificate Acceptance

4.4.1. Conduct Constituting Certificate Acceptance

Subscribers/Sponsors must accept a preview of certificates before issuance. CA certificates are considered accepted if not objected to within two business days.

4.4.2. Publication of the Certificate by the CA

CA certificates are published in the security repository. Individual/organizational certificates are not published publicly.

4.4.3. Notification of Certificate Issuance by the CA to Other Entities

CA notifies trusted root programs and the RA about certificate issuance.

4.5. Key Pair and Certificate Usage

4.5.1. Subscriber Private Key and Certificate Usage

Subscribers/Sponsors must protect private keys as specified in applicable terms and conditions. If CA stores key pairs, they are generated and protected on HSMs rated at least FIPS 140-2 Level 2. Multifactor authentication is required for access.

Note: The content above is a cleaned and structured extract of the substantive body of the Certification Practice Statement as provided. Some sections may be truncated due to length constraints.