Proof

Certificate Policy

The Certificate Policy (CP) for the Proof public key infrastructure (PKI) system outlines procedural and operational requirements for all PKI Participants involved in requesting, issuing, managing, and validating digital certificates and time stamp tokens, adhering to IETF RFC 3647 and various industry standards such as WebTrust, CA/Browser Forum Baseline Requirements, and Adobe Approved Trust List, while specifying that it applies only to the public Proof PKI system and that the Proof Root CA R1 complies with CA/B Forum Baseline Requirements which take precedence in case of conflicts.

Certificate Policy

1. Introduction

1.1. Overview

1.1.1. Certificate Policy

This Certificate Policy (CP) defines the procedural and operational requirements for the Proof public key infrastructure (PKI) system. It applies to all PKI Participants that request, issue, manage, and validate digital certificates and time stamp tokens (TSTs) from this Proof PKI system.

This CP is consistent with the Internet Engineering Task Force (IETF) RFC 3647 standard. It is organized into sections to cover security requirements and practices. Proof uses “Not Applicable” or “No Stipulation” terms for sections that do not apply.

This CP addresses requirements from the current versions of the following policies, guidelines, and practices:

  • WebTrust Principles and Criteria for Certification Authorities
  • WebTrust Principles and Criteria for Certification Authorities - Network Security
  • Certificate Authority/Browser Forum Baseline Requirements for Issuance and Management of Publicly-Trusted TLS Server Certificates
  • Certificate Authority/Browser Forum Network and Certificate System Security Requirements
  • Adobe Approved Trust List Technical Requirements
  • Coalition for Content Provenance and Authenticity Technical Specification

Proof tracks changes to these policies and updates this CP accordingly. Proof also produces other documents about this PKI system, including the Certification Practices Statement (CPS), privacy policies, and standard operating procedures (SOPs).

This CP does not apply to PKI Participants involved with other Proof PKI systems considered private. Different CPs and PKI-related documents exist for those systems.

The Proof Root CA R1 conforms to the current version of CA/B Forum Baseline Requirements. In the event of any inconsistency between this document and those Requirements, those Requirements take precedence.

1.1.2. Digital Certificates

The Proof PKI system issues digital certificates to individuals to assert their digital identity in electronic transactions (e.g., digitally signing documents). Proof registers individuals, performs identity verification, creates certificate requests, and issues individual certificates. Proof issues new certificates when existing ones are about to expire and allows revocation due to errors, changes to identity data, or if no longer required.

The system also issues certificates to legal entities for digital identity assertion in electronic transactions (e.g., digitally sealing documents). Registered and vetted individuals must request organizational certificates.

Certificates are issued in compliance with IETF RFC 5280 to cryptographically bind Subscriber data with public keys.

1.1.3. Validation Services

The Proof PKI system offers two validation methods to Relying Parties to determine the current status of certificates:

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

1.1.4. System Availability

The Proof PKI system and repositories are maintained with resources to ensure commercially reasonable availability at all times.

1.2. Document Name and Identification

1.2.1. Certificate Policy Name

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

1.2.2. Proof Object Identifiers

Proof registers its Object Identifier (OID) arc with the Internet Assigned Numbering Authority (IANA) and asserts appropriate OIDs in the Certificate Policy extension of issued certificates.

1.3. PKI Participants

1.3.1. Policy Management Authority

Proof establishes a Policy Management Authority (PMA) to govern the PKI system, including Root, Intermediate, and Issuing CAs. The PMA:

  • Represents Proof's interests
  • Drafts and updates the CP
  • Approves CPS and related policies
  • Supervises conformance with CP and CPS

Policies are designed to ensure compliance with US laws and regulations, international standards, and program requirements.

1.3.2. Certification Authority

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

  • Creating CA certificates
  • Issuing certificates
  • Managing certificates (rekeys, renewals, revocations)
  • Operating Validation Authority (VA) systems
  • Publishing CA certificates, CRLs, and PKI documents

1.3.3. Registration Authorities

Proof acts as 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

The RA may delegate responsibilities to Delegated Third Parties, who must submit a Registration Practice Statement (RPS) and maintain a WebTrust for RA audit annually.

1.3.4. Subscribers

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

1.3.5. Sponsors

Sponsors are representatives of legal entities who receive organizational certificates and are legally bound by applicable terms and conditions. Before identity verification and certificate issuance, they are known as Applicants.

1.3.6. Relying Parties

