DocuSign Certificate Policy for External CA
DocuSign Envelope ID: E2033666-E28F-43CE-A3EA-F785452EF1C4
click to sign
signature
click to edit
click to sign
signature
click to edit
DocuSign Inc
DocuSign Certificate Policy for External CA
2
Public
Version
1.0
Pages
Status
Draft
Final
Author
DocuSign Inc.
Diffusion List
External
Internal
Public
Public
History
Date
Version
Author
Information affected
Verified by
20/09/2019
0.1
DocuSign
Creation of document
EM
21/10/2019
0.2
DocuSign
Comments of document
DF
22/10/2019
0.3
DocuSign
Integration of comments
EM
13/01/2020
1.0
DocuSign
Creation of version 1.0
EM
DocuSign Envelope ID: E2033666-E28F-43CE-A3EA-F785452EF1C4
DocuSign Inc
DocuSign Certificate Policy for External CA
3
Public
SUMMARY
1 Introduction ________________________________________________________________ 10
1.1 OVERVIEW _____________________________________________________________________ 10
1.1.1 Certificate Policy (CP) __________________________________________________________________ 10
1.1.2 Relationship between the CP & CPS _______________________________________________________ 10
1.1.3 Scope _______________________________________________________________________________ 10
1.2 DOCUMENT IDENTIFICATION ______________________________________________________ 10
1.3 PKI ENTITIES____________________________________________________________________ 10
1.3.1 PKI Authorities ________________________________________________________________________ 11
1.3.2 Registration Authority (RA) _______________________________________________________________ 12
1.3.3 Subscribers ___________________________________________________________________________ 12
1.3.4 Affiliated Organizations _________________________________________________________________ 12
1.3.5 Relying Parties ________________________________________________________________________ 12
1.3.6 Other Participants ______________________________________________________________________ 13
1.4 CERTIFICATE USAGE ____________________________________________________________ 13
1.4.1 Appropriate Certificate Uses _____________________________________________________________ 13
1.4.2 Prohibited Certificate Uses _______________________________________________________________ 13
1.5 POLICY ADMINISTRATION ________________________________________________________ 14
1.5.1 Organization administering the document ___________________________________________________ 14
1.5.2 Contact Person ________________________________________________________________________ 14
1.5.3 Person Determining Certification Practices Statement Suitability for the Policy ______________________ 14
1.5.4 CPS Approval Procedures _______________________________________________________________ 14
1.5.5 Waivers ______________________________________________________________________________ 15
1.6 DEFINITIONS AND ACRONYMS ____________________________________________________ 15
2 PUBLICATION & REPOSITORY RESPONSIBILITIES _______________________________ 15
2.1 REPOSITORIES __________________________________________________________________ 15
2.2 PUBLICATION OF CERTIFICATION INFORMATION ____________________________________ 15
2.2.1 Publication of Certificates and Certificate Status ______________________________________________ 15
2.2.2 Publication of CA Information _____________________________________________________________ 16
2.3 FREQUENCY OF PUBLICATION ____________________________________________________ 16
2.4 ACCESS CONTROLS ON REPOSITORIES ____________________________________________ 16
3 IDENTIFICATION & AUTHENTICATION __________________________________________ 16
3.1 NAMING ________________________________________________________________________ 16
3.1.1 Types of Names _______________________________________________________________________ 16
3.1.2 Need for Names to Be Meaningful _________________________________________________________ 16
DocuSign Envelope ID: E2033666-E28F-43CE-A3EA-F785452EF1C4
DocuSign Inc
DocuSign Certificate Policy for External CA
4
Public
3.1.3 Anonymity or Pseudonymity of Certificate ___________________________________________________ 17
3.1.4 Rules for Interpreting Various Name Forms __________________________________________________ 17
3.1.5 Uniqueness of Names __________________________________________________________________ 17
3.1.6 Recognition, Authentication, and Role of Trademarks __________________________________________ 17
3.1.7 Name Claim Dispute Resolution __________________________________________________________ 17
3.2 Initial Identity Validation __________________________________________________________ 18
3.2.1 Method to Prove Possession of Private Key _________________________________________________ 18
3.2.2 Authentication of Organization Identity______________________________________________________ 18
3.2.3 Authentication of Physical Person Identity ___________________________________________________ 18
3.2.4 Non-verified Subscriber Information ________________________________________________________ 19
3.2.5 Validation of Authority __________________________________________________________________ 19
3.2.6 Criteria for Interoperation ________________________________________________________________ 19
3.3 IDENTIFICATION AND AUTHENTICATION FOR RE-KEY REQUESTS ______________________ 20
3.3.1 Identification and Authentication for Routine Re-keY___________________________________________ 20
3.3.2 Identification and Authentication for Re-key after Revocation ____________________________________ 20
3.4 IDENTIFICATION AND AUTHENTICATION FOR REVOCATION REQUEST __________________ 20
4 CERTIFICATE LIFE-CYCLE ___________________________________________________ 20
4.1 Certificate Application ____________________________________________________________ 20
4.1.1 Submission of Certificate Application _______________________________________________________ 20
4.1.2 Enrollment Process and Responsibilities ____________________________________________________ 21
4.2 Certificate Application Processing __________________________________________________ 22
4.2.1 Performing Identification and Authentication Functions _________________________________________ 22
4.2.2 Approval or Rejection of Certificate Applications ______________________________________________ 22
4.2.3 Time to Process Certificate Applications ____________________________________________________ 23
4.3 Certificate Issuance ______________________________________________________________ 23
4.3.1 CA Actions during Certificate Issuance _____________________________________________________ 23
4.3.2 Notification to Subscriber of Certificate issuance ______________________________________________ 24
4.4 Certificate Acceptance ____________________________________________________________ 24
4.4.1 Conduct constituting certificate acceptance __________________________________________________ 24
4.4.2 Publication of the Certificate by the CA _____________________________________________________ 25
4.4.3 Notification of Certificate Issuance by the CA to Other Entities ___________________________________ 25
4.5 Key Pair and Certificate Usage _____________________________________________________ 25
4.5.1 Subscriber Private Key and Certificate Usage ________________________________________________ 25
4.5.2 Relying Party Public Key and Certificate Usage ______________________________________________ 25
4.6 Certificate Renewal_______________________________________________________________ 25
4.6.1 Circumstance for Certificate Renewal ______________________________________________________ 25
4.7 Certificate Re-key ________________________________________________________________ 26
4.8 Certificate Modification ___________________________________________________________ 26
4.9 Certificate Revocation and Suspension ______________________________________________ 26
4.9.1 Circumstances for Revocation ____________________________________________________________ 26
4.9.2 Who Can Request Revocation ____________________________________________________________ 27
4.9.3 Procedure for Revocation Request ________________________________________________________ 27
4.9.4 Revocation Request Grace Period _________________________________________________________ 28
DocuSign Envelope ID: E2033666-E28F-43CE-A3EA-F785452EF1C4
DocuSign Inc
DocuSign Certificate Policy for External CA
5
Public
4.9.5 Time within which CA must Process the Revocation Request ___________________________________ 28
4.9.6 Revocation Checking Requirement for Relying Parties _________________________________________ 29
4.9.7 CRL Issuance Frequency ________________________________________________________________ 29
4.9.8 Maximum Latency for CRLs ______________________________________________________________ 29
4.9.9 On-line Revocation/Status Checking Availability ______________________________________________ 29
4.9.10 On-line Revocation Checking Requirements _________________________________________________ 29
4.9.11 Other Forms of Revocation Advertisements Available __________________________________________ 29
4.9.12 Special Requirements Related To Key Compromise ___________________________________________ 29
4.9.13 Circumstances for Suspension ____________________________________________________________ 29
4.9.14 Who can Request Suspension ____________________________________________________________ 29
4.9.15 Limits on Suspension Period _____________________________________________________________ 29
4.10 Certificate Status Services ________________________________________________________ 30
4.10.1 Operational Characteristics ______________________________________________________________ 30
4.10.2 Service Availability _____________________________________________________________________ 30
4.10.3 Optional Features ______________________________________________________________________ 30
4.11 End of Subscription ______________________________________________________________ 30
4.12 Key Escrow and Recovery _________________________________________________________ 30
4.12.1 Key Escrow and Recovery Policy and Practices ______________________________________________ 30
4.12.2 Session Key Encapsulation and Recovery Policy and Practices __________________________________ 30
5 Facility, Management and Operational Controls __________________________________ 30
5.1 Physical Controls ________________________________________________________________ 30
5.1.1 Site Location & Construction _____________________________________________________________ 30
5.1.2 Physical Access _______________________________________________________________________ 30
5.1.3 Power and Air Conditioning ______________________________________________________________ 32
5.1.4 Water Exposures ______________________________________________________________________ 32
5.1.5 Fire Prevention and Protection ____________________________________________________________ 32
5.1.6 Media Storage ________________________________________________________________________ 32
5.1.7 Waste Disposal ________________________________________________________________________ 32
5.1.8 Off-site Backup ________________________________________________________________________ 32
5.2 Procedural Controls ______________________________________________________________ 32
5.2.1 Trusted Roles _________________________________________________________________________ 32
5.2.2 Number of Persons Required per Task _____________________________________________________ 33
5.2.3 Identification and Authentication for Each Role _______________________________________________ 33
5.2.4 Roles Requiring Separation of Duties ______________________________________________________ 33
5.3 Personnel Controls_______________________________________________________________ 33
5.3.1 Background, Qualifications, Experience, & Security Clearance Requirements _______________________ 33
5.3.2 Background Check Procedures ___________________________________________________________ 33
5.3.3 Training Requirements __________________________________________________________________ 34
5.3.4 Retraining Frequency and Requirements ___________________________________________________ 34
5.3.5 Job Rotation Frequency and Sequence _____________________________________________________ 34
5.3.6 Sanctions for Unauthorized Actions ________________________________________________________ 34
5.3.7 Independent Contractor Requirements _____________________________________________________ 34
5.3.8 Documentation Supplied to Personnel ______________________________________________________ 35
5.4 Audit Logging Procedures _________________________________________________________ 35
5.4.1 Types of Events Recorded _______________________________________________________________ 35
5.4.2 Log Processing Frequency _______________________________________________________________ 36
DocuSign Envelope ID: E2033666-E28F-43CE-A3EA-F785452EF1C4
DocuSign Inc
DocuSign Certificate Policy for External CA
6
Public
5.4.3 Retention Period for Audit Logs ___________________________________________________________ 36
5.4.4 Protection of Audit Log __________________________________________________________________ 36
5.4.5 Audit Log Backup Procedures ____________________________________________________________ 37
5.4.6 Audit Collection System (Internal vs. External) _______________________________________________ 37
5.4.7 Notification to Event-Causing Subject ______________________________________________________ 37
5.4.8 Vulnerability Assessments _______________________________________________________________ 37
5.5 Records Archival ________________________________________________________________ 37
5.5.1 Types of Records Archived ______________________________________________________________ 38
5.5.2 Archive Retention Period ________________________________________________________________ 38
5.5.3 Archive Protection _____________________________________________________________________ 38
5.5.4 Archive Backup Procedures ______________________________________________________________ 38
5.5.5 Requirements for Record Time-Stamping ___________________________________________________ 38
5.5.6 Archive Collection System (Internal or External) ______________________________________________ 39
5.5.7 Procedures to Obtain and Verify Archive Information __________________________________________ 39
5.6 Key Changeover _________________________________________________________________ 39
5.7 Compromise and Disaster Recovery ________________________________________________ 39
5.7.1 Incident and Compromise Handling Procedures ______________________________________________ 39
5.7.2 Computing Resources, Software, and/or Data Are Corrupted ____________________________________ 40
5.7.3 Private Key Compromise Procedures ______________________________________________________ 41
5.7.4 Business Continuity Capabilities after a Disaster ______________________________________________ 41
5.8 CA, RCA & RA TERMINATION ______________________________________________________ 41
6 Technical Security Controls ___________________________________________________ 41
6.1 Key Pair Generation and Installation ________________________________________________ 41
6.1.1 Key pair generation ____________________________________________________________________ 41
6.1.2 Private Key Delivery to Subscriber _________________________________________________________ 42
6.1.3 Public Key Delivery to Certificate Issuer ____________________________________________________ 42
6.1.4 CA Public Key Delivery to Relying Parties ___________________________________________________ 43
6.1.5 Key Sizes ____________________________________________________________________________ 43
6.1.6 Public Key Parameters Generation and Quality Checking_______________________________________ 43
6.1.7 Key Usage Purposes (as per X.509 v3 key usage field) ________________________________________ 43
6.2 Private Key Protection and Cryptographic Module Engineering Controls __________________ 44
6.2.1 Cryptographic Module Standards and Controls _______________________________________________ 44
6.2.2 Private Key Multi-Person Control __________________________________________________________ 44
6.2.3 Private Key Escrow ____________________________________________________________________ 44
6.2.4 Private Key Backup ____________________________________________________________________ 44
6.2.5 Private Key Archival ____________________________________________________________________ 45
6.2.6 Private Key Transfer into or from a Cryptographic Module ______________________________________ 45
6.2.7 Private Key Storage on Cryptographic Module _______________________________________________ 46
6.2.8 Method of Activating Private Key __________________________________________________________ 46
6.2.9 Method of Deactivating Private Key ________________________________________________________ 46
6.2.10 Method of Destroying Private Key _________________________________________________________ 47
6.2.11 Cryptographic Module Rating _____________________________________________________________ 48
6.3 Other Aspects of Key Pair Management _____________________________________________ 48
6.3.1 Public Key Archival _____________________________________________________________________ 48
6.3.2 Certificate Operational Periods/Key Usage Periods ___________________________________________ 48
6.4 Activation Data __________________________________________________________________ 48
DocuSign Envelope ID: E2033666-E28F-43CE-A3EA-F785452EF1C4
DocuSign Inc
DocuSign Certificate Policy for External CA
7
Public
6.4.1 Activation Data Generation and Installation __________________________________________________ 48
6.4.2 Activation Data Protection _______________________________________________________________ 49
6.4.3 Other Aspects of Activation Data __________________________________________________________ 50
6.5 Computer Security Controls _______________________________________________________ 50
6.5.1 Specific Computer Security Technical Requirements __________________________________________ 50
6.5.2 Computer Security Rating _______________________________________________________________ 51
6.6 LIFE-CYCLE SECURITY CONTROLS ________________________________________________ 51
6.6.1 System Development Controls ____________________________________________________________ 51
6.6.2 Security Management Controls ___________________________________________________________ 52
6.6.3 Life Cycle Security Controls ______________________________________________________________ 52
6.7 Network Security Controls _________________________________________________________ 52
6.8 Time-Stamping __________________________________________________________________ 53
7 CERTIFICATE, CRL, AND OCSP PROFILES ______________________________________ 54
7.1 Certificate Profile ________________________________________________________________ 54
7.1.1 Version Numbers ______________________________________________________________________ 54
7.1.2 Certificate Extensions ___________________________________________________________________ 54
7.1.3 Algorithm Object Identifiers ______________________________________________________________ 54
7.1.4 Name Forms __________________________________________________________________________ 54
7.1.5 Name Constraints ______________________________________________________________________ 54
7.1.6 Certificate Policy Object Identifier _________________________________________________________ 54
7.1.7 Usage of Policy Constraints Extension _____________________________________________________ 55
7.1.8 Policy Qualifiers Syntax and Semantics _____________________________________________________ 55
7.1.9 Processing Semantics for the Critical Certificate Policy Extension ________________________________ 55
7.2 CRL Profile _____________________________________________________________________ 55
7.2.1 Version Numbers ______________________________________________________________________ 55
7.2.2 CRL Entry Extensions __________________________________________________________________ 55
7.3 OCSP PROFILE __________________________________________________________________ 55
7.3.1 Version Number _______________________________________________________________________ 55
7.3.2 OCSP Extensions ______________________________________________________________________ 55
8 Compliance Audit and Other Assessments ______________________________________ 55
8.1 FREQUENCY OF AUDIT OR ASSESSMENTS __________________________________________ 55
8.2 IDENTITY & QUALIFICATIONS OF ASSESSOR ________________________________________ 56
8.3 ASSESSOR’S RELATIONSHIP TO ASSESSED ENTITY _________________________________ 56
8.4 TOPICS COVERED BY ASSESSMENT _______________________________________________ 56
8.5 ACTIONS TAKEN AS A RESULT OF DEFICIENCY _____________________________________ 56
8.6 Communication of Results ________________________________________________________ 57
9 Other Business and Legal Matters _____________________________________________ 57
9.1 Fees ___________________________________________________________________________ 57
9.1.1 Certificate Issuance/Renewal Fees ________________________________________________________ 57
9.1.2 Certificate Access Fees _________________________________________________________________ 57
9.1.3 Revocation or Status Information Access Fees _______________________________________________ 57
DocuSign Envelope ID: E2033666-E28F-43CE-A3EA-F785452EF1C4
DocuSign Inc
DocuSign Certificate Policy for External CA
8
Public
9.1.4 Fees for Other Services _________________________________________________________________ 57
9.1.5 Refund Policy _________________________________________________________________________ 57
9.2 Financial Responsibility ___________________________________________________________ 58
9.2.1 Insurance Coverage ____________________________________________________________________ 58
9.2.2 Other Assets __________________________________________________________________________ 58
9.2.3 Insurance/warranty Coverage for End-Entities _______________________________________________ 58
9.3 Confidentiality of Business Information ______________________________________________ 58
9.4 Privacy of Personal Information ____________________________________________________ 58
9.4.1 Privacy Plan __________________________________________________________________________ 58
9.4.2 Information Treated as Private ____________________________________________________________ 59
9.4.3 Information Not Deemed Private __________________________________________________________ 59
9.4.4 Responsibility to Protect Private Information _________________________________________________ 59
9.4.5 Notice and Consent to use Private Information _______________________________________________ 59
9.4.6 Disclosure Pursuant to Judicial/Administrative Process ________________________________________ 59
9.4.7 Other Information Disclosure Circumstances _________________________________________________ 59
9.5 Intellectual Property Rights ________________________________________________________ 59
9.5.1 Property Rights in Certificates and Revocation Information______________________________________ 60
9.5.2 Property Rights in the CPS ______________________________________________________________ 60
9.5.3 Property Rights in Names _______________________________________________________________ 60
9.5.4 Property Rights in Keys _________________________________________________________________ 60
9.6 Representations & Warranties _____________________________________________________ 60
9.6.1 CA Representations and Warranties _______________________________________________________ 60
9.6.2 RA Representations and Warranties _______________________________________________________ 62
9.6.3 Subscriber Representations and Warranties _________________________________________________ 62
9.6.4 Relying Party Representations and Warranties _______________________________________________ 63
9.6.5 Representations and Warranties of Affiliated Organizations _____________________________________ 63
9.6.6 Representations and Warranties of other Participants __________________________________________ 63
9.7 Disclaimers of Warranties _________________________________________________________ 63
9.8 Limitations of Liability ____________________________________________________________ 63
9.9 Indemnities _____________________________________________________________________ 64
9.9.1 Indemnification by Customer _____________________________________________________________ 64
9.9.2 Indemnification by Relying Party __________________________________________________________ 64
9.10 Term and Termination ____________________________________________________________ 65
9.10.1 Term ________________________________________________________________________________ 65
9.10.2 Termination ___________________________________________________________________________ 65
9.10.3 Effect of Termination and Survival _________________________________________________________ 65
9.11 INDIVIDUAL NOTICES & COMMUNICATIONS WITH PARTICIPANTS ______________________ 65
9.12 Amendments ____________________________________________________________________ 65
9.12.1 Procedure for Amendment _______________________________________________________________ 65
9.12.2 Notification Mechanism and Period ________________________________________________________ 66
9.12.3 Circumstances under Which OID Must Be Changed ___________________________________________ 66
9.13 Dispute Resolution Provisions _____________________________________________________ 66
9.14 Governing Law __________________________________________________________________ 66
DocuSign Envelope ID: E2033666-E28F-43CE-A3EA-F785452EF1C4
DocuSign Inc
DocuSign Certificate Policy for External CA
9
Public
9.15 Compliance with Applicable Law ___________________________________________________ 66
9.16 Miscellaneous Provisions _________________________________________________________ 66
9.16.1 Entire Agreement ______________________________________________________________________ 67
9.16.2 Assignment ___________________________________________________________________________ 67
9.16.3 Severability ___________________________________________________________________________ 67
9.16.4 Enforcement (Attorney Fees/Waiver of Rights) _______________________________________________ 67
9.16.5 Force Majeure ________________________________________________________________________ 67
9.17 Other Provisions _________________________________________________________________ 67
10 CERTIFICATE, CRL, AND OCSP PROFILES ______________________________________ 67
10.1 RCA: SELF-SIGNED ROOT CERTIFICATE / TRUST ANCHOR ____________________________ 67
10.2 CA: ISSUING CA CERTIFICATE _____________________________________________________ 69
10.3 Demo CA: ISSUING CA CERTIFICATE for test purposes only ____________________________ 70
10.4 Subscriber: TEST certificate under DEMO CA _________________________________________ 72
10.5 Subscriber: HUMAN SUBSCRIBER SIGNATURE CERTIFICATE under issuing CA ___________ 72
10.6 RCA CRL: FULL CRL PROFILE _____________________________________________________ 73
10.7 CA CRL: FULL CRL PROFILE ______________________________________________________ 75
DocuSign Envelope ID: E2033666-E28F-43CE-A3EA-F785452EF1C4
DocuSign Inc
DocuSign Certificate Policy for External CA
10
Public
1 INTRODUCTION
DocuSign (DS) decided to create a trusted domain by creating a Root CA (RCA) and dedicated Certification Authority (CA)
to support each Customer of DocuSign desiring to manage Subscriber Certificate with a DocuSign box on premise to sign
document. These CAs can only issue subscriber certificate for signature usage.
The RCA enables interoperability among Customers and relying party who accepts the RCA and the present CP level.
The RCA issues certificates only to CAs designated by DocuSign for sole purposes of Customer.
This CP is consistent with the Internet Engineering Task Force (IETF) Public Key Infrastructure X.509 (IETF PKIX) RFC
3647, Certificate Policy and Certification Practices Framework.
The terms and provisions of this CP shall be interpreted under and governed by applicable law (see section 9.14).
1.1 OVERVIEW
1.1.1 CERTIFICATE POLICY (CP)
CA and Subscriber certificates contain one registered certificate policy object identifiers (OID), which may be used by a
Relying Party to decide whether a certificate is trusted for a particular purpose. The OID corresponds to a specific level of
assurance established by this Certificate Policy (CP) which shall be available to Relying Parties.
Each certificate issued by the RCA and CA will assert the appropriate level of assurance in the certificate Policies extension
as decided by DocuSign.
1.1.2 RELATIONSHIP BETWEEN THE CP & CPS
A CP states what assurance can be placed in a certificate issued by the CA and RCA. The Certification Practice Statement
(CPS) states how the CA and RCA establishes that assurance. A CPS shall be more detailed than the CP with which it
aligns.
1.1.3 SCOPE
This CP governs RCA and CA and Subscriber certificates. Subscriber certificates are limited to only one type as described
in section 10. Customer issues subscriber certificates from the CA hosted in a Digital Signature Appliance (DSA) which is
stored on the premises of the Customer facility. There is only one generic CA for all Customers.
1.2 DOCUMENT IDENTIFICATION
There is one level of assurance in this Certificate Policy, which is defined in subsequent sections. This level of assurance
has an Object Identifier (OID), to be asserted in certificates issued by the CA and RCA.
The policy OIDs is a sub-assignment of DocuSign Inc.’s Private Enterprise Number (PEN) registered in the IANA PEN
Registry (1.3.6.1.4.1.42482). The PEN sub-assignment is allocated to policy OID as follows: 1.3.6.1.4.1.42482.2.1.1.2.
1.3 PKI ENTITIES
The following are roles relevant to the administration and operation of the RCA and CA.
DocuSign Envelope ID: E2033666-E28F-43CE-A3EA-F785452EF1C4
DocuSign Inc
DocuSign Certificate Policy for External CA
11
Public
1.3.1 PKI AUTHORITIES
1.3.1.1 DOCUSIGN POLICY MANAGEMENT AUTHORITY (DS PMA)
The DocuSign PMA (DS PMA) owns this CP and represents the interest of DocuSign, Inc. The DS PMA is responsible for:
Approving the Certificate Policy and all associated CPSs.
Approving the technical part of the contract defined with Customers related to the implementation of the present CP
by Customer.
Approves RCA and CA creation, renewal and revocation.
Define audit guide used to conduct internal audit on all PKI entities (RCA, CA, RA, Trusted Agent…).
Approves cryptographic specification (algorithms used for signature, encryption, authentication, hash functions and
key length, operational lifetime) for the PKI systems and any related change according a survey made on
international standards.
Defines procedures for Subscriber keys and certificates management that Customers shall apply.
Approves Customer’s CPS.
Approves compliance between security practice documents and related policies (for instance CPS/CP and
procedures/CP).
Approves final annual internal audit report of the PKI’s components.
Manage external audit of Customers and all PKI entities.
Guarantees the validity and the integrity of the PKI’s published information.
Ensures that a proper process to manage security incidents within PKI components is in place.
Arbitrates disputes relating to the PKI services and the use of certificates.
A complete description of DS PMA roles and responsibilities is provided in the DS Policy Management Authority Charter
[DS PMA CHARTER].
1.3.1.2 DOCUSIGN OPERATIONS AUTHORITY (DS OA)
The DocuSign Operations Authority (DS OA) is the organization that operates and maintains the PKI entities, posting RCA
and CA certificates and Certificate Revocation Lists (CRLs) into the DocuSign Repository, and ensuring the continued
availability of the repository to all users. The Operational Authority acts upon approval of the DS PMA.
1.3.1.3 DOCUSIGN ROOT CERTIFICATION AUTHORITY (DS RCA)
A Root CA (RCA) is a CA which is characterized by having itself as the issuer (i.e., it is self-signed). RCA can’t be revoked
in the normal manner (i.e. being included in an Authority Revocation List), and, when used as a Trust Anchor, must be
transmitted or made available to any Relying Parties according to secure mechanisms outlined in section 6.1.4.
DocuSign is the Root CA for this CP. DS RCA is used to:
Issue CA certificates for DS CA only as in this CP.
Revoke CA certificates.
Generate logs for RCA operation.
DS Root CA is not signed by any others type of internal or external CAs.
1.3.1.4 DOCUSIGN CERTIFICATION AUTHORITY (DS CA)
DocuSign Envelope ID: E2033666-E28F-43CE-A3EA-F785452EF1C4
DocuSign Inc
DocuSign Certificate Policy for External CA
12
Public
A Signing CA is a CA whose primary function is to issue Certificates to Subscriber and CRL. A Signing CA does not issue
Certificates to other CAs.
DocuSign is owner of all CAs for this CP. A DS CA is used to:
Be signed only by the DS RCA.
Issue Subscriber certificates and CRL.
Revoke Subscriber certificates.
Manage Subscriber’s key pair centrally.
Generate logs for CA operation.
CA can only manage Subscriber’s Certificate and key pair only for Subscriber covered by Customer agreement established
with DS.
1.3.2 REGISTRATION AUTHORITY (RA)
RA designates Customer that collects and verifies Subscriber identity and information for inclusion in the Subscriber’s public
key certificate. The requirements for RAs in Entity PKIs are set forth elsewhere in this document. DS defines all procedures
and rules and log type to have to manage RA operation.
Procedures to manage Subscriber’s Certificate and key pairs are performed by Trusted Agent and Customer internal
repository of Customer data, recorded by Trusted Agent, approved by Customer. A Customer is responsible to establish
and maintain a list of all Trusted Agent and internal repository that are allowed to manage Subscribers and Subscriber data.
A Trusted Agent can be employed by entities different from the Customer. In this case, legal entity which employs Trusted
Agent shall have a contract to cover all aspect of Customer CPS delegated to the Trusted Agent.
The Customer CPS shall give details on how RA and Trusted Agent are organized and performs their operation to manage
Subscriber’s Certificate and key pair.
A Customer operates some RA services according to the Customer CPS and its associated procedures approved by DS
PMA. A Customer can’t start operating RA operation without prior approval of the DS PMA and having signed an agreement
with DS.
1.3.3 SUBSCRIBERS
In the case of this CP, a Subscriber is a natural person to whom a certificate and associated key pair is issued. This CP
does not provide for issuance of certificates to devices. Subscribers are individuals with a contractual relationship with the
Customer and enrolled by the Customer. Customers shall maintain their Subscribers' certificate in their repositories and
associated key pair in the DSA box provided by DocuSign. Subscribers, as the term is used in this CP, does not include or
refer to CAs. However, the term “Subscriber” as used in this document refers only to those who request certificates for uses
other than signing and issuing certificates or certificate status information.
1.3.4 AFFILIATED ORGANIZATIONS
In this CP, Subscriber certificates are always issued in conjunction with an organization that has a relationship with the
Subscriber; this is termed affiliation. The organization affiliation will be indicated in the certificate in the field "O" of the subject
DN. Affiliated organizations, also referred to as Customers in this CP, are responsible for verifying the affiliation at the time
of certificate application and requesting revocation of the certificate if the affiliation is no longer valid. For the present CP,
only the Customer name will appear in the certificate issued to the Subscriber.
1.3.5 RELYING PARTIES
DocuSign Envelope ID: E2033666-E28F-43CE-A3EA-F785452EF1C4
DocuSign Inc
DocuSign Certificate Policy for External CA
13
Public
A Relying Party uses a Subscriber’s certificate to verify the integrity of a digitally signed document and relies on the validity
of the binding of the Subscriber's identity and affiliated organization to a Public Key. The Relying Party is responsible for
deciding whether or how to check the validity of the certificate by checking the appropriate certificate status information. A
Relying Party may use information in the certificate (such as certificate policy identifiers) to determine the suitability of the
certificate for a particular use.
This CP makes no assumptions or limitations regarding the identity of Relying Parties and its relationship with Subscribers,
CA, RCA and Customer.
1.3.6 OTHER PARTICIPANTS
1.3.6.1 CUSTOMER
Customer is a Legal Entity different from DocuSign that has an agreement with DocuSign Inc to issue certificate to
Subscriber under this CP.
Customer is considered as a Registration Authority. Customer is responsible to hosts the dedicated DSA box it will have
according rules and procedures defines by PMA. Therefore, there is dedicated CPS for each Customer detailing some
section of CP implemented by Customer.
The Customer designates entities that act as Trusted Agent. In the contract between Customer and DocuSign all Customer’s
obligations are included to cover operation made by Customer to implement some CP and CPS operation.
When a Customer wants to use the DocuSign External trusted domain service is controlled by the PMA (refer to section 8
below).
1.3.6.2 TRUSTED AGENT
A Trusted Agent is the entity that collects and verifies each Subscriber’s identity and information on behalf of an RA.
Information shall be verified in accordance with section 3.2 and communicated to the RA in a secure manner.
Trusted Agents, or legal entity of Trusted Agent, are under contract with Customers.
1.4 CERTIFICATE USAGE
1.4.1 APPROPRIATE CERTIFICATE USES
The sensitivity of the information processed or protected using Certificates issued by CA is under sole decision of Customer.
Relying Parties must evaluate the environment and the associated threats and vulnerabilities and determine the level of risk
they are willing to accept based on the sensitivity or significance of the information protected by the key pair and Certificate
managed according the present CP. This evaluation is done by each Customer and Relying Party for its application and is
not controlled by this CP and DocuSign.
Technically Certificate and associated private key usage are defined by the present CP for CA and Subscriber.
1.4.2 PROHIBITED CERTIFICATE USES
No other uses than the ones stated in section 1.4.1 above are covered by this CP.
DocuSign is not responsible for any other use than the ones stated in this CP.
DocuSign Envelope ID: E2033666-E28F-43CE-A3EA-F785452EF1C4
DocuSign Inc
DocuSign Certificate Policy for External CA
14
Public
1.5 POLICY ADMINISTRATION
1.5.1 ORGANIZATION ADMINISTERING THE DOCUMENT
The DS PMA is responsible for all aspects of this CP.
1.5.2 CONTACT PERSON
Questions regarding this CP shall be directed to PMA, who can be reached at DS-PMA@docusign.com.
1.5.3 PERSON DETERMINING CERTIFICATION PRACTICES STATEMENT SUITABILITY FOR
THE POLICY
The Certification Practices Statement (CPS) must conform to the corresponding Certificate Policy. The DS PMA is
responsible for approving CPS and asserting whether the CPS conforms to this CP.
See Section 8 for further details.
1.5.4 CPS APPROVAL PROCEDURES
The CPSs shall provide (whether written or through the completion of a template) more detailed information than this CP.
The CPSs shall specify how this CP shall be implemented to ensure compliance with the provisions of this CP.
PMA creates the DOCUSIGN CPS (DS CPS) and the generic Customer CPS template. Customer completes the Customer
CPS based on the CPS template provided by DS. DS control the content of the Customer CPS. DOCUSIGN CPS describes
RCA and CA practice. Customer CPS describes RA, Trusted Agent and Subscriber key pair management practice.
The DS shall prepare and submit the DOCUSIGN CPS and each Customer CPS to the DS PMA for approval. If rejected,
the identified discrepancies shall be resolved, and the CPS shall be resubmitted to the DS PMA.
The DS PMA shall commission DOCUSIGN CPS compliance analysis, made by PMA, prior to authorizing the DS OA to
issue and manage RCA and CA Certificates asserting this CP.
The DS PMA shall commission for each Customer a Customer CPS compliance analysis, made by PMA, prior to authorizing
the DS OA to issue and manage Subscriber Certificates asserting this CP.
The Customer shall transmit the Customers CPS, written to the format of the Internet X.509 Public Key Infrastructure
Certificate Policy and Certification Practices Framework [RFC 3647], to DS for approval.
The following information shall accompany the Customer request:
- Customer’s CPS.
- Signed Subscriber’s naming document (refer below in same section).
- Any other requested information or documents asked from DS PMA in order to audit and control CPS request
against the present CP requirements.
The following information shall be contained in the Subscriber naming document:
- Type of identity to set in the Subscriber certificate (refer to section Error! Reference source not found. above).
- Legal name of the Customer to be used in the Subscriber certificate.
- CRL profile to be generated by the CA.
- Identity of the CA to be used to sign the Subscriber certificate.
- Validity period of the Subscriber certificate.
DocuSign Envelope ID: E2033666-E28F-43CE-A3EA-F785452EF1C4
DocuSign Inc
DocuSign Certificate Policy for External CA
15
Public
- Cryptographic information of the Subscriber certificate.
- Subscriber Certificate content.
- Customer Contact information:
o The full name, including surname and given name(s).
o The full legal name of Customer.
o Professional phone number and email.
o A reference to its national ID and the type of ID used to authenticate the person.
- DocuSign Contact information:
o The full name, including surname and given name(s).
o The full legal name of DS Administrator company.
o Professional phone number and email.
o A reference to its national ID and the type of ID used to authenticate the person.
The Subscriber naming document shall be signed electronically by the persons with means as described in CPS.DS PMA
shall store copy of all ID used in signed document above. Subscriber naming document is part of the Customer CPS.
The DS PMA either determines that the Customer CPS meets the CP requirements or that the Customer CPS is not able
to address remaining issues. When Customer CPS doesn’t meet the CP requirement, then Customer shall modify its
practice to fulfill the discrepancy.
If Customer is not able or not willing to address remaining discrepancies, then DS PMA ends the process and Subscriber
certificate can’t be delivered. If Customer CPS fulfills the CP requirement, then Subscriber certificate can be issued.
The DS PMA shall be responsible for approving or rejecting the Customer CPS. In the case where the Customer CPS is
compliant with this CP, the DS PMA approves the Customer CPS and continue the evaluation process. In the case where
the Customer CPS is rejected, the DS PMA will ask to re-submit a new Customer CPS with all required information.
1.5.5 WAIVERS
Waivers shall not be issued. Instead, CP and/or CPS changes shall be made or remediation activities shall be scheduled
and implemented.
1.6 DEFINITIONS AND ACRONYMS
See Sections 14 and 15 of the CP.
2 PUBLICATION & REPOSITORY RESPONSIBILITIES
2.1 REPOSITORIES
DocuSign and its Customer shall operate one or multiple repositories to support all PKI operations. These repositories are
used to hold information needed by an internal user of the PKI and by external users to support interoperation with other
organizational PKI domains. These repositories shall contain the information necessary to support interoperation such as
CA certificates, CRL files, and information on organizational policy (such as this Certificate Policy document itself).
2.2 PUBLICATION OF CERTIFICATION INFORMATION
2.2.1 PUBLICATION OF CERTIFICATES AND CERTIFICATE STATUS
CA, RCA and Subscribers certificates shall only contain valid Uniform Resource Identifiers (URIs) that are accessible
publicly by relying parties.
DocuSign Envelope ID: E2033666-E28F-43CE-A3EA-F785452EF1C4
DocuSign Inc
DocuSign Certificate Policy for External CA
16
Public
DocuSign publishes RCA certificate and CRL produced by RCA.
DocuSign shall publish all CA certificates issued by or to the RCA and all CRLs issued by the CA.
See Section 10 for more details.
The PKI Repositories containing Certificates and CRL shall be deployed so as to provide high levels of reliability (24/24h &
7/7d at a rate of 99% availability or better).
Customer shall have at least an internal repository to publish Subscriber Certificate. Customer decides which kind of Relying
Party can have access to all or part of this repository.
2.2.2 PUBLICATION OF CA INFORMATION
DocuSign shall publish the CP publicly available on the DocuSign website (see
https://www.docusign.com/trust/compliance/public-certificates).
Even if CP shall be published electronically by DocuSign, applicable RCA and Customers CPSs must be kept confidential
(not published) by DocuSign and Customers.
See Section 10 for more details.
2.3 FREQUENCY OF PUBLICATION
This CP and any subsequent changes shall be made publicly available within thirty days of approval. Certificates and
certificate status information shall be published as specified in sections 4.4.2, 4.9.7, 4.9.8, 4.9.9, and 4.9.10.
2.4 ACCESS CONTROLS ON REPOSITORIES
DocuSign and Customer shall protect any repository information not intended for public dissemination or modification.
Direct and/or remote access to information in DocuSign repositories shall be determined and controlled by the PMA.
3 IDENTIFICATION & AUTHENTICATION
3.1 NAMING
3.1.1 TYPES OF NAMES
The RCA and CA shall only generate and sign certificates that contain a non-null subject and issuer Distinguished Name
(DN).
Certificates shall indicate that the Subscriber is associated with an Affiliated Organization, Customer name, by including the
name of the Affiliated Organization in the distinguished name as an organization “O”.
All the exact content of DN for issuer and subject field of each type of certificate is described in section 10 below. Profile of
certificate described in section 10 are the sole authorized to be issued under this CP.
3.1.2 NEED FOR NAMES TO BE MEANINGFUL
DocuSign Envelope ID: E2033666-E28F-43CE-A3EA-F785452EF1C4
DocuSign Inc
DocuSign Certificate Policy for External CA
17
Public
The certificates issued pursuant to this CP are meaningful and the names that appear in the certificates shall be understood
and used by Relying Parties (humans). Names used in the RCA and CA certificates must identify the legal person which
owns the CA and RCA in a meaningful way.
The identity (name) set in the Subscriber certificate is the built using internal repository of the Customer. Trusted Agent is
responsible to collect identity of the Subscriber and store it in Customer’s repository.
Subscriber identity is always set in field “CN” of the subject in certificate.
A key pair can be linked with only a unique DN for each RCA, CA and Subscriber certificate.
3.1.3 ANONYMITY OR PSEUDONYMITY OF CERTIFICATE
RCA and CA certificates shall not contain anonymous or pseudonymous identities.
DNs in certificates issued to Subscriber may contain a pseudonym as long as name space uniqueness requirements are
met and as long as such name is unique and traceable to the actual entity. Trusted agent shall be able to make the link
between the real name of the subscriber as written in official ID and the pseudonym used for the subscriber in the certificate.
3.1.4 RULES FOR INTERPRETING VARIOUS NAME FORMS
Rules for interpreting name forms shall be contained in the applicable certificate profile (see section 10 and 3.1.1, 3.12 and
3.1.3). The DS PMA shall be the authority responsible for RCA and CA name space control. Customer shall be responsible
for the authority responsible for Subscriber name space control.
Relying parties shall use the subject name contained in the certificate (refer to section 3.1.1) to identify the RCA, CA and
Subscriber.
3.1.5 UNIQUENESS OF NAMES
The DNs contained in the certificate of RCA and CA (refer to section 3.1.1 above) shall be unique in the RCA trust domain.
The PMA controls that the RCA and the CA certificates are unique, by controlling the DN used in the RCA and the CA
certificates and approving the RCA and CA certificate creation. The same CN shall not be given to two or more distinct CAs
or RCAs representing distinct entities. Name (subject DN) uniqueness must be enforced by the Customer for the name
space for subscriber certificates. Two distinct subscribers may have the same CN, but shall always have unique DNs thanks
the to email set in the DN of Subscriber.
Customer is responsible to guaranty the uniqueness of DN for Subscriber registered by its Trusted Agent.
Name uniqueness is not violated when multiple certificates are issued to the same entity.
3.1.6 RECOGNITION, AUTHENTICATION, AND ROLE OF TRADEMARKS
The DS PMA and Customer will not knowingly use trademarks in names unless the Subscriber, Customer or DocuSign has
the rights to use that name.
3.1.7 NAME CLAIM DISPUTE RESOLUTION
The DS PMA shall resolve or cause to be resolved any name collision brought to its attention in RCA and CA certificates.
The Customer shall resolve or cause to be resolved any name collision brought to its attention in Subscriber certificate that
may affect interoperability. For that case, Customer can request advise to DS PMA to help to resolve the problem.
DocuSign Envelope ID: E2033666-E28F-43CE-A3EA-F785452EF1C4
DocuSign Inc
DocuSign Certificate Policy for External CA
18
Public
3.2 INITIAL IDENTITY VALIDATION
3.2.1 METHOD TO PROVE POSSESSION OF PRIVATE KEY
3.2.1.1 RCA AND CA
RCA and CA key pairs shall be generated, stored, activated, used, and destroyed by the DS OA in a way that demonstrates
to the PMA that DocuSign owns the private key corresponding to the public key contained in its RCA and CA certificate.
3.2.1.2 SUBSCRIBER
Customer is responsible to generate the Subscriber’s key pair in the DSA box in a secured manner in order to guaranty that
nobody can use key on behalf of the Subscriber. Subscriber’s key can only be used by DSA box to sign a CSR and transmit
it to CA to have a Subscriber Certificate.
For Subscriber Certificates, proof of ownership of the private key corresponding to the Subscriber Certificate used for signing
purposes is provided by the technical and organizational resources defined in the consent protocol (request Subscriber to
enter its activation data for use of key pair at the beginning and after each certain time frame that not exceeds 15 minutes)
used and applied as part of the DSA box when the key is used.
3.2.2 AUTHENTICATION OF ORGANIZATION IDENTITY
Requests for RCA and CA certificates in the name of an Affiliated Organization shall include the organization name, address,
and documentation of the existence of the organization.
Request for Subscriber Certificate is always associated to the Customer name organization identity.
The DS PMA, shall verify the information provided, the authenticity of the requesting representative, and the representative’s
authorization to act in the name of the organization for RCA and CA certificate.
The RA legal entity, Customer, is authenticated by DS OA during contractual phase with RA. The DS OA shall verify the
existence and authenticity of the claimed legal name to be used in the Subscriber Certificate for the field “O. DS OA uses
information retrieved from official database documentation (Qualified Independent Information Source, Qualified
Government Information Source, Qualified Government Tax Information Sources), that confirms the existence of the
organization. That database documentation contains trusted information that is filled by the trusted source that registers the
legal company. DS OA verifies also that the Customer Contact is empowered by Customer to act on behalf of the Customer
to use DS service covered by the present CP with the legal name of the Customer. DocuSign OA shall check that the legal
person is not known by an authoritative source to be in a status that would prevent it from acting as that legal person or
contained in a black list.
Customer is responsible to define which kind of natural person (employee of Customer, contractor of Customer …) can be
issued a Subscriber Certificate.
Trusted Agent is responsible to control that only the authorized natural persons are issued Subscriber Certificate.
3.2.3 AUTHENTICATION OF PHYSICAL PERSON IDENTITY
3.2.3.1 INITIAL IDENTITY PROOFING OF HUMAN SUBSCRIBERS
DocuSign Envelope ID: E2033666-E28F-43CE-A3EA-F785452EF1C4
DocuSign Inc
DocuSign Certificate Policy for External CA
19
Public
Identity proofing of Customer Contact shall be performed by DocuSign under rules approved by PMA (during the sales
process). DS OA is in charge of collecting the identity and contact information of Customer Contact using rules approved
by PMA.
The RA is responsible for collecting and storing the required information to provide evidence of the Subscriber identity set
in the Certificate and information used by Subscriber to sign (email and name). Subscriber identity verification rules are left
to the discretion of the RA, which is in charge of managing the Subscriber.
The enrollment of a Subscriber prior to issuing a Subscriber Certificate is performed directly by the RA and Trusted Agent.
Customer shall ensure that its registration process guaranties the following:
Ensure the applicant (natural person who will be issued a Subscriber Certificate) is aware of the terms and
conditions related to the use of the Certificate and associated private key and associated activation data (refer to
section 9.6.3).
Ensure the applicant is aware of recommended security precautions related to the activation data.
Collect the relevant identity data required for identity proofing and verification.
The applicant can be assumed to be in possession of evidence either; one unexpired National Government-issued
or REAL ID Act issued Picture ID or two Non-Federal Government IDs, one of which shall be a photo ID, in which
the application for the electronic identity means is being made and representing the claimed identity.
The evidence of applicant can be assumed to be genuine, or to exist according to an authoritative source and the
evidence appears to be valid.
Natural person corresponds to the criteria defined by Customer to be authorized to be issued a Subscriber
Certificate (refer to section 3.2.2 above).
After having authenticated the Subscriber, RA shall fill the Customer repository with the collected Subscriber’s information
and authorized the Subscriber in the Customer repository to be issued a Certificate.
3.2.3.2 HUMAN SUBSCRIBER RE-PROOFING FOLLOWING LOSS, DAMAGE, OR KEY
COMPROMISE
If Subscriber’s private keys associated with the public key certificates are lost, damaged, or stolen, the Subscriber may be
issued new certificates according to the re-proofing provisions in this Section.
The re-proofing provision is made using the Customer repository with Subscriber status. If Subscriber is contained in the
Customer repository then Certificate is re-issued using a new key pair and same information containing in the Customer
Repository.
3.2.4 NON-VERIFIED SUBSCRIBER INFORMATION
Information that is not verified shall not be included in certificates.
3.2.5 VALIDATION OF AUTHORITY
Approval from the DS PMA for RCA and CA certificate shall be obtained prior to issuing such certificate. Certificates that
contain explicit or implicit organizational affiliation shall be issued only after ascertaining the applicant has the authorization
to act on behalf of the organization in the asserted capacity.
Prior to issuing Subscriber certificates, the Trusted Agent shall verify that the Subscriber is authorized to have a certificate
in the name of the affiliated organization.
3.2.6 CRITERIA FOR INTEROPERATION
DocuSign Envelope ID: E2033666-E28F-43CE-A3EA-F785452EF1C4
DocuSign Inc
DocuSign Certificate Policy for External CA
20
Public
DS PMA shall control that RCA and CA are not signed by another CA of DocuSign or external to DocuSign. CA are only
authorized to be signed by RCA of DocuSign.
This CP represents one level of trust. Customer is responsible to communicate the RCA certificate to Relying Party who
accepts this level of trust for their needs. DS PMA takes care to ensure, controlling Customer CPS, that all Customers has
same level of security in their practice. By this way Subscriber Certificate shares the same level of trust.
3.3 IDENTIFICATION AND AUTHENTICATION FOR RE-KEY REQUESTS
3.3.1 IDENTIFICATION AND AUTHENTICATION FOR ROUTINE RE-KEY
DS PMA uses the same procedures as defined in section 3.2 to authenticate an RCA and CA certificate request. A new
RCA and CA certificate shall use a new key pair.
Trusted Agent shall regularly control that only legitimate natural person, according rules defined in section 3.2, are contained
in the Customer repository and still be authorized to be issued Certificate. Trusted Agent shall control that information of
Subscriber are still accurate and true. Customer is responsible of the update of Subscriber information in the Customer
repository. Any update of Subscriber information shall be authenticated as described in section 3.2 above.
RA is synchronized with Customer repository and controls that Subscriber is still in the Customer repository. If Customer is
removed from Customer repository or not anymore authorized to be issued a Certificate, then the DSA box revoke the
Subscriber Certificate.
3.3.2 IDENTIFICATION AND AUTHENTICATION FOR RE-KEY AFTER REVOCATION
After a certificate has been revoked, other than during a renewal, update, or to replace a lost/stolen/damaged credential,
the Subscriber is required to go through the initial registration processes described in Section 3.2.3 to obtain a new certificate
unless the Subscriber can be authenticated with a non-revoked certificate of equal or higher assurance issued from the
same CA.
3.4 IDENTIFICATION AND AUTHENTICATION FOR REVOCATION REQUEST
Revocation requests must be authenticated by RA.
4 CERTIFICATE LIFE-CYCLE
4.1 CERTIFICATE APPLICATION
Sections 4.1, 4.2, 4.3 and 4.4 specify the requirements for an initial application for certificate issuance. Sections 4.6, 4.7
and 4.8 specify the requirements for certificate renewal.
Certificates and corresponding private keys must be managed safely at their initial creation through their full life-cycle.
With the present CP, DS PMA establishes and publishes its criteria and procedures describing how Customer and
Subscribers may apply for certificate(s).
4.1.1 SUBMISSION OF CERTIFICATE APPLICATION
4.1.1.1 RCA
DocuSign Envelope ID: E2033666-E28F-43CE-A3EA-F785452EF1C4
DocuSign Inc
DocuSign Certificate Policy for External CA
21
Public
DS OA creates the RCA request (RCA naming document) and transmit to DS PMA for approval.
4.1.1.2 CA: DOCUSIGN GENERIC CA
DS OA creates the CA request (CA naming document) and transmit to DS PMA for approval.
4.1.1.3 SUBSCRIBER
RA is in charge to create the technical Subscriber Certificate request.
4.1.2 ENROLLMENT PROCESS AND RESPONSIBILITIES
All communications among PKI authorities materially supporting the certificate application and issuance process shall be
authenticated and protected from modification.
4.1.2.1 RCA
RCA certificates must be authorized by the DS PMA prior to issuance. The issuance process shall include documenting the
following information to be contained in the RCA certificate request (naming document):
- Identity to set in the RCA certificate (refer to section Error! Reference source not found. above).
- Validity period of the RCA certificate.
- Cryptographic information of the RCA certificate.
- RCA Certificate content (refer to section 10).
- CRL information to be produced with the RCA Certificate generation.
- DocuSign Inc. as the legal Entity which owns RCA.
- DS OA information:
o The full name, including surname and given name(s) of the representative.
o The full name and legal status of the authorized representative’s Employer.
o Professional phone number and email of the authorized representative.
o A reference to its national ID and the type of ID used to authenticate the person.
DS PMA shall store copy of Authorized representative’s ID. The RCA certificate request shall be signed electronically by
the authorized representative with means as described in CPS/
In parallel the DS OA shall transmit the DOCUSIGN CPS, written to the format of the Internet X.509 Public Key Infrastructure
Certificate Policy and Certification Practices Framework [RFC 3647], for approval. RCA key pair and certificate can’t be
generated without prior having the DOCUSIGN CPS and RCA key ceremony script approved by DS PMA. DOCUSIGN CPS
shall be signed by DS OA.
4.1.2.2 CA: DOCUSIGN DEDICATED CA
CA certificates must be authorized by the DS PMA prior to issuance. The issuance process shall include documenting the
following information to be contained in the CA certificate request (naming document):
- Identity to set in the CA certificate (refer to section Error! Reference source not found. above).
- Identity of the RCA to be used to sign the CA certificate.
- Validity period of the CA certificate.
- Cryptographic information of the CA certificate.
- CA Certificate content (refer to section 10).
- DocuSign Inc. as the legal Entity which owns CA.
- DS OA information:
o The full name, including surname and given name(s) of the representative.
o The full name and legal status of the authorized representative’s Employer.
DocuSign Envelope ID: E2033666-E28F-43CE-A3EA-F785452EF1C4
DocuSign Inc
DocuSign Certificate Policy for External CA
22
Public
o Professional phone number and email of the authorized representative.
o A reference to its national ID and the type of ID used to authenticate the person.
DS PMA shall store copy of Authorized representative’s ID. The CA certificate request shall be signed electronically by the
authorized representative with means as described in CPS.
In parallel the DS OA shall transmit the DOCUSIGN CPS, written to the format of the Internet X.509 Public Key Infrastructure
Certificate Policy and Certification Practices Framework [RFC 3647], for approval. RCA key pair and certificate can’t be
generated without prior having the DOCUSIGN CPS and RCA key ceremony script approved by DS PMA. DOCUSIGN CPS
shall be signed by DS OA.
4.1.2.3 SUBSCRIBER
Subscriber certificate request created by RA using Customer repository shall contain the following information:
Email of the subscriber (refer to section 3.2).
All required information to construct the Subscriber’s identity (name) to be set in the Certificate as described in
section 3.1.
4.2 CERTIFICATE APPLICATION PROCESSING
Information in certificate applications must be verified as accurate by the approver before certificates are issued. The
applicable CPS shall specify procedures to verify information in certificate applications.
4.2.1 PERFORMING IDENTIFICATION AND AUTHENTICATION FUNCTIONS
4.2.1.1 RCA
Requests are submitted by DS OA to DS PMA prior to issuance using means and process described in CPS and approved
by PMA. It is the responsibility of the DS PMA to authenticate the DS OA as described in section 3.2 above, and to verify
that the information in RCA Certificate request is accurate for the RCA.
4.2.1.2 CA: DOCUSIGN GENERIC CA
Requests are submitted by DS OA to DS PMA prior to issuance using means and process described in CPS and approved
by PMA. It is the responsibility of the DS PMA to authenticate the DS OA as described in section 3.2 above, and to verify
that the information in CA Certificate request is accurate for the CA.
4.2.1.3 SUBSCRIBER
It is the responsibility of the Trusted Agent to verify that the information in Customer repository is accurate (see sections
3.2). It is also responsibility of Trusted Agent to verify the link between Subscriber and affiliated organization to be set in the
certificate (see sections 3.2).
4.2.2 APPROVAL OR REJECTION OF CERTIFICATE APPLICATIONS
4.2.2.1 RCA
Once a completed RCA certificate request has been submitted to the DS PMA, the DS PMA studies it. DS PMA can’t take
decision based on an incomplete RCA certificate request. All required information listed in section 4.1.2 above shall be
DocuSign Envelope ID: E2033666-E28F-43CE-A3EA-F785452EF1C4
DocuSign Inc
DocuSign Certificate Policy for External CA
23
Public
given to the DS PMA. The DS PMA shall evaluate the completeness of the submitted request. The DS PMA shall
commission a CPS compliance analysis prior to authorizing the DS OA to issue and manage RCA Certificates asserting
this CP.
In the case where the RCA certificate request is complete and compliant with this CP statement, the DS PMA approves the
RCA certificate creation.
In the case where the RCA certificate request is rejected, the PMA will ask to re-submit a new RCA certificate request.
4.2.2.2 CA: DOCUSIGN GENERIC CA
Once a completed CA certificate request has been submitted to the DS PMA, the DS PMA studies it. DS PMA can’t take
decision based on an incomplete CA certificate request. All required information listed in section 4.1.2 above shall be given
to the DS PMA. The DS PMA shall evaluate the completeness of the submitted request. The DS PMA shall commission a
CPS compliance analysis prior to authorizing the DS OA to issue and manage CA Certificates asserting this CP.
In the case where the CA certificate request is complete and compliant with this CP statement, the DS PMA approves the
CA certificate creation.
In the case where the CA certificate request is rejected, the PMA will ask to re-submit a new CA certificate request.
4.2.2.3 SUBSCRIBER
The Trusted agent shall be responsible for approving or rejecting Subscriber in Customer repository after successful
authentication (see section 3.2).
4.2.3 TIME TO PROCESS CERTIFICATE APPLICATIONS
No stipulation.
4.3 CERTIFICATE ISSUANCE
4.3.1 CA ACTIONS DURING CERTIFICATE ISSUANCE
4.3.1.1 RCA
The PMA transmits the RCA certificate request to the DS OA. The OA authenticates the certificate request before issuance.
DS OA authenticates all key ceremony attendee (refer to section 3.2 above) using list provided by authorized representative
(for witness) and the list of DS OA of PKI trusted role (refer to section 5.2).
The RCA certificate is generated during a key ceremony using a RCA key pair (refer to section 6.1.1.1 below). During the
key ceremony, the RCA private key is backed-up (refer to section 6.2.4.1 below). At the end of the key ceremony the RCA
private key is deactivated (refer to section 6.2.9.1 below) and destroyed inside the HSM (refer to section 6.2.9.1 below) and
only exist on backup format.
4.3.1.2 CA: DOCUSIGN GENERIC CA
The PMA shall transmit the CA certificate request to the DS OA. The OA shall authenticate the CA certificate request prior
to the generation of the CA key pair and CSR. Transmission of the certificate request and CSR shall be performed in a
DocuSign Envelope ID: E2033666-E28F-43CE-A3EA-F785452EF1C4
DocuSign Inc
DocuSign Certificate Policy for External CA
24
Public
manner which ensures the integrity of the information. DS OA authenticates all key ceremony attendee (refer to section 3.2
above) using list provided by authorized representative (for witness) and the list of OA of PKI trusted role.
The following actions must occur during a CA Key Ceremony, which shall be witnessed by an DOCUSIGN FRANCE PMA
witness at least:
Issuance of CA keys (refer to section 6.1.1.3 below).
Backup of CA private key (refer to section 6.2.4.3 below).
Generation of CA CSR (The CSR shall include the CA’s public key).
RCA private key is activated to sign CA certificate (refer to section 6.2.6.1, 6.2.7.1 and 6.2.8.1 below).
At the end of the key ceremony the CA private key is deactivated (refer to section 6.2.9.3 below), CA key is
destroyed inside the HSM (refer to section 6.2.9.2 below) and only exist on backup format (refer to section 6.2.4.2
below).
At the end of the key ceremony the RCA private key is deactivated (refer to section 6.2.9.1 below), RCA key is destroyed
inside the HSM (refer to section 6.2.9.1 below) and only exist on backup format (refer to section 6.2.4.1 below).
4.3.1.3 SUBSCRIBER
RA signs and transmits the technical certificate request to the CA containing Subscriber’s information (name and email)
over a mutual TLS session with CA.
CA authenticates the RA using the TLS client certificate and verifying the signature of certificate request.
CA generates the Subscriber’s Subscriber certificate.
CA returns the Subscriber Certificate to RA.
4.3.2 NOTIFICATION TO SUBSCRIBER OF CERTIFICATE ISSUANCE
The Customer is shall notify Subscribers of successful Certificate issuance in accordance with procedures set forth in the
applicable Customer CPS.
The DS OA shall notify the DS PMA for RCA and CA certificate of successful Certificate issuance in accordance with
procedures set forth in the applicable DOCUSIGN CPS.
4.4 CERTIFICATE ACCEPTANCE
4.4.1 CONDUCT CONSTITUTING CERTIFICATE ACCEPTANCE
4.4.1.1 RCA
The DS PMA accepts the RCA certificate when the DS OA representative that witnesses the RCA key ceremony signs the
RCA certificate issuance attestation.
Once the RCA certificate has been accepted, the RCA may start signing certificate and CRL.
4.4.1.2 CA: DOCUSIGN GENERIC CA
The DS PMA accepts the CA certificate when the DS OA representative that witnesses the CA key ceremony signs the CA
certificate issuance attestation.
DocuSign Envelope ID: E2033666-E28F-43CE-A3EA-F785452EF1C4
DocuSign Inc
DocuSign Certificate Policy for External CA
25
Public
Once the CA certificate has been accepted, the CA may start signing certificate and CRL.
4.4.1.3 SUBSCRIBER
For subscriber, first use of the certificate constitutes acceptance of the issued certificate. If the Subscriber finds mistake in
the Certificate, then subscriber shall proceed to a revocation request to Trusted Agent.
4.4.2 PUBLICATION OF THE CERTIFICATE BY THE CA
As specified in 2.2.1, all RCA and CA certificates shall be published in Repositories.
This CP makes no stipulation regarding publication of Subscriber certificates.
4.4.3 NOTIFICATION OF CERTIFICATE ISSUANCE BY THE CA TO OTHER ENTITIES
Notification of Certificate issuance is provided by publishing RCA and CA certificates (refer to section 2.2 above).
4.5 KEY PAIR AND CERTIFICATE USAGE
4.5.1 SUBSCRIBER PRIVATE KEY AND CERTIFICATE USAGE
Subscribers shall protect their private keys from access by other parties.
Subscribers, RCA and CAs shall use their private key as specified through certificate extensions, including the key usage,
extended key usage extensions, and certificate policies in the associated certificate.
4.5.2 RELYING PARTY PUBLIC KEY AND CERTIFICATE USAGE
Relying parties shall accept public key certificates and associated public keys for the purposes intended as constrained by
the extensions (such as key usage, extended key usage, certificate policies, etc.) in the certificates.
4.6 CERTIFICATE RENEWAL
Certificate renewal consists of issuing a new certificate with a new validity period and serial number while retaining all other
information in the original certificate including the public key. Frequent renewal of certificates may assist in reducing the
size of CRLs. After certificate renewal, the old certificate may or may not be revoked, but must not be further re-keyed,
renewed, or modified.
This practice is not allowed for RCA and Subscriber. In case a new certificate is created, a new key pair shall be created.
While this practice is allowed for CA, it is discouraged for the CA and must be submitted to the DS PMA for approval.
4.6.1 CIRCUMSTANCE FOR CERTIFICATE RENEWAL
A certificate may be renewed if the private key has not reached the end of its validity period, has not been revoked or
compromised, and the CA name and attributes are unchanged.
Certificates may also be renewed when the RCA that issued the certificates is re-keyed.
The validity period of the certificate and private key must meet the requirements specified in Section 5.6.
DocuSign Envelope ID: E2033666-E28F-43CE-A3EA-F785452EF1C4
DocuSign Inc
DocuSign Certificate Policy for External CA
26
Public
For CA, procedure is the same as described in section 3.3, 4.1, 4.2, 4.3 and 4.4.
4.7 CERTIFICATE RE-KEY
Re-keying a certificate consists of creating new certificates with a new and different private key (and serial number) and
corresponding new and different public key, while retaining the remaining contents of the old certificate that describe the
subject. The new certificate may be assigned a different validity period, key identifiers, specify a different CRL distribution
point, and/or be signed with a different key. Re-key of a certificate does not require a change to the subject Distinguished
Name or subject Alternative Name(s) and does not violate the requirement for name uniqueness.
After certificate rekey, the old certificate may or may not be revoked, but must not be further re-keyed, renewed, or modified.
For RCA, CA and Subscriber procedure is the same as described in section 3.3, 4.1, 4.2, 4.3 and 4.4.
4.8 CERTIFICATE MODIFICATION
Certificate modification consists of creating new certificates with subject information (e.g., a name or email address) that
differs from the old certificate. For example, an CA may perform certificate modification for a Subscriber whose
characteristics have changed (e.g., has just received a medical degree). The new certificate may have the same or different
subject public key. After certificate modification, the old certificate may or may not be revoked, but must not be further re-
keyed, renewed, or modified.
RCA may perform a certificate modification process in support of cases where one or more of the CA’s names has changed.
Such circumstances included, but are not limited to name change from marriage, post nominal change, and email address
change.
CA must be entitled to continue with its existing certificate before certificate modification is performed.
This practice is not allowed for Subscriber. In case a new certificate is created, a new key pair shall be created.
For CA, procedure is the same as described in section 3.3, 4.1, 4.2, 4.3 and 4.4.
4.9 CERTIFICATE REVOCATION AND SUSPENSION
Revocation requests must be authenticated. Requests to revoke a certificate may be authenticated using that certificate's
associated private key, regardless of whether or not the private key has been compromised.
For RCA and CAs, the Customer shall be notified by DS PMA at least 3 months prior to the revocation of a CA or RCA
certificate, whenever possible. The notice period will begin to run upon written acknowledgement by the Customer.
4.9.1 CIRCUMSTANCES FOR REVOCATION
Whenever any of the below circumstances occur, the associated certificate shall be revoked and placed on the CRL.
Revoked certificates shall be included on all new publications of the certificate status information until the certificates expire.
4.9.1.1 CA: DOCUSIGN GENERIC CA
The circumstances under which certificates issued by an RCAs shall be revoked include:
DS PMA requests revocation.
The affiliation with an organization can no longer be confirmed (e.g. Customer terminates relationship with
DocuSign).
DocuSign Envelope ID: E2033666-E28F-43CE-A3EA-F785452EF1C4
DocuSign Inc
DocuSign Certificate Policy for External CA
27
Public
Content in a certificate is no longer valid (e.g. name, role, or privilege change).
CA Private key is compromised or suspected of compromise.
4.9.1.2 SUBSCRIBER
The circumstances under which certificates issued by an CAs shall be revoked include:
The Subscriber, Customer authorized roles or DS PMA requests revocation.
The affiliation with an affiliated organization asserted in the DN is no longer valid. Customer shall ensure in their
agreements with Subscriber that the Customer and Subscriber be required to notify the Customer of any changes
to the Subscriber affiliated organization.
The affiliation with an organization can no longer be confirmed (e.g. Subscriber terminates relationship with
Customer).
Content in a certificate is no longer valid (e.g. name, role, or privilege change)
Subscriber or Customer roles can be shown to have violated the stipulations of its respective Subscriber Agreement
or this CP.
Private key is compromised or suspected of compromise
4.9.2 WHO CAN REQUEST REVOCATION
4.9.2.1 CA: DOCUSIGN GENERIC CA
DS OA shall accept revocation requests as followed:
From DS PMA.
The DS OA is permitted to revoke the certificates they issue at the DS PMA sole discretion.
4.9.2.2 SUBSCRIBER
RAs shall accept revocation requests as followed:
From Subscriber for its certificates.
From Trusted Agent.
From designated officials of Affiliated Organizations for certificates limited to those asserting an affiliation with
their organization.
Authorized roles and person as described in Customer CPS.
The CA is permitted to revoke the certificates they issue at the DS PMA sole discretion.
4.9.3 PROCEDURE FOR REVOCATION REQUEST
4.9.3.1 CA: DOCUSIGN GENERIC CA
Revocation of the CA certificate requires also revocation of all Subscriber certificates CA has issued. The revocation of an
CA certificate requires the authorization of 2 distinct individuals acting as permanent members of the PMA.
CA revocation request is transmitted to the DS OA by the PMA. The DS OA authenticates the CA revocation request during
a face to face meeting. DS OA authenticates all key ceremony attendee (refer to section 3.2 above) using list provided by
authorized representative (for witness) and the list of DS OA of PKI trusted role.
DocuSign Envelope ID: E2033666-E28F-43CE-A3EA-F785452EF1C4
DocuSign Inc
DocuSign Certificate Policy for External CA
28
Public
The operation is video-recorded and performed according to a key ceremony script.
RCA key pair, according which has to be used for the revocation operation, is undertaken and witnessed in a physically
secure environment (refer to section 5.1 above) by personnel in trusted roles (refer to section 5.2 above) under at least dual
supervision. Private Key activation data are distributed to activation data holders that are trusted employees.
RCA key pair is carried out within a hardware security module (refer to section 6.2 and below). Witnesses are persons other
than the operational personnel. RCA private key is activated to sign CRL (refer to section 6.2.6.1, 6.2.7.1 and 6.2.8.1 below).
At the end of the key ceremony the RCA private key is deactivated (refer to section 6.2.9.1 below), RCA key is destroyed
inside the HSM (refer to section 6.2.9.1 below) and only exist on backup format (refer to section 6.2.4.1 below).
The current RCA issued CRL is replaced by the new one in the PS.
DS PMA can decide in this particular case to also destroy the CA private key backup and CA key in HSM hosted by DS OA
after all Subscriber certificate issued by CA has been revoked.
4.9.3.2 SUBSCRIBER
Revocation requests are authenticated by the RA.
The revocation request is stored in the RA’s logs.
The RA authenticates the revocation request it receives (refer to section 3.4 above).
The RA transmits the signed revocation request to the CA over mutual TLS session.
The CA authenticates the RA and makes sure the request was issued by an RA authorized by the CA.
The CA revokes the certificate by including the certificate's serial number in the next CRL to be issued by the Sub-CA if the
certificate is not expired.
The reason code set in CRL is always “unspecified”.
RA shall inform the Subscriber about the new status of the certificate.
4.9.4 REVOCATION REQUEST GRACE PERIOD
The revocation request grace period for CA is the time available to the responsible party within which the responsible party
must make a revocation request after reasons for revocation have been identified. This revocation shall be processed as
quickly as possible not to exceed 10 business days.
This CP does not allow a revocation grace period for Subscriber. Responsible parties must request revocation as soon as
they identify the need for revocation.
4.9.5 TIME WITHIN WHICH CA MUST PROCESS THE REVOCATION REQUEST
The DS PMA shall process a revocation request as soon as possible after receiving the revocation request, not to exceed
10 business days.
The CA shall process a revocation request as soon as practical after receiving, authenticated and approving the revocation
request. The maximum delay to revoke a certificate is 24 hours.
DocuSign Envelope ID: E2033666-E28F-43CE-A3EA-F785452EF1C4
DocuSign Inc
DocuSign Certificate Policy for External CA
29
Public
4.9.6 REVOCATION CHECKING REQUIREMENT FOR RELYING PARTIES
Although the CRL issued by the RCA has a validity period of 30 days, the Relying Party shall check for a refreshed CRL
every 24 hours to obtain the latest cross-certificate revocations reported.
In any case, use of revoked certificates could have damaging or catastrophic consequences in certain cases. The matter
of how often new revocation data should be obtained and whether to rely upon a certificate whose revocation status is
temporarily unavailable is a determination to be made by the Relying Party, considering the risk, responsibility, and
consequences for using a certificate whose revocation status cannot be guaranteed.
4.9.7 CRL ISSUANCE FREQUENCY
RCA issues CRL every year.
CA issues a CRL every 24 hours but CRL.
CRL publication service availability is 24 out of 24 hours and 7 out of 7 days.
4.9.8 MAXIMUM LATENCY FOR CRLS
CA issues CRL every 24 hours but CRL is valid for 7 days.
4.9.9 ON-LINE REVOCATION/STATUS CHECKING AVAILABILITY
Not applicable.
4.9.10 ON-LINE REVOCATION CHECKING REQUIREMENTS
Not applicable.
4.9.11 OTHER FORMS OF REVOCATION ADVERTISEMENTS AVAILABLE
Not applicable.
4.9.12 SPECIAL REQUIREMENTS RELATED TO KEY COMPROMISE
See Section 4.9.7.
4.9.13 CIRCUMSTANCES FOR SUSPENSION
Not applicable.
4.9.14 WHO CAN REQUEST SUSPENSION
Not applicable.
4.9.15 LIMITS ON SUSPENSION PERIOD
Not applicable.
DocuSign Envelope ID: E2033666-E28F-43CE-A3EA-F785452EF1C4
DocuSign Inc
DocuSign Certificate Policy for External CA
30
Public
4.10 CERTIFICATE STATUS SERVICES
Not applicable.
4.10.1 OPERATIONAL CHARACTERISTICS
Not applicable.
4.10.2 SERVICE AVAILABILITY
Not applicable.
4.10.3 OPTIONAL FEATURES
Not applicable.
4.11 END OF SUBSCRIPTION
Certificates that have expired prior to or upon end of subscription are not required to be revoked. Unexpired Subscriber
certificates shall always be revoked at the end of subscription with the Customer.
The contract between Customer and DocuSign deals with end of relationship.
4.12 KEY ESCROW AND RECOVERY
Not applicable.
4.12.1 KEY ESCROW AND RECOVERY POLICY AND PRACTICES
Not applicable.
4.12.2 SESSION KEY ENCAPSULATION AND RECOVERY POLICY AND PRACTICES
Not applicable.
5 FACILITY, MANAGEMENT AND OPERATIONAL CONTROLS
5.1 PHYSICAL CONTROLS
5.1.1 SITE LOCATION & CONSTRUCTION
The location and construction of the facility housing CA and RCA (See Section 1.3.3) equipment shall be consistent with
facilities used to house high value, sensitive information. The site location and construction, when combined with other
physical security protection mechanisms such as guards, high security locks, and intrusion sensors, shall provide robust
protection against unauthorized access to CA and RCA equipment and records.
5.1.2 PHYSICAL ACCESS
DocuSign Envelope ID: E2033666-E28F-43CE-A3EA-F785452EF1C4
DocuSign Inc
DocuSign Certificate Policy for External CA
31
Public
5.1.2.1 PHYSICAL ACCESS FOR CA AND RCA EQUIPMENT
CA and RCA equipment shall always be protected from unauthorized access. The security mechanisms shall be
commensurate with the level of threat in the equipment environment.
The physical security requirements pertaining to CAs are:
Ensure no unauthorized access to the hardware is permitted
Ensure all removable media and paper containing sensitive plain-text information is stored in secure containers
Ensure manual or electronic monitoring for unauthorized intrusion at all times
Ensure an access log is maintained and inspected periodically
Require two person physical access control to both the cryptographic module and computer systems
Require in-person access (no remote access)
Provide at least three layers of physical access boundaries (e.g. perimeter, building, PKI room)
Removable cryptographic modules shall be deactivated prior to storage. When not in use, cryptographic modules, activation
information used to access or enable cryptographic modules, and other sensitive CA equipment shall be placed in secure
containers when not in use. Activation data shall either be memorized, or recorded and stored in a manner commensurate
with the security afforded the cryptographic module, and shall not be stored with the cryptographic module.
A security check of the facility housing the CA and RCA equipment shall occur if the facility is to be left unattended. At a
minimum, the check shall verify the following:
The equipment is in a state appropriate to the current mode of operation (e.g., that cryptographic modules are in
place when “open”, and secured when “closed”);
Off-line RCA equipment is shut down or HSMs are deactivated and securely stored;
Any security containers are properly secured;
Physical security systems (e.g., door locks, vent covers) are functioning properly; and
The area is secured against unauthorized access.
A person or group of persons shall be made explicitly responsible for making such checks. When a group of persons is
responsible, a log identifying the person performing a check at each instance shall be maintained. If the facility is not
continuously attended, the last person to depart shall initial a sign-out sheet that indicates the date and time and assert that
all necessary physical protection mechanisms are in place and activated.
5.1.2.2 PHYSICAL ACCESS FOR RA EQUIPMENT
RA equipment shall be protected from unauthorized access while the DSA box is installed and activated. The RA shall
implement physical access controls to reduce the risk of equipment tampering even when the DSA box is not installed and
activated. These security mechanisms shall be commensurate with the level of threat in the RA equipment environment.
The physical security mechanisms for RA equipment (Customer repository, DSA box, DSA box activation data and DSA
box backup) at minimum shall be in place to:
Ensure monitoring, either manually or electronically, of unauthorized intrusion at all times.
Ensure no unauthorized access to the hardware and activation data and back up of DSA box is permitted.
Ensure all removable media and paper containing sensitive plain-text information is stored in secure location.
Any non-authorized individual entering secure areas shall always be under oversight by a trusted role.
Ensure an access log is maintained and inspected periodically.
Provide at least 2 layers of increasing security such as perimeter, building, and operational room.
DocuSign Envelope ID: E2033666-E28F-43CE-A3EA-F785452EF1C4
DocuSign Inc
DocuSign Certificate Policy for External CA
32
Public
Ensure that DSA box activation data and DSA box backup are stored in a protected location (safe for example) and
under dual control in way requiring 2 persons to restore a DSA box with activation data and back up file.
Require trusted roles physical access controls.
5.1.3 POWER AND AIR CONDITIONING
CAs shall have backup capability sufficient to automatically lock out input, finish any pending actions, and record the state
of the equipment before lack of power or air conditioning causes a shutdown. Repositories shall be provided with
Uninterrupted Power sufficient for a minimum of six hours operation in the absence of commercial power.
5.1.4 WATER EXPOSURES
CA equipment shall be installed such that it is not in danger of exposure to water (e.g., on tables or elevated floors). Water
exposure from fire prevention and protection measures (e.g. sprinkler systems) are excluded from this requirement.
5.1.5 FIRE PREVENTION AND PROTECTION
No stipulation.
5.1.6 MEDIA STORAGE
CA media shall be stored so as to protect it from accidental damage (water, fire, electromagnetic) and unauthorized physical
access.
5.1.7 WASTE DISPOSAL
Sensitive media and documentation that are no longer needed for operations shall be destroyed in a secure manner. For
example, sensitive paper documentation shall be shredded, burned, or otherwise rendered unrecoverable.
5.1.8 OFF-SITE BACKUP
CAs and RCA shall create full system backups sufficient to recover full PKI services from a system failure on a periodic
schedule. Backups are to be performed and stored off-site not less than once a month. At least one full backup copy shall
be stored at an off-site location separate from the CA and RCA equipment. Only the latest full backup need be retained.
The backup shall be stored at a site with physical and procedural controls commensurate to that of the operational CA and
RCA.
5.2 PROCEDURAL CONTROLS
5.2.1 TRUSTED ROLES
A trusted role is one whose incumbent performs functions that can introduce security problems if not carried out properly,
whether accidentally or maliciously. The people selected to fill these roles must be extraordinarily responsible or the integrity
of the RA, CA and RCA is weakened. The functions performed in these roles form the basis of trust for all uses of the RA,
CA and RCA. Two approaches are taken to increase the likelihood that these roles can be successfully carried out. The first
ensures that the person filling the role is trustworthy and properly trained. The second distributes the functions among more
than one person, so that any malicious activity would require collusion.
DocuSign Envelope ID: E2033666-E28F-43CE-A3EA-F785452EF1C4
DocuSign Inc
DocuSign Certificate Policy for External CA
33
Public
Customer is responsible to define and documented trusted roles and associated operation. Customer shall define trusted
to manage RA and Trusted Agent shall be formally appointed by senior manager.
5.2.2 NUMBER OF PERSONS REQUIRED PER TASK
Two or more persons are required for the following tasks:
CA and RCA key generation;
CA and RCA signing key activation;
CA and RCA private key backup.
Customer should appoint and define role to make at least a separation between personal in charge of RA services (Trusted
Agent) and personal in charge of RA software to proceed the following operation; configuration, installation, backup,
maintain and recovery. DSA box configuration and backup shall require 2 distinct persons in trusted roles. Customer
repository shall be under control of trusted roles approved by Customer.
5.2.3 IDENTIFICATION AND AUTHENTICATION FOR EACH ROLE
An individual in a trusted role shall identify and authenticate him/herself before being permitted to perform any actions set
forth above for that role or identity.
5.2.4 ROLES REQUIRING SEPARATION OF DUTIES
Role separation, when required as set forth below, may be enforced either by the RA, CA and RCA equipment, or
procedurally, or by both means.
Segregation of duties is defined in CPS and may be enforced using PKI equipment, procedures or both. PKI component
employees are individually appointed to trusted roles for operations defined in section 5.2.1 and 5.2.2 above.
5.3 PERSONNEL CONTROLS
5.3.1 BACKGROUND, QUALIFICATIONS, EXPERIENCE, & SECURITY CLEARANCE
REQUIREMENTS
DocuSign and Customer shall identify the set of individuals assigned to primary and secondary trusted roles, who are
responsible and accountable for the operation of each CA, RCA, and RA in that Entity.
All persons filling trusted roles shall be selected on the basis of loyalty, trustworthiness, and integrity and shall be subject
to a background investigation. Personnel appointed to trusted roles shall:
Have successfully completed an appropriate training program;
Have demonstrated the ability to perform their duties;
Be trustworthy;
Have no other duties that would interfere or conflict with their duties for the trusted role;
Have not been previously relieved of duties for reasons of negligence or nonperformance of duties;
Have not been denied a security clearance, or had a security clearance revoked for cause;
Have not been convicted of a felony offense; and
Be appointed in writing by an approving authority.
5.3.2 BACKGROUND CHECK PROCEDURES
DocuSign Envelope ID: E2033666-E28F-43CE-A3EA-F785452EF1C4
DocuSign Inc
DocuSign Certificate Policy for External CA
34
Public
Trusted Role Personnel (primary and secondary) shall, at a minimum, pass a background investigation covering the
following areas:
Employment;
Education;
Current place of residence;
Law Enforcement; and
References.
The period of investigation must cover at least the last five years for each area. Regardless of the date of award, the highest
educational degree shall be verified.
Adjudication of the background investigation shall be performed according local law of the country where person live.
If a formal clearance or other check is the basis for background check, the background refresh shall be in accordance with
the corresponding formal clearance or other check. Otherwise, the background check shall be refreshed every ten years.
5.3.3 TRAINING REQUIREMENTS
All trusted roles shall receive comprehensive training in all operational duties they are expected to perform. Training shall
cover the following:
Security principles and mechanisms applicable to the trusted role
All PKI software versions in use by the trusted role
All duties the trusted role is expected to perform
Disaster recovery and business continuity procedures
Documentation shall be maintained identifying all personnel who received training and the level of training completed. Where
competence was demonstrated in lieu of training, supporting documentation shall be maintained.
5.3.4 RETRAINING FREQUENCY AND REQUIREMENTS
Individuals in trusted roles shall be aware of changes in the PKI operation. Any significant change to the operations shall
have a training (awareness) plan, and the execution of such plan shall be documented. Examples of such changes are CA
software or hardware upgrade, changes in automated security systems, and relocation of equipment.
Documentation shall be maintained identifying all personnel who received training and the level of training completed.
5.3.5 JOB ROTATION FREQUENCY AND SEQUENCE
No stipulation.
5.3.6 SANCTIONS FOR UNAUTHORIZED ACTIONS
The DS PMA shall take appropriate actions where personnel have performed actions not authorized in this CP.
The Customer shall take appropriate actions where personnel have performed actions not authorized in this CP.
5.3.7 INDEPENDENT CONTRACTOR REQUIREMENTS
Contractor personnel employed to perform trusted role functions shall meet the personnel requirements set forth in Section
5.3 as applicable.
DocuSign Envelope ID: E2033666-E28F-43CE-A3EA-F785452EF1C4
DocuSign Inc
DocuSign Certificate Policy for External CA
35
Public
5.3.8 DOCUMENTATION SUPPLIED TO PERSONNEL
For the RA, RCA and CAs, documentation sufficient to define duties and procedures for each trusted role shall be provided
to the personnel filling that role. The documentation and procedures shall include the applicable portions of the CP and
CPS, relevant policies or contracts, and manuals as applicable.
5.4 AUDIT LOGGING PROCEDURES
Audit log files shall be generated for all events relating to the security of the CAs, RCA and RAs. For CAs operated in a
virtual machine environment (VME, For purposes of this policy, the definition of a virtual machine environment does not
include cloud-based solutions (e.g., platform-as-a-server) or container type solutions (e.g., Docker), which are not permitted
for any CA cross-certified with TSCP.), audit logs shall be generated for all applicable events on both the virtual machine
(VM) and isolation kernel. (i.e., hypervisor).
Where possible, the security audit logs shall be automatically collected. Where this is not possible, a logbook, paper form,
or other physical mechanism shall be used. All security audit logs, both electronic and non-electronic, shall be retained and
made available during compliance audits and per Section 5.5.2.
5.4.1 TYPES OF EVENTS RECORDED
Audit log files are generated by DS OA and PMA for all events related to security and PKI services.
Audit log files are generated for all events related to security and PKI services. Where possible, security audit logs shall be
automatically collected. Where this is not possible, a logbook, paper form, or other physical mechanism shall be used. All
security audit logs, both electronic and non-electronic, shall be retained and made available during compliance audits. Each
event related to certificate life cycle is logged in such a way that it can be attributed to the person that performed it.
Logging will include the following topics:
Physical facility access.
Trusted roles management.
Logical access.
Backup management.
Log management.
Data from the authentication process for Subscribers and PKI components.
Date, time, phone number used, persons spoken to, and end results of verification telephone calls.
Acceptance and rejection of certificate requests.
Certificate creation.
Certificate renewal.
HSM management.
Key creation, use and destruction.
Activation data management.
Role management.
IT and network management, as they pertain to the PKI systems.
PKI documentation management.
Security management (Successful and unsuccessful PKI system access attempts, PKI and security system actions
performed, Security profile changes, System crashes, hardware failures and other anomalies, Firewall and router
activities; and entries to and exits from the DS OA facility).
At minimum, each audit record includes the following (either recorded automatically or manually for each auditable event):
DocuSign Envelope ID: E2033666-E28F-43CE-A3EA-F785452EF1C4
DocuSign Inc
DocuSign Certificate Policy for External CA
36
Public
Type of event.
Trusted date and time the event occurred.
Result of the event: success or failure where appropriate.
Identity of the entity and/or operator that caused the event.
Identity for which the event is addressed.
Cause of the event.
Customer for its RA activity shall record the following:
Information used to verify the Subscriber identity.
Subscriber Certificate.
DSA box log.
Customer CPS.
Person with a Trusted role.
Access to RA equipment.
RA IT logs.
5.4.2 LOG PROCESSING FREQUENCY
CA and RA audit logs shall be reviewed regularly (at least every quarter), except for RCA where the review shall be
performed the longer between each month and when the system is activated.
Such reviews involve verifying that the log has not been tampered with, and then briefly inspecting log entries, with a more
thorough investigation of any alerts or irregularities in the log. Examples of irregularities include discontinuities in the logs
and loss of audit data.
A statistically significant set of security audit data generated by RA, CA and RCA since the last review shall be examined,
as well as a reasonable search for any evidence of malicious activity. Actions taken as a result of these reviews shall be
documented.
A DS OA trusted role shall explain all significant events in an audit log summary.
Customer is responsible to review its log regularly especially for Customer repository, to check the accuracy and validity of
Subscriber information used by RA and to detect Certificate that has been issued for Subscriber that are not any more
authorized to be issued certificate, and use of DSA box and its backup.
5.4.3 RETENTION PERIOD FOR AUDIT LOGS
Records related to PKI operation are held on the site, at least one month, before being archived.
5.4.4 PROTECTION OF AUDIT LOG
CA, RCA, RA system configuration and procedures must be implemented together to ensure that:
Only personnel assigned to Trusted Roles have read access to the logs;
Only authorized people may archive audit logs; and,
Audit logs are not modified.
Event logs are protected in such a way that only authorized users can access them.
Events are logged in such a way that they cannot be easily deleted or destroyed (except for transfer to long term media)
within the period of time that they are required to be held.
DocuSign Envelope ID: E2033666-E28F-43CE-A3EA-F785452EF1C4
DocuSign Inc
DocuSign Certificate Policy for External CA
37
Public
Event logs are protected in such a way so as to remain readable for the duration of their storage period.
Practice Note: If a system over-writes audit logs after a given time, the audit log is not considered deleted or destroyed if
the audit log has been backed up and archived.
5.4.5 AUDIT LOG BACKUP PROCEDURES
Audit logs and audit summaries shall be backed up regularly with a reasonable frequency, except for RCA where the backup
shall be performed the longer between monthly and when the system is activated.
Audit logs and audit summaries are backed up via enterprise backup mechanisms, under the control of authorized trusted
roles, separated from their component source generation. Audit log backups are protected with the same level of trust
defined for the original logs. RCA and CA have offsite backup. It is not mandatory for Customer.
5.4.6 AUDIT COLLECTION SYSTEM (INTERNAL VS. EXTERNAL)
The audit log collection system may or may not be external to the CA, RCA, or RA system. Automated audit processes shall
be invoked at system (or application) startup and cease only at system (or application) shutdown. Should it become apparent
that an automated audit system has failed, and the integrity of the system or confidentiality of the information protected by
the system is at risk, then the Customer or DS PMA shall determine whether to suspend its operation until the problem is
remediated.
5.4.7 NOTIFICATION TO EVENT-CAUSING SUBJECT
This CP imposes no requirement to provide notice that an event was audited to the individual, organization, device, or
application that caused the event.
5.4.8 VULNERABILITY ASSESSMENTS
For RCA, CA and RA, trusted roles in charge of conducting audit and roles in charge of realizing PKI system operation
explain all significant events in an audit log summary. Such reviews involve verifying that the log has not been tampered
with, there is no discontinuity or other loss of audit data, and then briefly inspecting all log entries, with a more thorough
investigation of any alerts or irregularities in the logs. Actions taken as a result of these reviews are documented.
For vulnerability, the following rules apply for DS OA and Customer:
Implement detection and prevention controls to protect PKI systems against viruses and malicious software.
Document and follow a vulnerability correction process that addresses the identification, review, response, and
remediation of vulnerabilities.
Undergo or perform a vulnerability scan on RA interface of Customer repository and interface to communicate with
DS OA (external IP address) and CA interface (internal and external IP address).
Undergo a penetration test on the PKI’s systems on; at least an annual basis and after infrastructure or application
upgrades or modifications that the PMA determine as significant for CA and on regular basis for Customer for RA.
Record evidence that each vulnerability scan and penetration test was performed by a person or entity (or collective
group thereof) with the skills, tools, proficiency, code of ethics, and independence necessary to provide a reliable
vulnerability or penetration test; and
Track and remediate vulnerabilities according to enterprise cybersecurity policies and risk mitigation methodology.
5.5 RECORDS ARCHIVAL
DocuSign Envelope ID: E2033666-E28F-43CE-A3EA-F785452EF1C4
DocuSign Inc
DocuSign Certificate Policy for External CA
38
Public
CA, RCA and RA archive records shall be sufficiently detailed as to verify that the PKI was properly operated as well as
verify the validity of any certificate (including those revoked or expired) issued by the CA and RCA.
5.5.1 TYPES OF RECORDS ARCHIVED
At a minimum, the following data shall be recorded by DS OA for archive:
CP and CPS: 7 years.
Contract with Customer: 7 years.
Technical logs (IT system, physical access …): one year.
Audit report: 7 years.
PKI equipment software: 7 years.
RCA, CA and Subscriber Certificates: 7 years.
Trusted role record: 7 years.
Customer for its RA activity shall keep the logs during:
Information used to verify the Subscriber identity: within Subscriber employment period as defined by Customer
according local law and at least until Certificate is still valid.
Subscriber Certificate: until Certificate is still valid years.
DSA box log: 1 year inside DSA box.
Customer CPS: until end of service.
Person with a Trusted role: 5 years.
Access to RA equipment: 1 year.
RA IT logs : 1 year.
5.5.2 ARCHIVE RETENTION PERIOD
The minimum retention period for archived data is defined in section 5.5.1 above. The PMA and Customer decide, according
the archive owner, to delete or keep all or part of the archives at the end of the retention period of each archive.
If the original media cannot retain the data for the required period, a mechanism to transfer the archived data to new media
shall be defined by the archive site.
5.5.3 ARCHIVE PROTECTION
The archives are created in such a way that they cannot be easily deleted or destroyed within their defined retention period.
Archive protection ensures that only authorized people can access them.
Archives are held in a manner that ensures integrity, authenticity and confidentiality of data.
5.5.4 ARCHIVE BACKUP PROCEDURES
The CPS or a referenced document shall describe how the records are backed up and how the archive backups are
managed.
5.5.5 REQUIREMENTS FOR RECORD TIME-STAMPING
Time stamping services for PKI are not mandatory.
The records and log data have a trusted time defined by the PKI. Details are given in section 6.8 below.
DocuSign Envelope ID: E2033666-E28F-43CE-A3EA-F785452EF1C4
DocuSign Inc
DocuSign Certificate Policy for External CA
39
Public
5.5.6 ARCHIVE COLLECTION SYSTEM (INTERNAL OR EXTERNAL)
The archive collection system is compliant with security requirements defined in section 5.4.6.
5.5.7 PROCEDURES TO OBTAIN AND VERIFY ARCHIVE INFORMATION
Media storing PKI archive information are verified upon creation. Periodically, statistical samples of archived information
are tested to check the continued integrity and readability of the information.
Only authorized trusted roles personnel are allowed to access archives.
5.6 KEY CHANGEOVER
To minimize risk from compromise of a RCA and CA’s private signing key, that key may be changed often; from that time
on, only the new key will be used for certificate signing purposes. The older, but still valid, public key will be available to
verify old signatures until all of the certificates signed using the associated private key have also expired. If the old private
key is used to sign CRLs that cover certificates signed with that key, then the old key must be retained and protected.
A CA cannot generate a Certificate for a Subscriber whose validity period would be longer than the CA Certificate validity
period. The CA key pair shall be changed prior to the end of the validity period of the CA certificate in time to ensure that
no certificate issued by the CA asserts a validity period that extends beyond the validity period of the CA certificate.
A RCA cannot generate a Certificate for a CA whose validity period would be longer than the RCA Certificate validity period.
The RCA key pair shall be changed prior to the end of the validity period of the RCA certificate in time to ensure that no
certificate issued by the RCA asserts a validity period that extends beyond the validity period of the RCA certificate.
After a CA or RCA performs a Key Changeover, the CA or RCA continue to issue CRLs with the old key until all certificates
signed with that key have expired. As soon as a new key pair is generated for the CA, only the new private key is used to
sign Subscriber certificates.
The Subscriber private key validity period is defined in compliance with cryptographic security recommendations for key
size length. The Subscriber certificate validity period is defined in this CP (refer to section 6). Subscriber shall only use
private key to sign document with a non-expired Certificate.
5.7 COMPROMISE AND DISASTER RECOVERY
5.7.1 INCIDENT AND COMPROMISE HANDLING PROCEDURES
If a CA or RCA detects a potential penetration it shall perform an investigation to determine the nature and extent of damage.
If a CA or RCA key is suspected of compromise, the procedures in Section 5.7.3 shall be followed. Otherwise, the damage
shall be assessed to determine if the remediation required will be to rebuild the impacted servers, revoke a set of certificates,
and/or declare a CA or RCA key compromise.
The DS PMA shall be notified if any of the following incidents occur:
suspected or detected compromise of the RCA or CA systems;
physical or electronic attempts to penetrate RCA or CA systems;
denial of service attacks on RCA or CA components;
any incident preventing the RCA or CA from issuing a CRL within 24 hours of the time specified in the next update
field of its currently valid CRL.
This will allow member entities to protect their interests as Relying Parties.
DocuSign Envelope ID: E2033666-E28F-43CE-A3EA-F785452EF1C4
DocuSign Inc
DocuSign Certificate Policy for External CA
40
Public
DS OA shall reestablish operational capabilities as quickly as possible in accordance with procedures set forth in the CPS
for RCA and CA.
DS PMA shall provide notice to the Customer as soon as possible after investigation of the following;
suspected or detected compromise of an RCA or CA system;
physical or electronic attempts to penetrate the RCA or CA system or systems;
denial of service attacks on RCA or CA components;
any incident preventing the CA from issuing a CRL within 24 hours of the time specified in the next update field of
its currently valid CRL.
If a RA component (for Customer) detects a potential hacking attempt or other form of compromise, it performs an
investigation in order to determine the nature and the degree of damage. The scope of potential damage is assessed by
the Customer in order to determine if the RA needs to be rebuilt, if only some certificates need to be revoked, and/or if the
RA has been compromised. In addition, the Customer determines which services are to be maintained and how, in
accordance with the Customer business continuity plan. Customer shall alert PMA in case of RA compromission as soon
as investigation is ended.
5.7.2 COMPUTING RESOURCES, SOFTWARE, AND/OR DATA ARE CORRUPTED
When CA or RCA computing resources, software, and/or data are corrupted, the CA or RCA shall respond as follows:
If the CA or RCA signature keys are not destroyed, CA or RCA operation shall be re-established, giving priority to
the ability to generate certificate status information (CRL);
Before returning to operation, ensure that the system’s integrity has been restored;
If a CA or RCA cannot issue a CRL prior to the time specified in the next update field of its currently valid CRL, then
all CAs that have been issued Certificates by the CA or RCA shall be securely notified immediately.
If the ability to revoke Certificates is damaged, the CA or RCA shall re-establish revocation capabilities as quickly
as possible in accordance with procedures set forth in the applicable CPS.
If the RCA’s or CA’s revocation capability cannot be recovered in a reasonable timeframe, the CA or RCA shall
determine whether the request revocation of its Certificate(s). Root CA shall determine whether to notify all
Subscribers that use the CA as a trust anchor to no longer trust the Root CA as a trust anchor.
In the event of an incident as described above, the DS PMA shall alert impacted Customer. See Section 5.7.1 for contents
of the notice.
If RA equipment is damaged or rendered inoperative or corrupted, but technical signature keys, used by RA to communicate
with CA, are not destroyed and not corrupted, the operation is re-established as quickly as possible, with priority given to
the ability to generate certificate status information. In particular:
If the RA signature technical keys are not destroyed and not corrupted, RA operation shall be re-established, giving
priority to the ability to generate revocation request;
Before returning to operation, ensure that the system’s integrity has been restored;
If a RA cannot issue a revocation request prior 24H00 after recent revocation request registered by RA, then DS
PMA shall be securely notified immediately.
If the ability to revoke Certificates is damaged, the RA shall re-establish revocation capabilities as quickly as
possible in accordance with procedures set forth in the applicable contract with DocuSign.
If investigation reveals some Subscriber data in the RA repository are corrupted, then RA shall interrupt immediately
the Certificate request issuance. RA shall investigate to determine which Subscriber data are corrupted and if they
have been used to issue Subscriber’s Certificate. If it is case, Customer shall immediately inform DS PMA and
proceed to revocation request for all impacted Subscriber Certificate.
DocuSign Envelope ID: E2033666-E28F-43CE-A3EA-F785452EF1C4
DocuSign Inc
DocuSign Certificate Policy for External CA
41
Public
5.7.3 PRIVATE KEY COMPROMISE PROCEDURES
If a CA or RCA signature key is compromised or lost (such that compromise or loss is possible even though not certain):
The DS PMA shall securely notify the Customer;
A new CA or RCA key pair shall be generated by the CA in accordance with procedures set forth in the applicable
CPS;
As RCA distributes its key in a self-signed certificate (e.g. Root CA), the new self-signed certificate shall be
distributed as specified in Section 6.1.4.;
The DS PMA governing body shall also investigate what caused the compromise or loss, and what measures shall
be taken to preclude recurrence.
If a RA signature key, used to communicate with CA, is compromised or lost (such that compromise or loss is possible even
though not certain):
The RA certificate shall be revoked immediately by CA;
A new RA key pair shall be generated according to the applicable CPS;
A new RA certificate shall be requested according to the applicable CPS;
All Certificate requests approved by the RA since the data of the suspected compromise shall be reviewed to identify
inappropriate certificate lifecycle actions which were a result of the compromise;
For actions that are identified as inappropriate or for which it is uncertain whether an action was appropriate or not,
the resulting active Certificates shall be revoked and the subjects shall be notified of both the inappropriate action(s)
and revocation event(s).
5.7.4 BUSINESS CONTINUITY CAPABILITIES AFTER A DISASTER
For DocuSign OA and Customer, the business continuity plan addresses all necessary operations as described in section
Error! Reference source not found. to 5.7.3 above.
5.8 CA, RCA & RA TERMINATION
In the event that an CA or RCA terminates operation, the DS PMA shall:
Whenever possible, provide notice to the Customer at least two months, which notice period will begin to run upon
the notice is transmitted to Customer, prior to termination of any CA or RCA. For emergency termination, RCAs
shall follow the notification procedures in Section 5.7.
The CA, RCA, and RA shall archive all audit logs and records prior to termination.
The CA, RCA, and RA shall destroy all of its private keys upon termination.
The CA, RCA, and RA shall transfer all archive records to DS PMA.
If a Root CA is terminated, the Customer shall use secure means to notify the Subscribers to delete all trust anchors
(self-signed Root CA).
6 TECHNICAL SECURITY CONTROLS
6.1 KEY PAIR GENERATION AND INSTALLATION
6.1.1 KEY PAIR GENERATION
6.1.1.1 RCA
DocuSign Envelope ID: E2033666-E28F-43CE-A3EA-F785452EF1C4
DocuSign Inc
DocuSign Certificate Policy for External CA
42
Public
After the DS PMA agrees to the generation of the RCA, a key pair and RCA certificate are generated for the RCA.
The operation of the RCA key pair and RCA certificate generation is video-recorded and performed according to a key
ceremony script.
The HSM used for the key ceremony is compliant with requirements defined in section 6.2.1 below.
RCA key pair generation is undertaken and witnessed in a physically secure environment (refer to section 5.1.1. above) by
personnel in trusted roles (refer to section 5.2 above) under at least dual supervision. Private Key activation data are
distributed to activation data holders that are trusted employees. RCA key generation is carried out within a hardware
security module (refer to section 6.2 below). During the key ceremony, the RCA key pair is backed up (refer to section 6.2.
below).
The key pair and certificate generation process shall create a verifiable audit trail that the security requirements for
procedures were followed. The documentation of the procedure shall be detailed enough to show that appropriate role
separation was used. An independent third party shall validate the process.
6.1.1.2 CA: DOCUSIGN GENERIC CA
After the DS PMA agrees to the generation of the CA, a key pair and CSR are generated for the CA.
The operation of the CA key pair and CSR generation is video-recorded and performed according to a key ceremony script.
The HSM used for the key ceremony is compliant with requirements defined in section 6.2.1 below.
CA key pair generation is undertaken in a physically secure environment (refer to section 5.1.1 above) by personnel in
trusted roles (refer to section 5.2 above) under at least dual supervision. Private Key activation data are distributed to
activation data holders that are trusted employees. CA key generation is carried out within a hardware security module
(refer to section 6.2 below). During the key ceremony, the CA key pair is backed up (refer to section 6.2. below).
After key ceremony, CA key pair are securely transferred to HSM (refer to section 6.2.6.3 below) in the online environment
(refer to section 5.1.1. above).
The key pair and certificate generation process shall create a verifiable audit trail that the security requirements for
procedures were followed. The documentation of the procedure shall be detailed enough to show that appropriate role
separation was used.
6.1.1.3 : SUSCRIBER
RA shall request generation of the Subscriber signature key pair to the DSA box. The generation is performed using a DSA
Box (refer to section 6.2.11 below). The generation shall be performed in such a way as to avoid compromising the private
key and associated activation data and avoid non required signature operation. The private key shall be protected with the
associated activation data of the Subscriber.
6.1.2 PRIVATE KEY DELIVERY TO SUBSCRIBER
RA generates keys on behalf of the Subscriber and the private key are not delivered to the Subscriber. Private keys of
Subscriber are stored in the DSA Box to centrally generates, stores, uses, backup and destroys all Subscriber key pairs.
6.1.3 PUBLIC KEY DELIVERY TO CERTIFICATE ISSUER
6.1.3.1 CA: DOCUSIGN GENERIC CA
DocuSign Envelope ID: E2033666-E28F-43CE-A3EA-F785452EF1C4
DocuSign Inc
DocuSign Certificate Policy for External CA
43
Public
CA public keys are securely delivered to the relevant RCA for certificate issuance during key ceremonies (for PKI set-up)
or during the registration process (refer to section 4.1 and 4.2 above). The delivery mechanism binds CA checked identities
to the public keys to be certified using the Pkcs#10 format.
6.1.3.2 SUBSCRIBER
RA sings a certificate request containing the pubic of Subscriber to be certified by CA and transmits using TLS mutual
authentication with CA.
6.1.4 CA PUBLIC KEY DELIVERY TO RELYING PARTIES
Refer to section 2 above for downloading the RCA and CA certificate and section 10 below to use technical URL to download
RCA and CA certificate.
6.1.5 KEY SIZES
If the security of a particular algorithm becomes compromised, the DS PMA may require CAs or RCA to revoke affected
certificates (Subscriber or CA), according to the terms of the applicable Customer contract.
All certificates, CRL and cryptographic network protocols (e.g. TLS) materially relied on or issued by the PKI shall use the
following key sizes and algorithms:
Cryptographic Function
Expires 1/1/2011 - 12/31/2030
Expires after 12/31/2030
Signing (per FIPS 186-3)
2048 bit RSA
Or
224 bit prime field or 233 bit binary
field ECDSA
3072 bit RSA
Or
256 bit prime field or 283 bit binary
field ECDSA
Asymmetric Encryption (Per
PKCS1 for RSA and per 800 - 56A for
ECDH)
2048 bit RSA
Or
224 bit prime field or 233 bit binary
field ECDH
3072 bit RSA
Or
256 bit prime field or 283 bit binary
field ECDH
Symmetric Encryption
3 Key TDES or AES
AES
The hashing algorithm used for certificates and CRL shall meet the following minimum requirements:
Scope
Issued 1/1/2011 - 12/31/2030
Issued after 12/31/2030
RCA, CA and Subscriber Certificates
SHA-224 or SHA-256
SHA-256
CRL issued by CA and RCA
SHA-224 or SHA-256
SHA-256
CRLs shall use the same or better signature algorithm, key size, and hash algorithm used for the certificate that is being
validated.
6.1.6 PUBLIC KEY PARAMETERS GENERATION AND QUALITY CHECKING
RSA keys and prime numbers shall be generated and tested in accordance with FIPS 186-3.
ECDSA and ECDH keys shall be generated in accordance with FIPS 186-3. Curves in FIPS 186-3 shall be used.
RCA, CA and Subscriber keys are generated in accordance with the cryptography tools of the hardware security modules
(refer to section 6.2.11 below).
6.1.7 KEY USAGE PURPOSES (AS PER X.509 V3 KEY USAGE FIELD)
DocuSign Envelope ID: E2033666-E28F-43CE-A3EA-F785452EF1C4
DocuSign Inc
DocuSign Certificate Policy for External CA
44
Public
The use of a specific key for RCA, CA and Subscriber are determined by the keyUsage and Extended key usage (only for
Subscriber) extension in the X.509 Certificate. The Certificate Profiles in section Error! Reference source not found.
below specify the allowable values for this extension for different types of Certificates defined under this CP. Extended key
usage OIDs shall be consistent with the key usage bits set. Subscriber Certificate is only used for digital signature operation
and not for authentication (TLS) or encryption.
Public keys that are bound into certificates shall not be certified for use in encrypting.
6.2 PRIVATE KEY PROTECTION AND CRYPTOGRAPHIC MODULE ENGINEERING
CONTROLS
6.2.1 CRYPTOGRAPHIC MODULE STANDARDS AND CONTROLS
Key pairs are generated and stored within an HSM or a token that is certified according to the rating specified in section
6.2.11 below.
6.2.2 PRIVATE KEY MULTI-PERSON CONTROL
6.2.2.1 RCA
The RCA implements technical and procedural mechanisms that require the participation of multiple trusted individual
authorizations to perform sensitive RCA cryptographic operations.
6.2.2.2 CA: DOCUSIGN GENERIC CA
The CA implements technical and procedural mechanisms that require the participation of multiple trusted individual
authorizations to perform sensitive CA cryptographic operations.
6.2.2.3 SUBSCRIBER
The RA implements technical and procedural mechanisms that require the participation of multiple trusted individual
authorizations to perform sensitive DSA Box cryptographic configuration.
Subscriber’s key pair is activated after successful authentication of the Subscriber using its activation data according
consent protocol defined in DSA Box.
6.2.3 PRIVATE KEY ESCROW
Under no circumstances shall a RCA, CA and Subscriber private key be escrowed by any PKI component or third party.
6.2.4 PRIVATE KEY BACKUP
6.2.4.1 RCA
The RCA private signature keys shall be backed-up under the same multi-person control as the RCA operational signature
operation. All back-up copy of the signature key shall be stored in the RCA off-site location (refer to section 5.1.8 above)
and the number of back-up copy is controlled by trusted roles.
DocuSign Envelope ID: E2033666-E28F-43CE-A3EA-F785452EF1C4
DocuSign Inc
DocuSign Certificate Policy for External CA
45
Public
6.2.4.2 CA: DOCUSIGN GENERIC CA
CA private signature keys shall be backed-up under the same multi-person control as the operational ones. All back-up
copy of the signature key shall be stored in the CA off-site location (refer to section 5.1.8 above) and the number of back-
up copy is controlled by trusted roles.
6.2.4.3 SUBSCRIBER
Subscriber private signature keys may be copied in another identical DSA Box protected with same secret as the initial one
(refer to section 6.2.2 above) for redundancy only. Storage and usage of the Subscriber private key copy must ensure
security controls consistent with the protection provided by the Subscriber’s cryptographic module. Backed up subscriber
private signature keys shall not be stored in plain text form outside the cryptographic module. Backup file of the Subscriber
key pair shall be stored under dual control.
Subscriber key are still protected and usable with same subscriber activation data.
6.2.5 PRIVATE KEY ARCHIVAL
RCA, CA and Subscriber private keys shall not be archived.
6.2.6 PRIVATE KEY TRANSFER INTO OR FROM A CRYPTOGRAPHIC MODULE
6.2.6.1 RCA
In case of private key transfer, then the RCA key pair is transferred to another Hardware Security Module (HSM) of the
same specification as described in section 6.2.1 above, by direct token-to-token copy or via a trusted transfer under N out
of M multi-person control (Refer to section 6.2.2 above).
RCA keys are generated, activated and stored in HSMs or in an encrypted format. When they are not stored onto HSMs,
RCA private keys are encrypted. An encrypted RCA private key cannot be decrypted without using an HSM with the required
trusted role (activation data holder), and must be performed in the presence of multiple persons in trusted roles.
6.2.6.2 CA: DOCUSIGN GENERIC CA
In case of private key transfer, then the CA key pair is transferred to another Hardware Security Module (HSM) of the same
specification as described in section 6.2.1 above, by direct token-to-token copy or via a trusted transfer under N out of M
multi-person control (Refer to section 6.2.2 above).
CA keys are generated, activated and stored in HSMs or in an encrypted format. When they are not stored onto HSMs,
private keys are encrypted. An encrypted private key cannot be decrypted without using an HSM with the required trusted
role (activation data holder), and must be performed in the presence of multiple persons in trusted roles.
6.2.6.3 SUBSCRIBER
In case of private key transfer, then the Subscriber key pair is transferred to another DSA Box of the same specification as
described in section 6.2.1 above, by direct token-to-token copy or via a trusted transfer under N out of M multi-person control
(Refer to section 6.2.2 above).
DocuSign Envelope ID: E2033666-E28F-43CE-A3EA-F785452EF1C4
DocuSign Inc
DocuSign Certificate Policy for External CA
46
Public
Subscriber keys are generated, activated and stored in DSA Box or in an encrypted format. When they are not stored onto
DSA Boxs, private keys are encrypted. An encrypted private key cannot be decrypted without using an DSA Box with the
required trusted role (activation data holder), and must be performed in the presence of multiple persons in trusted roles.
6.2.7 PRIVATE KEY STORAGE ON CRYPTOGRAPHIC MODULE
6.2.7.1 RCA
The HSM may store Private Keys in any form as long as the keys are not accessible without authentication mechanisms
that are compliant with the ones mentioned in the security policy attached to the HSM approved use and the present CP
section 6.2.
6.2.7.2 CA: DOCUSIGN GENERIC CA
The HSM may store Private Keys in any form as long as the keys are not accessible without authentication mechanisms
that are compliant with the ones mentioned in the security policy attached to the HSM approved use and the present CP
section 6.2.
6.2.7.3 SUBSCRIBER
The HSM may store Private Keys in any form as long as the keys are not accessible without authentication mechanisms
that are compliant with the ones mentioned in the security policy attached to the HSM approved use and the present CP
section 6.2.
6.2.8 METHOD OF ACTIVATING PRIVATE KEY
6.2.8.1 RCA
Activation of the RCA’s HSM, to sign and/or revoke CA certificates, requires several trusted roles with activation data to
activate the RCA private key. Each trusted role is authenticated before activating a RCA private key.
6.2.8.2 CA: DOCUSIGN GENERIC CA
Several trusted roles with activation data are required to realize the initial activation of the HSM that contains the key pair
corresponding to the CA certificate. Once the HSM containing the CA key are operational, only the authorized services of
the PKI system can use the CA key pair within the HSM.
6.2.8.3 SUBSCRIBER
Subscriber key pair is activated according the DSA Box consent protocol. Consent protocol shall require a technical
activation data (password of minimum 8 characters minimum with a standard complexity).
6.2.9 METHOD OF DEACTIVATING PRIVATE KEY
6.2.9.1 RCA
An activated RCA HSM is never left unattended or otherwise available to unauthorized access. After use, the HSMs are
deactivated. The HSMs are removed from RCA component and stored in secure locations (refer to section 5.1 above) to
DocuSign Envelope ID: E2033666-E28F-43CE-A3EA-F785452EF1C4
DocuSign Inc
DocuSign Certificate Policy for External CA
47
Public
avoid their use without authorization and strongly authenticated roles. After deactivation, the use of the HSM based RCA
key pair shall require the presence of the trusted roles with the activation data in order to reactivate said RCA key pair (refer
to section Error! Reference source not found. above).
6.2.9.2 CA: DOCUSIGN GENERIC CA
HSM that has been activated is never left unattended or otherwise available to unauthorized access.
After use, HSM are deactivated. After deactivation, the use of the HSM based CA key pair shall require the presence of the
trusted roles with the activation data in order to reactivate said CA key pair (refer to section Error! Reference source not
found. above).
The HSM automatically deactivate the HSM if there is an incident.
6.2.9.3 SUBSCRIBER
DSA box that has been activated is never left unattended or otherwise available to unauthorized access.
When a DSA Box is not used anymore, DSA Box is deactivated. Before deactivation of the DSA Box, all Subscriber key
pair shall be destroyed requiring the presence of the trusted roles with the activation data.
Subscriber’s key pair is used to sign document during a transaction with DSA Box and after each signature, Subscriber key
pair is deactivated and requires activation again by Subscriber with activation data of Subscriber to use it again.
6.2.10 METHOD OF DESTROYING PRIVATE KEY
6.2.10.1 RCA
Destroying RCA private key inside an HSM requires destroying the key(s) inside the HSM using the zeroization function of
the HSM in a manner that any information cannot be used to recover any part of the private key. All the RCA private key
back-ups have to be destroyed in a manner that any information cannot be used to recover any part of the private key. If
the functions of HSM are not accessible in order to destroy the key contained inside, then the HSM has to be physically
destroyed.
The destruction operation is realized in a physically secure environment (refer to section 5.1 above) by personnel in trusted
roles (refer to section 5.2 above) under at least dual control.
6.2.10.2 CA: DOCUSIGN GENERIC CA
Destroying CA private key inside an HSM requires destroying the key(s) inside the HSM using the zeroization function of
the HSM in a manner that any information cannot be used to recover any part of the private key. All the CA private key
back-ups have to be destroyed in a manner that any information cannot be used to recover any part of the private key. If
the functions of HSM are not accessible in order to destroy the key contained inside, then the HSM has to be physically
destroyed.
The destruction operation is realized in a physically secure environment (refer to section 5.1 above) by personnel in trusted
roles (refer to section 5.2 above) under at least dual control.
6.2.10.3 SUBSCRIBER
DocuSign Envelope ID: E2033666-E28F-43CE-A3EA-F785452EF1C4
DocuSign Inc
DocuSign Certificate Policy for External CA
48
Public
Destroying Subscriber private key inside an DSA Box requires destroying the key(s) inside the DSA Box using the
zeroization function of the DSA Box in a manner that any information cannot be used to recover any part of the private key.
By default it is the RA which request the destruction of Subscriber key pair in the DSA box due to renewal of Certificate or
end of issuance of Certificate to Subscriber.
All the Subscriber private key back-ups have to be destroyed in a manner that any information cannot be used to recover
any part of the private key. If the functions of DSA Box are not accessible in order to destroy the key contained inside, then
the DSA Box has to be physically destroyed.
The destruction operation is realized in a physically secure environment (refer to section 5.1 above) by personnel in trusted
roles (refer to section 5.2 above) under at least dual control.
6.2.11 CRYPTOGRAPHIC MODULE RATING
The Hardware Security Module used to generate RCA and CA key pairs is at least approved in accordance with FIPS 140
- 2 Level 3 standard or EAL4+ Common Criteria equivalent. DSA Box may be FIPS certified, but it is not mandatory.
6.3 OTHER ASPECTS OF KEY PAIR MANAGEMENT
6.3.1 PUBLIC KEY ARCHIVAL
The public key is archived as part of the certificate archival.
6.3.2 CERTIFICATE OPERATIONAL PERIODS/KEY USAGE PERIODS
See Section 5.6.
The Certificate validity period is given in section 10.
6.4 ACTIVATION DATA
6.4.1 ACTIVATION DATA GENERATION AND INSTALLATION
6.4.1.1 RCA
RCA activation data used to protect HSM containing RCA private keys are generated during the initial key ceremony. The
activation data used to unlock private keys, in conjunction with any other access control, shall have an appropriate level of
strength for the keys or data to be protected and shall meet the applicable security policy requirements of the cryptographic
module used to store the keys.
The DS PMA appointed individuals shall receive their activation data during the key ceremony through a face to face
meeting. Creation and distribution of activation data are logged. The activation data are never transmitted by any other
means.
6.4.1.2 CA: DOCUSIGN GENERIC CA
CA activation data used to protect HSM containing CA private keys are generated during the initial PKI key ceremony. The
activation data used to unlock private keys, in conjunction with any other access control, shall have an appropriate level of
strength for the keys or data to be protected and shall meet the applicable security policy requirements of the cryptographic
module used to store the keys.
DocuSign Envelope ID: E2033666-E28F-43CE-A3EA-F785452EF1C4
DocuSign Inc
DocuSign Certificate Policy for External CA
49
Public
The DS PMA, appointed individuals shall receive their activation data during the key ceremony through a face-to-face
meeting. Creation and distribution of activation data are logged. The activation data are never transmitted by any other
means.
6.4.1.3 SUBSCRIBER
DSA Box activation data used to protect DSA Box containing Subscriber private keys are generated during the initial DSA
Box ceremony. The activation data used to protect use of DSA Box and backup of DSA Box and transfer between DSA
Box, in conjunction with any other access control, shall have an appropriate level of strength for the keys or data to be
protected and shall meet the applicable security policy requirements of the cryptographic module used to store the keys.
The Customer, appointed individuals shall receive their activation data during the DSA Box ceremony through a face-to-
face meeting. Creation and distribution of activation data are logged. The activation data are never transmitted by any other
means.
This activation data to use Subscriber Key pair is generated either by Subscriber according the Customer security policy for
its IT system.
6.4.2 ACTIVATION DAT