GlobalSign
Certificate Policy

Date: March 28, 2023
Version: v7.0

Table of Contents
TABLE OF CONTENTS ................................................................................................................................ 2
CHANGES ................................................................................................................................................. 8
ACKNOWLEDGMENTS .............................................................................................................................. 9
1.0

INTRODUCTION ...........................................................................................................................10

1.1
OVERVIEW ........................................................................................................................................ 11
1.1.1
Certificate Naming ................................................................................................................. 12
1.2
DOCUMENT NAME AND IDENTIFICATION ................................................................................................. 14
1.3
PKI PARTICIPANTS .............................................................................................................................. 22
1.3.1
Certification Authorities (“Issuer CAs”) .................................................................................. 22
1.3.2
Registration Authorities ......................................................................................................... 22
1.3.3
Subscribers ............................................................................................................................. 23
1.3.4
Relying Parties ....................................................................................................................... 23
1.3.5
Other Participants .................................................................................................................. 23
1.4
CERTIFICATE USAGE ............................................................................................................................ 23
1.4.1
Appropriate Certificate Usage ............................................................................................... 23
1.4.2
Prohibited Certificate Usage .................................................................................................. 23
1.5
POLICY ADMINISTRATION ..................................................................................................................... 24
1.5.1
Organization Administering the Document ........................................................................... 24
1.5.2
Contact Person ....................................................................................................................... 24
1.5.3
Person Determining CP Suitability for the Policy ................................................................... 24
1.5.4
CP Approval Procedures ......................................................................................................... 25
1.6
DEFINITIONS AND ACRONYMS ............................................................................................................... 25
2.0
2.1
2.2
2.3
2.4
3.0

PUBLICATION AND REPOSITORY RESPONSIBILITIES .....................................................................34
REPOSITORIES .................................................................................................................................... 34
PUBLICATION OF CERTIFICATE INFORMATION ........................................................................................... 34
TIME OR FREQUENCY OF PUBLICATION.................................................................................................... 34
ACCESS CONTROLS ON REPOSITORIES ..................................................................................................... 34
IDENTIFICATION AND AUTHENTICATION .....................................................................................34

3.1
NAMING ........................................................................................................................................... 35
3.1.1
Types of Names...................................................................................................................... 35
3.1.2
Need for Names to be Meaningful ........................................................................................ 35
3.1.3
Anonymity or Pseudonymity of Subscribers ........................................................................... 35
3.1.4
Rules for Interpreting Various Name Forms .......................................................................... 35
3.1.5
Uniqueness of Names ............................................................................................................ 35
3.1.6
Recognition, Authentication, and Role of Trademarks .......................................................... 35
3.2
INITIAL IDENTITY VALIDATION................................................................................................................ 35
3.2.1
Method to Prove Possession of Private Key ........................................................................... 35
3.2.2
Authentication of Organization Identity ................................................................................ 35
3.2.3
Authentication of Individual identity ..................................................................................... 37
3.2.4
Non-Verified Subscriber Information ..................................................................................... 39
3.2.5
Validation of Authority .......................................................................................................... 40
3.2.6
Criteria for Interoperation ..................................................................................................... 41
3.2.7
Authentication of Domain Names ......................................................................................... 41
3.2.8
Authentication of IP Addresses .............................................................................................. 41
3.2.9
Authentication of Email Addresses ........................................................................................ 41
3.3
IDENTIFICATION AND AUTHENTICATION FOR RE-KEY REQUESTS.................................................................... 42
3.3.1
Identification and Authentication for Routine Re-key ........................................................... 42
3.3.2
Identification and Authentication for Re-key After Revocation ............................................. 42
3.4
IDENTIFICATION AND AUTHENTICATION FOR REVOCATION REQUEST ............................................................. 42

GlobalSign CP (Certificate Policy)
Version: 7.0

2 of 77

4.0

CERTIFICATE LIFE CYCLE OPERATIONAL REQUIREMENTS .............................................................42

4.1
CERTIFICATE APPLICATION .................................................................................................................... 42
4.1.1
Who Can Submit a Certificate Application ............................................................................. 42
4.1.2
Enrollment Process and Responsibilities ................................................................................ 42
4.2
CERTIFICATE APPLICATION PROCESSING .................................................................................................. 42
4.2.1
Performing Identification and Authentication Functions ....................................................... 42
4.2.2
Approval or Rejection of Certificate Applications .................................................................. 43
4.2.3
Time to Process Certificate Applications ................................................................................ 43
4.3
CERTIFICATE ISSUANCE ........................................................................................................................ 43
4.3.1
CA Actions during Certificate Issuance .................................................................................. 43
4.3.2
Notifications to Subscriber by the CA of Issuance of Certificate ............................................ 43
4.4
CERTIFICATE ACCEPTANCE .................................................................................................................... 43
4.4.1
Conduct Constituting Certificate Acceptance ........................................................................ 43
4.4.2
Publication of the Certificate by the CA ................................................................................. 43
4.4.3
Notification of Certificate Issuance by the CA to Other Entities ............................................ 43
4.5
KEY PAIR AND CERTIFICATE USAGE......................................................................................................... 43
4.5.1
Subscriber Private Key and Certificate Usage ........................................................................ 43
4.5.2
Relying Party Public Key and Certificate Usage ..................................................................... 44
4.6
CERTIFICATE RENEWAL ........................................................................................................................ 44
4.6.1
Circumstances for Certificate Renewal .................................................................................. 44
4.6.2
Who May Request Renewal ................................................................................................... 44
4.6.3
Processing Certificate Renewal Requests .............................................................................. 45
4.6.4
Notification of New Certificate Issuance to Subscriber .......................................................... 45
4.6.5
Conduct Constituting Acceptance of a Renewal Certificate ................................................... 45
4.6.6
Publication of the Renewal Certificate by the CA .................................................................. 45
4.6.7
Notification of Certificate Issuance by the CA to Other Entities ............................................ 45
4.7
CERTIFICATE RE-KEY ........................................................................................................................... 45
4.7.1
Circumstances for Certificate Re-Key ..................................................................................... 45
4.7.2
Who May Request Certification of a New Public Key ............................................................ 45
4.7.3
Processing Certificate Re-Keying Requests ............................................................................ 45
4.7.4
Notification of New Certificate Issuance to Subscriber .......................................................... 45
4.7.5
Conduct Constituting Acceptance of a Re-Keyed Certificate ................................................. 45
4.7.6
Publication of the Re-Keyed Certificate by the CA ................................................................. 45
4.7.7
Notification of Certificate Issuance by the CA to Other Entities ............................................ 45
4.8
CERTIFICATE MODIFICATION ................................................................................................................. 45
4.8.1
Circumstances for Certificate Modification ........................................................................... 45
4.8.2
Who May Request Certificate Modification........................................................................... 45
4.8.3
Processing Certificate Modification Requests ........................................................................ 46
4.8.4
Notification of New Certificate Issuance to Subscriber .......................................................... 46
4.8.5
Conduct Constituting Acceptance of Modified Certificate ..................................................... 46
4.8.6
Publication of the Modified Certificate by the CA .................................................................. 46
4.8.7
Notification of Certificate Issuance by the CA to Other Entities ............................................ 46
4.9
CERTIFICATE REVOCATION AND SUSPENSION ............................................................................................ 46
4.9.1
Circumstances for Revocation ............................................................................................... 46
4.9.2
Who Can Request Revocation ................................................................................................ 48
4.9.3
Procedure for Revocation Request......................................................................................... 48
4.9.4
Revocation Request Grace Period .......................................................................................... 49
4.9.5
Time Within Which CA Must Process the Revocation Request .............................................. 49
4.9.6
Revocation Checking Requirements for Relying Parties ........................................................ 49
4.9.7
CRL Issuance Frequency ......................................................................................................... 49
4.9.8
Maximum Latency for CRLs ................................................................................................... 50
4.9.9
On-Line Revocation/Status Checking Availability .................................................................. 50
4.9.10 On-Line Revocation Checking Requirements ......................................................................... 50
4.9.11 Other Forms of Revocation Advertisements Available .......................................................... 50
4.9.12 Special Requirements Related to Key Compromise ............................................................... 51
4.9.13 Circumstances for Suspension ............................................................................................... 51
GlobalSign CP (Certificate Policy)
Version: 7.0

3 of 77

4.9.14 Who Can Request Suspension ................................................................................................ 51
4.9.15 Procedure for Suspension Request......................................................................................... 51
4.9.16 Limits on Suspension Period .................................................................................................. 51
4.10 CERTIFICATE STATUS SERVICES .............................................................................................................. 51
4.10.1 Operational Characteristics ................................................................................................... 51
4.10.2 Service Availability ................................................................................................................. 51
4.10.3 Operational Features ............................................................................................................. 52
4.11 END OF SUBSCRIPTION......................................................................................................................... 52
4.12 KEY ESCROW AND RECOVERY ................................................................................................................ 52
4.12.1 Key Escrow and Recovery Policy and Practices ...................................................................... 52
4.12.2 Session Key Encapsulation and Recovery Policy and Practices .............................................. 52
5.0

FACILITY, MANAGEMENT, AND OPERATIONAL CONTROLS ..........................................................52

5.1
PHYSICAL CONTROLS ........................................................................................................................... 52
5.1.1
Site Location and Construction .............................................................................................. 52
5.1.2
Physical Access....................................................................................................................... 52
5.1.3
Power and Air Conditioning ................................................................................................... 52
5.1.4
Water Exposures .................................................................................................................... 52
5.1.5Fire Prevention and Protection .............................................................................................. 52
5.1.6
Media Storage ....................................................................................................................... 52
5.1.7
Waste Disposal ...................................................................................................................... 53
5.1.8
Off-Site Backup ...................................................................................................................... 53
5.2
PROCEDURAL CONTROLS ...................................................................................................................... 53
5.2.1
Trusted Roles ......................................................................................................................... 53
5.2.2
Number of Persons Required per Task ................................................................................... 53
5.2.3
Identification and Authentication for Each Role .................................................................... 53
5.2.4
Roles Requiring Separation of Duties..................................................................................... 54
5.3
PERSONNEL CONTROLS ........................................................................................................................ 54
5.3.1
Qualifications, Experience, and Clearance Requirements...................................................... 54
5.3.2
Background Check Procedures ............................................................................................... 54
5.3.3
Training Requirements........................................................................................................... 54
5.3.4
Retraining Frequency and Requirements ............................................................................... 55
5.3.5
Job Rotation Frequency and Sequence .................................................................................. 55
5.3.6
Sanctions for Unauthorized Actions ....................................................................................... 55
5.3.7
Independent Contractor Requirements ................................................................................. 55
5.3.8
Documentation Supplied to Personnel................................................................................... 55
5.4
AUDIT LOGGING PROCEDURES .............................................................................................................. 55
5.4.1
Types of Events Recorded ...................................................................................................... 55
5.4.2
Frequency of Processing Log .................................................................................................. 56
5.4.3
Retention Period for Audit Log .............................................................................................. 56
5.4.4
Protection of Audit Log .......................................................................................................... 56
5.4.5
Audit Log Backup Procedures ................................................................................................ 56
5.4.6
Audit Collection System ......................................................................................................... 56
5.4.7
Notification to Event-Causing Subject ................................................................................... 57
5.4.8
Vulnerability Assessments ..................................................................................................... 57
5.5RECORDS ARCHIVAL ............................................................................................................................ 57
5.5.1
Types of Records Archived ..................................................................................................... 57
5.5.2
Retention Period for Archive .................................................................................................. 57
5.5.3
Protection of Archive ............................................................................................................. 57
5.5.4
Archive Backup Procedures .................................................................................................... 57
5.5.5
Requirements for Timestamping of Records .......................................................................... 57
5.5.6
Archive Collection System (Internal or External) .................................................................... 57
5.5.7
Procedures to Obtain and Verify Archive Information ........................................................... 57
5.6
KEY CHANGEOVER .............................................................................................................................. 58
5.7
COMPROMISE AND DISASTER RECOVERY ................................................................................................. 58
5.7.1
Incident and Compromise Handling Procedures .................................................................... 58
5.7.2
Computing Resources, Software, and/or Data Are Corrupted ............................................... 58
GlobalSign CP (Certificate Policy)
Version: 7.0

4 of 77

5.7.3
Issuing CA Private Key Compromise Procedures .................................................................... 58
5.7.4
Business Continuity Capabilities After a Disaster .................................................................. 58
5.8
CA OR RA TERMINATION ..................................................................................................................... 58
5.8.1
Successor Issuing Certification Authority ............................................................................... 59
6.0

TECHNICAL SECURITY CONTROLS.................................................................................................59

6.1
KEY PAIR GENERATION AND INSTALLATION .............................................................................................. 59
6.1.1
Key Pair Generation ............................................................................................................... 59
6.1.2
Private Key Delivery to Subscriber ......................................................................................... 60
6.1.3
Public Key Delivery to Certificate Issuer ................................................................................. 60
6.1.4
CA Public Key Delivery to Relying Parties ............................................................................... 60
6.1.5
Key Sizes................................................................................................................................. 60
6.1.6
Public Key Parameters Generation and Quality Checking ..................................................... 61
6.1.7
Key Usage Purposes (as per X.509 v3 Key Usage Field) ......................................................... 61
6.2
PRIVATE KEY PROTECTION AND CRYPTOGRAPHIC MODULE ENGINEERING CONTROLS ....................................... 61
6.2.1
Cryptographic Module Standards and Controls ..................................................................... 61
6.2.2
Private Key (n out of m) Multi-Person Control ....................................................................... 62
6.2.3
Private Key Escrow ................................................................................................................. 62
6.2.4
Private Key Backup ................................................................................................................ 62
6.2.5
Private Key Archival ............................................................................................................... 62
6.2.6
Private Key Transfer into or from a Cryptographic Module ................................................... 62
6.2.7
Private Key Storage on Cryptographic Module ...................................................................... 62
6.2.8
Method of Activating Private Key .......................................................................................... 62
6.2.9
Method of Deactivating Private Key ...................................................................................... 62
6.2.10 Method of Destroying Private Key ......................................................................................... 62
6.2.11 Cryptographic Module Rating ................................................................................................ 62
6.3
OTHER ASPECTS OF KEY PAIR MANAGEMENT........................................................................................... 62
6.3.1
Public Key Archival ................................................................................................................. 62
6.3.2
Certificate Operational Periods and Key Pair Usage Periods ................................................. 63
6.4
ACTIVATION DATA .............................................................................................................................. 63
6.4.1
Activation Data Generation and Installation ......................................................................... 63
6.4.2
Activation Data Protection .................................................................................................... 63
6.4.3
Other Aspects of Activation Data .......................................................................................... 63
6.5
COMPUTER SECURITY CONTROLS ........................................................................................................... 64
6.5.1
Specific Computer Security Technical Requirements ............................................................. 64
6.5.2
Computer Security Rating ...................................................................................................... 64
6.6
LIFE CYCLE TECHNICAL CONTROLS .......................................................................................................... 64
6.6.1
System Development Controls ............................................................................................... 64
6.6.2
Security Management Controls ............................................................................................. 64
6.6.3
Life Cycle Security Controls .................................................................................................... 65
6.7
NETWORK SECURITY CONTROLS ............................................................................................................ 65
6.8
TIMESTAMPING .................................................................................................................................. 65
7.0

CERTIFICATE, CRL, AND OCSP PROFILES .......................................................................................65

7.1
CERTIFICATE PROFILE........................................................................................................................... 65
7.1.1
Version Number(s) ................................................................................................................. 65
7.1.2
Certificate Extensions ............................................................................................................ 65
7.1.3
Algorithm Object Identifiers .................................................................................................. 65
7.1.4
Name Forms........................................................................................................................... 65
7.1.5
Name Constraints .................................................................................................................. 66
7.1.6
Certificate Policy Object Identifier ......................................................................................... 66
7.1.7
Usage of Policy Constraints Extension ................................................................................... 66
7.1.8
Policy Qualifiers Syntax and Semantics ................................................................................. 66
7.1.9
Processing Semantics for the Critical Certificate Policies Extension ...................................... 66
7.1.10 Serial Numbers....................................................................................................................... 66
7.1.11 Special Provisions for Qualified Certificates ........................................................................... 66
7.2
CRL PROFILE ..................................................................................................................................... 67
GlobalSign CP (Certificate Policy)
Version: 7.0

5 of 77

7.2.1
Version Number(s) ................................................................................................................. 67
7.2.2
CRL and CRL Entry Extensions ................................................................................................ 67
7.3
OCSP PROFILE................................................................................................................................... 67
7.3.1
Version Number(s) ................................................................................................................. 67
7.3.2
OCSP Extensions..................................................................................................................... 67
8.0
8.1
8.2
8.3
8.4
8.5
8.6
8.7
9.0

COMPLIANCE AUDIT AND OTHER ASSESSMENTS .........................................................................67
FREQUENCY AND CIRCUMSTANCES OF ASSESSMENT .................................................................................. 67
IDENTITY/QUALIFICATIONS OF ASSESSOR ................................................................................................ 67
ASSESSOR’S RELATIONSHIP TO ASSESSED ENTITY....................................................................................... 68
TOPICS COVERED BY ASSESSMENT.......................................................................................................... 68
ACTIONS TAKEN AS A RESULT OF DEFICIENCY ........................................................................................... 68
COMMUNICATIONS OF RESULTS ............................................................................................................ 68
SELF-AUDIT ....................................................................................................................................... 68
OTHER BUSINESS AND LEGAL MATTERS ......................................................................................68

9.1
FEES................................................................................................................................................. 68
9.1.1
Certificate Issuance or Renewal Fees ..................................................................................... 68
9.1.2
Certificate Access Fees ........................................................................................................... 68
9.1.3
Revocation or Status Information Access Fees ...................................................................... 68
9.1.4
Fees for Other Services .......................................................................................................... 69
9.1.5
Refund Policy ......................................................................................................................... 69
9.2
FINANCIAL RESPONSIBILITY ................................................................................................................... 69
9.2.1
Insurance Coverage ............................................................................................................... 69
9.2.2
Other Assets ........................................................................................................................... 69
9.2.3
Insurance or Warranty Coverage for End Entities ................................................................. 69
9.3
CONFIDENTIALITY OF BUSINESS INFORMATION ......................................................................................... 69
9.3.1
Scope of Confidential Information ......................................................................................... 69
9.3.2
Information Not Within the Scope of Confidential Information ............................................ 69
9.3.3
Responsibility to Protect Confidential Information ................................................................ 69
9.4
PRIVACY OF PERSONAL INFORMATION .................................................................................................... 69
9.4.1
Privacy Plan ........................................................................................................................... 69
9.4.2
Information Treated as Private .............................................................................................. 69
9.4.3
Information Not Deemed Private........................................................................................... 69
9.4.4
Responsibility to Protect Private Information ........................................................................ 70
9.4.5
Notice and Consent to Use Private Information .................................................................... 70
9.4.6
Disclosure Pursuant to Judicial or Administrative Process ..................................................... 70
9.4.7
Other Information Disclosure Circumstances ........................................................................ 70
9.5
INTELLECTUAL PROPERTY RIGHTS ........................................................................................................... 70
9.6
REPRESENTATIONS AND WARRANTIES..................................................................................................... 70
9.6.1
CA Representations and Warranties ...................................................................................... 70
9.6.2
RA Representations and Warranties...................................................................................... 72
9.6.3
Subscriber Representations and Warranties ......................................................................... 72
9.6.4
Relying Party Representations and Warranties ..................................................................... 74
9.6.5
Representations and Warranties of Other Participants......................................................... 75
9.7
DISCLAIMERS OF WARRANTIES .............................................................................................................. 75
9.8
LIMITATIONS OF LIABILITY..................................................................................................................... 75
9.8.1
Exclusion of Certain Elements of Damages ............................................................................ 75
9.9
INDEMNITIES ..................................................................................................................................... 75
9.9.1
Indemnification by an Issuer CA............................................................................................. 75
9.9.2
Indemnification by Subscribers .............................................................................................. 75
9.9.3
Indemnification by Relying Parties ........................................................................................ 75
9.10 TERM AND TERMINATION..................................................................................................................... 75
9.10.1 Term ....................................................................................................................................... 75
9.10.2 Termination ........................................................................................................................... 75
9.10.3 Effect of Termination and Survival......................................................................................... 76
9.11 INDIVIDUAL NOTICES AND COMMUNICATIONS WITH PARTICIPANTS .............................................................. 76
GlobalSign CP (Certificate Policy)
Version: 7.0

6 of 77

9.12 AMENDMENTS ................................................................................................................................... 76
9.12.1 Procedure for Amendment .................................................................................................... 76
9.12.2 Notification Mechanism and Period ...................................................................................... 76
9.12.3 Circumstances Under Which OID Must be Changed .............................................................. 76
9.13 DISPUTE RESOLUTION PROCEDURES ....................................................................................................... 76
9.14 GOVERNING LAW ............................................................................................................................... 76
9.15 COMPLIANCE WITH APPLICABLE LAW...................................................................................................... 77
9.16 MISCELLANEOUS PROVISIONS ............................................................................................................... 77
9.16.1 Entire Agreement ................................................................................................................... 77
9.16.2 Assignment ............................................................................................................................ 77
9.16.3 Severability ............................................................................................................................ 77
9.16.4 Enforcement (Attorney’s Fees and Waiver of Rights) ............................................................ 77
9.16.5 Force Majeure ........................................................................................................................ 77
9.17 OTHER PROVISIONS ............................................................................................................................ 77

GlobalSign CP (Certificate Policy)
Version: 7.0

7 of 77

Changes
The following revisions have been made compared to previous version:
•
•
•
•
•
•
•
•
•
•

Updated naming of "PSD2" certificates to "Open Banking"Updates for CA/B Forum ballots CSC-13 and CSC-17
Revision of OIDs
Removed requirement of digitally signing this document for release
Clarified “subject uniqueness”
Included RA as a role in the notification and revocation process
Review of audit logging and records archival sections
Review of private key protection and cryptographic module engineering section
Clarified revocation limitations of short-term certificates
Grammatical updates, language consistency

GlobalSign CP (Certificate Policy)
Version: 7.0

8 of 77

Acknowledgments
GlobalSign® and the GlobalSign Logo are registered trademarks of GMO GlobalSign K.K.

GlobalSign CP (Certificate Policy)
Version: 7.0

9 of 771.0 Introduction
This Certificate Policy (CP) applies to the products and services of GlobalSign NV/SA and affiliatedentities (“GlobalSign”). Primarily, this pertains to the issuance and lifecycle management ofCertificates including validity checking services. GlobalSign may also provide additional services
such as timestamping. This CP may be updated from time to time as outlined in Section 1.5, Policy
Administration. The latest version may be found on the GlobalSign group company repository
https://www.globalsign.com/repository. (Alternative languages versions may be available to aid
Relying Parties and Subscribers in their understanding of this CP, however, in the event of any
inconsistency, the English version shall control).
A CP is a "named set of rules that indicates the applicability of a Digital Certificate to a particularcommunity and/or class of application with common security requirements.” This CP meets theformal requirements of Internet Engineering Task Force (IETF) RFC 3647, dated November 2003
with regard to content, layout and format (RFC 3647 obsoletes RFC 2527). An RFC issued by IETF
is an authoritative source of guidance with regard to standard practices in the area of Electronic
Signatures and Certificate management. While certain section titles are included in this policy
according to the structure of RFC 3647, the topic may not necessarily apply to services of
GlobalSign. These sections have ‘No stipulation’ appended. Where necessary, additional
information is presented in subsections to the standard structure. Meeting the format requirementsof RFC 3647 enhances and facilitates the mapping and interoperability with other third party CAs
and provides Relying Parties with advance notice of GlobalSign’s practices and procedures.
This CP aims to comply with the requirements of:
•
•
•
•
•
•
•
•
•
•

Browsers’ root programs
RFC3647, Request for Comments: 3647, Internet X.509 Public Key Infrastructure:
Certificate Policy and Certification Practices Framework, Chokhani, et al, November 2003
North American Energy Standards Board (NAESB) Accreditation Requirements for
Authorized Certificate Authorities
WebTrust Principles and Criteria for Certification Authorities
WebTrust Principles and Criteria for Certification Authorities - SSL Baseline with Network
Security
WebTrust Principles and Criteria for Certification Authorities - Extended Validation SSL
WebTrust Principles and Criteria for Certification Authorities – Code Signing Baseline
Requirements
Regulation (EU) No 910/2014 of the European Parliament and of the Council of 23 July
2014 on electronic identification and trust services for electronic transactions in the internalmarket and repealing Directive 1999/93/EC
The Electronic Identification and Trust Services for Electronic Transactions (Amendmentetc.) (EU Exit) Regulations 2019)
The Electronic Identification and Trust Services for Electronic Transactions Regulation
2016 (2016 No.696))

This CP conforms to current versions of the requirements:••••

CA/Browser Forum Baseline Requirements for the Issuance and Management of
Publicly-Trusted Certificates (“Baseline Requirements”)
CA/Browser Forum Guidelines For The Issuance And Management Of Extended
Validation Certificates (“EV Guidelines”)
CA/Browser Forum Network and Certificate System Security Requirements
CA/Browser Forum Baseline Requirements for Code Signing (“Baseline Requirements for
Code Signing”)

published at http://www.cabforum.org. If there is any inconsistency between this document and theRequirements above, the Requirements take precedence over this document.
This CP addresses areas of policy and practice such as, but not limited to, technical requirements,
security procedures, personnel and training needs, which are required to meet industry bestpractices for Certificate lifecycle management. This CP applies to all Certificates issued by
GlobalSign CP (Certificate Policy)
Version: 7.0

10 of 77

GlobalSign including its Root Certificates and any chaining services to third party
Subordinate/Issuing CAs. Root Certificates are used to manage Certificate hierarchies through thecreation of one or more Subordinate CAs that may or may not be controlled directly by the same
entity that manages the Root Certificate itself.
This CP is applicable to the Subscriber and/or Relying Party, who uses, relies upon or attempts torely upon certification services made available by the Certification Authority referring to this CP.
The English version of this CP is the primary version. In the event of any conflict or inconsistency
between the English CP and any localized or translated version, the provisions of the English
version shall prevail.

