Proof

Proof Registration Practice Statement

The Proof Registration Practice Statement (RPS) outlines Proof's role as a Registration Authority (RA) operating under SSL.com's Certification Practice Statement (CP/CPS) to verify and manage digital certificate issuance in compliance with Adobe Approved Trust List requirements, detailing the responsibilities of PKI participants including SSL.com as the Certification Authority and Proof as the RA.

1. INTRODUCTION

Proof is a Registration Authority (RA) responsible for the verification prior to the issuance of Digital Signature Certificates (Certificates) issued under SSL.com’s CP/CPS (CP/CPS). Proof (or a third party Operator designated by Proof) operates the RA on behalf of SSL.com and is responsible for ensuring compliance with this RPS and the associated CP/CPS.

1.1 Overview

The requirements in this RPS are a subset of the requirements specified in the CP/CPS. Section numbers not included in this RPS are omitted and should be interpreted as no stipulation. If the provisions of this RPS conflict with the CP/CPS, the CP/CPS prevails.

This RPS conforms to the current version of requirements adopted by the Adobe Approved Trusted List program and published to their site. Certificates are issued and managed per the Adobe Approved Trust List Technical Requirements (AATL-TR).

1.2 Document name and identification

This document is the Proof Registration Practices Statement (RPS) and has been approved by the Proof Policy Management Authority (PMA) and the SSL.com PMA.

1.3 PKI participants
  • Certification authorities: The Certification Authority (CA) issues publicly trusted digital certificates in accordance with its CPS and performs functions associated with Public Key Infrastructure (PKI) operations, including receiving certificate requests, issuing, revoking and renewing a certificate, and maintaining, issuing, and publishing Certificate Revocation Lists (CRLs). Within the SSL.com PKI hierarchy, SSL.com functions as both the Root CA and Issuing CA.
  • Registration authorities: The RA identifies, authenticates, and manages a Certificate Subscriber’s certificate request information. Registration operations are performed by the RA under CA supervision and utilize trusted trained personnel or third parties and trustworthy systems to provide the necessary assurance. Proof functions as an RA in the SSL.com PKI hierarchy.
  • Certificate Subscribers: A Certificate Subscriber is a natural person to whom a Certificate is issued and who is legally bound by the Proof Terms of Use. Before identity validation and Certificate issuance, a requesting Certificate Subscriber is defined as an Applicant. Once the Certificate is issued, the Applicant is referred to as a Certificate Subscriber.
  • Relying parties: A Relying Party is any entity performing transactions, communications or functions which rely on a Certificate or a Digital Signature facilitated by the RA and issued by the CA.
1.4 Certificate usage
  • Appropriate certificate uses: The CA issues Digital Signature Certificates (Certificates) to Certificate Subscribers by enabling digital signature key usage and Adobe Authentic Documents extended key usage, thus specifying the appropriate Certificate uses.
  • Prohibited certificate uses: Certificates may not be used for any other purpose (e.g., authentication, code signing, etc.).
1.5 Policy administration
  • Organization administering the document: The Proof PMA is responsible for administering this RPS.
  • Contact information: The Proof PMA may be reached at pma@proof.com.
  • Person determining RPS suitability for the policy: The Proof PMA and the SSL.com PMA are jointly responsible for determining the suitability and applicability of this RPS.
  • RPS approval procedures: The Proof PMA and the SSL.com PMA approve this RPS and any material amendments, in accordance with RPS Section 9.12.
1.6 Definitions and acronyms

Capitalized terms and acronyms not otherwise defined in this RPS have the meanings given to them in Section 1.6 of the CP/CPS.

2. PUBLICATION AND REPOSITORY RESPONSIBILITIES
2.1 Repositories

The RA publishes the following terms and practices at its website:

  • Registration Practice Statement (RPS)
  • Terms of Use
  • Digital Certificate Supplement
  • Privacy Policy
  • Data Privacy Supplement

The RA ensures the above Repository of legal documents is available 24 hours a day, 7 days a week, 365 days a year with at least 99% availability.

The RA’s Credential Policy and Practice Statement (CPPS) is available upon request by contacting the Proof PMA as defined in RPS Section 1.5.2.

The CA’s repository is available at https://www.ssl.com/repository. CA’s repository provisions are specified in Section 2.1 of the CP/CPS.

2.2 Access controls on repositories

The RA Repository is publicly and anonymously available on the Internet with read-only access. Only authorized RA personnel have rights to modify files in this Repository. Further, the RA applies restrictions and access-control to this Repository to protect against enumeration and denial of service (DoS) attacks.

3. IDENTIFICATION AND AUTHENTICATION
3.1 Naming
  • Types of names: All Certificates adhere to rules for naming and identification, and require a Distinguished Name (DN) that complies with RFC822 and the ITU X.500 standard for Distinguished Names.
  • Need for names to be meaningful: The RA and CA jointly prepare the End Entity Naming Forms that contain non-null Subject and Issue DNs for all End Entity Certificates. SSL.com and Proof review and approve all End Entity Naming Forms. The RA configures the Certificate Applications in the Proof service to ensure non-null Subject DNs for all Certificates based on these End Entity Naming Forms.
  • Anonymity or pseudonymity of subscribers: Pseudonyms in the Subject DNs are not supported.
  • Uniqueness of names: The RA verifies the uniqueness of Names in the Subject DN that includes the individual’s full name and email address.