Relying Parties are natural persons or legal 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 include software or SaaS 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 must only be used 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 by 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 CP and relevant documents.

1.5.2. Contact Person

Questions about this CPS should 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

See CP Section 4.9.3.4 for instructions on submitting Certificate Problem Reports.

1.5.3. Person Determining CPS Suitability for the Policy

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

1.5.4. CP Approval Procedures

The PMA approves the CP and amendments, decides on amendment notice or OID changes as defined in CP Sections 9.10 and 9.12.

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 Proof policies, agreements, CA certificates, and revocation data.

Repositories are maintained for commercially-reasonable availability.

2.2. Publication of Certification Information

The CA publishes the following in publicly-available repositories:

  • Public CA certificates (Root, Intermediate, Issuing)
  • CRLs with revocation data
  • PKI documents (CP, 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 seven 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 seven 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 within Subject and Issuer Distinguished Name (DN) extensions. Additional attributes (e.g., Country, Organization) may be included and must be verified. All attributes comply with ITU X.500 standard.

3.1.1. Need for Names to Be Meaningful

Names for natural persons or legal entities in CN or Organization (O) attributes must be meaningful and verified.

3.1.2. Anonymity or Pseudonymity of Subscribers

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

3.1.3. Rules for Interpreting Various Name Forms

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

3.1.5. Uniqueness of Names

Name uniqueness is ensured based on a combination of attributes in the Subject DN extension. Multiple certificates for the same entity do not violate uniqueness.

3.1.6. Recognition, Authentication, and Role of Trademarks

The CA verifies the right of legal entities to use trade names, trademarks, service names, and d.b.a. names. Certificates may be revoked if information is found to violate intellectual property rights.

3.2. Initial Identity Validation

3.2.1. Method to Prove Possession of Private Key

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

3.2.2. Authentication of Organization Identity

Legal entity information is verified against Reliable Data Sources authorized by the PMA.

3.2.3. Authentication of Individual Identity

PII of Proof personnel and Subscribers/Sponsors is verified as specified in the CPS. Delegated Third Parties may be authorized to perform identity verification.

3.2.4. Non-Verified Subscriber Information

Only verified PII is used for C, O, and E attributes in production. Non-verified PII may be used in non-production environments.

3.2.5. Validation of Authority

The RA contacts legal entity executives to validate Sponsors' authority to request organizational certificates. A list of authorized approvers is maintained 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.
  • RA provides Subscribers/Sponsors with rekey options before expiration or revocation.
  • For rekey after expiration or revocation, multifactor authentication is required to submit new certificate requests.

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.
  • Revocation requests from other parties are investigated; if justified, the CA submits and approves revocation requests.

4. Certificate Life Cycle Operational Requirements

4.1. Certificate Application

4.1.1. Who May Submit a Certificate Application

Applicants must be:

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

The RA ensures Applicants are not on denied persons/business lists or located in sanctioned countries.

4.1.2. Enrollment Process and Responsibilities

The CA ensures the RA verifies PII and legal entity information before issuing certificates. Applicants must provide sufficient information and documentation for verification.

4.2. Certificate Application Processing

4.2.1. Performing Identification and Authentication Functions

CA or RA identifies and verifies Applicants per CP and associated CPS/RPS. Previously collected and 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

Applications may also be rejected for:

  • Correlation with previously rejected or revoked applications/certificates
  • Presence on denied persons/business lists
  • Location in sanctioned countries

4.2.3. Time to Process Certificate Applications

Applications are processed in commercially reasonable timeframes. Delays caused by Applicants or events outside CA/RA control are not the responsibility of CA/RA.

4.3. Certificate Issuance

4.3.1. CA Actions During Certificate Issuance

The CA verifies authenticity of requests before issuing certificates. Two-person control is required for offline CA certificates. A linting process checks conformity of certificates.

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

The CA or RA notifies individuals or entities about certificate issuance by a reliable method within a reasonable timeframe.

4.4. Certificate Acceptance

4.4.1. Conduct Constituting Certificate Acceptance

A preview of certificates is displayed to Subscribers/Sponsors before issuance. Acceptance is required for issuance. CA certificates are considered accepted if no objection is made within two business days.

4.4.2. Publication of the Certificate by the CA

CA certificates are published in the security repository. Individual or organizational certificates are not published in a public repository.

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

Trusted root programs are notified about CA certificates for inclusion in trust lists. The RA is notified about issuance of individual or organizational certificates.

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 the CA stores key pairs, it is responsible for their generation, storage, and protection.