1.1

Overview

This CP applies to the complete GlobalSign hierarchy of GlobalSign and all Certificates that it
issues either directly through its own systems, including self-signed Root Certificates and Key Pairs.
The purpose of this CP is to present GlobalSign’s practices and procedures in managing Root
Certificates and Issuing CAs in order to demonstrate compliance with formal industry accepted
accreditations such as WebTrust. Additionally, eIDAS Regulation (Regulation (EU)N910/2014)(“eIDAS”) and eIDAS (UK Legislation) and The Electronic Identification and Trust Services forElectronic Transactions Regulations 2016 (“UK eIDAS”) provide for the recognition of Electronic
Signatures that are used for the purposes of authentication or nonrepudiation. In this regard,
GlobalSign operates within the scope of the applicable sections of the Law when delivering its
services. Trust services for the United Kingdom are operated by and provided through GMO
GlobalSign LTD., an affiliate entity of GlobalSign.
This CP sets out the objectives, roles, responsibilities and practices of all entities involved in the
lifecycle of Certificates issued under this CP. In simple terms, a CP states “what is to be adhered
to,” setting out an operational rule framework for products and services.
A Certification Practice Statement (CPS) complements this CP and states, “how the Certification
Authority adheres to the Certificate Policy.” A CPS provides an end user with a summary of theprocesses, procedures and overall prevailing conditions that the Issuing CA (i.e. the entity which
provides the Subscriber its Certificate) will use in creating and managing such Certificates.
In addition to this CP and the CPS, GlobalSign maintains additional documented policies which
address such issues as:
•
•
•
•
•

Business continuity and disaster recovery
Security policy
Personnel policies
Key management policies
Registration procedures

Additionally, other relevant documents include:•••

The GlobalSign Warranty Policy that addresses issues on insurance;
The GlobalSign Privacy Policy on the protection of personal data; andThe GlobalSign Certification Practice Statement that addresses the methods and rules bywhich Certificates are delivered for the domain of the GlobalSign top roots.

All applicable GlobalSign policies are subject to audit by authorised third parties which GlobalSign
highlights on its public facing web site via a WebTrust Seal of Assurance. Additional information
can be made available upon request.

GlobalSign CP (Certificate Policy)
Version: 7.0

11 of 77

1.1.1

Certificate Naming

The GlobalSign Certificates governed by this CP are:GlobalSign Public Root CA Certificates
•
•
•

•
•
•

GlobalSign Root CA – R1 with fingerprint EBD41040E4BB3EC742C9E381D31EF2A41A48B6685C96E7CEF3C1DF6CD4331C99
GlobalSign Root CA – R3 with fingerprint CBB522D7B7F127AD6A0113865BDF1CD4102E7D0759AF635A7CF4720DC963C53B
GlobalSign Root CA – R5 with fingerprint 179FBC148A3DD00FD24EA13458CC43BFA7F59C8182D783A513F6EBEC100C8924
GlobalSign Root CA – R6 with fingerprint 2CABEAFE37D06CA22ABA7391C0033D25982952C453647349763A3AB5AD6CCF69
GlobalSign Root CA – R46 with fingerprint 4FA3126D8D3A11D1C4855A4F807CBAD6CF919D3A5A88B03BEA2C6372D93C40C9
GlobalSign Root CA – E46 with fingerprint CBB9C44D84B8043E1050EA31A69F514955D7BFD2E2C6B49301019AD61D9F5058

GlobalSign Public Non-TLS Root CA Certificates
•
•
•
•
•
•
•
•
•
•
•
•

GlobalSign Client Authentication Root R45 with fingerprint 165C7E810BD37C1D57CE9849ACCD500E5CB01EEA37DC550DB07E598AAD2474A8
GlobalSign Client Authentication Root E45 with fingerprint 8B0F0FAA2C00FE0532A8A54E7BC5FD139C1922C4F10F0B16E10FB8BE1A634964
GlobalSign Code Signing Root R45 with fingerprint 7B9D553E1C92CB6E8803E137F4F287D4363757F5D44B37D52F9FCA22FB97DF86
GlobalSign Code Signing Root E45 with fingerprint 26C6C5FD4928FD57A8A4C5724FDD279745869C60C338E262FFE901C31BD1DB2B
GlobalSign Document Signing Root R45 with fingerprint 38BE6C7EEB4547D82B9287F243AF32A9DEEB5DC5C9A87A0056F938D91B456A5A
GlobalSign Document Signing Root E45 with fingerprint F86973BDD0514735E10C1190D0345BF89C77E1C4ADBD3F65963B803FD3C9E1FF
GlobalSign Secure Mail Root R45 with fingerprint 319AF0A7729E6F89269C131EA6A3A16FCD86389FDCAB3C47A4A675C161A3F974
GlobalSign Secure Mail Root E45 with fingerprint 5CBF6FB81FD417EA4128CD6F8172A3C9402094F74AB2ED3A06B4405D04F30B19
GlobalSign Timestamping Root R45 with fingerprint 2BCBBFD66282C680491C8CD7735FDBBAB7A8079B127BEC60C535976834399AF7
GlobalSign Timestamping Root E46 with fingerprint 4774674B94B78F5CCBEF89FDDEBDABBD894A71B55576B8CC5E6876BA3EAB4538
GlobalSign IoT Root R60 with fingerprint 319AF0A7729E6F89269C131EA6A3A16FCD86389FDCAB3C47A4A675C161A3F974
GlobalSign IoT Root E60 with fingerprint 5CBF6FB81FD417EA4128CD6F8172A3C9402094F74AB2ED3A06B4405D04F30B19

The Root Certificates above are Public, WebTrust-audited certificates that are configured for non-TLS use, to cater to GlobalSign’s various product offerings.
GlobalSign actively promotes the inclusion of the Root Certificates above in hardware and software platforms that are capable of supporting Certificates andassociated cryptographic services according to the specified GlobalSign use case and applicable hardware/software trust bits. Where possible, GlobalSign willseek to enter into a contractual agreement with platform providers to ensure effective Root Certificate life cycle management. However, GlobalSign also actively
encourages platform providers at their own discretion to include GlobalSign Root Certificates without contractual obligation.

GlobalSign CP (Certificate Policy)
Version: 7.0

12 of 77

GlobalSign Non-public Root CA Certificates
•
•
•
•
•

GlobalSign Non-Public Root CA – R1 with fingerprint 8D2EEFC79397F86BD4DB5B16A84144156D7EE352B57DE36B2C4FC738081DF9C9GlobalSign Non-Public Root CA – R2 with fingerprint 24FD17248F3B76F82AF2FD9C57D60F3EF60551508EE98DC460FD3A67866ECCEA
GlobalSign Non-Public Root CA – R3 with fingerprint A3BB9A2462E728818A6D30548BD3950B8C8DAE1B63FC89FE66E10BB7BAB5725A
GlobalSign Trusted Platform Module Root CA with fingerprint F27BF02C6E00C73D915EEB6A6A2F5FBF0C31AE0393149E6B5C31E41B113841C3
GlobalSign Trusted Platform Module ECC Root CA with fingerprint 5A8C7B5EB888CFCE9322068E80E82B28B554FFEB7FDC9638DCB3763077401D26

GlobalSign actively promotes the inclusion of the Root Certificates above into hardware and software platforms that are capable of supporting Certificates andassociated cryptographic services. Where possible, GlobalSign will seek to enter into a contractual agreement with platform providers to ensure effective Root
Certificate lifecycle management. However, GlobalSign also actively encourages platform providers at their own discretion to include GlobalSign Root
Certificates without contractual obligation. Roots R2 & R4 are no longer owned by GlobalSign nv/sa.
Certificates allow entities that participate in an electronic transaction to prove their identity to other participants or sign data digitally. By means of a Certificate,a Certification Authority provides confirmation of the relationship between a named entity (Subscriber) and its Public Key.
The process to obtain a Certificate includes the identification, naming, authentication and registration of an Applicant as well as aspects of Certificate
management such as the issuance, revocation and expiration. By means of this policy, GlobalSign provides confirmation of the identity of the Subject of a
Certificate by binding the Public Key the Subscriber uses through the issuance of a Certificate. An entity in this instance might include an end user or another
Certification Authority. GlobalSign makes available Certificates that can be used for non-repudiation/contentCommitment, encryption and authentication. The
use of these Certificates can be further limited to a specific business or contractual context or transaction level in support of a warranty policy or other limitations
imposed by the applications that Certificates are used in.
GlobalSign accepts comments regarding this CP addressed to the address stated in Section 1.5, Policy Administration.

GlobalSign CP (Certificate Policy)
Version: 7.0

13 of 77

1.2

Document Name and Identification

This document is the GlobalSign Certificate Policy.
The OID for GlobalSign NV/SA (GlobalSign) is an iso (1) identified-organization (3) dod (6) internet(1) private (4) enterprise (1) GlobalSign (4146).
GlobalSign organizes its OID arcs for the various Certificates and documents described in this CP
as follows:
Category

OID

Description

TLS

1.3.6.1.4.1.4146.10.1

TLS Policies Arc

1.3.6.1.4.1.4146.10.1.1

Extended Validation TLS Policy

1.3.6.1.4.1.4146.10.1.2

Organization Validation TLS Policy

1.3.6.1.4.1.4146.10.1.3

Domain Validation TLS Policy

1.3.6.1.4.1.4146.10.2

Authentication Policies Arc

1.3.6.1.4.1.4146.10.2.1

Extended Validation Auth Policy

1.3.6.1.4.1.4146.10.2.2

Organization Validation Auth Policy

1.3.6.1.4.1.4146.10.2.3

Domain Validation Auth Policy

1.3.6.1.4.1.4146.10.2.4

Individual Validation Auth Policy

1.3.6.1.4.1.4146.10.3

S/MIME Policies Arc

1.3.6.1.4.1.4146.10.3.1

Organization Validation S/MIME Policy

1.3.6.1.4.1.4146.10.3.2

Sponsored Validation S/MIME Policy

1.3.6.1.4.1.4146.10.3.3

Mailbox Validation S/MIME Policy

1.3.6.1.4.1.4146.10.3.4

Individual Validation S/MIME Policy

1.3.6.1.4.1.4146.1.40.70

Client Certificates Policy (Email Protection)

1.3.6.1.4.1.4146.10.4

Code Signing Policies Arc

1.3.6.1.4.1.4146.10.4.1

Extended Validation Code Signing Policy

1.3.6.1.4.1.4146.10.4.2

Organization Validation Code Signing Policy

1.3.6.1.4.1.4146.10.5

Document Signing Policies Arc

Authentication

S/MIME

Code Signing

Document
SigningGlobalSign CP (Certificate Policy)
Version: 7.0

14 of 77

Category

OID

Description

Qualified

1.3.6.1.4.1.4146.1.40.36

eIDAS Qualified Certificates - QSCD

1.3.6.1.4.1.4146.1.40.36.1

Qualified Certificates for Electronic Signatures

Private key on QSCDManaged by Subscriber

1.3.6.1.4.1.4146.1.40.36.2

Qualified Certificates for Electronic Seals

Private key on QSCDManaged by Subscriber

1.3.6.1.4.1.4146.1.40.37

eIDAS Qualified Certificates – Non QSCD

1.3.6.1.4.1.4146.1.40.37.1

Qualified Certificates for Electronic Signatures

Private key not on QSCDManaged by Subscriber

1.3.6.1.4.1.4146.1.40.37.2

Qualified Certificates for Electronic Seals

Private key not on QSCDManaged by Subscriber

1.3.6.1.4.1.4146.1.40.37.3

Qualified Certificates for Electronic Seals - Open Banking

Private key not on QSCDManaged by Subscriber

1.3.6.1.4.1.4146.1.40.38

eIDAS Qualified Certificates – Remote QSCD

1.3.6.1.4.1.4146.1.40.38.1

Qualified Certificates for Electronic Signatures

Private key on QSCDManaged on behalf of Subscriber

1.3.6.1.4.1.4146.1.40.38.2

Qualified Certificates for Electronic Seals

Private key on QSCDManaged on behalf of Subscriber

1.3.6.1.4.1.4146.1.40.39

Qualified Certificates for Authentication

1.3.6.1.4.1.4146.1.40.39.1

Qualified Certificates for Authentication (Natural Persons)

1.3.6.1.4.1.4146.1.40.39.2

Qualified Certificates for Authentication (Legal Persons)

1.3.6.1.4.1.4146.1.40.39.3

Qualified Certificates for Website Authentication (QWAC)

1.3.6.1.4.1.4146.1.40.39.4

Qualified Certificates for Website Authentication (QWAC) – OpenBankingGlobalSign CP (Certificate Policy)
Version: 7.0

Private Key

15 of 77

Category

OID

Description

1.3.6.1.4.1.4146.1.40.41

eIDAS Qualified Certificates – Remote Non QSCD

1.3.6.1.4.1.4146.1.40.41.1

Qualified Certificates for Electronic Signatures

Private key not on QSCDManaged on behalf of Subscriber

1.3.6.1.4.1.4146.1.40.41.2

Qualified Certificates for Electronic Seals

Private key not on QSCDManaged on behalf of Subscriber

1.3.6.1.4.1.4146.1.44.36

UK eIDAS Qualified Certificates – QSCD

1.3.6.1.4.1.4146.1.44.36.1

Qualified Certificates for Electronic Signatures

Private key on QSCDManaged by Subscriber

1.3.6.1.4.1.4146.1.44.36.2

Qualified Certificates for Electronic Seals

Private key on QSCDManaged by Subscriber

1.3.6.1.4.1.4146.1.44.37

UK eIDAS Qualified Certificates – Non QSCD

1.3.6.1.4.1.4146.1.44.37.1

Qualified Certificates for Electronic Signatures

Private key not on QSCDManaged by Subscriber

1.3.6.1.4.1.4146.1.44.37.2

Qualified Certificates for Electronic Seals

Private key not on QSCDManaged by Subscriber

1.3.6.1.4.1.4146.1.44.37.3

Qualified Certificates for Electronic Seals - Open Banking

Private key not on QSCDManaged by Subscriber

1.3.6.1.4.1.4146.1.44.38

UK eIDAS Qualified Certificates – Remote QSCD

1.3.6.1.4.1.4146.1.44.38.1

Qualified Certificates for Electronic Signatures

Private key on QSCDManaged on behalf of Subscriber

1.3.6.1.4.1.4146.1.44.38.2

Qualified Certificates for Electronic Seals

Private key on QSCDManaged on behalf of Subscriber

1.3.6.1.4.1.4146.1.44.39

UK eIDAS Qualified Certificates for Authentication

1.3.6.1.4.1.4146.1.44.39.1

Qualified Certificates for Authentication (Natural Persons)

1.3.6.1.4.1.4146.1.44.39.2

Qualified Certificates for Authentication (Legal Persons)GlobalSign CP (Certificate Policy)
Version: 7.0

Private Key

16 of 77

Category

OID

Description

1.3.6.1.4.1.4146.1.44.40

UK eIDAS Qualified Certificates for Website Authentication (QWAC)

1.3.6.1.4.1.4146.1.44.40.1

Qualified Certificates for Website Authentication (QWAC)

1.3.6.1.4.1.4146.1.44.40.2

Qualified Certificates for Website Authentication (QWAC) – OpenBanking

1.3.6.1.4.1.4146.1.44.41

UK eIDAS Qualified Certificates – Remote Non QSCD

1.3.6.1.4.1.4146.1.44.41.1

Qualified Certificates for Electronic Signatures

Private key not on QSCDManaged on behalf of Subscriber

1.3.6.1.4.1.4146.1.44.41.2

Qualified Certificates for Electronic Seals

Private key not on QSCDManaged on behalf of Subscriber

GlobalSign CP (Certificate Policy)
Version: 7.0

Private Key

17 of 77

Category

OID

Description

Registration
Authorities

1.3.6.1.4.1.4146.1.45.1

LRA for Qualified certificates

1.3.6.1.4.1.4146.1.45.2

External RA for Qualified certificates

1.3.6.1.4.1.4146.1.30

Timestamping Certificates Policy

1.3.6.1.4.1.4146.1.31

Timestamping Certificates Policy – AATL

1.3.6.1.4.1.4146.1.32

Timestamping Certificate Policy – Certificates for Qualified Timestamping(QTS) under eIDAS regulation

1.3.6.1.4.1.4146.1.33

Timestamping Certificate Policy – Certificates for Qualified Timestamping(QTS) under UK eIDAS regulation

1.3.6.1.4.1.4146.1.34

Hosted Timestamping Certificates Policy

1.3.6.1.4.1.4146.1.35

Hosted Timestamping Certificates Policy – AATL

1.3.6.1.4.1.4146.2

Policy by which the timestamping services operated by GlobalSign
incorporates the time into IETF RFC 3161 responses

1.3.6.1.4.1.4146.2.2

Timestamping policy covering Timestamp Tokens (TST) issued under IETF
RFC 3161 with a Secure Hash Algorithm version 1 (SHA1)

1.3.6.1.4.1.4146.2.3

Timestamping policy covering Timestamp Tokens (TST) issued under IETF
RFC 3161 with a Secure Hash Algorithm version 2 (SHA2)

1.3.6.1.4.1.4146.2.3.1

Timestamping policy covering Timestamp Tokens (TST) issued under IETF
RFC 3161 with a Secure Hash Algorithm version 2 (SHA2) with R6 CA
hierarchy

1.3.6.1.4.1.4146.2.3.1.1

Trusted Timestamping policy covering Timestamp Tokens (TST) issued
under IETF RFC 3161 with a Secure Hash Algorithm version 2 (SHA2) withR6 CA hierarchy

1.3.6.1.4.1.4146.2.3.1.2

CodeSign Timestamping policy covering Timestamp Tokens (TST) issued
under IETF RFC 3161 with a Secure Hash Algorithm version 2 (SHA2) withR6 CA hierarchy

1.3.6.1.4.1.4146.2.4

Policy by which the time-stamping services operated by GlobalSign
incorporate the time into IETF RFC 3161 responses specifically for extended
validation code signing services

1.3.6.1.4.1.4146.2.6

JP Accredited Timestamping Tokens - AATL

1.3.6.1.4.1.4146.2.7

JP Accredited Timestamping Tokens - non-AATL

1.3.6.1.4.1.4146.1.40

Non-Generic use Certificates Policy

1.3.6.1.4.1.4146.1.40.20

Japan Certificate Authority Network (JCAN) Issuing CA Policy

1.3.6.1.4.1.4146.1.40.30

GlobalSign AATL Certificates Policy

1.3.6.1.4.1.4146.1.40.30.2

GlobalSign AATL Certificates Policy (Class 2)

1.3.6.1.4.1.4146.1.80

Retail Industry Electronic Data Interchange Client Certificate Policy

1.3.6.1.4.1.4146.1.81

Retail Industry Electronic Data Interchange Server Certificate Policy

1.3.6.1.4.1.4146.1.95

Online Certificate Status Protocol Policy

1.3.6.1.4.1.4146.3

GlobalSign's documents (such as Certificate Policy (CP) and Certification
Practice Statement (CPS))

1.3.6.1.4.1.4146.4

GlobalSign-specific certificate extensions Internet of Things (IoT)

Timestamping

Other Certificate
Policies

GlobalSign CP (Certificate Policy)
Version: 7.0

18 of 77

Private hierarchy

1.3.6.1.4.1.4146.5

GlobalSign Time Assessment policies

1.3.6.1.4.1.4146.5.1

GlobalSign Japan Accredited Time Assessment Service Policy

1.3.6.1.4.1.4146.11.1

Private Hierarchy Certificate Policy Arc

1.3.6.1.4.1.4146.11.1.1

Shared Customer Certificates Arc

1.3.6.1.4.1.4146.11.1.1.1

IntranetSSL

1.3.6.1.4.1.4146.11.1.1.2

IntranetSMIME

1.3.6.1.4.1.4146.11.1.1.3

Demo Certificates Policy – Should not be trusted as it may not containaccurate information. This is to be used for testing and integration purposes.

1.3.6.1.4.1.4146.11.1.2

GlobalSign Internal Certificates

1.3.6.1.4.1.4146.11.1.3

Customer Branded Certificates

GlobalSign CP (Certificate Policy)
Version: 7.0

19 of 77

Legacy OIDs
The following OIDs are marked as legacy and where applicable are being replaced with a newhierarchy indicated in the table above.
Category

OID

Description

TLS

1.3.6.1.4.1.4146.1.1

Extended Validation Certificates Policy – SSL - Legacy

1.3.6.1.4.1.4146.1.1.1

Qualified Certificates under eIDAS Regulation – Qualified Web Authentication
Certificates (QWAC) - Legacy

1.3.6.1.4.1.4146.1.1.2

Qualified Certificates under eIDAS Regulation – Qualified Web Authentication
Certificates (QWAC) – Open Banking - Legacy

1.3.6.1.4.1.4146.1.2

Extended Validation Certificates Policy – Code Signing - Legacy

1.3.6.1.4.1.4146.1.10

Domain Validation Certificates Policy - Legacy

1.3.6.1.4.1.4146.1.10.10

Domain Validation Certificates Policy – AlphaSSL - Legacy

1.3.6.1.4.1.4146.1.20

Organization Validation Certificates Policy - Legacy

1.3.6.1.4.1.4146.1.25

IntranetSSL Validation Certificates Policy - Legacy

1.3.6.1.4.1.4146.1.40.35

eIDAS Qualified Certificates (Generic) - Legacy

1.3.6.1.4.1.4146.1.40.35.1

Qualified Certificates for Electronic Seals (Legal Persons with QSCD) managed by Subscriber - Legacy

1.3.6.1.4.1.4146.1.40.35.1.1

Qualified Certificates for Electronic Seals (Legal Persons) - Open Banking Legacy

1.3.6.1.4.1.4146.1.40.35.2

Qualified Certificates for Electronic Signatures (Natural Persons with QSCD) managed by Subscriber – Legacy

1.3.6.1.4.1.4146.40.40.1

Qualified Certificates for Website Authentication (QWAC) – Legacy

1.3.6.1.4.1.4146.40.40.2

Qualified Certificates for Website Authentication (QWAC) – Open Banking Legacy

1.3.6.1.4.1.4146.1.50

Code Signing Certificates Policy (Certificates issued by GlobalSign containing
1.3.6.1.4.1.4146.1.50 are issued and managed in accordance with the Baseline
Requirements for Code Signing)

Authentication

1.3.6.1.4.1.4146.1.40.60

Client Certificates Policy (Client Authentication)

Client certificates

1.3.6.1.4.1.4146.1.40.10

Client Certificates Policy (EPKI – Enterprise PKI - Legacy)

1.3.6.1.4.1.4146.1.40.40

Client Certificates Policy (EPKI for private CAs - Legacy)

1.3.6.1.4.1.4146.1.40.50

Client Certificates Policy (Private Hierarchy - AEG - Legacy)

1.3.6.1.4.1.4146.1.26

Test Certificate Policy –Should not be trusted as it may not contain accurate
information. This is to be used for testing and integration purposes. (Legacy)

1.3.6.1.4.1.4146.1.70

High Volume CA Policy

1.3.6.1.4.1.4146.1.100

Internet of Things Device Certificates Policy (legacy)

Qualified

Code signing

OthersGlobalSign CP (Certificate Policy)
Version: 7.0

20 of 77

Community OIDs
Certificates that comply with the applicable community requirements will include one of the following
additional identifiers.
Community

OID

Description

CA/Browser
Forum

2.23.140.1.1

Extended Validation Certificate Policy

2.23.140.1.2.1

Domain Validation Certificates Policy

2.23.140.1.2.2

Organization Validation Certificates Policy

2.23.140.1.3

EV Code Signing Certificates Policy

2.23.140.1.4.1

Code Signing Minimum Requirements Policy

2.23.140.1.4.2

Code Signing Minimum Requirements Timestamping Policy

0.4.0.194112.1.0

QCP-n: certificate policy for EU qualified certificates issued to natural persons

0.4.0.194112.1.1

QCP-l: certificate policy for EU qualified certificates issued to legal persons

0.4.0.194112.1.2

QCP-n-qscd: certificate policy for EU qualified certificates issued to natural
persons with private key related to the certified public key in a QSCD

0.4.0.194112.1.3

QCP-l-qscd: certificate policy for EU qualified certificates issued to legal
persons with private key related to the certified public key in a QSCD

0.4.0.194112.1.4

QCP-w: certificate for EU qualified website certificate issued to a natural or alegal person and linking the website to that person

2.16.840.1.114505.1.12.1.2

NAESB Rudimentary Assurance

2.16.840.1.114505.1.12.2.2

NAESB Basic Assurance

2.16.840.1.114505.1.12.3.2

NAESB Medium Assurance

ETSI

NAESB

GlobalSign CP (Certificate Policy)
Version: 7.0

21 of 77

1.3

PKI Participants

1.3.1

Certification Authorities (“Issuer CAs”)

A Certification Authority (CA)’s primary responsibility is to perform tasks related to Public Key
Infrastructure (PKI) functions such as Certificate lifecycle management, Subscriber registration,
Certificate issuance, Certificate renewal, Certificate distribution and Certificate revocation.
Certificate status information may be provided using a Repository in the form of a Certificate
Revocation List (CRL) distribution point and/or Online Certificate Status Protocol (OCSP)
responder. A Certification Authority may also be described by the term “Issuing Authority” or “Issuer
CA” to denote its purpose of issuing Certificates at the request of a Registration Authority (RA) froma Subordinate CA which may or may not be managed by GlobalSign.
The GlobalSign Policy Authority, which is composed of members of the GlobalSign management
team and appointed by its Board of Directors, is responsible for maintaining this Certificate Policy
relating to all Certificates in the GlobalSign hierarchy. Through its Policy Authority, GlobalSign has
ultimate control over the lifecycle and management of the GlobalSign Root CA and any subsequent
Subordinate CAs belonging to the hierarchy.
Henceforth and for ease of reference all CAs issuing Certificates in accordance with this CP(including GlobalSign) shall be referred to as Issuing CAs.
Issuing CAs ensure the availability of all services relating to the management of Certificates issued.
Appropriate publication is necessary to ensure that Relying Parties obtain notice or knowledge of
revoked Certificates. Issuing CAs provide Certificate status information using a Repository in theform of a CRL distribution point and/or OCSP responder as indicated within the Certificate
properties.
1.3.2