3.2 Initial identity validation

  • Method to prove possession of private key: Private keys of Certificate Subscribers are generated and stored on the CA’s hardware security modules (HSMs) based on Applications submitted by the RA. Since the private keys are generated on HSMs, proof-of-possession is not required before issuing the Certificates.

  • Authentication of organization identity: The RA does not issue Certificates to organizations.

  • Authentication of individual identity: The RA relies on strong identity proofing, based on a face to face meeting with the Applicant, or a procedure that provides an equivalent assurance. This may include secure video communication, use of identity verification software/AI, hybrid or other methods. The RA verifies all Subject DN data in the Applications with a process that meets NIST Special Publication 800-63 Identity Assurance Level 2 (IAL2). The process is certified as IAL2 compliant by the Kantara Initiative and is fully documented in the Proof Credential Policy and Practice Statement (CPPS).

    As part of this identity proofing process, Certificate Subscribers set up login credentials with multiple factors. Certificate Subscribers select complex passwords as the first authentication factor and one of the following as a second factor:

    • Enrollment codes delivered via SMS
    • One-time passcodes (OTPs) from a software-based application (e.g., Google Authenticator, Okta Verify, etc.)

  • Non-verified subscriber information: The RA is granted a waiver by the CA to use non-verified Certificate Subscriber information for Certificates issued in non-production environments. The RA verifies all information before approving Applications in the production environment.

3.3 Identification and authentication for re-key requests

The RA does not support re-keying of Certificates via the Proof service.

3.4 Identification and authentication for revocation request

Certificate Subscribers may request revocation of their Certificates by authenticating to the Proof service with multi factors, selecting the revocation option, and providing a revocation reason. The Proof service sends the revocation requests to the CA, receives confirmation of the Certificate revocation and notifies the Certificate Subscriber.

Any other entity seeking to revoke a Certificate may submit a Certificate Problem Report as defined in RPS Section 4.9.3.3.

4. CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS
4.1 Certificate Application

  • Who can submit a certificate application: Applications may only be submitted by:

    • Any individual who is to be included in the Subject of the Certificate.
    • Any authorized representative of the above individual.
    • Any authorized representative of the RA.

    Controls apply to prevent issuance of Certificates to Applicants of Countries restricted by U.S. export restriction laws.

  • Enrollment process and responsibilities: The RA verifies the identity of Certificate Subscribers in accordance with RPS Section 3.2.3. Certificate Subscribers also electronically accept the Proof Terms of Use and Digital Certificate Supplement which include terms, conditions, and warranties for their Certificates. The RA captures and retains the required evidence for the above in accordance with RPS Sections 5.4 and 5.5.

4.2 Certificate application processing
  • Performing identification and authentication functions: The RA enrolls Certificate Subscribers through an identity proofing process and requires Certificate Subscribers to set up their authentication factors in accordance with RPS Section 3.2. The RA requires Certificate Subscribers to complete the identity proofing process and set up their authentication factors in a single session. If Certificate Subscribers do not finish the identity proofing process or authentication factor selection within the session or time frame, the RA rejects the Application.
  • Time to process certificate applications: The RA will process Applications in a commercially reasonable time frame.
4.3 Certificate issuance
  • CA actions during certificate issuance: Once the RA approves Applications, the Proof service creates, digitally signs, and sends requests with the Certificate Subscribers’ identity information to the APIs operated by the CA. Once the authenticity of these requests is verified, the CA generates new asymmetric key pairs on the HSMs and new Certificate Signing Requests (CSRs) with the Certificate Subscribers’ identity information. The CA issues Certificates based on the above CSRs, installs them on the HSMs and notifies the Proof service via the APIs.
  • Notification to subscriber by the CA of issuance of certificate: Upon receiving issuance confirmation via the API, the Proof service displays a modal about the Certificate issuance to Certificate Subscribers.
4.4 Certificate acceptance
  • Conduct constituting certificate acceptance: The Proof service displays the information to be put in the Certificate before issuance for the Applicant to review. The Applicant’s acceptance is required to issue the Certificate. The Certificate Subscriber or agent is responsible for review and verification of information contained in the issued Certificate. The Certificate Subscriber or agent is deemed to have accepted the issued Certificate by taking delivery of the Certificate, in accordance with the provisions of CP/CPS Section 4.4.1.
4.5 Key pair and certificate usage
  • Certificate Subscriber private key and certificate usage: Certificate Subscribers are required to protect the authentication factors that provide access to the private keys for their Certificate, as specified in Sections 3 and 4 of the Proof Digital Certificate Supplement. If a Certificate Subscriber does not protect their authentication factors or misuses their Certificate, the Proof service revokes their Certificate in accordance with RPS Section 4.9.
4.6 Certificate renewal

The RA does not support the renewal of Certificates. Upon expiration, Subscribers instead reapply to receive a new Certificate.

4.9 Certificate revocation and suspension

Certificates may be revoked for numerous reasons (e.g., Private Key compromised, change in identity information, etc.). The revocation process changes the status of Certificates from “Valid” to “Revoked.” Further, this process adds the Certificates to the CRLs based on the status changes. The “Revoked” status remains valid until the expiration of the Certificates. After expiration, this process removes the Certificates from the CRLs.

Proof does not support “Suspended” status for Certificates.

  • Circumstances for revocation: The RA (or CA) begins the revocation procedure of a Certificate within 24 hours, based on one or more of several criteria, including key compromise, cessation of operation, affiliation change, superseded certificates, unauthorized requests, evidence of misuse, material changes, and legal requirements.
  • Who can request revocation: Certificate Subscribers or the RA may request revocation of a Certificate. Any other entity may submit a Certificate Problem Report.
  • Procedure for revocation request:
    • Certificate Subscriber revocation request: Certificate Subscribers authenticate to the Proof service, select the Revocation Reason, and submit the Revocation Request. Proof service uses the CA’s revocation API to submit the request to the CA. Once verified, the CA revokes the Certificate and updates the CRLs.
    • RA revocation request: Authorized RA personnel authenticate to the Proof service, select the Certificate to be revoked, select the Revocation Reason, and submit the request. Proof service uses the CA’s revocation API to submit the request to the CA. Once verified, the CA revokes the Certificate and updates the CRLs.
    • Certificate problem report: Any other entity may submit a Certificate Problem Report to report suspected Private Key compromise, Certificate misuse, fraud, or other issues. The CA investigates and revokes the Certificate if warranted.
    • Revocation request by Application Software Providers: Application Software Suppliers may request revocation if a Certificate attribute is deceptive or used for illicit purposes. The RA forwards such requests to the CA.
  • Time within which CA must process the revocation request: The RA processes Revocation Requests in accordance with RPS Section 4.9.1, considering any additional time required for manual processing by the CA.
  • Certificate problem report: Certificate problem reports are handled by the CA in accordance with CP/CPS Section 4.9.5.2. The CA works with the Certificate Subscriber and any reporting entity to determine whether revocation is warranted and sets a revocation date based on several criteria.
  • Revocation checking requirement for relying parties: Relying Parties should validate the authenticity and intended usage of a Certificate using resources described in RPS Section 4.10.1.
  • CRL issuance frequency: The CA publishes a new CRL with revoked Certificates at least once every 7 days. The “Next Update” field value is not more than 10 days beyond the “This Update” field.
  • Maximum latency for CRLs: Where applicable, the maximum latency for the CRL is 10 minutes.
  • On-line revocation/status checking availability: Online Certificate Status Protocol (OCSP) is not supported for Certificates in the Proof service.
  • Special requirements re key compromise: Any entity needs to use the Certificate Problem Report to show evidence of a Private Key Compromise by submission of the Private Key itself, a CSR with a Common Name indicating compromise, or signed data indicating key compromise.
4.10 Certificate status services
  • Operational characteristics: The CA automatically generates and publishes CRLs for Digital Signature Certificates to a specified URI included in the CRL Distribution Point (CDP) extension of the Certificates.
4.11 End of subscription

Certificate Subscribers can terminate their subscriptions by allowing their Certificates to expire without renewing. Certificates can also be revoked as defined in RPS Section 4.9.3.

5. FACILITY, MANAGEMENT, AND OPERATIONAL CONTROLS
5.1 Physical controls
  • The RA implements and maintains physical security controls to restrict access to the hardware and software used for the Proof service.
  • Site location and construction: The RA operates the Proof service from 2 geographic locations, US East and US West, within Amazon Web Services (AWS).
  • Physical access: The RA relies on AWS to secure and protect the physical infrastructure in its data centers from unauthorized access with physical access controls including physical cards and biometric readers. AWS provides 24x7x365 video monitoring.
  • Power and air conditioning: The RA relies on AWS for uninterrupted power supply (UPS), backup generators, and HVAC systems.
  • Water exposures: The RA relies on AWS to protect infrastructure from water exposure.
  • Fire prevention and protection: The RA relies on AWS for automatic fire suppression systems.
  • Off-site backup: The RA backs up software code and data between 2 geographic locations in AWS and leverages Github to store and protect software code, which is backed up in multiple geographic locations.
5.2 Procedural controls

  • Trusted roles: The RA has established Trusted Roles to share responsibility, limit individual action, and securely separate duties and functions:

    • Identity Verification Agent
    • Certificate Operations
    • System Administrator
    • Network Administrator
    • Engineering Manager
    • Software Engineer
    • Security Auditor

  • Number of persons required per task: The RA requires all software code and infrastructure-as-code changes be peer-reviewed to ensure dual control before merging changes into the main line code branch. The RA also submits and approves changes to deploy authorized code changes to the Proof service and monitors the Proof service for unauthorized changes.