Registration Authorities

In addition to identifying and authenticating Applicants for Certificates, a Registration Authority (RA)may also initiate or pass along revocation requests for Certificates and requests for renewal andre-key of Certificates.
Issuing CAs may act as a Registration Authority for Certificates they issue in which case they are
responsible for:
•
•
•
•
•
•

Accepting, evaluating, approving or rejecting the registration of Certificate applications;Registering Subscribers for certification services;
Providing systems to facilitate the identification of Subscribers (according to the type of
Certificate requested);
Using officially notarised or otherwise authorised documents or sources of information toevaluate and authenticate an Applicant’s application;
Requesting issuance of a Certificate via a multi-factor authentication process following theapproval of an application; andInitiating the process to revoke a Certificate from the applicable GlobalSign Subordinate
CA or partner Subordinate CA.

GlobalSign may delegate identity proofing and certificate lifecycle events to a third party, underconditions and if permitted by the applicable regulations, laws, industry standards and policies for
the Certificate.
Third parties who enter into a contractual relationship with GlobalSign may operate their own RA
and authorize the issuance of Certificates. Third parties must comply with all the requirements ofthis CP and the terms of their contract which may also refer to additional criteria as recommended
by the CA/B Forum. RAs may implement more restrictive vetting practices if their internal policy
dictates.
To issue certain Certificate types, RAs may need to rely on Certificates issued by third party
Certification Authorities or other third-party databases and sources of information such as
government national identity cards such as passports, eID, and drivers’ licenses. Where the RA
GlobalSign CP (Certificate Policy)
Version: 7.0

22 of 77

relies on Certificates issued by a third party Certification Authority, RA must review the validation
practices of the third party and relying party obligations by referring to such third party’s CPS.
Issuing CAs may designate an Enterprise RA to verify Certificate Requests from the Enterprise
RA’s own organization. In Enterprise RA, the Subscriber’s organization shall be validated and predefined, and shall be constrained by system configuration.
1.3.3

Subscribers

Subscribers of Issuing CAs are either directly reliant on the Issuing CA to issue end entity
Certificates from a hierarchy managed by the Issuing CA or they are third parties that seek to beissued with an Issuing CA capable of issuing additional Certificates to their own PKI hierarchy.
Subscribers are either Legal Entities or natural persons that successfully apply for and receive a
Certificate to support their use in transactions, communications and the application of Digital
Signatures. In some cases, individuals are not able to obtain certain Certificate types.
A Subscriber, as used herein, refers to both the Subject of the Certificate and the entity that
contracted with the Issuing CA for the Certificate’s issuance. Prior to verification of identity andissuance of a Certificate, a Subscriber is an Applicant.
End entity Subscribers have ultimate authority over the Private Key corresponding to the Public
Key that is listed in a Subscriber’s Certificate. A Subscriber may or may not be the Subject of a
Certificate (For example, machine or role-based Certificates issued to firewalls, routers, servers orother devices used within an organization).
1.3.4

Relying Parties

To verify the validity of a Certificate, Relying Parties must always refer to Issuing CA’s revocation
information either in the form of a CRL distribution point or an OCSP responder.
1.3.5

Other Participants

Other participants include bridge CAs and CAs that cross certify Issuing CAs to provide trust among
other PKI communities.

1.4

Certificate Usage

A Certificate allows an entity taking part in an electronic transaction to prove its identity to otherparticipants in such transaction. Certificates are used in commercial environments as a digital
equivalent of an identification card.
1.4.1

Appropriate Certificate Usage

End entity Certificate use is restricted by the key usage and extended key usage values.
Unauthorised use of Certificates may result in the voiding of warranties offered by GlobalSign to
Subscribers and their Relying Parties.
1.4.2

Prohibited Certificate Usage

Certificate use is restricted by using Certificate extensions on key usage and extended key usage.
Any usage of the Certificate inconsistent with these extensions is not authorised. Certificates are
not authorised for use for any transactions above the designated reliance limits that have been
indicated in the GlobalSign Warranty Policy.
Certificates do not guarantee that the Subject is trustworthy, operating a reputable business or thatthe equipment into which the Certificate has been installed is free from defect, malware or virus. In
the case of code signing, Certificates do not guarantee that signed code is free from bugs orvulnerabilities.
Certificates issued under this CP may not be used:•

For any application requiring fail safe performance

GlobalSign CP (Certificate Policy)
Version: 7.0

23 of 77

•
•
•
•

1.5
1.5.1

For any application or mechanism where issues with the certificate could cause a safety
risk (e.g. human or environmental risk)
Where prohibited by law
Qualified Certificates for Electronic Signatures should only be used by natural persons
whereas Certificates for Electronic Seals should only be used by legal persons
Certificates issued under the NAESB WEQ PKI shall never be used for performing any of
the following functions:o Any transaction or data transfer that may result in imprisonment if compromised or
falsified.
o Any transaction or data transfer deemed illegal under federal law.

Policy Administration
Organization Administering the Document

Requests for information on the compliance of Issuing CAs with accreditation schemes as well as
any other inquiry associated with this CP should be addressed to:
PACOM1 - CA Governance GlobalSign
Diestsevest 14,
3000 Leuven, Belgium
Tel: + 32 (0)16 891900
Fax: + 32 (0) 16 891909
Email: policy-authority@globalsign.com
1.5.2

Contact Person

General Inquiries
GlobalSign NV/SA
attn. Legal Practices,
Diestsevest 14,
3000 Leuven, Belgium
Tel: + 32 (0)16 891900
Fax: + 32 (0) 16 891909
Email: legal@globalsign.com
URL: www.globalsign.com
Certificate Problem Report
Anti-Malware Organizations, Subscribers, Relying Parties, Application Software Suppliers, andother third parties may report suspected Private Key Compromise, Certificate misuse, Certificatesused to sign Suspect Code, Takeover Attacks, or other types of fraud, compromise, misuse,inappropriate conduct, or any other matter related to Certificates by sending email to:report-abuse@globalsign.com
GlobalSign may or may not revoke in response to this request. See section 4.9.5 for detail of actions
performed by GlobalSign for making this decision.
1.5.3

Person Determining CP Suitability for the Policy

PACOM1 – CA Governance determines the suitability and applicability of this CP and theconformance of a CPS to this CP based on the results and recommendations received from a
Qualified Auditor.
In an effort to maintain credibility and promote trust in this CP and better correspond to accreditationand legal requirements, PACOM1 – CA Governance shall review this CP at least annually and may
make revisions and updates to policies as it sees fit or as required by other circumstances. Any
updates become binding for all Certificates that have been issued or are to be issued upon the dateof the publication of the updated version of this CP.

GlobalSign CP (Certificate Policy)
Version: 7.0

24 of 77

1.5.4CP Approval Procedures

PACOM1 – CA Governance reviews and approves any changes to the CP. Upon approval of a CP
update by PACOM1 – CA Governance, the new CP is published in the GlobalSign Repository at
https://www.globalsign.com/repository.
The updated version is binding upon all Subscribers including the Subscribers and parties relying
on Certificates that have been issued under a previous version of the CP.

1.6

Definitions and Acronyms

Any terms used but not defined herein shall have the meaning ascribed to them in the the Baseline
Requirements, the EV Guidelines, Baseline Requirements for Code Signing, and/or the eIDAS or
UK eIDAS regulation.
Adobe Approved Trust List (AATL): A document signing certificate authority trust store createdby the Adobe Root CA policy authority implemented from Adobe PDF Reader version 9.0
Affiliate: A corporation, partnership, joint venture or other entity controlling, controlled by, or undercommon control with another entity, or an agency, department, political subdivision, or any entity
operating under the direct control of a Government Entity.
Anti‐Malware Organization: An entity that maintains information about Suspect Code and/or
develops software used to prevent, detect, or remove malware.
Applicant: The natural person or Legal Entity that applies for (or seeks renewal of) a Certificate.
Once the Certificate issues, the Applicant is referred to as the Subscriber. For Certificates issued
to devices, the Applicant is the entity that controls or operates the device named in the Certificate,even if the device is sending the actual Certificate Request.
Application Software Supplier: A supplier of Internet browser software or other Relying Party
application software that displays or uses Certificates and incorporates Root Certificates.
Attestation Letter: A letter attesting that Subject Identity Information is correct.
Authorized Certification Authority: A Certification Authority that complies with all provisions of
the North American Energy Standards Board (NAESB) Business Practice Standard for Public Key
Infrastructure (PKI) – WEQ-012.
Base Domain Name: The portion of an applied‐for FQDN that is the first Domain Name node leftof a registry‐controlled or public suffix plus the registry‐controlled or public suffix (e.g.
“example.co.uk” or “example.com”). For FQDNs where the right‐most Domain Name node is agTLD having ICANN Specification 13 in its registry agreement, the gTLD itself may be used as theBase Domain NameBusiness Entity: Any entity that is not a Private Organization, Government Entity, or noncommercial entity as defined in the EV Guidelines. Examples include, but are not limited to, generalpartnerships, unincorporated associations, sole proprietorships, etc.

Certificate: An electronic document that uses a digital signature to bind a Public Key and an
identity.
Certificate Authority Authorization (CAA): The CAA record is used to specify which Certificate
authorities are allowed to issue Certificates for a domain.
Certificate Beneficiaries: The Subscriber that is a party to the Subscriber Agreement or Terms of
Use for the Certificate, all Application Software Suppliers with whom GlobalSign has entered into acontract for inclusion of its Root Certificate in software distributed by such Application Software
Supplier, and all Relying Parties who reasonably rely on a Valid Certificate.

GlobalSign CP (Certificate Policy)
Version: 7.0

25 of 77

Certificate Data: Certificate Requests and data related thereto (whether obtained from theApplicant or otherwise) in the CA’s possession or control or to which the CA has access.
Certificate Management Process: Processes, practices, and procedures associated with the useof keys, software, and hardware, by which the CA verifies Certificate Data, issues Certificates,
maintains a Repository, and revokes Certificates.
Certificate Policy: A set of rules that indicates the applicability of a named Certificate to aparticular community and/or PKI implementation with common security requirements.
Certificate Problem Report: A complaint of suspected Key Compromise, Certificate misuse, orother types of fraud, compromise, misuse, or inappropriate conduct related to Certificates.
Certificate Request: Communications described in Section 10 of the Baseline Requirements
requesting the issuance of a Certificate.
Certificate Revocation List: A regularly updated timestamped list of revoked Certificates that iscreated and digitally signed by the CA that issued the Certificates.
Certification Authority: An organization that is responsible for the creation, issuance, revocation,and management of Certificates. The term applies equally to both Roots CAs and Subordinate CAs.
Certification Practice Statement: One of several documents forming the governance frameworkin which Certificates are created, issued, managed, and used.
Common CA Database (CCADB): A certificate repository run by Mozilla, where all publicly trusted
root and issuing certificates are listed.
Compromise: A violation of a security policy that results in loss of control over sensitive
information.
Conformity Assessment Body: A body defined in point 13 of Article 2 of Regulation (EC) No
765/2008, which is accredited in accordance with that Regulation as competent to carry out
conformity assessment of a qualified trust service provider and the qualified trust services it
providesCountry: Either a member of the United Nations OR a geographic region recognized as asovereign nation by at least two UN member nations.
Cross Certificate: A Certificate that is used to establish a trust relationship between two RootCAs.
DCF77: A German longwave time signal and standard-frequency radio station.
Digital Signature: To encode a message by using an asymmetric cryptosystem and a hashfunction such that a person having the initial message and the signer’s Public Key can accurately
determine whether the transformation was created using the Private Key that corresponds to thesigner’s Public Key and whether the initial message has been altered since the transformation wasmade.
DNS CAA Email Contact:
Requirements.

The email address defined in Appendix B.1.1. of the Baseline

DNS TXT Record Email Contact: The email address defined in Appendix B.2.1. of the Baseline
Requirements.
DNS TXT Record Phone Contact: The phone number defined in Appendix B.2.2. of the Baseline
Requirements.

GlobalSign CP (Certificate Policy)
Version: 7.0

26 of 77

Domain Contact: The Domain Name Registrant, technical contact, or administrative contract (orthe equivalent under a ccTLD) as listed in the WHOIS record of the Base Domain Name or in a
DNS SOA record, or as obtained through direct contact with the Domain Name Registrar.
Domain Label: From RFC 8499 (http://tools.ietf.org/html/rfc8499): “An ordered list of zero or more
octets that makes up a portion of a domain name. Using graph theory, a label identifies one node
in a portion of the graph of all possible domain names.”
Domain Name: An ordered list of one or more Domain Labels assigned to a node in the Domain
Name System.
Domain Name System: An Internet service that translates Domain Names into IP addresses.
Domain Namespace: The set of all possible Domain Names that are subordinate to a single nodein the Domain Name System.
Domain Name Registrant: Sometimes referred to as the “owner” of a Domain Name, but more
properly the person(s) or entity(ies) registered with a Domain Name Registrar as having the rightto control how a Domain Name is used, such as the natural person or Legal Entity that is listed as
the “Registrant” by WHOIS or the Domain Name Registrar.
Domain Name Registrar: A person or entity that registers Domain Names under the auspices ofor by agreement with: (i) the Internet Corporation for Assigned Names and Numbers (ICANN), (ii)a national Domain Name authority/registry, or (iii) a Network Information Center (including theiraffiliates, contractors, delegates, successors, or assigns).
eIDAS Regulation (“eIDAS”): REGULATION (EU) No 910/2014 OF THE EUROPEANPARLIAMENT AND OF THE COUNCIL of 23 July 2014 on electronic identification and trust
services for electronic transactions in the internal market and repealing Directive 1999/93/EC.
Electronic Seal: Data in electronic form, which is attached to or logically associated with otherdata in electronic form to ensure the latter’s origin and integrity;
Electronic Signature: Data in electronic form which is attached to or logically associated with otherdata in electronic form and which is used by the signatory to sign
Enterprise PKI (EPKI): A GlobalSign product for organizations to manage the full lifecycle ofMicrosoft Window’s trusted digital IDs, Adobe Approved Trust List, including issuing, reissuing,
renewing, and revoking.
Enterprise RA: An employee or agent of an organization unaffiliated with the CA who authorizes
issuance of Certificates to that organization or its subsidiaries. An Enterprise RA may also authorize
issuance of client authentication Certificates to partners, customers, or affiliates wishing to interact
with that organization.
Expiry Date: The “Not After” date in a Certificate that defines the end of a Certificate’s Validity
Period.
Fully-Qualified Domain Name: A Domain Name that includes the Domain Labels of all
superior nodes in the Internet Domain Name System.
GlobalSign Certificate Center (GCC): A cloud-based certificate management system throughwhich customers and partners may purchase and manage Certificates from GlobalSign.
Global Positioning System (GPS): A U.S.-owned utility that provides users with positioning,navigation, and timing (PNT) services.
Governmentally Accepted Form of ID: A physical or electronic form of ID issued by the local
country/state government or a form of ID that the local government accepts for validating identities
of Individuals for its own official purposes.

GlobalSign CP (Certificate Policy)
Version: 7.0

27 of 77

Government Entity: A government-operated legal entity, agency, department, ministry, branch,or similar element of the government of a Country, or political subdivision within such Country (suchas a state, province, city, county, etc.).
Hash (e.g. SHA1 or SHA256): An algorithm that maps or translates one set of bits into another(generally smaller) set in such a way that:• A message yields the same result every time the algorithm is executed using the samemessage as input.
• It is computationally infeasible for a message to be derived or reconstituted from the result
produced by the algorithm.
• It is computationally infeasible to find two different messages that produce the same hashresult using the same algorithm.
Hardware Security Module (HSM): A type of secure crypto processor targeted at managing digitalkeys, accelerating crypto processes in terms of digital signings/second and for providing strong
authentication to access critical keys for server applications.
Incorporate by Reference: To make one document a part of another by identifying the document
to be incorporated, with information that allows the recipient to access and obtain the incorporated
message in its entirety, and by expressing the intention that it be part of the incorporating message.
Such an incorporated message shall have the same effect as if it had been fully stated in themessage.
Incorporating Agency: In the context of a Private Organization, the government agency in the
Jurisdiction of Incorporation under whose authority the legal existence of the entity is registered(e.g., the government agency that issues certificates of formation or incorporation). In the context
of a Government Entity, the entity that enacts law, regulations, or decrees establishing the legal
existence of Government Entities.
Individual: A natural person.
Internal Name: A string of characters (not an IP address) in a Common Name or Subject
Alternative Name field of a Certificate that cannot be verified as globally unique within the public
DNS at the time of certificate issuance because it does not end with a Top Level Domain registeredin IANA’s Root Zone Database.
Internationalized Domain Name (IDN): An internet domain name containing at least one
language-specific script or alphabetic character which is then encoded in punycode for use in DNS
which accepts only ASCII strings.
IP Address: A 32-bit or 128-bit number assigned to a device that uses the Internet Protocol forcommunication.
IP Address Contact: The person(s) or entity(ies) registered with an IP Address Registration
Authority as having the right to control how one or more IP Addresses are used.
IP Address Registration Authority: The Internet Assigned Numbers Authority (IANA) or a
Regional Internet Registry (RIPE, APNIC, ARIN, AfriNIC, LACNIC).
Issuing CA: In relation to a particular Certificate, the CA that issued the Certificate. This could beeither a Root CA or a Subordinate CA.
Jurisdiction of Incorporation: In the context of a Private Organization, the country and (whereapplicable) the state or province or locality where the organization’s legal existence was establishedby a filing with (or an act of) an appropriate government agency or entity (e.g., where it wasincorporated). In the context of a Government Entity, the country and (where applicable) the stateor province where the Entity’s legal existence was created by law.

GlobalSign CP (Certificate Policy)
Version: 7.0

28 of 77

Key Compromise: A Private Key is said to be Compromised if its value has been disclosed to an
unauthorized person, an unauthorized person has had access to it, or there exists a practicaltechnique by which an unauthorized person may discover its value.
Key Pair: The Private Key and its associated Public Key.
Legal Entity: An association, corporation, partnership, proprietorship, trust, government entity orother entity with legal standing in a Country’s legal system.
North American Energy Standards Board (NAESB) Accreditation Requirements for
Authorized Certification Authorities (“NAESB Accreditation Specification”): The technicaland management details which a Certification Authority is required to meet in order to be accredited
as an Authorized Certification Authority (ACA) by NAESB.
NAESB Business Practice Standards for Public Key Infrastructure (PKI) – WEQ-012(“NAESB Business Practice Standards”): Defines the minimum requirements that must be met
by Certification Authorities, the Certificates issued by those Certification Authorities and end entities
that use those Certificates in order to comply with NAESB PKI standards.
Network Time Protocol (NTP): A networking protocol for clock synchronization between
computer systems over packet-switched, variable-latency data networks.
Object Identifier (OID): A unique alphanumeric or numeric identifier registered under theInternational Organization for Standardization’s applicable standard for a specific object or object
class.
OCSP Responder: An online server operated under the authority of the CA and connected to its
Repository for processing Certificate status requests. See also, Online Certificate Status Protocol.
Online Certificate Status Protocol: An online Certificate-checking protocol that enables Relying
Party application software to determine the status of an identified Certificate. See also OCSP
Responder.
Open Banking Certificate: A Qualified Certificate that includes Open Banking Specific Attributes.
Open Banking Specific Attributes: Attributes that are specific to Open Banking Certificates which
are: which are:• authorization number if it is issued by the NCA, or registration number recognized onnational or European level or Legal Entity Identifier included in the register of credit
institutions.
• role or roles of PSP;
• NCA name (NCAName) and unique identifier (NCAId).
Payment Services Directive (PSD2): European Union Directive (EU) 2015/2366 that regulates
payment services and payment service providers throughout the European Union and European
Economic Area.
Place of Business: The location of any facility (such as a factory, retail store, warehouse, etc.)
where the Applicant’s business is conducted.
Private Key: The key of a Key Pair that is kept secret by the holder of the Key Pair, and that isused to create Digital Signatures and/or to decrypt electronic records or files that were encryptedwith the corresponding Public Key.
Private Organization: A non-governmental legal entity (whether ownership interests are privately
held or publicly traded) whose existence was created by a filing with (or an act of) the Incorporating
Agency or equivalent in its Jurisdiction of Incorporation.
Public Key: The key of a Key Pair that may be publicly disclosed by the holder of thecorresponding Private Key and that is used by a Relying Party to verify Digital Signatures created
GlobalSign CP (Certificate Policy)
Version: 7.0

29 of 77

with the holder's corresponding Private Key and/or to encrypt messages so that they can bedecrypted only with the holder's corresponding Private Key.
Public Key Infrastructure (PKI): A set of hardware, software, people, procedures, rules, policies,
and obligations used to facilitate the trustworthy creation, issuance, management, and use of
Certificates and keys based on Public Key cryptography.
Publicly-Trusted Certificate: A Certificate that is trusted by virtue of the fact that its corresponding
Root Certificate is distributed as a trust anchor in widely-available application software.
Qualified Auditor: A natural person or Legal Entity that meets the requirements of Section 8.2(Identity/ Qualifications of Assessor).
Qualified Certificate: A Certificate that meets the qualification requirements defined by theeIDAS/UK eIDAS Regulation.
Qualified Certificate for Electronic Seals: A certificate for Electronic Seals, that is issued by aqualified trust service provider and meets the requirements laid down in Annex III of eIDAS/UK
eIDAS Regulation.
Qualified Certificate for Electronic Signature: a certificate for Electronic Signatures, that isissued by a qualified trust service provider and meets the requirements laid down in Annex I ofeIDAS Regulation.
Qualified Electronic Seals: An advanced Electronic Seal, which is created by a Qualified
Electronic Seal Creation Device, and that is based on a Qualified Certificate for Electronic Seal.
Qualified Electronic Signature: An advanced Electronic Signature that is created by a Qualified
Electronic Signature Creation Device, and which is based on a Qualified Certificate for Electronic
Signatures.
Qualified Government Information Source: A database maintained by a Government Entity.
Qualified Government Tax Information Source: A Qualified Governmental Information Sourcethat specifically contains tax information relating to Private Organizations, Business Entities, orIndividuals.
Qualified Independent Information Source: A regularly updated and current, publicly available,
database designed for the purpose of accurately providing the information for which it is consulted,
and which is generally recognized as a dependable source of such information.
Qualified Electronic Signature/Seal Creation Device (QSCD): An electronic signature/seal
creation device that meets the requirements as stipulated within Annex II of eIDAS Regulation.
Qualified Timestamping (QTS): The provisioning of timestamps that comply with Article 42 of theeIDAS/UK eIDAS Regulation.
Qualified Trust Service Provider (QTSP): a natural or a legal person who provides one or moretrust services and is granted the qualified status by the supervisory body as defined within theeIDAS/UK eIDAS regulation.
Qualified Web Authentication Certificates (QWAC): a qualified SSL Certificate that meets therequirements of article 45 of the eIDAS/UK eIDAS Regulation.
Registered Domain Name: A Domain Name that has been registered with a Domain Name
Registrar.
Registration Authority (RA): Any Legal Entity that is responsible for identification andauthentication of Subjects of Certificates, but is not a CA, and hence does not sign or issue
Certificates. An RA may assist in the Certificate application process or revocation process or both.
GlobalSign CP (Certificate Policy)
Version: 7.0

30 of 77

When “RA” is used as an adjective to describe a role or function, it does not necessarily imply aseparate body, but can be part of the CA.
Relying Party: Any natural person or Legal Entity that relies on a Valid Certificate. An Application
Software Supplier is not considered a Relying Party when software distributed by such supplier
merely displays information relating to a Certificate.
Repository: An online database containing publicly-disclosed PKI governance documents (suchas Certificate Policies and Certification Practice Statements) and Certificate status information,either in the form of a CRL or an OCSP response.
Reserved IP Address: An IPv4 or IPv6 address that is contained in the address block ofany entry in either of the following IANA registries:
https://www.iana.org/assignments/iana‐ipv4‐special‐registry/iana‐ipv4‐special‐registry.xhtml
https://www.iana.org/assignments/iana‐ipv6‐special‐registry/iana‐ipv6‐special‐registry.xhtml
Root CA: The top level Certification Authority whose Root Certificate is distributed by Application
Software Suppliers and that issues Subordinate CA Certificates.
Root Certificate: The self-signed Certificate issued by the Root CA to identify itself and to facilitate
verification of Certificates issued to its Subordinate CAs.
SSL Certificate: Certificates intended to be used for authenticating servers accessible throughthe Internet.
Subject: The natural person, device, system, unit, or Legal Entity identified in a Certificate as the
Subject. If the Subject is a device or system, it must be under the control and operation of the
Subscriber.
Subject Identity Information: Information that identifies the Certificate Subject. Subject Identity
Information does not include a Domain Name listed in the subjectAltName extension or thecommonName field.
Subordinate CA: A Certification Authority whose Certificate is signed by the Root CA, or another
Subordinate CA.
Subscriber: A natural person or Legal Entity to whom a Certificate is issued and who is legallybound by a Subscriber Agreement or Terms of Use.
Subscriber Agreement: An agreement between the CA and the Applicant/Subscriber thatspecifies the rights and responsibilities of the parties.
Supervisory Body: A body responsible for the task of supervising the qualified trust service
providers established in the territory of the Member State and to take action, if necessary, in relation
to non-qualified trust service providers established in the territory of the Member State. Details aredescribed in eIDAS Article 17.
Takeover Attack: An attack where a Signing Service or Private Key associated with a CodeSigning Certificate has been compromised by means of fraud, theft, intentional malicious act of the
Subject’s agent, or other illegal conduct.
Technically Constrained Subordinate CA Certificate: A Subordinate CA certificate which uses
a combination of Extended Key Usage settings and Name Constraint settings to limit the scope
within which the Subordinate CA Certificate may issue Subscriber or additional Subordinate CA
Certificates.

GlobalSign CP (Certificate Policy)
Version: 7.0

31 of 77

Terms of Use: Provisions regarding the safekeeping and acceptable uses of a Certificate issuedin accordance with the Baseline Requirements when the Applicant/Subscriber is an Affiliate of theCA.
Trusted Platform Module (TPM): A hardware cryptographic device which is defined by the Trusted
Computing Group. https://www.trustedcomputinggroup.org/specs/TPM.
Trusted Third Party: A service provider with a secure process used for individual identity
verification based on Governmentally Accepted Form(s) of ID, or whose service itself is considered
to generate a Governmentally Accepted Form of ID.
Trustworthy System: Computer hardware, software, and procedures that are: reasonably securefrom intrusion and misuse; provide a reasonable level of availability, reliability, and correct
operation; are reasonably suited to performing their intended functions; and enforce the applicablesecurity policy.
UK eIDAS ("UK eIDAS"): eIDAS (UK Legislation) and The Electronic Identification and Trust
Services for Electronic Transactions Regulations 2016.
Valid Certificate: A Certificate that passes the validation procedure specified in RFC 5280.
Validation Specialist: Someone who performs the information verification duties specified by theBaseline Requirements.
Validity Period: The period of time measured from the date when the Certificate is issued until the
Expiry Date.
WebTrust Program for CAs: The then-current version of the AICPA/CICA WebTrust Program for
Certification Authorities.
WebTrust Seal of Assurance: An affirmation of compliance resulting from the WebTrust Programfor CAs.
Wildcard Certificate: A Certificate containing at least one Wildcard Domain Name in the Subject
Alternative Names in the Certificate.
Wildcard Domain Name: A string starting with “*.” (U+002A ASTERISK, U+002E FULL STOP)
immediately followed by a Fully‐Qualified Domain Name.
WHOIS Lookup: Information retrieved directly from the Domain Name Registrar or registry
operator via the protocol defined in RFC 3912, the Registry Data Access Protocol defined in RFC
7482, or an HTTPS website.
X.400: The standard of the ITU-T (International Telecommunications Union-T) for E-mail.
X.500: The standard of the ITU-T (International Telecommunications Union-T) for Directory
Services.
X.509: The standard of the ITU-T (International Telecommunications Union-T) for Certificates.
AATL
AICPA
API
ARL
CA
CAA
CCADB
ccTLD
CICA
CP

Adobe Approved Trust List
American Institute of Certified Public Accountants
Application Programming Interface
Authority Revocation List (A CRL for Issuing CAs rather than end entities)
Certification Authority
Certificate Authority Authorization
Common CA Database
Country Code Top-Level Domain
Canadian Institute of Chartered Accountants
Certificate Policy

GlobalSign CP (Certificate Policy)
Version: 7.0

32 of 77

CPS
CRL
DBA
DNS
EIR
EKU
EPKI
ETSI
EV
FIPS
FQDN
GCC
GPS
IANA
ICANN
IETF
ISO
ITU
LRA
NAESB
NCA
NIST
NTP
OCSP
OID
PKI
PSP
QGIS
QGTIS
QIIS
RA
RFC
S/MIME
SSCD
SSL
TLD
TLS
VAT
WEQ

Certification Practice Statement
Certificate Revocation List
Doing Business As
Domain Name System
Electric Industry Registry
Extended Key UsageEnterprise PKIEuropean Telecommunications Standards Institute
Extended Validation(US Government) Federal Information Processing Standard
Fully-Qualified Domain Name
GlobalSign Certificate Center
Global Positioning System
Internet Assigned Numbers Authority
Internet Corporation for Assigned Names and Numbers
Internet Engineering Task Force
International Organization for Standardization
International Telecommunications Union
Local Registration Authority
North American Energy Standards Board
National Competent Authority(US Government) National Institute of Standards and Technology
Network Time Protocol
Online Certificate Status Protocol
Object Identifier
Public Key Infrastructure
Payment service provider
Qualified Government Information Source
Qualified Government Tax Information Source
Qualified Independent Information Source
Registration Authority
Request for Comments
Secure MIME (Multipurpose Internet Mail Extensions)
Secure Signature Creation Device
Secure Sockets Layer
Top-Level Domain
Transport Layer Security
Value Added Tax
Wholesale Electric Quadrant

GlobalSign CP (Certificate Policy)
Version: 7.0

33 of 77

2.0 Publication and Repository Responsibilities
2.1

Repositories

The Issuing CA shall publish all CA Certificates and Cross Certificates issued to and from theIssuing CA, revocation data for issued Certificates, CP, CPS, and Relying Party agreements andSubscriber Agreements in Repositories. The Issuing CA shall ensure that revocation data for issued
Certificates and its Root Certificate are available through a Repository 24 hours a day, 7 days aweek with a minimum of 99% availability overall per year with a scheduled downtime that does notexceed 0.5% annually.
All parties who are associated with the issuance, use or management of Issuing CA Certificatesare hereby notified that Issuing CAs may publish submitted information on publicly accessible
directories for the provision of Certificate status information.
Issuing CAs may refrain from making publicly available certain sensitive and/or confidential
documentation including security controls, operating procedures, and internal security policies.
These documents are, however, made available to Qualified Auditors as required during any
WebTrust or ETSI audit performed on GlobalSign.
Country specific web sites and translations of this CP and other public documentation may be madeavailable by Issuing CAs for marketing purposes, however the repositories for all GlobalSign public
facingdocumentationarehttps://www.globalsign.com/repositoryandhttps://www.globalsign.com/en/company/corporate-policies and in the event of any inconsistency,
the English version shall control.

2.2

Publication of Certificate Information

GlobalSign publishes its CP, CPS, Subscriber Agreements, and Relying Party agreements at
https://www.globalsign.com/repository. The CP and CPS include all the material required by RFC
3647, and are structured in accordance with RFC 3647.

2.3Time or Frequency of Publication

CA Certificates are published in a Repository via support pages as soon as possible after issuance.
GlobalSign reviews its CP and CPS at least annually and makes appropriate changes so that
GlobalSign operation remains accurate, transparent and complies with external requirements listed
in the “Acknowledgements” section of this document. GlobalSign closely monitors CA/Browser
Forum ballots and updates to the Requirements and implements updates to GlobalSign operations
in a timely manner. New or modified versions of this CP, the CPS, Subscriber Agreements, orRelying Party agreements are published within seven days after approval.

2.4

Access Controls on Repositories

Issuing CA shall make its Repository publicly available in a read-only manner and implement logicaland physical controls to prevent unauthorized write access to such Repositories. In the case of
GlobalSign, the integrity and authenticity of its public documentation is maintained through the useof Digital Signatures applied to PDF documents.

3.0 Identification and Authentication
Issuing CAs maintain documented practices and procedures to authenticate the identity and/or
other attributes of the Applicant.
Issuing CAs use approved procedures and criteria to accept applications from entities seeking tobecome part of the CAs hierarchy, either as Subordinate CA seeking chaining services or as an
RA, Enterprise RA or as an end entity Subscriber.
Issuing CAs must authenticate the requests of parties wishing to perform revocation of Certificates
under this CP.

GlobalSign CP (Certificate Policy)
Version: 7.0

34 of 77

3.1
3.1.1

NamingTypes of Names

To identify a Subscriber, Issuing CAs shall follow naming and identification rules that include typesof names assigned to the Subject, such as X.500 distinguished names RFC-822 names and X.400
names. DNs (Distinguished Names) must respect name space uniqueness and must not be
misleading. RFC2460 (IP version 6) or RFC791 (IP version 4) addresses may be used.
3.1.2

Need for Names to be Meaningful

When applicable, Issuing CAs shall use distinguished names to identify both the Subject and issuer
name of the Certificate. When User Principal Names (UPN) are used, they must be unique andaccurately reflect organizational structures.
3.1.3

Anonymity or Pseudonymity of Subscribers

Issuing CAs may issue end entity anonymous or pseudonymous Certificates provided that such
Certificates are not prohibited by applicable policy and name space uniqueness is preserved.
3.1.4

Rules for Interpreting Various Name Forms

Distinguished names in Certificates are interpreted using X.500 standards and ASN.1 syntax. See
RFC 2253 and RFC 2616 for further information on how X.500 distinguished names in Certificatesare interpreted as Uniform Resource Identifiers and HTTP references.
3.1.5

Uniqueness of Names

No stipulation.
3.1.6

Recognition, Authentication, and Role of Trademarks

Subscribers may not request Certificates with any content that infringes the intellectual property
rights of another entity. This CP does not require that an Applicant’s right to use a trademark beverified. However, Issuing CAs may reject any applications or require revocation of any Certificatethat is part of a dispute.

3.2

Initial Identity Validation

Issuing CAs may perform identification of the Applicant or for services including CA chaining
services using any legal means of communication or investigation necessary to identify the Legal
Entity or Individual.
Issuing CAs may use the result of a successful Subject DN initial identity validation process tocreate alternative product offerings by effectively combining elements of previously verified
information with alternative, newly verified, information. A suitable account based challenge
response mechanism must be used to authenticate any previously verified information for any
returning Applicant provided that the re-verification requirements of Section 3.3.1 are complied with.
3.2.1

Method to Prove Possession of Private Key

No stipulation
3.2.2

Authentication of Organization Identity

For all Certificates that include an organization identity, Applicants are required to indicate theorganization’s name and registered or trading address. The legal existence, legal name, legal
form (where included in the request or part of the legal name in the jurisdiction of incorporation) andprovided address of the organization must be verified and any methods used must be highlighted
in the CPS.
The authority of the Applicant to request a Certificate on behalf of the organization must be verified
in accordance with Section 3.2.5.
3.2.2.1

Local Registration Authority Authentication

For accounts that allow the concept of a Local Registration Authority, Issuing CAs and RAs may
set authenticated organizational details in the form of a Profile. Suitably authenticated accountadministrators acting in the capacity of a Local Registration Authority must authenticate Individuals
GlobalSign CP (Certificate Policy)
Version: 7.0

35 of 77

affiliated with the organization and/or any sub-domains owned or controlled by the organization.
(Whilst LRA’s are able to authenticate Individuals under contract, all Domain Names to beauthenticated must have previously had the appropriate higher-level Domain Name pre-authorized
and authenticated in compliance with this CP and the Baseline Requirements).
3.2.2.2

Machine, Device, Department, and Role based Certificate Authentication(DepartmentSign)

Issuing CAs must ensure that requests for machine, device, department, or role-based Certificatesare authenticated either by a RA, acting on behalf of the CA, or an LRA that is contractually
obligated to the Issuing CA/RA to ensure that machine, device, department, or role-based names
relating to the organization and its business are accurate and correct.
3.2.2.3

Qualified Certificates

GlobalSign issues three types of Qualified Certificates that include an Organization Identity:• Qualified Certificate for Electronic Seals, which assert the identity of an Organization• Qualified Certificates for Electronic Signatures, which assert the Individual’s affiliation withan Organization.
• Qualified Website Authentication Certificates.
For all Qualified Certificates that include an organization identity, Applicants are required to indicate
the organization’s full legal name (including the legal form) and the address of the physical locationof the Subject’s place of business.
GlobalSign verifies the legal existence and the address by reference to:• official government records provided in Qualified Government Information Sources; or• documentation provided by or confirmation received from a government agency in thejurisdiction of the Organization’s legal creation, existence or recognition; or• records provided by a Qualified Independent Information Source.
Additionally, GlobalSign may verify the address by reference to:• a Verified Legal Opinion or a Verified Accountant letter; or• an attestation of the physical location signed using the Organization’s valid Qualified
Electronic Seal.
The information in the attestation must match the content of the Qualified Certificate.
The Full Legal Name of the Organization, doing business as names (Trade Name or Trading As
Name) may also be included in the Qualified Certificate. GlobalSign will verify that the Organization
has registered the use of any included doing business as name with the appropriate government
agency for such filings in the jurisdiction of its Place of Business, and that such filing continues tobe valid.
For Certificates that assert the Individual’s affiliation with an Organization, GlobalSign will verify thisaffiliation by reference to:• Confirmation provided by the Organization, obtained using a Verified Method ofCommunication; or• Independent Confirmation from the Organization; or• a Verified Legal Opinion or a Verified Accountant letter; or• an attestation signed using the Organization’s valid Qualified Electronic Seal; or• an attestation obtained by a suitably authenticated account administrators acting in thecapacity of a Local Registration Authority.
For Qualified Certificates that assert the identity of the Organization and for Qualified Website
Authentication Certificates, GlobalSign will verify the identity and the authority of the Organization’s
authorised representative(s).
GlobalSign will verify the authority of the authorised representative(s) by reference to:• official government records provided in Qualified Government Information Sources; orGlobalSign CP (Certificate Policy)
Version: 7.0

36 of 77••••

documentation provided by or confirmation received from a government agency in thejurisdiction of the Organization’s legal creation, existence or recognition; orrecords provided by a Qualified Independent Information Source; ora Verified Legal Opinion or a Verified Accountant letter; oran attestation the signed using the Organization’s valid Qualified Electronic Seal. The
information in the attestation must match the content of the Qualified Certificate.

GlobalSign will verify the identity of the authorised representative in accordance with section 3.2.3.
For any Open Banking Specific Attributes, GlobalSign will validate attributes using information
provided by the National Competent Authority, which includes but is not limited to national public
registers, European Banking Authority registers and authenticated communication from the
National Competent Authority.
If GlobalSign is notified of an email address where it can inform the NCA identified in a newly issued
certificate then GlobalSign shall send to that email address information on the content of thecertificate in plain text including the certificate serial number in hexadecimal, the subject
distinguished name, the issuer distinguished name, the certificate validity period, as well as contact
information and instructions for revocation requests and a copy of the a certificate file.
3.2.3

Authentication of Individual identity

Issuing CAs or RAs shall authenticate Individuals depending upon the class of Certificate as
indicated below.
3.2.3.1

Class 1The Applicant is required to demonstrate control of the email address or domain name to which theCertificate relates. Issuing CAs or RAs are not required to authenticate any other information
provided.
3.2.3.2

Class 2The Applicant is required to demonstrate control of certain identity attributes included in the request,
such as his/her email address or domain name to which the Certificate relates if included in theCertificate Request.
The Applicant may also be required to submit a legible copy of a valid government issued national
identity document or photo ID (driver’s license, military ID or equivalent). A suitable non-government
issued identity document or photo ID may also be required for additional proof. GlobalSign verifies
to a reasonable level of assurance that the copy of the ID matches the requested name and that
other Subject information such as Country and/or state and locality fields are correct.
GlobalSign may also authenticate the Applicant’s identity through one of the following methods:
1. Performing a telephone challenge/response to the Applicant using a telephone number
from a reliable source; or
2. Performing a fax challenge/response to the Applicant using a fax number from a reliable
source; or
3. Performing an email challenge/response to the Applicant using an email address from areliable source; or
4. Performing a postal challenge to the Applicant using an address obtained from a reliable
source; or
5. The Applicant’s seal impression (in jurisdictions that permit their use to legally sign adocument) is included with any application received in writing.
For AATL, the options are defined as follows. Please note that these options are also available forother Class 2 products:
1. Receiving an attestation from an appropriate notary or Trusted Third Party that they haveverified the individual identity based on a Governmentally Accepted Form of ID.
2. In the case of individuals affiliated with an organization: obtaining an executed declarationof identity of the individual that includes at least one unique biometric identifier of the
GlobalSign CP (Certificate Policy)
Version: 7.0

37 of 77

individual (such as a fingerprint or handwritten signature). In this executed declaration ofidentity, an authorized representative of the Organization mentioned in the certificate
confirms having seen the individual, reviewed the individual’s photo ID, and confirm thatthe individual’s identity information in the certificate requests matches the information
contained in the reviewed photo ID. GlobalSign confirms the document’s authenticity
directly with the authorized representative of the organization using contact information
confirmed using a Qualified Independent Information Source or a Qualified Government
Information Source or any other method in line with the EV Guidelines. GlobalSign confirms
the authorized representative’s authority to represent the Organization in line with the EV
Guidelines.
3. In the case of individuals affiliated with an organization, GlobalSign may rely on attestations
from the approved Local RA. Refer to 3.2.3.5 in case of a Class 2 Certificate requested
through an EPKI or an MSSL profile.
4. Receiving an attestation from an organization to validate the identities of its own end
customers based on a verification of a Governmentally Accepted Form of ID, while theorganization maintains a secure auditable trail of these verifications.
5. Other verifications in line with the verification of individuals for Qualified Certificates.
GlobalSign may request further information from the Applicant. Other information and/or methods
may be utilized in order to demonstrate an equivalent level of confidence.
If an email address is to be included in the Certificate Request, GlobalSign or LRA shall verify thevalidity and ownership of that email address.
3.2.3.3

Class 3For EV Code Signing, the Applicant is required to demonstrate control of any email address to be
included within a Certificate.
For Extended Validation SSL, the Applicant is required to demonstrate control of all domain names
to be included in a Certificate.
The Applicant is required to submit a legible copy of a valid government issued national identity
document or photo ID (drivers licence, military ID or equivalent). A suitable non-government issued
identity document or photo ID may also be required for additional proof. Issuing CAs are required
to verify to a reasonable level of assurance that the copy of the ID matches the requested nameand that other Subject information such as Country and/or state and locality fields areauthenticated.
For PersonalSign 3 Pro, a face-to-face meeting is required to establish the individual’s identity withan attestation from the notary or Trusted Third Party that they have met the individual and haveinspected their national photo ID document, and that the application details for the order are correct.
The Applicant is also required to demonstrate control of any email address to be included in a
Certificate.
Issuing CA or RAs are also required to authenticate the Applicant’s authority to represent theorganization wishing to be named as the Subject in the Certificate, using reliable means ofcommunication, verified by GlobalSign as a reliable way of communicating with the Applicant inaccordance with the EV Guidelines and the Baseline Requirements for Code Signing.
Further information may be requested from the Applicant or the Applicant’s organization. Other
information and/or methods may be utilized in order to achieve an equivalent level of confidence.
3.2.3.4

Qualified Certificates

Verification of the Identity of Individual Subscribers must be performed according to Article 24.1 ofthe eIDAS/UK eIDAS Regulation.
3.2.3.5

Local Registration Authority Authentication

For Organization accounts which allow the concept of a Local Registration Authority, Issuing CAs
and RAs may set authenticated organizational details in the form of a profile. Certificates issued
GlobalSign CP (Certificate Policy)
Version: 7.0

38 of 77

within these accounts are populated with data fields from the profile. The Organization iscontractually obligated to authenticate individuals affiliated with the organization.
3.2.3.6

North American Energy Standards Board (NAESB) Certificates

For NAESB Certificate Requests, authenticity of organization identity requests for Certificates in
the name of an affiliated organization shall include the organization name, address, anddocumentation of the existence of the organization. GlobalSign or the RA shall verify the
information, in addition to the authenticity of the requesting representative and the representative’s
authorization to act in the name of the organization. End entities shall be obligated to register theirlegal business identification and if using certificate for WEQ-012 applications secure an “Entity
Code” that will be published in the NAESB EIR and used in all Subscriber applications submitted
by, and Certificates issued to, that end entity.
When issuing certificates for use within the energy industry for other than WEQ-012 applications,
ACAs must comply with: the provisions of the NAESB WEQ-012 Public Key Infrastructure Business
Practice Standards and Models, except provisions in WEQ-012-1.9.1, WEQ-012-1.3.3, and WEQ012-1.4.3, which require End Entity registration within the NAESB EIR.
GlobalSign may elect to perform RA operations/functions in-house or choose to delegate some, orall, RA operations/functions to other parties that are separate legal entities via one of its managed
service offerings. In both cases, the party or parties performing RA operations/functions are subject
to the obligations for identity proofing, auditing, logging, protection of Subscriber information, record
retention and other aspects germane to the RA function outlined in this CP and the NAESB
Accreditation Specification and NAESB Business Practice Standards. All RA infrastructure andoperations performing RA operations/functions shall be held to this requirement as incumbent upon
the Certificate Authority when performing in-house RA operations/functions. The Authorized
Certification Authority and/or delegated entity are responsible for ensuring that all parties
performing RA operations/functions understand and agree to conform to the NAESB Accreditation
Specification.
For Subscribers, GlobalSign and/or associated RAs shall ensure that the Applicant’s identity
information is verified in accordance with the process established by the GlobalSign CP and CPS.
The process shall depend upon the Certificate level of assurance and shall be addressed in the
NAESB Accreditation Specification. The documentation and authentication requirements shall varydepending upon the level of assurance.
Registration of Identity Proofing Requirements shall use the following mappings:
NIST Assurance Level
Level 1
Level 2
Level 3

NAESB Assurance Level
Rudimentary
BasicMediumGlobalSign, or its designated RA in the case of EPKI, shall verify all of the identification information
supplied by the Applicant in compliance with the authentication requirements defined by the Identity
Proofing Process (IPP) Method described in section 2.2.2: Authentication of Subscribers of the“NAESB Accreditation Requirements for Authorized Certification Authorities.”
3.2.4

Non-Verified Subscriber Information

Issuing CAs must validate all information to be included within the Subject DN of a Certificate or
clearly indicate within their CPS or within the issued Certificate itself any exceptions that may apply
to specific product types or services offered.
For IntranetSSL Certificates only, Issuing CAs may rely upon information provided by the Applicant
to be included within the subjectAlternativeName, such as internal or non-public DNS names,
hostnames and RFC 1918 IP addresses.
Specifically for SSL Certificates and Code Signing Certificates, the CA must maintain a process toensure that Applicants cannot add self-reported information to the subject:organizationalUnitName.

GlobalSign CP (Certificate Policy)
Version: 7.0

39 of 77

3.2.5

Validation of Authority

PersonalSign1
Certificates
PersonalSign Demo
Certificates
PersonalSign2
Certificates
NAESB Certificates

PersonalSign2 Pro

PersonalSign2
Department
Certificates

PersonalSign3
Certificates

S/MIME certificates

Code Signing
Certificates
EV Code Signing
Certificates
DV/AlphaSSL
Certificates
OV SSL Certificates

EV SSL Certificates

Verification that the Applicant has control over the email
address to be listed within the Certificate through a challenge
response mechanism.
Verification that the Applicant has control over the email
address to be listed within the Certificate.
Verification through a reliable means of communication with
the individual Applicant together with verification that the
Applicant has control over any email address included.
Verification through a reliable means of communication withthe organization or individual Applicant together withverification that the Applicant has control over any email
address included (see Section 3.2.3.5.)
Verification through a reliable means of communication with
the individual Applicant together with verification that the
Applicant has control over the email address included if
required. For Certificates issued through an EPKI account, theAuthority of the Local Registration Authority will be verified at
the time of the set-up of the profile.
Verification through a reliable means of communication with
the individual Applicant together with verification that the
Applicant has control over the email address if an email
address is requested to be included in the Certificate. For
Certificates issued through an EPKI account, the Authority of
the Local Registration Authority will be verified at the time ofthe set-up of the profile.
Verification through a reliable means of communication withthe organization that the Applicant represents theorganization. Personal appearance is mandatory before asuitable Registration Authority to validate the personalcredentials of the Applicant together with verification that the
Applicant has control over the email address to be listed within
the Certificate.
Verification through a reliable means of communication withthe organization or individual Applicant together withverification that the Applicant has control over any email
address included.
Verification of Organization and Individual Applicants inaccordance with the Code Signing Minimum Requirements.
Verification of the authority of the contract signer andCertificate approver in accordance with the EV Guidelines andBaseline Requirements for Code Signing.
Validation of the ownership or control of the domain name isperformed via one of the domain validation methods defined in
Section 3.2.7.
Verification through a reliable means of communication withthe organization or individual Applicant together withverification that the Applicant has ownership or control of thedomain name via the methods listed in section 3.2.7. For
Certificates issued through an MSSL account, the Authority of
the Local Registration Authority will be verified at the time ofthe set-up of the profile.
Verifying the authority of the contract signer and Certificate
approver in accordance with the EV Guidelines together withverification that the Applicant has ownership or control of thedomain name via the methods listed in section 3.2.7. For
Certificates issued through an MSSL account, the Authority of
the Local Registration Authority will be verified at the time ofthe set-up of the profile.

GlobalSign CP (Certificate Policy)
Version: 7.0

40 of 77

Timestamping
Certificates
AATL

Qualified Website
Authentication
Certificates

Qualified Certificate forElectronic Seal
Qualified Certificate forElectronic Signature

Verification through a reliable means of communication withthe organization’s Applicant.
Verification through a reliable means of communication withthe organization or individual Applicant together withverification that the Applicant has control over the email
address if an email address is requested to be included in theCertificate. For Certificates issued through an EPKI account,
the Authority of the Local Registration Authority will be verified
at the time of the set-up of the profile.
Verifying the authority of the contract signer, Certificate
approver and the Authorised representative in accordancewith the methods listed in section 3.2.2.3 together withverification that the Applicant has ownership or control of thedomain name via the methods listed in section 3.2.7.
Verifying the authority of the contract signer Certificate
approver and the Authorised representative in accordancewith the methods listed in section 3.2.2.3.
Verification of the authenticity of the individual Applicant’s
request with the methods listed in section 3.2.3.4.

Alternative to any reliable means of communication with the organization, the authority can be
confirmed using either:• an advanced electronic signature (or higher) or seal which includes the name of theorganization, its parent, subsidiary or affiliate, or• an advanced electronic signature (or higher) of a confirmed employee or agent of theorganization.
3.2.6

Criteria for Interoperation

Issuing CAs SHALL disclose all Cross Certificates that identify the CA as the Subject, provided that
the CA arranged for or accepted the establishment of the trust relationship (i.e. the Cross Certificate
at issue).
3.2.7

Authentication of Domain Names

For all SSL Certificates, the Applicant’s ownership or control of all requested FQDN(s) must be
verified with methods to achieve this in accordance with the Baseline Requirements section 3.2.2.4
and must be detailed within the CPS.
GlobalSign shall validate each server FQDN in publicly trusted SSL Certificates against thedomain's CAA records. GlobalSign's CAA issuer domain is "globalsign.com." If a CAA record existsthat does not list globalsign.com as an authorized CA, GlobalSign shall not issue the Certificate.
Further information may be requested from the Applicant, and other information and/or methods
may be utilized to achieve an equivalent level of confidence.
3.2.8

Authentication of IP Addresses

For all SSL Certificates, the Applicant’s ownership or control of all requested IP addresses must be
verified with methods to achieve this in accordance with the Baseline Requirements section 3.2.2.4
and must be detailed within the CPS.
Further information may be requested from the Applicant, and other information and/or methods
may be utilized to achieve an equivalent level of confidence.
3.2.9

Authentication of Email Addresses

GlobalSign must uses the following methods to confirm that the Applicant has control of or right touse email addresses:
1. Having the Applicant demonstrate control over the requested email address by sending aRandom Value to the requested email address and then receiving a confirming response
utilizing the Random Value; orGlobalSign CP (Certificate Policy)
Version: 7.0

41 of 77

2. Having the Applicant demonstrate control over or right to use the FQDN using one of theDomain Validation processes listed in Section 3.2.7 of the GlobalSign Certification PracticeStatement. Once verified, an Enterprise RA can issue certificates containing email
addresses under that FQDN.
3. The RA enters into a contractual agreement with the entity requesting the End Entity
certificate to be signed according to the requirements in the applicable certificate policy.

3.3

Identification and Authentication for Re-key Requests

Issuing CAs may support re-key requests from Subscribers prior to the expiry of the Subscriber’s
existing Certificate.
3.3.1

Identification and Authentication for Routine Re-key

All re-key requests must be authenticated by the Issuing CA. If at any point any information
embodied in a Certificate is changed in any way, additional validation must be performed.
3.3.2

Identification and Authentication for Re-key After Revocation

A routine re-key after revocation is not supported. Re-key after revocation of a Certificate requires
the Subscriber to follow the initial validation process that was previously completed to allow theinitial issuance of the Certificate.

3.4

Identification and Authentication for Revocation Request

All revocation requests must be authenticated by the Issuing CA or RA. Revocation requests fromSubscribers may be granted following a suitable challenge response such as logging into an
account with a username and password, or proving possession of unique elements incorporated
into the Certificate, e.g. Domain Name or email address.
Issuing CAs may also perform revocation on behalf of Subscribers in accordance with therequirements of the applicable Subscriber Agreement. Examples of reasons for revocation include
a breach of the Subscriber Agreement or non-payment of applicable fees.

4.0 Certificate Life Cycle Operational Requirements
4.1
4.1.1

Certificate Application
Who Can Submit a Certificate Application

Issuing CAs shall maintain their own blocklists for individuals from whom or entities from which they
will not accept Certificate applications. Blocklists may be based on historic certificates issued orother sources. In addition, other external sources such as government denied lists or internationallyrecognized denied persons lists which are applicable to the jurisdictions in which the Issuing CA
operates may be used to screen unwanted Applicants.
4.1.2

Enrollment Process and Responsibilities

Issuing CAs shall maintain systems and processes that sufficiently authenticate the Applicant’s
identify for all Certificate types that present the identity to Relying Parties. Applicants should submit
sufficient information to allow Issuing CAs and RAs to successfully perform the required verification.
Issuing CAs and RAs shall protect communications and securely store information presented by
the Applicant during the application process.

4.2
4.2.1

Certificate Application Processing
Performing Identification and Authentication Functions

Issuing CAs shall maintain systems and processes to sufficiently authenticate the Applicant’s
identify in in compliance with its CPS. Initial identity validation shall be performed by an Issuing
CAs validation team or by Registration Authorities under contract as set forth in Section 3.2 of thisCP. All communications shall be securely stored along with all information presented directly by the
Applicant during the application process. Future identification of repeat Applicants and subsequentauthentication checks may be addressed using single (username and password) or multi-factor(Certificate in combination with username/password) authentication principles.
GlobalSign CP (Certificate Policy)
Version: 7.0

42 of 77

4.2.2

Approval or Rejection of Certificate Applications

Issuing CAs shall reject applications for Certificates where validation of all items cannot
successfully be completed.
Assuming all validation steps can be completed successfully following appropriate best practicetechniques Issuing CAs shall generally approve the Certificate Request. Issuing CAs may rejectapplications including for the following reasons:• Based on potential brand damage to GlobalSign in accepting the application.
• For Certificates from Applicants who have previously been rejected or have previously
violated a provision of a Subscriber Agreement.
Issuing CAs are under no obligation to provide a reason to an Applicant for rejection of a Certificate
Request.
Issuing CA shall not issue publicly trusted SSL Certificates to Internal Names or Reserved IP
Addresses.
4.2.3

Time to Process Certificate Applications

Issuing CAs shall ensure that all reasonable methods are used in order to process and evaluate
Certificate applications.

4.3
4.3.1

Certificate IssuanceCA Actions during Certificate Issuance

Certificate issuance by GlobalSign Root CA requires an authorized Trusted Role member from
GlobalSign to deliberately issue a direct command for the Root CA to perform a Certificate signing
operation.
Issuing CAs shall communicate with any RA accounts capable of causing Certificate issuance using
multi-factor authentication. RAs directly operated by the Issuing CA or RAs contracted by theIssuing CA to perform validation shall ensure that all information sent to the CA is verified andauthenticated in a secure manner.
4.3.2

Notifications to Subscriber by the CA of Issuance of Certificate

The Issuing CA or RA shall notify the Subscriber of the issuance of a Certificate in a convenientand appropriate way based on information submitted during the enrollment process.

4.4
4.4.1

Certificate Acceptance
Conduct Constituting Certificate AcceptanceIssuing CAs shall inform the Subscriber that s/he may not use the Certificate until the Subscriber
has reviewed and verified the accuracy of the data incorporated into the Certificate. To avoid thisbeing an open-ended stipulation, Issuing CAs may set a time limit by when the Certificate is deemed
to be accepted.
4.4.2

Publication of the Certificate by the CA

Issuing CAs may publish a Certificate by sending the Certificate to the Subscriber and/or publishingin a suitable Repository, including to Certificate Transparency Logs.
4.4.3

Notification of Certificate Issuance by the CA to Other Entities

RAs, local RA, partners/resellers, GlobalSign and other entities may be informed of the issuance ifthey were involved in the initial enrollment.

4.5
4.5.1

Key Pair and Certificate Usage
Subscriber Private Key and Certificate Usage

Subscribers must protect their Private Key taking care to avoid disclosure to third parties. Issuing
CAs must maintain a suitable Subscriber Agreement which highlights the obligations of the
Subscriber with respect to Private Key protection. Private Keys must only be used as specified in

GlobalSign CP (Certificate Policy)
Version: 7.0

43 of 77

the appropriate key usage and extended key usage fields as indicated in the corresponding
Certificate.
For Qualified Certificates where the Private Key related to the certified Public Key resides in a
QSCD, Subscriber keys must be generated and stored within a recognized Qualified Signature
Creation Device (QSCD).
For Non-EV Code Signing Certificates issued prior to April 24, 2023, the Subscriber’s private key
should be generated, stored and used in a crypto module which meets the requirements of FIPS
140-2 level 2 or Common Criteria EAL 4+ or within a Trusted Platform Module (TPM) that generates
and secures a key pair and that can document the Subscriber’s private key protection through a
TPM key attestation.
For EV Code Signing Certificates issued prior to April 24, 2023, the Subscriber’s private key mustbe generated, stored and used in a crypto module that meets or exceeds the requirements of FIPS
140-2 level 2 or Common Criteria EAL 4+.
Effective April 24, 2023, Subscriber Private Keys for EV and Non-EV Code Signing Certificatesmust be generated and protected in a Hardware Crypto Module with a unit design form factor
certified as conforming to at least FIPS 140‐2 Level 2 or Common Criteria EAL 4+.
Where it is possible to make a backup of a Private Key, Subscribers must use the same level ofcare and protection attributed to the live Private Key. At the end of the useful life of a Private Key,
Subscribers must securely delete the Private Key and any fragments that it has been split into forthe purposes of backup.
In the case of GlobalSign’s digital signing service, and with the consent of the Subscriber,
GlobalSign shall host, secure, and manage short-lived Certificates and corresponding Private Keys
in a conformant HSM/QSCD.
4.5.2

Relying Party Public Key and Certificate Usage

Issuing CAs must describe the conditions under which Certificates may be relied upon by Relying
Parties within their CPS including the appropriate mechanisms available to verify Certificate validity(e.g. CRL or OCSP). Issuing CAs must also offer a Relying Party agreement to Subscribers thecontent of which should be presented to the Relying Party. Relying Party must accept and act inaccordance with the Relying Party Agreement prior to reliance upon a Certificate from the Issuing
CA. Relying Parties should use the information to make a risk assessment and as such are solely
responsible for performing the risk assessment prior to relying on the Certificate or any assurances
made.
Software used by Relying Parties should be fully compliant with X.509 standards including bestpractice for chaining decisions around policies and key usage.

4.6

Certificate Renewal

Certificate renewal means the issuance of a Certificate with a new validity period ending after thevalidity period of the old Certificate, but without changing the Subscriber or other participant's Public
Key or any other information in the Certificate.
4.6.1

Circumstances for Certificate Renewal

Certificate renewal may be performed upon request of the Subscriber, an authorized representativeof Subscriber or by the Issuing CA at its sole discretion.
Certificate renewal shall only be performed if the original Certificate has not been revoked.
4.6.2

Who May Request Renewal

Requests for renewal must be submitted by the Subscriber of the Certificate or their authorized
representative.

GlobalSign CP (Certificate Policy)
Version: 7.0

44 of 77

4.6.3

Processing Certificate Renewal Requests

To process a renewal request, the Issuing CA must verify the request with Subscriber or theirauthorized representative.
4.6.4

Notification of New Certificate Issuance to Subscriber

As per 4.3.2
4.6.5

Conduct Constituting Acceptance of a Renewal Certificate

As per 4.4.1
4.6.6

Publication of the Renewal Certificate by the CA

As per 4.4.2
4.6.7

Notification of Certificate Issuance by the CA to Other Entities

No stipulation

4.7

Certificate Re-Key

Certificate re-key means the issuance of a new Certificate with a different Public Key, but withoutchanging the validity period or any other information in the Certificate.
4.7.1

Circumstances for Certificate Re-Key

Certificate re-key may be performed upon request of the Subscriber, an authorized representativeof Subscriber or by the Issuing CA at its sole discretion.
Certificate re-key may be requested upon compromise of the Certificate Private Key.
4.7.2

Who May Request Certification of a New Public Key

Requests for re-key must be submitted by the Subscriber of the Certificate or their authorized
representative.
4.7.3

Processing Certificate Re-Keying Requests

To process a re-key request, the Issuing CA must verify the request with Subscriber or theirauthorized representative.
4.7.4

Notification of New Certificate Issuance to Subscriber

As per 4.3.2
4.7.5

Conduct Constituting Acceptance of a Re-Keyed Certificate

As per 4.4.1
4.7.6

Publication of the Re-Keyed Certificate by the CA

As per 4.4.2
4.7.7

Notification of Certificate Issuance by the CA to Other Entities

No stipulation

4.8

Certificate Modification

Certificate modification means issuance of a new Certificate due to changes in the information in
the Certificate other than the Subscriber Public Key.
4.8.1

Circumstances for Certificate Modification

Certificate modification may be performed upon request of the Subscriber, an authorized
representative of Subscriber or by the Issuing CA at its sole discretion.
4.8.2

Who May Request Certificate Modification

Requests for modification must be submitted by the Subscriber of the Certificate or their authorized
representative.

GlobalSign CP (Certificate Policy)
Version: 7.0

45 of 77

4.8.3

Processing Certificate Modification Requests

To process a modification request, the Issuing CA must verify the request with Subscriber or theirauthorized representative.
4.8.4

Notification of New Certificate Issuance to Subscriber

As per 4.3.2
4.8.5

Conduct Constituting Acceptance of Modified Certificate

As per 4.4.1
4.8.6

Publication of the Modified Certificate by the CA

As per 4.4.2
4.8.7

Notification of Certificate Issuance by the CA to Other Entities

No stipulation

4.9

Certificate Revocation and Suspension

4.9.1

Circumstances for Revocation

Prior to performing a revocation, Issuing CAs will verify the authenticity of the revocation request.
GlobalSign may revoke any Certificate at its sole discretion.
Revocation of a Subscriber Certificate is performed within twenty-four (24) hours under thefollowing circumstances:
1. The Subscriber requests in writing (to GlobalSign which provided the Certificate) that theywish to revoke the Certificate;
2. The Subscriber notifies GlobalSign that the original Certificate Request was not authorized
and does not retroactively grant authorization;
3. GlobalSign obtains reasonable evidence that the Subscriber's Private Key corresponding
to the Public Key in the Certificate suffered a Key Compromise;
4. GlobalSign is made aware of a demonstrated or proven method that can easily compute
the Subscriber’s Private Key based on the Public Key in the Certificate (such as a Debianweak key, see https://wiki.debian.org/SSLkeys);
5. GlobalSign obtains evidence that the validation of domain authorization or control for any
Fully-Qualified Domain Name or IP address in the Certificate should not be relied upon.
6. GlobalSign receives notice or otherwise becomes aware of unexpected termination of a
Subscriber's or Subject's agreement or business functions.
7. In case of Open Banking Certificates, GlobalSign receives an authenticated revocation
request (or authenticates a revocation request) that originated from the NCA which has
authorized or registered the payment service provider, and which includes a valid reason
for revocation. Valid reasons for revocation include when the authorization of the PSP has
been revoked or any PSP role included in the Certificate has been revoked.
Revocation of a Subscriber’s Certificate should be performed within twenty-four (24) hours and is
performed within 5 days if one or more of the following occurs:
1. The Certificate no longer complies with the requirements for algorithm type and key size of
the Baseline Requirements, as specified in Sections 6.1.5 and 6.1.6;
2. GlobalSign obtains evidence that the Certificate was misused;
3. GlobalSign receives notice or otherwise becomes aware that the Subscriber violated anyof its material obligations under the Subscriber Agreement or Terms of Use;
4. GlobalSign is made aware of any circumstance indicating that use of a Fully-Qualified
Domain Name or IP address in the Certificate is no longer legally permitted (e.g. a court or
arbitrator has revoked a Domain Name Registrant’s right to use the Domain Name, a
relevant licensing or services agreement between the Domain Name Registrant and theApplicant has terminated, or the Domain Name Registrant has failed to renew the DomainName);

GlobalSign CP (Certificate Policy)
Version: 7.0

46 of 77

5. GlobalSign is made aware that a Wildcard Certificate has been used to authenticate afraudulently misleading subordinate Fully-Qualified Domain Name;
6. GlobalSign receives notice or otherwise becomes aware of a material change in theinformation contained in the Certificate;
7. GlobalSign is made aware that the Certificate was not issued in accordance with theBaseline Requirements or GlobalSign’s CP or CPS;
8. GlobalSign determines that any of the information appearing in the Certificate is inaccurate;
9. GlobalSign’s right to issue Certificates under the Baseline Requirements expires or isrevoked or terminated, unless GlobalSign has made arrangements to continue maintaining
the CRL/OCSP Repository;
10. Revocation is required by GlobalSign’s CP and/or CPS;
11. GlobalSign is made aware of a demonstrated or proven method that exposes the
Subscriber’s Private Key to compromise or if there is clear evidence that the specificmethod used to generate the Private Key was flawed;
12. The technical content or format of the Certificate presents an unacceptable risk to
Application Software Suppliers or Relying Parties (e.g. the CA/B Forum might determinethat a deprecated cryptographic/signature algorithm or key size presents an unacceptablerisk and that such Certificates should be revoked and replaced by CAs within a given periodof time);13. GlobalSign receives notice or otherwise becomes aware of any circumstance indicatingthat use of the email address in the certificate is no longer legally permitted;
14. the CA private key used in issuing the certificate is suspected to have been compromised;
15. GlobalSign ceases operations for any reason and has not arranged for another CA toprovide revocation support for the Certificate;
16. The Certificate was issued in violation of the then-current version of the Mozilla Root Store
Policy.
Revocation of a Subscriber Certificate may also be performed within a commercially reasonable
period of time under the following circumstances:
1. The Subscriber or organization administrator requests revocation of the Certificate througha GCC account which controls the lifecycle of the Certificate;
2. The Subscriber requests revocation through an authenticated request to GlobalSign's
support team or GlobalSign’s Registration Authority;
3. GlobalSign receives notice or otherwise becomes aware that the Subscriber has been
added as a denied party or prohibited person to a blocklist, or is operating from a prohibited
destination under the laws of GlobalSign's jurisdiction of operation;
4. Overdue payment of applicable fees by the Subscriber;
5. Following the request for cancellation of a Certificate;
6. If a Certificate has been re-issued, GlobalSign may revoke the previously issued
Certificate;
7. Under certain licensing arrangements, GlobalSign may revoke Certificates following
expiration or termination of the license agreement; and8. GlobalSign determines the continued use of the Certificate is otherwise harmful to thebusiness of GlobalSign or third parties. When considering whether Certificate usage isharmful to a third party’s business or reputation, GlobalSign will consider, amongst otherthings, the nature and number of complaints received, the identity of the complainant(s),relevant legislation in force, responses to the alleged harmful use by the Subscriber;
9. If Microsoft, in its sole discretion, identifies a certificate whose usage or attributes are
determined to be contrary to the objectives of the Trusted Root Program, Microsoft will
notify GlobalSign and request that it revoke the certificate. GlobalSign will either revoke thecertificate or request an exception from Microsoft within 24 hours of receiving Microsoft's
notice. Microsoft will review submitted material and inform GlobalSign of its final decision
to grant or deny the exception at its sole discretion. In the event that Microsoft does notgrant the exception, GlobalSign will revoke the certificate within 24 hours of the exception
being denied.
10. Death of a Subscriber.
Revocation of a Subordinate CA Certificate is performed within seven (7) days under the following
circumstances:
GlobalSign CP (Certificate Policy)
Version: 7.0

47 of 77

1. The Subordinate CA requests in writing to the GlobalSign entity which provided theSubordinate CA Certificate or the authority detailed in Section 1.5.2 of this CP, that
GlobalSign revoke the Certificate;
2. The Subscriber notifies the Issuing CA that the original Certificate Request was not
authorized and does not retroactively grant authorization;
3. The Issuing CA obtains reasonable evidence that the Subordinate CA’s Private Key
corresponding to the Public Key in the Certificate suffered a Key Compromise or no longer
complies with the requirements for algorithm type and key size of the Baseline
Requirements as specified in Sections 6.1.5 and 6.1.6;
4. GlobalSign obtains evidence that the Certificate was misused;
5. GlobalSign is made aware that the Certificate was not issued in accordance with or that
the Subordinate CA has not complied with the Baseline Requirements or applicable CP or
CPS;
6. GlobalSign determines that any of the information appearing in the Certificate is inaccurate
or misleading;
7. The Issuing CA or Subordinate CA ceases operations for any reason and has not arranged
for another CA to provide revocation support for the Certificate;
8. The Issuing CA’s or Subordinate CA’s right to issue Certificates under the Baseline
Requirements expires or is revoked or terminated, unless the issuing CA has madearrangements to continue maintaining the CRL/OCSP Repository;
9. Revocation is required by the Issuing CA’s CP and/or CPS;
10. The technical content or format of the Certificate presents an unacceptable risk to
Application Software Suppliers or Relying Parties (e.g. the CA/B Forum might determinethat a deprecated cryptographic/signature algorithm or key size presents an unacceptablerisk and that such Certificates should be revoked and replaced by CAs within a given periodof time).
Issuing CAs that cross sign other Issuing CAs may revoke the Issuing CA if the cross signed Issuing
CA no longer meets the contractual terms and conditions of the agreement between the two parties.
4.9.2

Who Can Request Revocation

Issuing CAs, RAs or Subscribers can initiate revocation. Only authenticated requests for revocation
are accepted. Authorization for revocation shall be accepted if the revocation request is received
from either the Subscriber or an affiliated organization named in the Certificate. Subscribers,
Relying Parties, Application Software Suppliers, and other third parties may submit Certificate
Problem Reports to notify GlobalSign of a suspected reasonable cause to revoke a Certificate.
Additionally, for Open Banking Certificates, revocation request can originate from the NCA which
has authorized or registered the payment service provider.
Issuing CAs may also at their own discretion revoke Certificates including Certificates that areissued to other cross signed Issuing CAs.
4.9.3

Procedure for Revocation Request

Due to the nature of revocation requests and the need for efficiency, Issuing CAs and RAs may
provide automated mechanisms for requesting and authenticating revocation requests; forexample, through an account which issued the Certificate that is requested to be revoked. RAs may
also provide manual backup processes in the event that automated revocation methods are notpossible.
Issuing CAs and RAs will record each request for revocation and authenticate the source, taking
appropriate action to revoke the Certificate if the request is authentic and approved.
Once revoked, the serial number of the Certificate and the date and time shall be added to theappropriate CRL. CRL reason codes may be included. CRLs may be published immediately or they
may be published as defined within the Issuing CA’s CPS.
Issuing CAs and RAs shall prepare methods for Subscribers, Relying Parties, Application Software
Suppliers, and other third parties to submit a Certificate Problem Report. Issuing CAs and RAs may
or may not revoke in response to this request. See section 4.9.5 for detail of actions required for
Issuing CAs and RAs for making this decision.
GlobalSign CP (Certificate Policy)
Version: 7.0

48 of 77

4.9.4

Revocation Request Grace Period

For SSL and Code Signing Certificates, GlobalSign does not support a revocation request grace
period.
For all other certificates, the revocation request grace period is the time available for a Subscriber
to take any necessary actions themselves in order to request revocation of a suspected Key
Compromise, use of a weak key or discovery of inaccurate information within an issued Certificate.
Issuing CAs should allow Subscribers a maximum of 48 hours to take appropriate action to revoke
or take appropriate action on behalf of Subscribers.
4.9.5

Time Within Which CA Must Process the Revocation Request

Issuing CAs shall begin investigating Certificate Problem Reports within twenty-four (24) hours ofreceipt of the report.
All revocation requests for end entity Certificates, both those generated automatically via user
accounts and those initiated by the Issuing CA itself, must be processed within a maximum of 30
minutes of receipt.
Issuing CAs that cross sign other CAs should process a revocation request within 24 hours of aconfirmation of Compromise and an ARL should be published within 12 hours of any off-line ARL
key ceremony.
Issuing CAs and RAs shall maintain 24 x 7 ability to respond internally to a high-priority Certificate
Problem Report through report abuse channel and, where appropriate, forward such a complaint
to law enforcement authorities, and/or revoke a Certificate that is the subject of such a complaint.
Issuing CAs and RAs shall begin investigation procedures for a suspected Key Compromise or
misuse of a Certificate within 24 hours of receipt of the report.
Issuing CAs and RAs shall decide whether revocation or other action is warranted based on at least
following criteria:••••

The nature of the alleged problem;
The number of reports received about a particular Certificate or Subscriber;
The entity making the complaint; andRelevant legislation.

For Qualified Certificates, actual revocation status shall be published/available through all
revocation mechanisms within 60 minutes after the revocation decision and will never be reverted.
4.9.6

Revocation Checking Requirements for Relying Parties

Prior to relying on a Certificate, Relying Parties must validate the suitability of the Certificate for theintended purpose and ensure the Certificate is valid. Relying Parties will need to consult CRL or
OCSP information for each Certificate in the chain as well as validating that the Certificate chain
itself is complete. This may include the validation of Authority Key Identifier (AKI) and Subject Key
Identifier (SKI). Issuing CAs may include all applicable URLs within the Certificate to aid Relying
Parties in performing the revocation checking process.
For Qualified Certificates, validation of the certificate chain shall be carried out successfully up to
the Issuing CA trust anchor within the EU or UK eIDAS trusted list.
4.9.7

CRL Issuance Frequency

All Issuing CAs must meet the requirements of the Baseline Requirements and the EV Guidelines(if applicable).
If CRLs are provided and the CA decides or is required to terminate a CRL, the CA SHALL issue
and publish at the corresponding CRL Distribution Point a last CRL with a nextUpdate field value“99991231235959Z”. The CA SHALL NOT issue a last CRL until all certificates in the scope of the
CRL are either expired or revoked and SHALL preserve the integrity and the availability of the last
CRL at least for the period specified in the CPS.

GlobalSign CP (Certificate Policy)
Version: 7.0

49 of 77

For the status of Subscriber Certificates:
If the CA publishes a CRL, then the CA SHALL update and re-issue CRLs at least once every
seven days, and the value of the nextUpdate field MUST NOT be more than ten days beyond thevalue of the thisUpdate field.
For the status of Subordinate CA Certificates:
If the Subordinate CA contains a CDP, the CA SHALL update and re-issue CRLs at least (i) once
every twelve months and (ii) within 24 hours after revoking a Subordinate CA Certificate, and thevalue of the nextUpdate field MUST NOT be more than twelve months beyond the value of the
thisUpdate field.
4.9.8

Maximum Latency for CRLs

CRLs are posted to the repository within a commercially reasonable time after generation.
4.9.9

On-Line Revocation/Status Checking Availability

Issuing CAs that support OCSP responses in addition to CRLs shall provide response times nolonger than 10 seconds under normal network operating conditions.
Issuing CAs’ OCSP responses shall conforms to RFC6960 and/or RFC5019. OCSP responses
shall be signed by an OCSP Responder whose Certificate is signed by the CA that issued theCertificate whose revocation status is being checked. OCSP signing Certificate must contain an
extension of type id-pkix-ocsp-nocheck, as defined by RFC6960.
4.9.10 On-Line Revocation Checking Requirements
OCSP responders operated by the CA SHALL support the HTTP GET method, as described in
RFC 6960 and/or RFC 5019.
The validity interval of an OCSP response is the difference in time between the thisUpdate andnextUpdate field, inclusive. For purposes of computing differences, a difference of 3,600 seconds
shall be equal to one hour, and a difference of 86,400 seconds shall be equal to one day, ignoring
leap-seconds.
For the status of Subscriber Certificates:
1. OCSP responses MUST have a validity interval greater than or equal to eight hours.
2. OCSP responses MUST have a validity interval less than or equal to ten days.
3. For OCSP responses with validity intervals less than sixteen hours, then the CA SHALL
update the information provided via an Online Certificate Status Protocol prior to one-halfof the validity period before the nextUpdate.
4. For OCSP responses with validity intervals greater than or equal to sixteen hours, then the
CA SHALL update the information provided via an Online Certificate Status Protocol atleast eight hours prior to the nextUpdate, and no later than four days after the thisUpdate.
For the status of Subordinate CA Certificates:• The CA shall update information provided via an OCSP Responder (i) at least every twelve
months and (ii) within 24 hours after revoking a Subordinate CA Certificate.
OCSP Responders that receive a request for status of a Certificate that has not been issued, shallnot respond with a "good" status for such Certificates. OCSP Responders for CAs which are notTechnically Constrained, in line with Section 7.1.5, shall not respond with a "good" status for such
Certificates.
Issuing CA shall require OCSP requests to contain the following data:• Protocol version• Service request• Target Certificate identifier
4.9.11 Other Forms of Revocation Advertisements Available
If the Subscriber Certificate is for a high-traffic FQDN, Issuing CA may choose to rely on stapling,in accordance with RFC4366, to distribute its OCSP responses. In this case, Issuing CA shall
GlobalSign CP (Certificate Policy)
Version: 7.0

50 of 77

ensure that the Subscriber “staples” the OCSP response for the Certificate in its TLS handshake.
Issuing CA shall enforce this requirement on the Subscriber contractually through the Subscriber
Agreement or Terms of Use, or by technical review measures implemented by the CA.
4.9.12 Special Requirements Related to Key Compromise
Issuing CAs and related Registration Authorities shall use commercially reasonable methods toinform Subscribers that their Private Key may have been Compromised. This includes cases where
new vulnerabilities have been discovered or where the Issuing CA at their own discretion decides
that evidence suggests a possible Key Compromise has taken place. Where Key Compromise is
not disputed Issuing CAs shall revoke Issuing CA Certificates or Subscriber end entity Certificatesand publish a revised CRL within 24 hours.
4.9.13 Circumstances for Suspension
Certificate suspension is only allowed for Client certificates. Certificate suspension is not allowed
for any other types of end entity Certificates. Certificate suspension is strictly forbidden for SSL
Certificates and Qualified Certificates.
4.9.14 Who Can Request Suspension
Issuing CAs and RAs shall accept authenticated requests for suspension. Authorization forsuspension shall be accepted if the suspension request is received from either the Subscriber oran affiliated organization named in the Certificate. Issuing CAs may also at their own discretion
suspend Certificates including Certificates that are issued to other cross signed Issuing CAs.
4.9.15 Procedure for Suspension Request
Due to the nature of suspension requests and the need for efficiency, Issuing CAs and RAs may
provide automated mechanisms for requesting and authenticating suspension requests; forexample, through an account which issued the Certificate that is requested to be suspended. RAs
may also provide manual backup processes in the event that automated suspension methods are
not possible. Issuing CAs and RAs will record each request for suspension and authenticate thesource, taking appropriate action to suspend the Certificate if the request is authentic and approved.
Once suspended, the serial number of the Certificate and the date and time shall be added to theappropriate CRL. CRL reason code “certificateHold” will be included. CRLs may be published
immediately or they may be published as defined within the Issuing CA’s CPS.
4.9.16 Limits on Suspension Period
There are no limits on the Certificate suspension period.

4.10 Certificate Status Services
4.10.1 Operational Characteristics
Issuing CAs shall provide a Certificate status service either in the form of a CRL distribution pointor an OCSP responder or both. Revocation entries may be removed after expiry of the Certificate
to promote more efficient CRL file size management, except for Code Signing Certificates (only 10
years after expiry).
For other Certificate types, Issuing CAs shall not remove revocation entries on CRL or OCSP until
after the Expiry Date of the revoked Certificate.
If required by Root Programs or CA/B Forum requirements, Issuing CAs may backdate revocationof Certificates with the revocationDate field, as an exception to the best practice described in RFC
5280 to use the invalidityDate field.
4.10.2 Service Availability
Issuing CAs shall maintain 24x7 availability of Certificate status services and may choose to use
additional content distribution network cloud based mechanisms to aid service availability. Issuing
CAs shall maintain a continuous 24x7 ability to respond internally to a high-priority Certificate
Problem Report, and where appropriate, forward such a complaint to law enforcement authorities,
and/or revoke a Certificate that is the subject of such a complaint.

GlobalSign CP (Certificate Policy)
Version: 7.0

51 of 77

4.10.3 Operational Features
No stipulation

4.11 End of Subscription
Subscribers may end their subscription to Certificate services by having their Certificate revoked or
naturally letting it expire. Where Issuing CAs have issued Issuing CAs capable of end entity
issuance contracts between parties must be maintained unless revocation is used to terminate thecontract.

4.12 Key Escrow and Recovery
4.12.1 Key Escrow and Recovery Policy and Practices
CA Private Keys are never escrowed. An Issuing CA that offers key escrow services to Subscribers
may escrow Subscriber Private Keys. Any Private Keys that are escrowed must be held in at least
the same level of security as when the Key Pair was originally created.
4.12.2 Session Key Encapsulation and Recovery Policy and Practices
No stipulation

5.0 Facility, Management, and Operational Controls
5.1

Physical Controls

Issuing CAs shall have physical and environmental security policies for systems used for Certificate
issuance and management which cover physical access control, natural disaster protection, fire
safety factors, failure of supporting utilities (e.g. power, telecommunications), structure collapse,
plumbing leaks, protection against theft, breaking & entering, and disaster recovery. Controls shallbe implemented to avoid loss, damage or Compromise of assets and interruption to businessactivities and theft of information and information processing facilities.
5.1.1

Site Location and Construction

Issuing CAs shall ensure that critical and sensitive information processing facilities are housed insecure areas with appropriate security barriers and entry controls. They shall be physicallyprotected from unauthorized access, damage and interference, and the protections provided shallbe commensurate with the identified risks in risk analysis plans.
5.1.2

Physical Access

Issuing CAs shall ensure that the facilities used for Certificate life cycle management are operated
in an environment that physically protects the services from Compromise through unauthorizedaccess to systems or data. An authorized employee shall always accompany any unauthorized
person entering a physically secured area. Physical protections shall be achieved through thecreation of clearly defined security perimeters (i.e. physical barriers) around the systems hosting
the CA operations. No parts of the CA premises shall be shared with other organizations within thisperimeter.
5.1.3

Power and Air Conditioning

Issuing CAs shall ensure that the power and air conditioning facilities are sufficient to support theoperation of the CA system.
5.1.4

Water Exposures

Issuing CAs shall ensure that the CA system is protected from water exposure.
5.1.5Fire Prevention and Protection

Issuing CAs shall ensure that the CA system is protected with a fire suppression system.
5.1.6

Media Storage

Issuing CAs shall ensure that any media used is securely handled to protect it from damage, theftand unauthorized access. Media management procedures shall be protected against obsolescenceand deterioration of the media within a defined period of time. Records are required to be retained.
GlobalSign CP (Certificate Policy)
Version: 7.0

52 of 77

All media shall be handled securely in accordance with requirements of the information asset
classification scheme and media containing sensitive data must be securely disposed of when nolonger required.
5.1.7

Waste Disposal

Issuing CAs shall ensure that all media used for the storage of information is declassified or
destroyed in a generally accepted manner before being released for disposal.
5.1.8

Off-Site Backup

Issuing CAs shall ensure that full system backups of the Certificate issuance system are sufficient
to recover from system failures and are made periodically, as defined in the Issuing CA’s CPS.
Back-up copies of essential business information and software must be taken regularly. Adequate
back-up facilities must be provided to ensure that all essential business information and software
can be recovered following a disaster or media failure. Back-up arrangements for individual
systems shall be regularly tested to ensure that they meet the requirements of business continuity
plans. At least one full backup copy must be stored at an offsite location (at a location separate
from the Certificate issuance equipment). Backups shall be stored at a site with physical andprocedural controls commensurate to that of the operational facility.

5.2

Procedural Controls

5.2.1

Trusted Roles

Issuing CAs should ensure that all operators and administrators including Validation Specialists are
acting in the capacity of a trusted role. Trusted roles are such that no conflict of interest is possible,
and the roles are distributed such that no single person can circumvent the security of the CA
system.
GlobalSign may subscribe certificates for GlobalSign affiliate companies, or persons identified inassociation with these companies (as a subject). GlobalSign affiliate companies includes
GlobalSign's parent and subsidiary companies, as well and other companies that share a same
parent company as GlobalSign.
Trusted roles include but are not limited to the following:
•
•
•
•
•
•
5.2.2

Developers: Responsible for development of CA systems.
Security Manager: overall responsibility for administering the implementation of the CA's
security practices, cryptographic key life cycle management functions (e.g., key
component custodians);
Administrator: approval of the generation, revocation and suspension of certificates;
System Engineer: installation, configuration and maintenance of the CA
systems, viewing and maintenance of CA system archives and audit logs;
Operator: day-to-day operation of CA systems and system backup and recovery;
Key Manager: cryptographic key life cycle management functions (e.g., key component
custodians).
Number of Persons Required per Task

Issuing CAs shall state the number of persons required per task within their CPS. The goal is toguarantee the trust for all CA services (Key Pair generation, Certificate generation, and revocation)
so that any malicious activity would require collusion. Where multiparty control is required, at least
one of the participants shall be an Administrator. All participants shall serve in a trusted role asdefined in Section 5.2.1 above.
5.2.3

Identification and Authentication for Each Role

Before appointing a person to a trusted role, Issuing CAs shall run a background check. Each roledescribed above is identified and authenticated in a manner to guarantee that the right person has
the right role to support the CA. The CPS should describe the mechanisms that are used to identify
and authenticate people appointed to trusted roles.

GlobalSign CP (Certificate Policy)
Version: 7.0

53 of 77

5.2.4

Roles Requiring Separation of Duties

Issuing CAs shall enforce role separation either by the CA equipment or procedurally or by bothmeans.
Individual CA personnel are specifically designated to the roles defined in Section 5.2.1 above
Roles requiring a separation of duties include:• Those performing approval of the generation, revocation, and suspension of certificates.
(Validation Specialists)• Those performing installation, configuration, and maintenance of the CA systems. (Infra
system engineer)• Those with overall responsibility for administering the implementation of the CA’s security
practices. (Security Officer)• Those performing duties related to cryptographic key life cycle management (e.g., key
component custodians). (CA activation data holders)• Those performing CA systems development. (Developers)• Those performing CA systems auditing (Infra Operator, Auditor)

5.3
5.3.1

Personnel Controls
Qualifications, Experience, and Clearance Requirements

Prior to the engagement of any person in the Certificate Management Process, whether as an
employee, agent, or an independent contractor, Issuing CA shall verify the identity andtrustworthiness of such person.
Issuing CAs shall employ a sufficient number of personnel that possess the expert knowledge,
experience and qualifications necessary for the offered services, as appropriate to the job function.
Issuing CA personnel should fulfil the requirement of expert knowledge, experience andqualifications through formal training and education, actual experience, or a combination of the two.
Trusted roles and responsibilities, as specified in the Issuing CA’s CPS, are documented in job
descriptions. Issuing CA personnel (both temporary and permanent) have job descriptions definedfrom the view point of separation of duties and least privilege, determining position sensitivity basedon the duties and access levels, background screening and employee training and awareness.
Issuing CA personnel shall be formally appointed to trusted roles.
5.3.2

Background Check Procedures

All Issuing CA personnel in trusted roles shall be free from conflicting interests that might prejudice
the impartiality of the CA operations. The Issuing CA shall not appoint to a trusted role any person
who is known to have a conviction for a serious crime or another offence, is such conviction affects
his/her suitability for the position. Personnel do not have access to the trusted functions until any
necessary checks are completed and results analysed, provided such checks are permitted by thejurisdiction in which the person will be employed. All persons filling trusted roles shall be selectedon the basis of loyalty, trustworthiness, and integrity, and shall be subject to backgroundinvestigation.
Any use of information revealed by background checks by the Issuing CA shall be in compliancewith applicable laws of jurisdiction where the person is employed.
5.3.3

Training Requirements

Issuing CA shall provide all personnel performing information verification duties with skills-trainingthat covers basic Public Key Infrastructure knowledge, authentication and vetting policies andprocedures (including the CA’s Certificate Policy and/or Certification Practice Statement), common
threats to the information verification process (including phishing and other social engineering
tactics), and the Baseline Requirements.
Issuing CA maintains records of such training and ensures that personnel entrusted with Validation
Specialist duties maintain a skill level that enables them to perform such duties satisfactorily.

GlobalSign CP (Certificate Policy)
Version: 7.0

54 of 77

Issuing CA documents that each Validation Specialist possesses the skills required by a task before
allowing the Validation Specialist to perform that task.
Issuing CA requires all Validation Specialists to pass an examination provided by the CA on theinformation verification requirements outlined in the Baseline Requirements.
5.3.4

Retraining Frequency and Requirements

All personnel in Trusted Roles shall maintain skill levels consistent with GlobalSign’s training andperformance programs.
Any significant change to the operations shall have a training (awareness) plan with at least annual
training on information security, and the execution of such plan shall be documented.
5.3.5

Job Rotation Frequency and Sequence

Issuing CAs should ensure that any change in the staff will not affect the operational effectivenessof the service or the security of the system.
5.3.6

Sanctions for Unauthorized Actions

Appropriate disciplinary sanctions shall be applied to personnel violating provisions and policies
within the CP, CPS or CA related operational procedures.
5.3.7

Independent Contractor Requirements

Contractor personnel employed for Issuing CA operations must be subjected to the same process,procedures, assessment, security control and training as permanent CA personnel.
5.3.8

Documentation Supplied to Personnel

Issuing CA should make available to its personnel this CP, any corresponding CPS and any
relevant statutes, policies or contracts. Other technical, operational and administrative documents(e.g., administrator manuals, user manuals, etc.) are provided in order for the trusted personnel toperform their duties.
Documentation is maintained identifying all personnel who received training and the level of training
completed.

5.4

Audit Logging Procedures

5.4.1

Types of Events Recorded

Issuing CA and each Delegated Third Party shall record events related to the security of their
Certificate Systems, Certificate Management Systems, Root CA Systems, and Delegated Third
Party Systems. Issuing CA and each Delegated Third Party shall record events related to theiractions taken to process a certificate request and to issue a Certificate, including all information
generated and documentation received in connection with the certificate request; the time and date;
and the personnel involved. Issuing CA shall make these records available to its Qualified Auditor.
Issuing CA shall record at least the following events:
1. CA certificate and key lifecycle events, including:
i.
ii.
iii.
iv.
v.
vi.
vii.

Key generation, backup, storage, recovery, archival, and destruction;
Certificate requests, renewal, and re-key requests, and revocation;
Approval and rejection of certificate requests;
Cryptographic device lifecycle management events;
Generation of Certificate Revocation Lists;
Signing of OCSP Responses; andIntroduction of new Certificate Profiles and retirement of existing Certificate
Profiles.

2. Subscriber Certificate lifecycle management events, including:i.

Certificate requests, renewal, and re-key requests, and revocation;

GlobalSign CP (Certificate Policy)
Version: 7.0

55 of 77

ii.
iii.
iv.
v.
vi.

All verification activities stipulated in this Certificate Policy;
Approval and rejection of certificate requests;
Issuance of Certificates;
Generation of Certificate Revocation Lists; andSigning of OCSP Responses.

3. Security events, including:
i.
ii.
iii.
iv.
v.
vi.
vii.

Successful and unsuccessful PKI system access attempts;
PKI and security system actions performed;
Security profile changes;
Installation, update and removal of software on a Certificate System;
System crashes, hardware failures, and other anomalies;
Firewall and router activities; andEntries to and exits from the CA facility.

Log records must include the following elements:
1. Date and time of event;2. Identity of the person making the journal record; and3. Description of the event.
5.4.2

Frequency of Processing Log

No stipulation.
5.4.3

Retention Period for Audit Log

Issuing CA and each Delegated Third Party shall retain, for at least two (2) years:
1. CA certificate and key lifecycle management event records (as set forth in Section 5.4.1(1)) after the later occurrence of:i.
the destruction of the CA Private Key; orii.
the revocation or expiration of the final CA Certificate in that set of Certificatesthat have an X.509v3 basicConstraints extension with the cA field set to true andwhich share a common Public Key corresponding to the CA Private Key;
2. Subscriber Certificate lifecycle management event records (as set forth in Section 5.4.1(2)) after the expiration of the Subscriber Certificate;
3. Any security event records (as set forth in Section 5.4.1 (3)) after the event occurred.
5.4.4

Protection of Audit Log

The events must be logged in a way that they cannot be deleted or destroyed (except for transfer
to long term media) for any period of time that they are retained.
The events must be logged in a manner to ensure that only trusted roles can perform operations
without modifying integrity, authenticity and confidentiality of the data.
The records of events must be protected in a manner to prevent alteration and detect tampering.
The records of events must be date stamped in a secure manner that guarantees, from the date ofcreation of the record to the end of the archive period that there is a trusted link between the eventand the time of its realisation.
5.4.5

Audit Log Backup Procedures

Audit logs must be backed-up in a secure location (for example, a fire proof safe), under the control
of a trusted role, and separated from their component source generation. Audit log backup should
be protected to the same degree as the originals.
5.4.6

Audit Collection System

The audit log collection systems may be an internal component. Audit processes must be initiatedat system start up and may finish only at system shutdown. The audit collection system should
ensure the integrity and availability of the data collected. If necessary, the audit collection system
GlobalSign CP (Certificate Policy)
Version: 7.0

56 of 77

should protect the data confidentiality. In the case of a problem occurring during the process of theaudit collection the Issuing CAs must determine whether to suspend Issuing CA operations until
the problem is solved.
5.4.7

Notification to Event-Causing Subject

No stipulation.
5.4.8

Vulnerability Assessments

Issuing CA shall perform annual risk assessments that:
1. Identifies foreseeable internal and external threats that could result in unauthorized access,disclosure, misuse, alteration, or destruction of any Certificate Data or Certificate
Management Process;2. Assesses the likelihood and potential damage of these threats, taking into consideration
the sensitivity of the Certificate Data and Certificate Management Processes; and3. Assesses the sufficiency of the policies, procedures, information systems, technology, andother arrangements that the Issuing CA has in place to counter such threats.
Issuing CA shall also perform regular vulnerability assessment and penetration testing covering all
CA assets related to Certificate issuance, products and services. Assessments focus on internaland external threats that could result in unauthorized access, tampering, modification, alteration or
destruction of the Certificate issuance process.

5.5

Records Archival

5.5.1

Types of Records Archived

Issuing CA and each Delegated Third Party shall archive all audit logs (as set forth in Section 5.4.1).
Additionally, Issuing CA and each Delegated Third Party shall archive:
1. Documentation related to the security of their Certificate Systems, Certificate Management
Systems, Root CA Systems, and Delegated Third Party Systems; and2. Documentation related to their verification, issuance, and revocation of certificate requests
and Certificates.
5.5.2

Retention Period for Archive

Issuing CA shall retain audit logs (as set forth in Section 5.4.1) and records (as set forth in Section
5.5.1) for at least the retention period defined by the WebTrust and/or eIDAS or UK eIDAS
requirements for the Certificate type.
5.5.3

Protection of Archive

The archives should be created in such a way that they cannot be deleted or destroyed (except fortransfer to long term media) within the period for which they are required to be held. Archive
protections should ensure that only trusted roles can perform operations without modifying integrity,
authenticity and confidentiality of the data. If the original media cannot retain the data for therequired period, a mechanism to periodically transfer the archived data to new media will be definedby the archive site.
5.5.4

Archive Backup Procedures

No stipulation.
5.5.5

Requirements for Timestamping of Records

If a timestamping service is used to date the records, it must comply with the requirements definedin Section 6.8. Irrespective of timestamping methods, all logs must have must have data indicating
the time at which the event occurred.
5.5.6

Archive Collection System (Internal or External)

The archive collection system complies with the security requirements defined in Section 5.3.
5.5.7

Procedures to Obtain and Verify Archive Information

No stipulation.
GlobalSign CP (Certificate Policy)
Version: 7.0

57 of 77

5.6

Key Changeover

Issuing CAs may periodically changeover Key material for Issuing CAs in accordance with Section
6.3.2. Certificate Subject information may be modified and Certificate profiles may be altered toadhere to new best practices. Private Keys used to sign previous Subscriber Certificates shall bemaintained until such time as all Subscriber Certificates have expired.

5.7

Compromise and Disaster Recovery

5.7.1

Incident and Compromise Handling Procedures

Issuing CAs shall establish business continuity procedures that outline the steps to be taken in theevent of the corruption or loss of computing resources, software and/or data that could disturb or
Compromise the Issuing CA services. Issuing CAs should carry out risk assessments to evaluatebusiness risk and determine the necessary security requirements and operational procedures tobe taken as a consequence of its disaster recovery plan. This risk analysis is regularly reviewed
and revised if necessary (threat evolution, vulnerability evolution, etc.). This business continuity is
included in the scope of the audit process as described in Section 8 to validate which operations
should be first restored after a disaster and the recovery plan.
Issuing CA personnel that serve in a trusted role and operational role should be specially trained
to operate according to procedures defined in the disaster recovery plan for business criticaloperations.
If an Issuing CA detects a potential hacking attempt or another form of Compromise, it should
perform an investigation in order to determine the nature and the degree of damage. Otherwise,
the Issuing CA should assess the scope of potential damage in order to determine if the CA or RA
system needs to be rebuilt, if only some Certificates need to be revoked, and/or if a CA hierarchyneeds to be declared as Compromised. The CA disaster recovery plan should highlight which
services should be maintained (for example, revocation and Certificate status information).
5.7.2

Computing Resources, Software, and/or Data Are Corrupted

If any equipment is damaged or rendered inoperative, but the Private Keys are not destroyed, theoperation should be re-established as quickly as possible, giving priority to the ability to generate
Certificate status information according to the Issuing CA’s disaster recovery plan.
5.7.3

Issuing CA Private Key Compromise Procedures

In the event an Issuing CA Private Key is Compromised, lost, destroyed, or suspected to be
Compromised:
•

5.7.4

The Issuing CA shall, after investigation of the problem, decide whether the Issuing CA
Certificate should be revoked. If so, then:o All the Subscribers who have been issued a Certificate will be notified at theearliest feasible opportunity; ando A new Issuing CA Key Pair shall be generated, or an alternative existing CA
hierarchy shall be used to create new Subscriber Certificates.
Business Continuity Capabilities After a Disaster

The disaster recovery plan deals with the business continuity as described in Section 5.7.1.
Certificate status information systems should be deployed so as to provide 24 hours per day, 365
days per year availability.

5.8

CA or RA Termination

When it is necessary to terminate an Issuing CA or RA activities, the impact of the termination must
be minimized as much as possible in light of the prevailing circumstances and is subject to theapplicable Issuing CA and/or Registration Authority Agreements. Issuing CAs must specify theprocedures they will follow when terminating all or a portion of their Digital Certificate issuance andmanagement operations. The procedures must, at a minimum:• ensure that any disruption caused by the termination of an Issuing CA is minimised asmuch as possible;• ensure that archived records of the Issuing CA are retained;

GlobalSign CP (Certificate Policy)
Version: 7.0

58 of 77

•
•
•
•
•
•
•
5.8.1

ensure that prompt notification of termination is provided to Subscribers, Authorised
Relying Parties, Application Software Providers, and other relevant stakeholders in
GlobalSign certificate lifecycles;
ensure Certificate status information services are provided and maintained for theapplicable period after termination, including, if applicable, transferring Certificate status
information services to another GMO Internet Group entity;
ensure that a process for revoking all Digital Certificates issued by an Issuing CA at thetime of termination is maintained;
notify all auditors including the eIDAS/UK eIDAS Conformity Assessment Bodies; andnotify the Belgian eIDAS supervisory body (FPS Economy, SMEs, Self-employed andEnergy - Quality and Safety)
notify the United Kingdom UK eIDAS supervisory body (Information Commissioner’s
Office)notify other relevant Government and Certification bodies under applicable laws andrelated regulations
Successor Issuing Certification Authority

To the extent that it is practical and reasonable, the successor Issuing CA should assume the samerights, obligations, and duties as the terminating Issuing CA.

6.0 Technical Security Controls
6.1
6.1.1

Key Pair Generation and Installation
Key Pair Generation

6.1.1.1

CA Key Pair Generation

For Root CA Key Pairs, GlobalSign shall performs following controls;
1. prepares and follows a Key Generation Script,
2. has a Qualified Auditor witness the Root CA Key Pair generation process or record a videoof the entire Root CA Key Pair generation process, and3. has a Qualified Auditor issue a report opining that GlobalSign followed its key ceremony
script during its Key and Certificate generation process and the controls used to ensure theintegrity and confidentiality of the Key Pair.
In other CA Key Pairs, issuing CA shall performs following controls;
1. Generates the keys in a physically secured environment as described in Section 5.1 and5.2.2. of Certificate Policy and/or Certification Practice Statement;
2. Generates the CA keys using personnel in trusted roles under the principles of multiple
person control and split knowledge;
3. Generate the CA keys within cryptographic modules meeting the applicable technical andbusiness requirements as disclosed in the CA’s Certificate Policy and/or Certification
Practice Statement;
4. Log its CA key generation activities; and5. maintain effective controls to provide reasonable assurance that the Private Key was
generated and protected in conformance with the procedures described in its Certificate
Policy and/or Certification Practice Statement and (if applicable) its Key Generation Script.
Issuing CAs shall generate all issuing Key Pairs in a physically secure environment by personnel
in trusted roles under, at least, dual control. External witnesses (Ideally an independent auditor who
normally performs audits on a regular basis) should be present or the ceremony, as a whole, must
be videotaped/recorded. Issuing CA key generation is carried out within a device which is at leastcertified to FIPS 140-2 level 3.
Issuing CA shall also reject a certificate request if it has a known weak Private Key.
6.1.1.2

Subscriber Key Pair Generation

For Subscriber keys generated by issuing CA, Key generation must be performed in a secure
cryptographic device that meets FIPS 140-2 (or equivalent) using key generation algorithm and key
size as specified in Section 6.1.5 and 6.1.6.
GlobalSign CP (Certificate Policy)
Version: 7.0

59 of 77

For Qualified Certificates where the Private Key related to the certified Public Key resides in a
QSCD, Subscriber keys must be generated and stored within a recognized Qualified Signature
Creation Device (QSCD). Issuing CAs shall monitor QSCD certification status and apply
appropriate measures, including revocation, if the certification status of a QSCD changes.
6.1.2

Private Key Delivery to Subscriber

Issuing CAs that create Private Keys on behalf of Subscribers may do so only when sufficient
security is maintained within the key generation process and any onward issuance process to the
Subscriber. The cryptographic algorithms regarding Public/Private key generation (encryption, sign,
cryptographic hash, RNG or PRNG etc.) were approved by FIPS, the Public/Private key generation
algorithm is also specified in FIPS 186-4.
The generated Public/Private key is encrypted with PIN code which was provided by the Subscriber.
The encrypted Public/Private key will be delivered in TLS session, authenticated by the password
pre-registered by an administrator of the Subscriber.
As of March 1, 2018, GlobalSign does not generate private keys for publicly trusted SSL
Certificates.
6.1.3

Public Key Delivery to Certificate Issuer

Issuing CAs shall only accept Public Keys from RAs that have been protected during transit andhave had the authenticity and integrity of their origin from the RA suitably verified.
6.1.4

CA Public Key Delivery to Relying Parties

Issuing CAs shall ensure that Public Key delivery to Relying Parties is undertaken in such a way
as to prevent substitution attacks. This may include working with commercial browsers and platform
operators to embed Root Certificate Public Keys into root stores and operating systems. Issuing
CA Public Keys may be delivered by the Subscriber in the form of a chain of Certificates or via a
Repository operated by the Issuing CA and referenced within the profile of the issued Certificate.
6.1.5

Key Sizes

GlobalSign follows NIST Special Publication 800-133 Revision 2 (2020) - Recommendation for
Cryptographic Key Generation - for recommended timelines and best practices in the choice of Key
Pairs for Root CAs, Issuing CAs and end entity Certificates delivered to Subscribers.
GlobalSign selects from the following Key Sizes/Hashes for Root Certificates, Issuing CA
Certificates, and end entity Certificates as well as CRL/OCSP Certificate status responders. These
choices align with the Baseline Requirements and EV Guidelines:
Root CA Certificates
Digest algorithm
Minimum RSA
modulus size (bits)
ECC curve

Validity period beginning on or before
31 Dec 2010
SHA-1, SHA-256, SHA-384 or SHA512
20481

Validity period beginning after 31 Dec
2010
SHA-256, SHA-384 or SHA-512

NIST P-256, P-384, or P-521

NIST P-256, P-384, or P-521

2048

Subordinate Certificates
Validity period beginning on or before
31 Dec 2010 and ending on or before
31 Dec 2013

Validity period beginning after 31 Dec
2010 or ending after 31 Dec 2013

1

RSA key modulus size in bits must be divisible by 8. A Root CA Certificate issued prior to 31 Dec. 2010
with an RSA key size less than 2048 bits MAY still serve as a trust anchor for Subscriber Certificates issuedin accordance with these Requirements.

GlobalSign CP (Certificate Policy)
Version: 7.0

60 of 77

Digest algorithm
Minimum
RSA
modulus size (bits)
ECC curve

SHA-1, SHA-256, SHA-384 or SHA512
1024

SHA-12, SHA-256, SHA-384 or SHA512
2048

NIST P-256, P-384, or P-521

NIST P-256, P-384, or P-521

Subscriber Certificates
Digest algorithm
Minimum RSA
modulus size (bits)
ECC curve
RSASSA-PSS4

SHA-13, SHA-256, SHA-384 or SHA- 512
2048
NIST P-256, P-384, or P-521

As of July 1, 2017, the minimum key size for new Root CA certificates which issue Subordinate
CAs for AATL is RSA 3072-bit or ECC NIST P-384.
As of January 1, 2021, the minimum key size for new Root and Subordinate CA Certificates whichissue Code Signing and Timestamping Certificates is RSA 3072-bit or ECC NIST P-256
As of June 1, 2021, the minimum key size for new Code Signing and Timestamping Subscriber
Certificates for CodeSign is RSA 3072-bit or ECC NIST P-256.
6.1.6

Public Key Parameters Generation and Quality Checking

Issuing CAs shall generate Key Pairs in accordance with FIPS 186 and shall use reasonable
techniques to validate the suitability of Public Keys presented by Subscribers. Known weak keys
shall be tested for and rejected at the point of submission. Issuing CAs shall reference Baseline
Requirements Section 6.1.6 on quality checking.
6.1.7

Key Usage Purposes (as per X.509 v3 Key Usage Field)

Issuing CAs shall set key usage of Certificates depending on their proposed field of application via
the v3 Key Usage Field for X.509 v3 (See Section 7.1).
Private Keys corresponding to Root Certificates shall not be used to sign Certificates except in thefollowing cases:
1. Self-signed Certificates to represent the Root CA itself;
2. Certificates for Subordinate CAs and Cross Certificates;
3. Certificates for OCSP Response verification.

6.2

Private Key Protection and Cryptographic Module Engineering Controls

Issuing CAs shall implement physical and logical safeguards to prevent unauthorized certificate
issuance. Protection of the CA Private Key outside the validated system or device specified above
must consist of physical security, encryption, or a combination of both, implemented in a mannerthat prevents disclosure of the CA Private Key. Issuing CAs shall encrypt its Private Key with analgorithm and key-length that, according to the state of the art, are capable of withstanding
cryptanalytic attacks for the residual life of the encrypted key or key part.
6.2.1

Cryptographic Module Standards and Controls

Issuing CAs shall protect its CA Private Key in a system or device that has been validated asmeeting at least FIPS 140-2 level 3, FIPS 140-3 level 3, or an appropriate Common Criteria
Protection Profile or Security Target, EAL 4 (or higher), which includes requirements to protect thePrivate Key and other assets against known threats.

2

SHA-1 may be used for IntranetSSL Subordinate CA Certificates, but they are not chained to publicly
trusted roots.
3

SHA-1 may be used for IntranetSSL Subscriber CA Certificates, but they are not chained to publicly
trusted roots.
48

RSASSA-PSS MAY be used with RSA keys for PersonalSign Certificates in accordance with the criteria
defined in Section 7.1.3.4 RSASSA-PSS MAY be used with RSA keys for PersonalSign Certificates inaccordance with the criteria defined in Section 7.1.3.

GlobalSign CP (Certificate Policy)
Version: 7.0

61 of 77

Issuing CAs that require Subscribers to use specific systems for Private Key protection must
contractually obligate the Subscriber to use such a system or provide a suitable mechanism toguarantee protection.
6.2.2

Private Key (n out of m) Multi-Person Control

Issuing CAs shall activate Private Keys for cryptographic operations with multi-person control(using CA activation data) performing duties associated with their trusted roles. The trusted roles
permitted to participate in this Private Key multi-person controls are strongly authenticated (i.e.
token with PIN code).
6.2.3

Private Key Escrow

Issuing CAs shall not escrow CA Private Keys for any reason.
6.2.4

Private Key Backup

Issuing CAs shall back up CA Private Keys under the same multi-person control as the originalPrivate Key.
6.2.5

Private Key Archival

Issuing CAs shall not archive Private Keys and must ensure that any temporary location where a
Private Key may have existed in any memory location during the generation process is purged.
6.2.6

Private Key Transfer into or from a Cryptographic Module

Issuing CA Private Keys must be generated, activated, and stored in Hardware Security Modules.
When Private Keys are outside of a Hardware Security Module (either for storage or transfer), theymust be encrypted. Private Keys must never exist in plain text outside of a cryptographic module.
If Issuing CA becomes aware that a CA’s Private Key has been communicated to an unauthorized
person or an organization not affiliated with the CA, then Issuing CA shall revoke all certificatesthat include the Public Key corresponding to the communicated Private Key.
6.2.7

Private Key Storage on Cryptographic Module

Issuing CAs shall store Private Keys on a device meeting the requirements of Section 6.2.1.
6.2.8

Method of Activating Private Key

Issuing CAs are responsible for activating the Private Key in accordance with the instructions anddocumentation provided by the manufacturer of the hardware security module. Subscribers are
responsible for protecting Private Keys in accordance with the obligations that are presented in theform of a Subscriber Agreement or Terms of Use.
6.2.9

Method of Deactivating Private Key

Issuing CAs shall ensure that Hardware Security Modules that have been activated are not left
unattended or otherwise available to unauthorized access. During the time, an Issuing CA’s
Hardware Security Module is on-line and operational, it shall only be used to sign Certificates and
CRL/OCSPs from an authenticated RA. When a CA is no longer operational, its Private Key must
be removed from the Hardware Security Module.
6.2.10 Method of Destroying Private Key
Issuing CA Private Keys must be destroyed when they are no longer needed or when the Certificate
to which they correspond have expired or are revoked. Destroying Private Keys requires Issuing
CAs to destroy all associated CA secret activation data in the HSM in such a manner that no
information can be used to deduce any part of the Private Key.
6.2.11 Cryptographic Module Rating
See Section 6.2.1

6.3
6.3.1

Other Aspects of Key Pair Management
Public Key Archival

Issuing CAs must archive Public Keys from Certificates.

GlobalSign CP (Certificate Policy)
Version: 7.0

62 of 77

6.3.2

Certificate Operational Periods and Key Pair Usage Periods

Certificates shall have a maximum validity period of:Type
Root Certificates5
TPM Root Certificates
Publicly Trusted Sub-CAs/Issuer CAs
PersonalSign Certificates
Code Signing Certificates
EV Code Signing Certificates
AATL End Entity Certificates
Qualified Certificate for Electronic Signatures and Seals
DV SSL Certificates
AlphaSSL Certificates
OV SSL Certificates
EV SSL Certificates
Qualified Website Authentication Certificates
Intranet SSL
Timestamping Certificates
NAESB Certificates
Private Key Archival\Key Recovery Agent Certificates

Key Pair Usage Period
No stipulation
30 years
No stipulation
No stipulation
No stipulation
No stipulation
No stipulation
No stipulation
No stipulation
No stipulation
No stipulation
No stipulation
No stipulation
No stipulation
15 months
2 years
No stipulation

Max Validity Period
28 years
41 years
18 years
39 months
39 months
39 months
39 months
39 months
398 days
398 days
398 days
398 days
398 days
5 years
11 years
2 years
5 years

The Key Pair usage period can be up to the Certificate Validity Period.
Certificates signed by a specific CA must expire before or at the end of that CA Certificate Validity
period.
Issuing CAs must comply with the Baseline Requirements with respect to the maximum validity
period, in some cases thereby reducing the effective available Certificate term. In some cases, themaximum validity period may not be realized by the Subscriber in the event the current or future
Baseline Requirements impose requirements on Certification Authorities relative to Certificate
issuance that were not in place at the time the Certificate was originally issued, particularly in thecase of a request for reissuance, e.g., additional requirements are included for identification andauthentication for certain Certificate type, or maximum Validity Period is decreased.
Effective April 1, 2022, the maximum validity period of end entity certificates with id-kpemailProtection EKU is 1185 days.

6.4
6.4.1

Activation Data
Activation Data Generation and Installation

Generation and use of Issuing CA activation data used to activate Issuing CA Private Keys shallbe made during a key ceremony (Refer to Section 6.1.1). Activation data shall be generated
automatically by the appropriate HSM and delivered to a shareholder who must be a person intrusted role. The delivery method must maintain the confidentiality and the integrity of the activation
data.
6.4.2

Activation Data Protection

Issuing CA activation data must be protected from disclosure through a combination of
cryptographic and physical access control mechanisms. Issuing CA activation data must be storedon smart cards.
6.4.3

Other Aspects of Activation Data

Issuing CA activation data must only be held by Issuing CA personnel in trusted roles.

5 2048-bit keys generated prior to 2003 using RSA may be used for 25 years due to limited usage due to key

size restrictions within hardware, root stores and operating systems.

GlobalSign CP (Certificate Policy)
Version: 7.0

63 of 77

6.5

Computer Security Controls

6.5.1

Specific Computer Security Technical Requirements

The following computer security functions must be provided by the operating system, or through a
combination of operating system, software, and physical safeguards. The Issuing CA PKI
components must include the following functions:
•
•
•
•
•
•
•
•
•
•
•

Require authenticated logins for trusted role;
Provide discretionary access control with least privilege;
Provide security audit capability (protected in integrity);
Prohibit object re-use;
Require use of strong password policy;
Require use of cryptography for session communication;
Require trusted path for identification and authentication;
Provide means for malicious code protection;
Provide means to maintain software and firmware integrity;
Provide domain isolation and partitioning different systems and processes; andProvide self-protection for the operating system.

For accounts capable of directly causing certificate issuance, Issuing CA shall enforce multifactor
authentication.
6.5.2

Computer Security Rating

No Stipulation

6.6

Life Cycle Technical Controls

6.6.1

System Development Controls

The system development controls for the Issuing CA are as follows:
•
•
•
•
•
•

•
6.6.2

Use software that has been designed and developed under a formal, documented
development methodology;
Hardware and software procured are purchased in a fashion to reduce the likelihood thatany particular component was tampered with (e.g., by ensuring the equipment was
randomly selected at time of purchase);
Hardware and software are developed in a controlled environment, and the development
processes are defined and documented. This requirement does not apply to commercial
off-the-shelf hardware or software;
All hardware must be shipped or delivered via controlled methods that provide a continuous
chain of accountability, from the purchase location to the operations location;
The hardware and software are dedicated to performing CA activities. There are no otherapplications, hardware devices, network connections, or component software installed
which are not part of the CA operation;
Proper care is taken to prevent malicious software from being loaded onto the equipment.
Only applications required to perform the CA operations are installed on the equipment andare obtained from sources authorized by local policy. Issuing CA hardware and softwareare scanned for malicious code on first use and periodically thereafter; andHardware and software updates are purchased or developed in the same manner as
original equipment; and are installed by trusted and trained personnel in a defined manner.
Security Management Controls

The configuration of the Issuing CA system as well as any modifications and upgrades are
documented and controlled by the Issuing CA management. There is a mechanism for detecting
unauthorized modification to the Issuing CA software or configuration. A formal configuration
management methodology is used for installation and on-going maintenance of the Issuing CA
system. The Issuing CA software, when first loaded, is checked as being that supplied from thevendor, with no modifications, and is the version intended for use.

GlobalSign CP (Certificate Policy)
Version: 7.0

64 of 77

6.6.3

Life Cycle Security Controls

Issuing CA monitors the maintenance scheme requirements in order to maintain the level of trustof software and hardware that are evaluated and certified.

6.7

Network Security Controls

Issuing CA PKI components implement appropriate security measures to ensure they are guarded
against denial of service and intrusion attacks. Such measures include the use of security guards,
firewalls, and filtering routers. Unused network ports and services are turned off. Any boundary
control devices used to protect the network on which PKI equipment are hosted deny all but thenecessary services to the PKI equipment even if those services are enabled for other devices on
the network.

6.8

Timestamping

All Issuing CA components are regularly synchronized with a time service such as an atomic clock
or Network Time Protocol (NTP) service. A dedicated authority, such as a timestamping authority,
may be used to provide this trusted time. Time derived from the time service shall be used forestablishing the time of:••••Initial validity time of a CA Certificate;
Revocation of a CA Certificate;
Posting of CRL updates; andIssuance of Subscriber end entity Certificates.

Electronic or manual procedures may be used to maintain system time. Clock adjustments areauditable events.

7.0 Certificate, CRL, and OCSP Profiles
7.1

Certificate Profile

7.1.1

Version Number(s)Issuing CAs shall issue Certificates in compliance with X.509 Version 3.
7.1.2

Certificate Extensions

Issuing CAs shall issue Certificates in compliance with RFC 5280 and applicable best practiceincluding compliance to the current Baseline Requirements sections 7.2.1.1 through 7.2.1.5 except
where mentioned in this document or certification practice statements implementing this policy.
Criticality shall also follow best practice and where possible prevent unnecessary risks to Relying
Parties when applied to name constraints.
7.1.3

Algorithm Object Identifiers

Issuing CAs shall issue Certificates with algorithms indicated by the following OIDs
SHA1WithRSAEncryption{iso(1) member-body(2) us(840) rsadsi (113549) pkcs(1) pkcs-1(1) 5}*
SHA256WithRSAEncryption {iso(1) member-body(2) us(840) rsadsi (113549) pkcs(1) pkcs-1(1) 11}
SHA384WithRSAEncryption {iso(1) member-body(2) us(840) rsadsi (113549) pkcs(1) pkcs-1(1) 12}
SHA512WithRSAEncryption {iso(1) member-body(2) us(840) rsadsi (113549) pkcs(1) pkcs-1(1) 13}
ECDSAWithSHA256ECDSAWithSHA384
ECDSAWithSHA512RSASSA-PSS{iso(1) member‐body(2) us(840) ansi‐X9‐62 (10045) signatures(4) ecdsa‐with‐SHA2(3) 2}{iso(1) member‐body(2) us(840) ansi‐X9‐62 (10045) signatures(4) ecdsa‐with‐SHA2(3) 3}{iso(1) member‐body(2) us(840) ansi‐X9‐62 (10045) signatures(4) ecdsa‐with‐SHA2(3) 4}{iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) rsassa-pss(10)}*Not used for signing publicly trusted end entity certificates

7.1.4

Name Forms

Issuing CAs shall issue Certificates with name forms compliant to RFC 5280 and section 7.1.4 of
the Baseline Requirements.

GlobalSign CP (Certificate Policy)
Version: 7.0

65 of 77

For publicly trusted SSL certificates, the Subject organizationalUnitName field is not included for
Certificates issued on or after September 1, 2022.
7.1.5

Name Constraints

Issuing CAs may issue Subordinate CA Certificates with name constraints and mark as critical
where necessary. When name constraints are NOT set on a Subordinate CA, such CA must be
subject for full audit specified in section 8.0 of this document.
GlobalSign may issue Subordinate CA Certificates with name constraints and mark as critical whereapplicable.
7.1.6

Certificate Policy Object Identifier

GlobalSign follows Section 7.1.6 of Baseline Requirements.
7.1.7

Usage of Policy Constraints Extension

No stipulation
7.1.8

Policy Qualifiers Syntax and Semantics

Issuing CAs may issue Certificates with a policy qualifier to aid Relying Parties in determining
applicability.
7.1.9

Processing Semantics for the Critical Certificate Policies Extension

No stipulation
7.1.10 Serial Numbers
Each Issuing CA must issue certificates that include a unique (within the context of the Issuer
Subject DN and CA certificate serial number) non-sequential Certificate serial number greater thanzero (0) containing at least 64 bits of output from a CSPRNG.
7.1.11 Special Provisions for Qualified Certificates
Qualified Certificates are configured to meet the applicable profile requirements of ETSI EN 319
412 and ETSI TS 119 495.
7.1.11.1 Qualified Certificates for Electronic Signatures
Qualified Certificates for Electronic Signatures contain following qcStatements:••

id-etsi-qcs-QcCompliance
id-etsi-qct-esign

If the Private Key related to the certified Public Key resides in a QSCD “id-etsi-qcs-QcSSCD” isincluded.
Qualified Certificates for Electronic Signatures which are issued under UK eIDAS include “id-etsiqcs-QcCClegislation” with value set as GB
7.1.11.2 Qualified Certificates for Electronic Seals
Qualified Certificates for Electronic Seals contain following qcStatements:••

id-etsi-qcs-QcCompliance
id-etsi-qct-eseal

If the Private Key related to the certified Public Key resides in a QSCD “id-etsi-qcs-QcSSCD” isincluded.
Qualified certificates for Electronic Seals which are issued for Open Banking use include “id-etsipsd2-qcStatement”.
Qualified Certificates for Electronic Seals which are issued under UK eIDAS include “id-etsi-qcsQcCClegislation” with value set as GB

GlobalSign CP (Certificate Policy)
Version: 7.0

66 of 77

7.1.11.3 Qualified Web Authentication Certificates
Qualified Web Authentication Certificates contain the following qualified statements:••

id-etsi-qcs-QcCompliance
id-etsi-qct-web

Qualified Web Authentication Certificates which are issued for Open Banking use include “id-etsipsd2-qcStatement”.
Qualified Web Authentication Certificates which are issued under UK eIDAS include “id-etsi-qcsQcCClegislation” with value set as GB

7.2

CRL Profile

7.2.1

Version Number(s)Issuing CAs shall issue Version 2 CRLs in compliance with RFC 5280.
7.2.2

CRL and CRL Entry Extensions

CRLs must include the CRL Number and Authority Key Identifier extensions and may support thereasoncode extension.

7.3

OCSP Profile

Issuer CAs may operate an Online Certificate Status Profile (OCSP) responder in compliance with
RFC 6960 or RFC 5019.
7.3.1

Version Number(s)Issuing CAs shall issue Version 1 OCSP responses.
7.3.2

OCSP Extensions

No stipulation

8.0 Compliance Audit and Other Assessments
The policies within this CP encompass relevant portions of currently applicable PKI standards forthe various vertical PKI industries in which Issuing CAs are required to operate.standards listed in
Section 1.0.

8.1

Frequency and Circumstances of Assessment

GlobalSign maintains its compliance with the WebTrust/eIDAS/UK eIDAS standards identified in
Section 1.0 via a Qualified Auditor on an annual (WebTrust), bi-annual (eIDAS/UK eIDAS) andcontiguous basis.

8.2

Identity/Qualifications of Assessor

Applicable audits of Issuing CAs shall be performed by a Qualified Auditor. A Qualified Auditor
means a natural person, Legal Entity, or group of natural persons or Legal Entities that collectively
possess the following qualifications and skills:
•
•
•
•
•

Independence from the subject of the audit;
The ability to conduct an audit that addresses the criteria specified in an Eligible Audit
Scheme such as stipulated in section 8.0 of this document;
Employs individuals who have proficiency in examining Public Key Infrastructuretechnology, information security tools and techniques, information technology and security
auditing, and the third-party attestation function;
Certified, accredited, licensed, or otherwise assessed as meeting the qualification
requirements of auditors under the audit scheme;
Bound by law, government regulation, or professional code of ethics; andGlobalSign CP (Certificate Policy)
Version: 7.0

67 of 77

•

Except in the case of an internal government auditing agency, maintains professional
liability/errors & omissions insurance with policy limits of at least one million US dollars($1,000,000) in coverage.

For eIDAS, the audit is performed by a conformity assessment body accredited by a European
Union member state national accreditation body on the basis of EN ISO/IEC 17065 as profiled by
ETSI EN 319 403 and in particular against the requirements defined in the eIDAS Regulation (EU)No 910/2014.
For UK eIDAS, the audit is performed by a conformity assessment body accredited on the basis of
EN ISO/IEC 17065 as profiled by ETSI EN 319 403 and in particular against the requirements
defined in the UK eIDAS Regulation (eIDAS (UK Legislation) and The Electronic Identification andTrust Services for Electronic Transactions Regulations 2016).

8.3

Assessor’s Relationship to Assessed Entity

Issuing CAs must choose an auditor/assessor who is completely independent from the Issuing CA.

8.4

Topics Covered by Assessment

The audit must meet the requirements of the audit scheme under which the assessment is being
made. These requirements may vary as audit schemes are updated.

8.5

Actions Taken as a Result of Deficiency

Issuing CAs, including cross signed Issuing CAs that are not technically constrained, must follow
the same process if presented with a material non-compliance by external auditors and must createa suitable corrective action plan to remove the deficiency.

8.6

Communications of Results

Results of the audit must be reported to the GlobalSign Policy Authority for analysis and resolutionof any deficiency through a subsequent corrective action plan. The results could also be madeavailable to any other appropriate entities that may be entitled to a copy of the results by law,regulation, or agreement. Copies of GlobalSign’s WebTrust for CAs audit reports can be found at:https://www.globalsign.com/en/repository/.

8.7

Self-Audit

Issuing CA shall monitor its adherence to this Certificate Policy, Issuing CA’s Certification PracticeStatement and other external requirements specified in the “Acknowledgements” section andstrictly control its service quality by performing self-audits on at least a quarterly basis against
randomly selected samples of at least 3 percent (6% for EV SSL Certificate and EV Code Signing
Certificate) of the Certificates issued.

9.0 Other Business and Legal Matters
9.1
9.1.1

Fees
Certificate Issuance or Renewal Fees

Issuing CAs may charge fees for Certificate issuance or renewal. Issuing CAs may also charge forre-issuance or re-key. Fees and any associated terms and conditions should be made clear to
Applicants.
9.1.2

Certificate Access Fees

Issuing CAs may charge for access to any database which stores issued Certificates.
9.1.3

Revocation or Status Information Access Fees

Issuing CAs may charge additional fees to Subscribers who have a large Relying Party communityand choose not to use OCSP stapling or other similar techniques to reduce the load on the Issuing
CAs Certificate status infrastructure.

GlobalSign CP (Certificate Policy)
Version: 7.0

68 of 77

9.1.4

Fees for Other Services

Issuing CAs may charge for other additional services such as timestamping.
9.1.5

Refund Policy

Issuing CAs may offer a refund policy to Subscribers. Subscribers who choose to invoke the refund
policy should have all issued Certificates revoked.

9.2
9.2.1

Financial Responsibility
Insurance Coverage

Issuing CAs that have no name constraints imposed on their Issuing CA shall maintain Commercial
General Liability insurance with policy limits of at least two million US dollars ($2,000,000) incoverage and Errors and Omissions / Professional Liability insurance with a policy limit of at least
five million ($5,000,000) US dollars in coverage. The Issuing CA’s insurance policies include
coverage for (1) claims for damages arising out of an act, error, or omission, unintentional breachof contract, or neglect in issuing or maintaining EV Certificates, and (2) claims for damages arisingout of infringement of the proprietary rights of any third party (excluding copyright, patent, andtrademark infringement), invasion of privacy, and advertising injury. Insurance is carried throughcompanies rated no less than A- as to policy holder's rating in the current edition of Best’s Insurance
Guide (or with an association of companies, each of the members of which are so rated).
9.2.2

Other Assets

No stipulation
9.2.3

Insurance or Warranty Coverage for End Entities

Issuer CAs may offer a warranty policy to Subscribers.

9.3
9.3.1

Confidentiality of Business Information
Scope of Confidential Information

Issuing CAs shall define the scope of confidential information within its CPS.
9.3.2

Information Not Within the Scope of Confidential Information

Any information not defined as confidential within the CPS shall be deemed public. Certificate status
information and Certificates themselves are deemed public.
9.3.3

Responsibility to Protect Confidential Information

Issuing CAs shall protect confidential information. Issuing CAs shall enforce protection ofconfidential information through training and contracts with employees, agents, and contractors.

9.4
9.4.1

Privacy of Personal Information
Privacy Plan

Issuing CAs shall protect personal information in accordance with a privacy policy published on asuitable Repository along with this CP.
9.4.2

Information Treated as Private

Issuing CAs shall treat all information received from Applicants that will not ordinarily be placed intoa Certificate as private. This applies both to those Applicants who are successful in being issued a
Certificate and those who are unsuccessful and rejected. Issuing CAs should periodically train all
RA and vetting staff as well as anyone who has access to the information about due care andattention that must be applied.
9.4.3

Information Not Deemed Private

Certificate status information and any Certificate content is deemed not private.

GlobalSign CP (Certificate Policy)
Version: 7.0

69 of 77

9.4.4

Responsibility to Protect Private Information

Issuing CAs are responsible for securely storing private information in accordance with a publishedprivacy policy document and may store information received in either paper or digital form. Any
backup of private information must be encrypted when transferred to suitable backup media.
9.4.5

Notice and Consent to Use Private Information

Personal information obtained from Applicants during the application and enrolment process isdeemed private and permission is required from the Applicant to allow the use of such information.
Issuing CAs should incorporate the relevant provisions within an appropriate Subscriber Agreement
including any additional information obtained from third parties that may be applicable to thevalidation process for the product or service being offered by the Issuing CA.
9.4.6

Disclosure Pursuant to Judicial or Administrative Process

Issuing CAs may disclose private information without notice to Applicants or Subscribers whererequired to do so by law or regulation.
9.4.7

Other Information Disclosure Circumstances

No Stipulation.

9.5

Intellectual Property Rights

Issuing CAs shall not knowingly violate the intellectual property rights of third parties. Public andPrivate Keys remain the property of Subscribers who legitimately hold them. Issuing CAs retain
ownership of Certificates however, they shall grant permission to reproduce and distributeCertificates on a non-exclusive, royalty free basis, provided that they are reproduced and distributedin full.

9.6

Representations and Warranties

9.6.1

CA Representations and Warranties

Issuing CAs use this CP and applicable Subscriber Agreements to convey legal conditions of usageof issued Certificates to Subscribers and Relying Parties. Participants that may makerepresentations and warranties include GlobalSign, RAs, Subscribers, Relying Parties, and anyother participants as it might become necessary. All parties including the Issuing CA, any RAs andSubscribers warrant the integrity of their respective Private Key(s). If any such party suspects thata Private Key has been Compromised they will immediately notify the appropriate RA.
Issuing CA represents and warrants to Certificate Beneficiaries, during the period when theCertificate is valid, Issuing CA has complied with its Certificate Policy and/or Certification PracticeStatement in issuing and managing the Certificate:•••

Right to Use Domain Name or IP Address: That, at the time of issuance, Issuing CA (i)implemented a procedure for verifying that the Applicant either had the right to use, or had
control of, the Domain Name(s) and IP address(es) listed in the Certificate’s Subject fieldand subjectAltName extension (or, only in the case of Domain Names, was delegated suchright or control by someone who had such right to use or control); (ii) followed the procedurewhen issuing the Certificate; and (iii) accurately described the procedure in Issuing CA’s
Certificate Policy and/or Certification Practice Statement (see Section 3.2);
Authorization for Certificate: That, at the time of issuance, Issuing CA (i) operated aprocedure for verifying that the Subject authorized the issuance of the Certificate and that
the Applicant Representative is authorized to request the Certificate on behalf of the
Subject; (ii) followed the procedure when issuing the Certificate; and (iii) accurately
described the procedure in Issuing CA’s Certificate Policy and/or Certification PracticeStatement (see Section 3.2.5);
Accuracy of Information: That, at the time of issuance, Issuing CA (i) operated aprocedure for verifying all of the information contained in the Certificate (with the exceptionof the subject:organizationalUnitName attribute) was true and accurate; (ii) followed theprocedure when issuing the Certificate; and (iii) accurately described the procedure in
Issuing CA’s Certificate Policy and/or Certification Practice Statement (see Sections 3.2.3,
3.2.3, 3.2.4);

GlobalSign CP (Certificate Policy)
Version: 7.0

70 of 77

•

•

•

•

•

No Misleading Information: That, at the time of issuance, Issuing CA (i) implemented aprocedure for reducing the likelihood that the information contained in the Certificate’s
subject:organizationalUnitName attribute would be misleading; (ii) followed the procedurewhen issuing the Certificate; and (iii) accurately described the procedure in Issuing CA’s
Certificate Policy and/or Certification Practice Statement (see Sections 3.2.3, 3.2.3, 3.2.4);
Identity of Applicant: That, if the Certificate contains Subject Identity Information, the CA(i) operated a procedure to verify the identity of the Applicant and that for Code Signing
Certificates this procedure at least meets the requirements of section 11 of the Baseline
Requirements for Code Signing; (ii) followed the procedure when issuing and managing
the Certificate; and (iii) accurately described the procedure in Issuing CA’s Certificate
Policy and/or Certification Practice Statement (see Sections 3.2.3, 3.2.3, 3.2.4);
Subscriber Agreement: That, if Issuing CA and Subscriber are not Affiliates, theSubscriber and CA are parties to a legally valid and enforceable Subscriber Agreementthat satisfies the Baseline Requirements, Baseline Requirements for Code Signing (ifapplicable) or, if Issuing CA and Subscriber are Affiliates, the Applicant Representative
acknowledged and accepted the Terms of Use (see Section 4.5.1);
Status: The Issuing CA maintains a 24 x 7 publicly accessible Repository with current
information regarding the status (valid or revoked) of all unexpired Certificates and that for
Code Signing Certificates will maintain the Repository for the period required by theBaseline Requirements for Code Signing;
Revocation: The Issuing CA will revoke the Certificate for any of the reasons specified in
the Baseline Requirements, EV Guidelines and/or Baseline Requirements for CodeSigning (as applicable) (see Section 4.9.1);

In addition, Issuing CA represents and warrants to Certificate Beneficiaries for NAESB Certificates
that, during the period when the Certificate is valid, Issuing CA has complied with its Certificate
Policy and/or Certification Practice Statement in issuing and managing the Certificate:
•
•
•
•
•

Issuing CA has issued, and will manage, the Certificate in accordance with the NAESBWEQ PKI Standards.
Issuing has complied with all requirements in the NAESB WEQ PKI Standards whenidentifying the Subscriber and issuing the Certificate.
There are no misrepresentations of fact in the Certificate known to or reasonably knowableby Issuing CA and Issuing CA has verified information in the Certificate.
Information provided by the Applicant for inclusion in the Certificate has been accuratelytranscribed to the Certificate.
The Certificate meets the material requirements of the NAESB WEQ PKI standards.

In lieu of the warranties set forth above, Issuing CA represents and warrants to Certificate
Beneficiaries for EV SSL Certificates and EV Code Signing Certificates that, during the period when
the Certificate is valid, Issuing CA has followed the Guidelines and its Certification PracticeStatement in issuing and managing the Certificate and in verifying the accuracy of the information
contained in the EV SSL Certificate and/or EV Code Signing Certificate:
•

•

•
•

Legal Existence: Issuing CA has confirmed with the Incorporating or Registration Agency
in the Subject’s Jurisdiction of Incorporation or Registration that, as of the date theCertificate was issued, the Subject named in the Certificate legally exists as a validorganization or entity in the Jurisdiction of Incorporation or Registration;
Identity: Issuing CA has confirmed that, as of the date the Certificate was issued, the legalname of the Subject named in the Certificate matches the name on the official government
records of the Incorporating or Registration Agency in the Subject’s Jurisdiction ofIncorporation or Registration, and if an assumed name is also included, that the assumed
name is properly registered by the Subject in the jurisdiction of its Place of Business;
Right to Use Domain Name: For EV Certificates only, Issuing CA has taken all steps
reasonably necessary to verify that, as of the date the Certificate was issued, the Subject
named in the Certificate has the right to use all the Domain Name(s) listed in the Certificate;
Authorization for EV Certificate: Issuing CA has taken all steps reasonably necessary
to verify that the Subject named in the Certificate has authorized the issuance of theCertificate;

GlobalSign CP (Certificate Policy)
Version: 7.0

71 of 77

•
•

•

•

Accuracy of Information: Issuing CA has taken all steps reasonably necessary to verify
that all of the other information in the Certificate is accurate, as of the date the Certificate
was issued;
Subscriber Agreement: The Subject named in the Certificate has entered into a legallyvalid and enforceable Subscriber Agreement with the CA that satisfies the requirements ofthese Guidelines or, if they are affiliated, the Applicant Representative has acknowledged
and accepted the Terms of Use;
Status: Issuing CA will follow the requirements of the EV Guidelines and/or Baseline
Requirements for Code Signing (as applicable) and maintain a 24 x 7 online-accessible
Repository with current information regarding the status of the Certificate as Valid or
revoked; andRevocation: Issuing CA will follow the requirements of the EV Guidelines and/or Baseline
Requirements for Code Signing and revoke the Certificate for any of the revocation reasonsspecified in the EV Guidelines and/or Baseline Requirements for Code Signing.

Specifically for Code Signing Certificates:•

Compliance: That, for Code Signing Certificates, GlobalSign has complied with theBaseline Requirements for Code Signing and the applicable Certificate Policy andCertification Practice Statement in issuing each Code Signing Certificate and operating its
PKI.

•

Key Protection: That, for Code Signing Certificates, GlobalSign represents that it provided
the Subscriber at the time of issuance with documentation on how to securely store andprevent the misuse of Private Keys associated with Code Signing Certificates.

9.6.1.1

CA Representations and Warranties for NAESB Certificates

NAESB WEQ PKI requires that Issuing CAs must warrant that they have:• Issued, and will manage, the Certificate in accordance with the NAESB Business PracticeStandards;• Complied with all requirements in the NAESB Business Practice Standards whenidentifying the Subscriber and issuing the Certificate;• That there are no misrepresentations of fact in the Certificate known to or reasonably
knowable by the RA and that the RA has verified information in the Certificate;• That information provided by the Applicant for inclusion in the Certificate has been
accurately transcribed in to the Certificate; and• That the Certificate meets the material requirements of the NAESB Business Practicestandards.
9.6.2

RA Representations and Warranties

Issuing CAs require all RAs to warrant that they are in compliance with this CP and the relevant
CPS and may choose to include additional representations within its CPS or RA agreement.
9.6.3

Subscriber Representations and Warranties

Subscribers and/or Applicants warrant that:
•
•

•
•

Accuracy of Information: Subscriber will provide accurate and complete information at
all times to Issuing CA, both in the Certificate Request and as otherwise requested by
Issuing CA in connection with issuance of a Certificate;Protection of Private Key: Applicant shall take all reasonable measures to maintain solecontrol of, keep confidential, and properly protect at all times the Private Key to be includedin the requested Certificate(s) and any associated activation data or device, e.g. password
or token;Acceptance of Certificate: Subscriber shall review and verify the Certificate contents for
accuracy;
Use of Certificate: Subscriber shall install an SSL Certificate only on servers that areaccessible at the subjectAltName(s) listed in the Certificate, and use the Certificate solely
in compliance with all applicable laws and solely in accordance with the Subscriber
Agreement or Terms of Use;

GlobalSign CP (Certificate Policy)
Version: 7.0

72 of 77

•

•
•
•

Reporting and Revocation: Subscriber shall (a) promptly request revocation of thecertificate, and cease using it and its associated Private Key, if there is any actual orsuspected misuse or compromise of the Subscriber’s Private Key associated with the
Public Key included in the Certificate; and (b) promptly request revocation of the Certificate,and cease using it, if any information in the Certificate is or becomes incorrect or
inaccurate;
Termination of Use of Certificate: Subscriber shall promptly cease use of Private Key
associated with the Public Key in the Certificate upon revocation of that Certificate;
Responsiveness: Subscriber shall respond to Issuing CA’s instructions concerning
Compromise or Certificate misuse within forty-eight (48) hours; andAcknowledgment and Acceptance: Applicant acknowledges and accepts that Issuing
CA is entitled to revoke the Certificate immediately if the Applicant violates the terms of the
Subscriber Agreement or Terms of Use or if Issuing CA discovers that the Certificate is
being used to enable criminal activities such as phishing attacks, fraud, or the distributionof malware.

9.6.3.1

North American Energy Standards Board (NAESB) Subscribers

Subscribers participating in the NAESB WEQ PKI Standard shall be required to be registered in
the NAESB EIR and furnish proof that they are an entity authorized to engage in the wholesale
electricity industry. Entities or organizations that may require access to applications using
authentication specified under the NAESB WEQ PKI Standards, but do not qualify as a wholesale
electricity market participant (e.g., regulatory agencies, universities, consulting firms, etc.) mustregister.
Registered end entities and the user community they represent shall be required to meet all end
entity obligations in the NAESB WEQ PKI Standards.
Each subscriber organization acknowledges their understanding of the following obligations of the
NAESB WEQ PKI Standard through GlobalSign as follows:
Each subscriber organization shall certify to their certification entity that they have reviewed andacknowledge the following Business Practice Standard WEQ-012.
•

Subscriber acknowledges the electric industry’s need for secure private electronic
communications that facilitate the following purposes:•

Privacy: The assurance to an entity that no one can read a particular piece of data except
the receiver(s) explicitly intended;
Authentication: The assurance to one entity that another entity is who he/she/it claims tobe;Integrity: The assurance to an entity that data has not been altered (intentionally orunintentionally) between “there” and “here,” or between “then” and “now”; andNon-Repudiation/contentCommitment: A party cannot deny having engaged in thetransaction or having sent the electronic message.

•
•
•
•

Subscriber acknowledges the industry’s endorsement of public key cryptography which
utilizes Certificates to bind a person’s or computer system’s Public Key to its entity and tosupport symmetric encryption key exchange.

•

Subscriber has evaluated each of its selected Certification Authority’s CPS in light of thoseindustry standards as identified by the Certification Authority.

Subscribers shall be obligated to register their legal business identification and secure an “Entity
Code” that will be published in the NAESB EIR and used in all Subscriber applications submitted
by, and Certificates issued to, that end entity.
Subscribers shall also be required to comply with the following requirements:•

Protect their Private Keys from access by other parties;

GlobalSign CP (Certificate Policy)
Version: 7.0

73 of 77

•
•
•
•

•
9.6.4

Identify, if applicable through the NAESB EIR, that they have selected GlobalSign to use
as their Authorized Certification Authority;
Execute all agreements and contracts with GlobalSign as required by GlobalSign’s CPS
necessary for GlobalSign to issue Certificates to the end entity for use in securing electronic
communications;
Comply with all obligations required and stipulated by GlobalSign in this certificate policye.g., Certificate application procedures, Applicant identity proofing/verification, andCertificate management practices; andConfirm that it has a PKI Certificate management program, has trained all affected
employees in that program, and has established controls to ensure compliance with that
program. This program shall include, but is not limited to:o Certificate Private Key security and handling policy(ies)o Certificate revocation policy(ies)
Identify the type of Subscriber (I.e., individual, role, device, or application) and provide
complete and accurate information for each Certificate Request.
Relying Party Representations and Warranties

A party relying on an Issuing CA’s Certificate warrants to:
•
•
•
•
•
•

Have the technical capability to use Certificates;
Receive notice of the Issuing CA and associated conditions for Relying Parties;
Validate an Issuing CA’s Certificate by using Certificate status information (e.g. a CRL or
OCSP) published by the issuing CA in accordance with the proper Certificate pathvalidation procedure;
Trust an Issuing CA’s Certificate only if all information featured on such Certificate can beverified via such a validation procedure as being correct and up to date;
Rely on an Issuing CA’s Certificate, only as it may be reasonable under the circumstances;andNotify the appropriate RA immediately, if the Relying Party becomes aware of or suspects
that a Private Key has been Compromised.

The obligations of the Relying Party, if it is to reasonably rely on a Certificate, are to:•••

Verify the validity or revocation of the CA Certificate using current revocation status
information as indicated to the Relying Party;
Take account of any limitations on the usage of the Certificate indicated to the Relying
Party either in the Certificate or this CP;
Take any other precautions prescribed in the Issuing CA’s Certificate as well as any otherpolicies or terms and conditions made available in the application context a Certificate
might be used.

Relying Parties must at all times establish that it is reasonable to rely on a Certificate under thecircumstances taking into account circumstances such as the specific application context a
Certificate is used in.
9.6.4.1

North American Energy Standards Board (NAESB) Relying Parties

Relying Party obligations shall be specified within the context of each NAESB requirement that
employs the NAESB WEQ PKI Standards, in addition to the following:••••

the Certificate was issued by GlobalSign, a registered Authorized Certification Authority;
the entire Certificate validation/trust chain to the GlobalSign for NAESB issuing Authorized
Certification Authority Root Certificate is intact and valid;
the Certificate is valid and has not been revoked; andthe Certificate was issued under one of the NAESB assurance level object identifiers

9.6.4.2

Relying Parties for Qualified Certificates

For qualified certificates under the payment services Directive (EU) 2015/2366 or Open Banking,
Relying Party must take into account the legislation applicable to Relying Party and the certificate
GlobalSign CP (Certificate Policy)
Version: 7.0

74 of 77

Subject. At least the following information included in the certificate must be considered by Relying
Party:••
9.6.5

Competent Authority
Payment service provider or financial institution
Representations and Warranties of Other Participants

No stipulation.

9.7

Disclaimers of Warranties

Issuing CAs should make statements in their CPS that they do not warrant:
•
•

9.8

The accuracy of any unverifiable piece of information contained in Certificates except as it
may be stated in the relevant product description below in this CP and in a warranty policy,
if available.
The accuracy, authenticity, completeness, or fitness of any information contained in, free,test or demo Certificates.

Limitations of Liability

The total liability of the Issuing CA should be limited in accordance with any warranty policy andany limitations set forth in its CPS.
9.8.1

Exclusion of Certain Elements of Damages

Issuing CAs should make statements in their CPS to the effect that in no event (except for fraud or
wilful misconduct) is the Issuing CA liable for:
•
•
•
•
•
•

9.9
9.9.1

Any loss of profits;
Any loss of data;
Any indirect, consequential, or punitive damages arising from or in connection with the use,delivery, license, and performance or non-performance of Certificates or Digital Signatures;
Any transactions or services offered or within the framework of this CP;
Any other damages except for those due to reliance on the verified information in a
Certificate, except for information featured on, free, test or demo Certificates; andAny liability incurred in any case if the error in such verified information is the result of fraud
or wilful misconduct of the Applicant.

Indemnities
Indemnification by an Issuer CA

The Issuing CA’s indemnification obligations must be set forth in its CPS, Subscriber Agreement,
or Relying Party Agreement including any obligation to third party beneficiaries.
9.9.2

Indemnification by Subscribers

The Issuing CA shall include its indemnification requirements for Subscribers in the CPS and in its
Subscriber Agreements.
9.9.3

Indemnification by Relying Parties

The Issuing CA shall include its indemnification requirements for Relying Parties in its CPS.

9.10 Term and Termination
9.10.1 Term
This CP remains in force until such time as communicated otherwise by GlobalSign on its web site
or Repository.
9.10.2 Termination
Notified changes are appropriately marked by an indicated version. Changes become effective
immediately upon publication.
GlobalSign CP (Certificate Policy)
Version: 7.0

75 of 77

9.10.3 Effect of Termination and Survival
Issuing CAs should communicate the conditions and effect of this CP’s termination via theirappropriate Repository.

9.11 Individual Notices and Communications with Participants
GlobalSign accepts notices related to this CP by means of digitally signed messages or in paper
form. Upon receipt of a valid, digitally signed acknowledgment of receipt from GlobalSign thesender of the notice deems its communication effective. The sender must receive suchacknowledgment within twenty (20) business days, or else written notice must then be sent in paper
form through a courier service that confirms delivery or via certified or registered mail, postage
prepaid, return receipt requested, addressed as follows. Individuals communications made to
GlobalSign must be addressed to: legal@globalsign.com or by post to GlobalSign in the addressprovided in Section 2.2.

9.12 Amendments
9.12.1 Procedure for Amendment
This CP is reviewed at least annually and may be reviewed more frequently. All changes arereviewed and approved by the GlobalSign CA Governance Policy Authority before insertion.
Changes to this CP are indicated by appropriate numbering.
9.12.2 Notification Mechanism and Period
Issuing CAs should post appropriate notice on their web sites of any major or significant changes
to this CP as well as any appropriate period by when the revised CP is deemed to be accepted.
9.12.3 Circumstances Under Which OID Must be Changed
No stipulation

9.13 Dispute Resolution Procedures
Before resorting to any dispute resolution mechanism including adjudication or any type ofalternative dispute resolution (including without exception mini-trial, arbitration, binding expert’s
advice, co-operation monitoring and normal expert’s advice) complaining parties agree to notify
GlobalSign of the dispute in an effort to seek dispute resolution.
Upon receipt of a dispute notice, GlobalSign convenes a dispute committee that advises GlobalSign
management on how to proceed with the dispute. The dispute committee convenes within twenty(20) business days from receipt of a dispute notice. The dispute committee is composed by acounsel, a data protection officer, a member of GlobalSign operational management and a security
officer. The counsel or data protection officer chair the meeting. In its resolutions the disputecommittee proposes a settlement to the GlobalSign executive management. The GlobalSign
executive management may subsequently communicate the proposed settlement to thecomplaining party.
If the dispute is not resolved within twenty (20) business days after initial notice pursuant to CP,
parties submit the dispute to arbitration, in accordance with art. 1676-1723 of the Belgian Judicial
Code.
There will be three arbitrators of whom each party proposes one while both parties of the disputechoose the third arbitrator. The place of the arbitration is Leuven, Belgium and the arbitrators
determine all associated costs.

9.14 Governing Law
This CP is governed, construed, and interpreted in accordance with the laws of Belgium. This
choice of law is made to ensure uniform interpretation of this CP, regardless of the place ofresidence or place of use of GlobalSign Certificates or other products and services. The laws ofBelgium also apply to all GlobalSign commercial or contractual relationships in which this CP may

GlobalSign CP (Certificate Policy)
Version: 7.0

76 of 77

apply or quoted implicitly or explicitly in relation to GlobalSign products and services where
GlobalSign acts as a provider, supplier, beneficiary receiver or otherwise.
Each party, including GlobalSign partners, Subscribers and Relying Parties, irrevocably submit to
the jurisdiction of the district courts of Leuven, Belgium.

9.15 Compliance with Applicable Law
GlobalSign complies with applicable laws of Belgium. Export of certain types of software used incertain GlobalSign public Certificate management products and services may require the approvalof appropriate public or private authorities. Parties (including GlobalSign, Subscribers and Relying
Parties) agree to comply with applicable export laws and regulations as pertaining in Belgium.

9.16 Miscellaneous Provisions
9.16.1 Entire Agreement
The Issuing CA will contractually obligate every RA involved with Certificate issuance to comply
with this CP and all applicable Industry guidelines. No third party may rely on or bring action to
enforce any such agreement.
9.16.2 Assignment
Entities operating under this CP must not assign their rights or obligations without the prior writtenconsent of GlobalSign.
9.16.3 Severability
If any provision of this CP, including limitation of liability clauses, is found to be invalid or
unenforceable, the remainder of this CP will be interpreted in such manner as to affect the original
intention of the parties.
Each and every provision of this CP that provides for a limitation of liability, is intended to be
severable and independent of any other provision and is to be enforced as such.
9.16.4 Enforcement (Attorney’s Fees and Waiver of Rights)
GlobalSign may seek indemnification and attorneys’ fees from a party for damages, losses andexpenses related to that party’s conduct. GlobalSign’s failure to enforce a provision of this CP does
not waive GlobalSign’s right to enforce the same provisions later or right to enforce any otherprovisions of this CP. To be effective any waivers must be in writing and signed by GlobalSign
9.16.5 Force Majeure
GlobalSign shall not be liable for any losses, costs, expenses, liabilities, damages, or claims arisingout of or related to delays in performance or from failure to perform its obligations if such failure ordelay is due to circumstances beyond GlobalSign’s reasonable control, including without limitation,acts of any governmental body, war, insurrection, sabotage, embargo, fire, flood, strike or other,interruption of or delay in transportation, unavailability of, interruption or delay intelecommunications or third party services.

9.17 Other Provisions
No stipulation.

GlobalSign CP (Certificate Policy)
Version: 7.0

77 of 77