Starfield Technologies, LLC

Certificate Policy
andCertification Practice Statement(CP/CPS)

Version 5.01
April 1, 2024

Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
iStarfield CP-CPS v5.01

Table of Contents
1 INTRODUCTION .......................................................................................................... 0
1.1 Overview ..............................................................................................................................0
1.2 Document Name and Identification .....................................................................................0
1.2.1 Document History ....................................................................................................... 0
1.3 PKI Participants ...................................................................................................................3
1.3.1 Certification Authorities ............................................................................................. 3
1.3.2 Registration Authorities .............................................................................................. 6
1.3.3 Subscribers .................................................................................................................. 6
1.3.4 Relying Parties ............................................................................................................ 6
1.3.5 Other Participants........................................................................................................ 7
1.4 Certificate Usage ..................................................................................................................7
1.4.1 Appropriate Certificate Uses....................................................................................... 7
1.4.2 Prohibited Certificate Uses ......................................................................................... 7
1.5 Policy Administration ..........................................................................................................7
1.5.1 Organization Administering the Document ................................................................ 7
1.5.2 Contact Person ............................................................................................................ 7
1.5.3 Person Determining CPS Suitability for the Policy .................................................... 8
1.5.4 CPS Approval Procedure ............................................................................................ 8
1.6 Definitions, Acronyms, and References .............................................................................81.6.1 Definitions and Acronyms .......................................................................................... 8
1.6.2 References ................................................................................................................. 12
1.6.3 Conventions .............................................................................................................. 15
2 PUBLICATION AND REPOSITORY RESPONSIBILITIES .................................... 16
2.1 Repositories........................................................................................................................16
2.2 Publication of Certification Information ............................................................................16
2.3 Time or Frequency of Publication .....................................................................................16
2.4 Access Controls on Repositories .......................................................................................16
3 IDENTIFICATION AND AUTHENTICATION......................................................... 17
3.1 Naming...............................................................................................................................173.1.1 Types of Names ........................................................................................................ 17
3.1.2 Need for Names to be Meaningful ............................................................................ 17
3.1.3 Anonymity or Pseudonymity of Subscribers ............................................................ 17
3.1.4 Rules for Interpreting Various Name Forms ............................................................ 17
3.1.5 Uniqueness of Names ............................................................................................... 17
3.1.6 Recognition, Authentication and Role of Trademarks ............................................. 17
3.2 Initial Identity Validation ...................................................................................................18
3.2.1 Method to Prove Possession of Private Key ............................................................. 18
3.2.2 Authentication of Organization and Domain Identity .............................................. 18
3.2.3 Authentication of Individual Identity........................................................................ 25
3.2.4 Non-verified Subscriber Information ........................................................................ 25
3.2.5 Validation of Authority ............................................................................................. 25
3.2.6 Criteria for Interoperation ......................................................................................... 26
3.3 Identification and Authentication for Re-key Requests .....................................................26
3.3.1 Identification and Authentication for Routine Re-key.............................................. 26
3.3.2 Identification and Authentication for Re-key After Revocation............................... 26
3.4 Identification and Authentication for Revocation Request ................................................26
Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
ii

Starfield CP-CPS v5.01

4 CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS ........................ 27
4.1 Certificate Application .......................................................................................................27
4.1.1 Who Can Submit a Certificate Application .............................................................. 27
4.1.2 Enrollment Process and Responsibilities .................................................................. 27
4.2 Certificate Application Processing ....................................................................................27
4.2.1 Performing Identification and Authentication Functions ......................................... 27
4.2.2 Approval or Rejection of Certificate Applications ................................................... 28
4.2.3 Time to Process Certificate Applications ................................................................. 28
4.3 Certificate Issuance ............................................................................................................28
4.3.1 CA Actions During Certificate Issuance................................................................... 28
4.3.2 Notification to Subscriber by the CA of Issuance of Certificate .............................. 28
4.4 Certificate Acceptance .......................................................................................................28
4.4.1 Conduct Constituting Certificate Acceptance ........................................................... 28
4.4.2 Publication of the Certificate by the CA ................................................................... 29
4.4.3 Notification of Certificate Issuance by the CA to Other Entities ............................. 29
4.5 Key Pair and Certificate Usage ..........................................................................................29
4.5.1 Subscriber Private Key and Certificate Usage .......................................................... 29
4.5.2 Relying Party Public Key and Certificate Usage ...................................................... 29
4.6 Certificate Renewal ............................................................................................................29
4.6.1 Circumstance for Certificate Renewal ...................................................................... 29
4.6.2 Who May Request Renewal...................................................................................... 29
4.6.3 Processing Certificate Renewal Requests ................................................................. 29
4.6.4 Notification of New Certificate Issuance to Subscriber ........................................... 30
4.6.5 Conduct Constituting Acceptance of a Renewal Certificate ..................................... 30
4.6.6 Publication of the Renewal Certificate by the CA .................................................... 30
4.6.7 Notification of Certificate Issuance by the CA to Other Entities ............................. 30
4.7 Certificate Re-key ..............................................................................................................30
4.7.1 Circumstance for Certificate Re-key ........................................................................ 30
4.7.2 Who May Request Certification of a New Public Key ............................................. 30
4.7.3 Processing Certificate Re-keying Requests .............................................................. 30
4.7.4 Notification of New Certificate Issuance to Subscriber ........................................... 30
4.7.5 Conduct Constituting Acceptance of a Re-keyed Certificate ................................... 30
4.7.6 Publication of the Re-keyed Certificate by the CA .................................................. 30
4.7.7 Notification of Certificate Issuance by the CA to Other Entities ............................. 31
4.8 Certificate Modification .....................................................................................................31
4.8.1 Circumstance for Certificate Modification ............................................................... 31
4.8.2 Who May Request Certificate Modification ............................................................. 31
4.8.3 Processing Certificate Modification Requests .......................................................... 31
4.8.4 Notification of New Certificate Issuance to Subscriber ........................................... 31
4.8.5 Conduct Constituting Acceptance of Modified Certificate ...................................... 31
4.8.6 Publication of the Modified Certificate by the CA ................................................... 31
4.8.7 Notification of Certificate Issuance by the CA to Other Entities ............................. 31
4.9 Certificate Revocation and Suspension .............................................................................31
4.9.1 Circumstances for Revocation .................................................................................. 32
4.9.2 Who Can Request Revocation .................................................................................. 35
4.9.3 Procedure for Revocation Request............................................................................ 35
4.9.4 Revocation Request Grace Period ............................................................................ 35
4.9.5 Time Within Which CA Must Process the Revocation Request .............................. 36
Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
iii

Starfield CP-CPS v5.01

4.9.6 Revocation Checking Requirement for Relying Parties ........................................... 36
4.9.7 CRL Issuance Frequency .......................................................................................... 36
4.9.8 Maximum Latency for CRLs (if applicable) ............................................................ 36
4.9.9 On-line Revocation/Status Checking Availability .................................................... 37
4.9.10 On-line Revocation Checking Requirements............................................................ 37
4.9.11 Other Forms of Revocation Advertisements Available ............................................ 37
4.9.12 Special Requirements Regarding Key Compromise................................................. 37
4.9.13 Circumstances for Suspension .................................................................................. 38
4.9.14 Who Can Request Suspension .................................................................................. 38
4.9.15 Procedure for Suspension Request............................................................................ 38
4.9.16 Limits on Suspension Period .................................................................................... 38
4.10 Certificate Status Services .................................................................................................38
4.10.1 Operational Characteristics ....................................................................................... 38
4.10.2 Service Availability .................................................................................................. 38
4.10.3 Optional Features ...................................................................................................... 39
4.11 End of Subscription............................................................................................................39
4.12 Key Escrow and Recovery .................................................................................................39
4.12.1 Key Escrow and Recovery Policy and Practices ...................................................... 39
4.12.2 Session Key Encapsulation and Recovery Policy and Practices .............................. 39
5 FACILITY, MANAGEMENT, AND OPERATIONAL CONTROLS ........................ 40
5.1 Physical Controls ...............................................................................................................41
5.1.1 Site Location and Construction ................................................................................. 41
5.1.2 Physical Access......................................................................................................... 41
5.1.3 Power and Air Conditioning ..................................................................................... 41
5.1.4 Water Exposures ....................................................................................................... 41
5.1.5 Fire Prevention and Protection.................................................................................. 41
5.1.6 Media Storage ........................................................................................................... 41
5.1.7 Waste Disposal.......................................................................................................... 41
5.1.8 Offsite Backup .......................................................................................................... 41
5.2 Procedural Controls ...........................................................................................................425.2.1 Trusted Roles ............................................................................................................ 42
5.2.2 Number of Persons Required Per Task ..................................................................... 42
5.2.3 Identification and Authentication for Each Role ...................................................... 42
5.2.4 Roles requiring separation of duties ......................................................................... 42
5.3 Personnel Controls .............................................................................................................425.3.1 Qualifications, Experience, and Clearance Requirements ........................................ 42
5.3.2 Background Check Procedures ................................................................................. 43
5.3.3 Training Requirements.............................................................................................. 43
5.3.4 Retraining Frequency and Requirements .................................................................. 43
5.3.5 Job Rotation Frequency and Sequence ..................................................................... 43
5.3.6 Sanctions for Unauthorized Actions ......................................................................... 43
5.3.7 Independent Contractor Requirements ..................................................................... 44
5.3.8 Documentation Supplied to Personnel ...................................................................... 44
5.4 Audit Logging Procedures .................................................................................................44
5.4.1 Types of Events Recorded ........................................................................................ 44
5.4.2 Frequency of Processing Log.................................................................................... 45
5.4.3 Retention Period for Audit Log ................................................................................ 45
5.4.4 Protection of Audit Log ............................................................................................ 45
Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
iv

Starfield CP-CPS v5.01

5.4.5 Audit Log Backup Procedures .................................................................................. 45
5.4.6 Audit Collection System (Internal vs. External) ....................................................... 46
5.4.7 Notification to Event-Causing Subject ..................................................................... 46
5.4.8 Vulnerability Assessments ........................................................................................ 46
5.5 Records Archival ...............................................................................................................46
5.5.1 Types of Records Archived ...................................................................................... 46
5.5.2 Retention Period for Archive .................................................................................... 46
5.5.3 Protection of Archive ................................................................................................ 46
5.5.4 Archive Backup Procedures...................................................................................... 47
5.5.5 Requirements for Time-Stamping of Records .......................................................... 47
5.5.6 Archive Collection System (Internal or External) .................................................... 47
5.5.7 Procedures to Obtain and Verify Archive Information............................................. 47
5.6 Key Changeover.................................................................................................................47
5.7 Compromise and Disaster Recovery ..................................................................................47
5.7.1 Incident and Compromise Handling Procedures ...................................................... 47
5.7.2 Computing Resources, Software, and/or Data are Corrupted ................................... 47
5.7.3 Entity Private Key Compromise Procedures ............................................................ 47
5.7.4 Business Continuity Capabilities After a Disaster .................................................... 48
5.8 CA or RA Termination ......................................................................................................48
6 TECHNICAL SECURITY CONTROLS ..................................................................... 49
6.1 Key Pair Generation and Installation .................................................................................49
6.1.1 Key Pair Generation.................................................................................................. 49
6.1.2 Private Key Delivery to Subscriber .......................................................................... 49
6.1.3 Public Key Delivery to Certificate Issuer ................................................................. 49
6.1.4 CA Public Key Delivery to Relying Parties ............................................................. 49
6.1.5 Key Sizes .................................................................................................................. 49
6.1.6 Public Key Parameters Generation and Quality Checking ....................................... 51
6.1.7 Key Usage Purposes ................................................................................................. 51
6.2 Private Key Protection and Cryptographic Module Engineering Controls .......................51
6.2.1 Cryptographic Module Standards and Controls........................................................ 51
6.2.2 Private Key Multi-Person Control ............................................................................ 51
6.2.3 Private Key Escrow................................................................................................... 51
6.2.4 Private Key Backup .................................................................................................. 52
6.2.5 Private Key Archival................................................................................................. 52
6.2.6 Private Key Transfer Into or From a Cryptographic Module ................................... 52
6.2.7 Private key storage on cryptographic module ........................................................... 52
6.2.8 Method of Activating Private Keys .......................................................................... 52
6.2.9 Method of Deactivating Private Key ........................................................................ 52
6.2.10 Method of Destroying Private Key ........................................................................... 52
6.2.11 Cryptographic Module Rating .................................................................................. 52
6.3 Other Aspects of Key Pair Management ...........................................................................53
6.3.1 Public Key Archival .................................................................................................. 53
6.3.2 Certificate Operational Periods and Key Pair Usage Periods ................................... 53
6.4 Activation Data ..................................................................................................................53
6.4.1 Activation Data Generation and Installation............................................................. 53
6.4.2 Activation Data Protection ........................................................................................ 53
6.4.3 Other Aspects of Activation Data ............................................................................. 53
6.5 Computer Security Controls ..............................................................................................54
Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
v

Starfield CP-CPS v5.01

6.5.1 Specific Computer Security Technical Requirements .............................................. 54
6.5.2 Computer Security Rating......................................................................................... 54
6.6 Life Cycle Technical Controls ...........................................................................................54
6.6.1 System Development Controls ................................................................................. 54
6.6.2 Security Management Controls................................................................................. 54
6.6.3 Life Cycle Security Controls .................................................................................... 54
6.7 Network Security Controls ................................................................................................54
6.8 Time-Stamping ..................................................................................................................54
7 CERTIFICATE, CRL, AND OCSP PROFILES .......................................................... 55
7.1 Certificate Profile ...............................................................................................................55
7.1.1 Version Number ........................................................................................................ 55
7.1.2 Certificate Extensions ............................................................................................... 55
7.1.3 Algorithm Object Identifiers ..................................................................................... 55
7.1.4 Name Forms .............................................................................................................. 55
7.1.5 Name Constraints ...................................................................................................... 59
7.1.6 Certificate Policy Object Identifier ........................................................................... 59
7.1.7 Usage of Policy Constraints Extension ..................................................................... 59
7.1.8 Policy Qualifier Syntax and Semantics..................................................................... 60
7.1.9 Processing Semantics for the Critical Certificate Policies Extension ....................... 60
7.2 CRL Profile ........................................................................................................................60
7.2.1 Version Number ........................................................................................................ 60
7.2.2 CRL and CRL Entry Extensions ............................................................................... 60
7.3 OCSP Profile ......................................................................................................................62
7.3.1 Version Number ........................................................................................................ 62
7.3.2 OCSP Extensions ...................................................................................................... 62
The singleExtensions of an OCSP response MUST NOT contain the reasonCode (OID 2.5.29.21)
CRL entry extension. ............................................................................................................ 62
8 COMPLIANCE AUDIT AND OTHER ASSESSMENTS .......................................... 63
8.1 Frequency or Circumstances of Assessment......................................................................63
8.2 Identity/Qualifications of Assessor ....................................................................................63
8.3 Assessor's Relationship to Assessed Entity .......................................................................63
8.4 Topics Covered by Assessment .........................................................................................63
8.5 Actions Taken as a Result of Deficiency ...........................................................................63
8.6 Communication of Results.................................................................................................63
8.7 Self –Audits .......................................................................................................................64
8.8 Specification Administration .............................................................................................64
8.8.1 Specification Change Procedures ............................................................................. 64
8.8.2 Publication and Notification Policies........................................................................ 64
8.9 CPS Approval Procedures..................................................................................................64
9 OTHER BUSINESS AND LEGAL MATTERS .......................................................... 65
9.1 Fees ....................................................................................................................................65
9.1.1 Certificate Issuance or Renewal Fees ....................................................................... 65
9.1.2 Certificate Access Fees ............................................................................................. 65
9.1.3 Revocation or Status Information Access Fees ........................................................ 65
9.1.4 Fees for Other Services ............................................................................................. 65
9.1.5 Refund Policy............................................................................................................ 65
9.2 Financial Responsibility.....................................................................................................65
9.2.1 Insurance Coverage ................................................................................................... 66
Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
vi

Starfield CP-CPS v5.01

9.2.2 Other Assets .............................................................................................................. 66
9.2.3 Insurance or Warranty Coverage for End-entities .................................................... 66
9.3 Confidentiality of Business Information ............................................................................66
9.3.1 Scope of Confidential Information ........................................................................... 66
9.3.2 Information not Within the Scope of Confidential Information ............................... 66
9.3.3 Responsibility to Protect Confidential Information .................................................. 66
9.4 Privacy of Personal Information ........................................................................................66
9.4.1 Privacy Plan .............................................................................................................. 66
9.4.2 Information Treated as Private.................................................................................. 67
9.4.3 Information Not Deemed Private .............................................................................. 67
9.4.4 Responsibility to Protect Private Information........................................................... 67
9.4.5 Notice and Consent to Use Private Information ....................................................... 67
9.4.6 Disclosure Pursuant to Judicial or Administrative Process ...................................... 67
9.4.7 Other Information Disclosure Circumstances ........................................................... 67
9.5 Intellectual Property Rights ...............................................................................................67
9.5.1 Property Rights in Certificates and Revocation Information .................................... 67
9.5.2 Property Rights in the Agreement............................................................................. 68
9.5.3 Property Rights to Names ......................................................................................... 68
9.5.4 Property Rights in Keys and Key Material ............................................................... 68
9.6 Representations and Warranties .........................................................................................68
9.6.1 CA Representations and Warranties ......................................................................... 68
9.6.2 RA Representations and Warranties ......................................................................... 70
9.6.3 Subscriber Representations and Warranties .............................................................. 70
9.6.4 Relying Party Representations and Warranties......................................................... 71
9.6.5 Representations and Warranties of Other Participants ............................................. 71
9.7 Disclaimers of Warranties..................................................................................................71
9.7.1 Fiduciary Relationships ............................................................................................ 71
9.8 Limitations of Liability ......................................................................................................71
9.9 Indemnities.........................................................................................................................74
9.9.1 Indemnification by Starfield ..................................................................................... 74
9.9.2 Indemnification by Subscribers ................................................................................ 74
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 .......................................................................... 75
9.11 Individual Notices and Communications with Participants ...............................................76
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 Provisions ...........................................................................................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
Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
vii

Starfield CP-CPS v5.01

9.16.4 Enforcement .............................................................................................................. 77
9.16.5 Force Majeure ........................................................................................................... 77
9.17 Other Provisions.................................................................................................................77
10 APPENDIX A – CERTIFICATE PROFILES .............................................................. 78
10.1 Root CAs ............................................................................................................................78
10.1.1 Starfield Class 2 Certification Authority .................................................................. 78
10.1.2 Starfield Root Certificate Authority – G2................................................................. 79
10.1.3 Go Daddy Class 2 Certification Authority................................................................ 79
10.1.4 Go Daddy Root Certificate Authority – G2 .............................................................. 80
10.1.5 Starfield Services Root Certification Authority ........................................................ 81
10.1.6 GoDaddy Root Certificate Authority - G5................................................................ 81
10.1.7 Starfield Root Certificate Authority - G5 ................................................................. 82
10.1.8 GoDaddy Root Certificate Authority – G6 ............................................................... 82
10.1.9 Starfield Root Certificate Authority - G6 ................................................................. 83
10.2 Issuing CAs ........................................................................................................................84
10.2.1 Starfield Issuing (subordinate) CAs .......................................................................... 84
10.3 Cross CA Certificates ........................................................................................................85
10.3.1 Go Daddy Root Certificate Authority - G2 + Go Daddy Class 2 Certification Authority
85
10.3.2 Starfield Root Certificate Authority - G2 + Starfield Class 2 Certification Authority87
10.3.3 Starfield Services Root Certificate Authority + Starfield Services Root Certificate Authority
88
10.3.4 Starfield Services Root Certificate Authority - G2 + Starfield Class 2 Certification
Authority 89
10.3.5 Certainly E1 + Starfield Services Root Certificate Authority - G2 .......................... 90
10.3.6 Certainly R1 + Starfield Services Root Certificate Authority - G2 ......................... 91
10.4 End Entity SSL Certificates ...............................................................................................92
10.4.1 Go Daddy Issuing CA: Subscriber Certificates ........................................................ 92
10.4.2 Starfield Issuing CA: Subscriber Certificates ........................................................... 94
10.4.3 Go Daddy Issuing CA – G2: Subscriber Certificates ............................................... 96
10.4.4 Starfield Issuing CA – G2: Subscriber Certificates .................................................. 98
10.5 End Entity Code Signing Certificates ..............................................................................100
10.5.1 Go Daddy Issuing CA: Subscriber Certificates ...................................................... 100
10.5.2 Starfield Issuing CA: Subscriber Certificates ......................................................... 102
10.5.3 Go Daddy Secure Certificate Authority – G2 AND Go Daddy Secure Extended Validation
Code Signing CA – G2: Subscriber Certificates................................................................. 104
10.5.4 Starfield Secure Certificate Authority – G2 AND Starfield Secure Extended Validation
Code Signing CA – G2: Subscriber Certificates................................................................. 106
11 APPENDIX B: TEST SITES ...................................................................................... 108

Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
viii

Starfield CP-CPS v5.01

1 INTRODUCTION
Starfield Technologies is an innovator in the field of Internet foundation services, providing advanced
software and Internet solutions critical to the building of online presence and e-commerce.
The Starfield Public Key Infrastructure (“Starfield PKI”) has been established to provide a variety ofdigital certificate services.

1.1

Overview

This Certificate Policy and Certification Practice Statement (CP/CPS) describes the practices of theStarfield PKI and applies to all Certification Authorities (CAs) within the Starfield PKI hierarchy.
This CP/CPS is applicable to all entities with relationships with the Starfield PKI, including Policy
Authorities (PAs), Certification Authorities (CAs), Registration Authorities (RAs), Subscribers, andRelying Parties.
The Starfield PKI conforms to the current version of the Baseline Requirements for the Issuance andManagement of Publicly-Trusted TLS Server Certificates as well as Guidelines for Issuance andManagement of Extended Validation Certificates published at http://www.cabforum.org. In the eventof any inconsistency between this document and those Requirements, those Requirements takeprecedence over this document. The following policy identifiers are managed in accordance withthese requirements: 2.23.140.1.2.1, 2.23.140.1.2.2, 2.23.140.1.2.3, and 2.23.140.1.1
Note: References to Baseline Requirements sections are denoted in short form using the section number.
For example [BR 3.2.2.1] denotes section 3.2.2.1 of the current revision of the Baseline Requirements for
the Issuance and Management of Publicly-Trusted TLS Server Certificates.

1.2

Document Name and Identification

This document is formally referred to as the “Starfield Certificate Policy and Certification PracticeStatement” (Starfield CP/CPS). Starfield CAs issue certificates in accordance with the policy andpractice requirements of this document.
The OID-arcs associated with this document are 2.16.840.1.114413 and 2.16.840.1.114414.

1.2.1 Document History
Version
3.12

Effective Date
August 15, 2017

3.12.2
3.13
4.0
4.1

November 9, 2017
September 18, 2018
September 27, 2018
May 14, 2019

4.2

March 11, 2020

Change Summary•
Added this changelog•
Updated 3.3.9 to state that Starfield now relies on 3rd party data sources to identify high risk
requests•
Updated section 4.1.1 to confirm that Starfield now processes CAA records•
Corrected the 3.1.8 section to reference valid subsections•
Reformat to RFC 3647 Part 1•
Reformat to RFC 3647 Part 2•
Added text to sections 1.4 and 1.4.1•
Updated section 9.8•
Updated to reflect Mozilla Root Store requirements•
Updated section 3.2

Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
0

Starfield CP-CPS v5.01

Version
4.3
4.4
4.5
4.6
4.7

Effective Date
May 26, 2020
June 19, 2020
July 23, 2020
July 30, 2020
August 31, 2020

4.8

September 30, 2020

4.9

October 21, 2020

4.10

April 19, 2021

4.11

June 10, 2021

4.12

July 9, 2021

4.13

September 8, 2021

4.14
4.15
4.16

October 15, 2021
November 29, 2021
March 9, 2022

4.17

June 17, 2022

4.18

November 11, 2022

Change Summary•
Updated section 7.2 to show both versions of CRL•
Updated section 4.9.4 in accordance to BRs•
Removed the G3 and G4 roots from 1.3.1, 3.2.2.4.9 and Appendix A•
Updated link to repository in section 2.1•
Updated section 6.3.2 to reflect 398 day maximum validity period•
Updated section 2.1 to reflect updated repository link•
Updated 7.2.2.1 and 7.2.2.2 to remove reason code 6•
Updated section 3.2 to add link to agency disclosure list•
Updated sections 10.4 and 10.5 to reflect SHA2•
Updates section 8.6 to acknowledge new audit requirements•
Added section 9.16.5 Force Majeure•
Updated sections 1.6 and 4.9.1 to add definitions and details to revocation•
Updated section 1.5.2 with more clear instructions for Certificate Problem Report•
Updated section 4.2.2 to indicate that SOD is also applicable to Code Signing•
Updated section 5.4.3 to reflect the 7 years retention period for audit log•
Updated section 1.4 to indicate Code signing EOL as of May 30, 2021•
Updated section 4.9.12 to specify methods used to demonstrate private key compromise•
Updated section 1.4 to reflect Code Signing policy updates in relation to Code Signing EOL•
Updated section 1.5.2 to reflect new company address•
Updated section 3.2.2 header to include Domain•
Added section 3.2.2.4.20 TLS Using ALPN (Ballot SC33)•
Removed Code Signing references in the following sections: 1.1, 3.2, 4.2.2, 6.3.2, 7.1.6, 8.7,
10.2•
Updated section 10.5 in relation to Code Signing EOL•
Updated section 10.4 to reflect removal of OU (Ballot SC47)•
Ballot SC48 clean up:oReplaced all instances of Fully Qualified with Fully-QualifiedoAdded and updated some definitions in 1.6.1oUpdated applicable sections under 3.2.2.4 to replace instances of label(s) with
Domain Label(s)•Added subsections to 7.1.4 Name Forms: 7.1.4.1, 7.1.4.2, 7.1.4.2.1, 7.1.4.2.2, 7.1.4.3,
7.1.4.3.1.
•
Added 3.2.2.5 Authentication for an IP Address, and 3.2.2.6 Wildcard Domain Validation.
Re-numbered Data Source Accuracy to 3.2.2.7.
•
Updated sections 4.9.7, 4.9.10, 7.2.2.1, and 7.2.2.2 regarding OSCP and CRL timeframes.
•
Updated sections 3.2.2.4.18 and 3.2.2.4.19 regarding redirects and Wildcard Domain Names•
Updated sections 3.2.2.4.20, 3.4, 4.2.1, 4.2.3, 4,9.2, 4.9.3, 4.9.7, 4.9.10, and 9.1.5 to accountfor Certainly CPS alignment.
•
Cleaned up formatting in sections 1.5.3, 1.6, and 8.6.
•
Fixed references in sections 2.3, 6.1.1, 6.1.6, and 6.2.1.
•
Updated section 4.9.1 and subsections, to be in-line with BR formatting, and include
timeframes.
•
Updated audit log retention in section 5.4.3•
Updated section 9.9 to include indemnification by Starfield•
Added definition of Application Software Supplier in section 1.6•
Corrected spelling mistake in 1.3.1•
Added Certainly to 1.3.1 diagram•
Increased diagram sizes for readability•
Added 2 new roots to 10.1•
Added 2 new Cross CA Certs to 10.3

Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
1

Starfield CP-CPS v5.01

Version
5.0

Effective Date
August 1, 2023

5.01

April 1, 2024

Change Summary•
Added Appendices for Test Sites, adjusted formatting of appendices•
Added Definitions and Acronyms in 1.6.1 to align with CA/B forum definitions as well as
ensure all acronyms used are pre-defined•
Updated reference URLs within this document to display the Section name as well as thesection number•
Introduced [BR X.XX] formatting to delineate CA/B Forum alignment sections from
CP/CPS sections•
Updated formatting: Section indentation, table formatting, font styling•
Added new Section 3.2.2.8 CAA Records•
Added text to Section 5 for BR alignment•
Added References to new Section 1.6.2•
Added clarifying text to 4.2.1•
Added lastUpdate/nextUpdate clarification to 4.9.7•
Added bullet expansion to 5.4.1 for CA/B alignment•
Added 1.6.3 Conventions•
Added 7.2.2 text and modified 7.2.2.1 and 7.2.2.2 for CAB alignment•
Added 7.3 text for CAB alignment•
Updated 4.9.1.1 and 4.9.1.2 for CAB alignment
•
•
•
•
•
•
•
•
•
•

Updated 1.3.3 to clarify when Starfield may act as a subscriber
Added definition for short lived certificate to 1.6.1
Added RFC8954 as a reference in 1.6.2
Updated to allow use of FIPS 140-2 or FIPS 140-3
Updated references to the Baseline Requirements
Updated term from “Random Number” to “Random Value” in sections 3.2.2.4.10 and
3.2.2.4.18
Updated CRL frequency to align with current business practices
Updated contact address in 1.5.2
Updated 5.4.1 to align with BR update
Added 5.4.1.1 to align with BR update

Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
2

Starfield CP-CPS v5.01

1.3

PKI ParticipantsThis CP/CPS is applicable to all certificates issued by Starfield CAs within the Starfield PKI. This
document defines the specific communities for which a specific class or type of certificate isapplicable, specific Starfield PKI practices and requirements for the issuance and management ofsuch certificates, and the intended purposes and uses of such certificates.

1.3.1 Certification Authorities
Starfield Certification Authorities (CAs) perform the following general functions:• Create and sign certificates• Distribute certificates to the appropriate Subscribers and Relying Parties• Revoke certificates• Distribute certificate status information in the form of Certificate Revocation Lists (CRLs)
or other mechanisms• Provide a repository where certificates and certificate status information are stored andmade available (if applicable).
Obligations of the CAs within the Starfield PKI include:• Generating, issuing, and distributing public key certificates• Distributing CA certificates• Generating and publishing certificate status information (such as CRLs)• Maintaining the security, availability, and continuity of the certificate issuance and CRL
signing functions• Providing a means for Subscribers to request revocation• Revoking public-key certificates• Periodically demonstrating internal or external audited compliance with this CP/CPS.
Within the Starfield PKI, there are two general types of CAs: Root and Issuing CAs. Currently,
the Starfield PKI hierarchy consists of the CAs in the diagrams below. Relationships between
these CA certificates are represented in the following diagrams:

Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
3

Starfield CP-CPS v5.01

Starfield Class 2
Certification Authority(SHA-1)

Starfield Secure
Certification Authority(SHA-1)

Cross-signs Starfield Root
Certificate Authority - G2

Cross-signs Starfield
Services Root Certificate
Authority - G2 (operatedby Amazon)

All types of SSL and codesigning certificates (SHA1)

Go Daddy Class 2
Certification
Authority (SHA-1)

Go Daddy Secure
Certification
Authority (SHA-1)

Cross-signs Go Daddy
Root Certificate
Authority - G2
Starfield Services Root
Certificate Authority(SHA-1)

All types of SSL andcode signing
certificates (SHA-1)

Cross-signs Starfield
Services Root Certificate
Authority - G2 (operatedby Amazon)

Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
4

Starfield CP-CPS v5.01

Starfield Root
Certificate Authority G2

Starfield Secure
Certificate Authority G2

Starfield Secure CodeSigning Certificate
Auhtority - G2

Starfield Secure
Extended Validation
Code Signing CA - G2

Cross-signs CertainlyIntermediate E1 andCertainly intermediate
R1

All types of SSL andcode signing
certificates

Go Daddy Root
Certificate Authority G2

Go Daddy Secure
Certificate Authority G2

Go Daddy Secure
Code Signing
Certificate Authority G2

Go Daddy Secure
Extended Validation
Code Signing CA - G2

All types of SSL andcode signing
certificates

Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
5

Starfield CP-CPS v5.01

1.3.2 Registration Authorities
Registration Authorities (RAs) evaluate and either approve or reject Subscriber certificate
management transactions (including certificate requests, renewal and re-key requests, andrevocation requests). Starfield serves as the sole RA for the Starfield PKI.
Obligations of the Registration Authorities (RAs) within the Starfield PKI include:• Obtaining a public-key from the Subscriber• Identifying and authenticating Subscribers in accordance with this CP/CPS• Verifying that the Subscriber possesses the asymmetric private key corresponding to the
public-key submitted for certification• Receiving, authenticating and processing certificate revocation requests• Providing suitable training to personnel performing RA functions.
For the Starfield Root CAs the Subscribers are Subordinate CAs that are under the control ofStarfield. Accordingly, the RA function for these CAs is performed manually by authorized
Starfield PKI personnel.
For the Starfield Issuing CAs, the RA function is performed by Starfield using a combination of
automated and manual processes.

1.3.3 Subscribers
For the Root CAs, the Subscribers include subordinate CAs. For Starfield Issuing CAs,
Subscribers typically include organizations and individuals. In some situations, Starfield may act
as an Applicant or Subscriber, for instance, when it generates and protects a Private Key, requests
a Certificate, demonstrates control of a Domain, or obtains a Certificate for its own use.
Obligations of Subscribers within the Starfield PKI include:• Generating or causing to be generated one or more asymmetric key pairs• Submitting public keys and credentials for registration• Providing information to the RA that is accurate and complete to the best of the
Subscribers’ knowledge and belief regarding information in their certificates andidentification and authentication information• Taking appropriate measures to protect their private keys from compromise• Promptly reporting loss or compromise of private key(s) and inaccuracy of certificate
information• Using its key pair(s) in compliance with this CP/CPS.

1.3.4 Relying Parties
Relying Parties include any entity that may rely upon a Starfield certificate for purposes ofdetermining the organizational or individual identity of an entity providing a web site, dataencryption, digital signature verification, and user authentication.
Obligations of Relying Parties within the Starfield PKI include:• Confirming the validity of Subscriber public-key certificates
Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
6

Starfield CP-CPS v5.01

••Verifying that Subscriber possesses the asymmetric private key corresponding to the
public-key certificate (e.g., through digital signature verification)
Using the public-key in the Subscriber’s certificate in compliance with this CP/CPS.

1.3.5 Other Participants
Not applicable.

1.4

Certificate Usage

Starfield offers TLS Certificates in the following levels of assurance:
Assurance Level
Basic and Medium Assurance
High Assurance
Extended Validation

Certificate Validation Type
Domain Validation (DV)Organization and Individual Validation (OV)
Extended Validation (EV)

Note: As of May 30, 2021, Starfield no longer issues High Assurance Code Signing Certificates and will nolonger update this CP/CPS for Code Signing related changes to the Baseline Requirements. Code Signingreferences were removed in v4.12. Refer to Certificate Policy and Certification Practice Statement v4.11 inStarfield’s Repository, for most recent policy containing Code Signing references.

1.4.1 Appropriate Certificate Uses
A certificate issued by Starfield shall be used only as designated by the terms of this CP/CPS andany service agreements. However, the sensitivity of the information processed or protected by a
Certificate varies greatly, and each Relying Party must evaluate the associated risks before
deciding on whether to rely on a Certificate issued under this CPS.

1.4.2 Prohibited Certificate Uses
As defined in the applicable Subscriber Agreement.

1.5

Policy Administration

1.5.1 Organization Administering the Document
This CP/CPS is administered by the Starfield Governance and Policy Committee.

1.5.2 Contact Person
Starfield Technologies, LLC
100 S Mill Ave, Suite 1600
Tempe, AZ 85281
Phone: 480-505-8800
E-mail: practices@starfieldtech.com
In case of a Certificate Problem Report, that concerns a key compromised certificate, a misissued certificate, or any other type of suspicious activity with a certificate, contact us at (480)505-8852, or practices@starfieldtech.com.
Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
7

Starfield CP-CPS v5.01

The Starfield Governance and Policy Committee consists of representatives from executive
management, corporate security, PKI operations, and legal.
Obligations of the Starfield Governance and Policy Committee (GPC) include:• Approving and maintaining this CP/CPS• Interpreting adherence to this CP/CPS• Specifying the content of public-key certificates• Resolving or causing resolution of disputes related to this CP/CPS• Remaining current regarding security threats and ensuring that appropriate actions aretaken to counteract significant threats.

1.5.3 Person Determining CPS Suitability for the Policy
The Starfield Governance and Policy Committee determines the suitability of a CPS for the policy
based on the results of independent audits.

1.5.4 CPS Approval Procedure
All changes to this document are approved by a quorum of The Starfield Governance and Policy
Committee.

1.6

Definitions, Acronyms, and References

1.6.1 Definitions and Acronyms
Term

AcronymDefinition

AICPA

A corporation, partnership, joint venture or other entity controlling, controlled by, or
under common control with another entity, or an agency, department, politicalsubdivision, or any entity operating under the direct control of a Government Entity.
American Institute of Certified Public Accountants

Affiliate

American Institute ofCertified Public
Accountants
ApplicantApplicant Representative
Application‐Layer
Protocol Negotiation
Application Software
Supplier
Attestation Letter

ALPN

Audit Period

Audit Report

Authorization Domain
Name
Authorized PortAND

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.
A natural person or human sponsor who is either the Applicant, employed by the
Applicant, or an authorized agent who has been delegated authority to represent the
Applicant.
A TLS Extension that includes the protocol negotiation within the exchange of hellomessages.
A supplier of Internet browser software or other relying‐party application software that
displays or uses Certificates and incorporates Root Certificates.
A letter attesting that Subject Information is correct written by an accountant, lawyer,
government official, or other reliable third party customarily relied upon for suchinformation.
In a period-of-time audit, the period between the first day (start) and the last day ofoperations (end) covered by the auditors in their engagement. (This is not the same as theperiod of time when the auditors are on-site at the CA.) The coverage rules andmaximum length of audit periods are defined in Section 8.1 Frequency or Circumstancesof Assessment
A report from a Qualified Auditor stating the Qualified Auditor’s opinion on whether anentity’s processes and controls comply with the mandatory provisions of these
Requirements.
The FQDN returned in defined processes to obtain authorization for inclusion in a
Certificate.
One of the following ports: 80 (http), 443 (http), 115 (sftp), 25 (smtp), 22 (ssh).

Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
8

Starfield CP-CPS v5.01

Term

Acronym

The portion of an applied‐for FQDN that is the first Domain Name node left of aregistry-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 Namenode is a gTLD having ICANN Specification 13 in its registry agreement, the gTLD
itself may be used as the Base Domain Name.
Starfield’s vetting process that verifies an Applicant’s access to the domain.

Base Domain Name

Basic Assurance
Baseline Requirements

BR

Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server
Certificates published by the CA/Browser Forum.

[BR X.X]
Certificate Authority
Authorization
CA Key Pair

CAA

Certificate
Certificate Data
Certificate Management
Process
Certificate Policy

CP

Certificate Problem
ReportCertificate Profile

Certificate Revocation
List
Certificate Signing
RequestCertification Authority

CRL

Certification PracticeStatement
Canonical Name

CPS

CSR
CA

CNAME

Code Signing Certificate
CompromiseCountryCountry code top-leveldomainCross Certificate

Definition

ccTLD

References to Baseline Requirements sections are denoted in short form using the section
number. For example [BR 3.2.2.1] denotes section 3.2.2.1 of the current revision of theBaseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server
Certificates.
A DNS Resource Record defined further in RFC 8659.
A Key Pair where the Public Key appears as the Subject Public Key Info in one or more
Root CA Certificate(s) and/or Subordinate CA Certificate(s).
Digital record that contains information such as the Subscriber’s distinguished name andpublic key, and the signer's signature and data.
Certificate requests and data related thereto (whether obtained from the Applicant orotherwise) in the CA’s possession or control or to which the CA has access.
Processes, practices, and procedures associated with the use of keys, software, andhardware, by which the CA verifies Certificate Data, issues Certificates, maintains a
Repository, and revokes Certificates.
A set of rules that indicates the applicability of a named Certificate to a particularcommunity and/or PKI implementation with common security requirements.
Complaint of suspected Key Compromise, Certificate misuse, or other types of fraud,
compromise, misuse, or inappropriate conduct related to Certificates.
A set of documents or files that defines requirements for Certificate content andCertificate extensions in accordance with Section 7 Certificate, CRL, and OCSP Profiles,
e.g. a Section in a CA’s CPS or a certificate template file used by CA software.
A regularly updated time-stamped list of revoked Certificates that is created and digitally
signed by the CA that issued the Certificates.
A message sent to the certification authority containing the information required to issue
a digital certificate.
Certificate Issuing entity defined further in Section 1.3.1 Certificate Authorities of thisdocument.
One of several documents forming the governance framework in which Certificates are
created, issued, managed, and used.
A DNS resource record to provide the canonical name associated with an alias namefurther defined in RFC 2181 Section 10.1.
A certificate issued to an organization for the purpose of digitally signing software.
A loss, theft, disclosure, modification, unauthorized use, or other breach of security
related to a Private Key.
Either a member of the United Nations OR a geographic region recognized as a
Sovereign State by at least two UN member nations.
An internet top level domain reserved for a country or dependent territory.
A certificate that is used to establish a trust relationship between two Root CAs.

Custom Certificate

A certificate profile defined for a specific, non-standard usage.

Delegated Third Party

Distinguished Name

DN

A natural person or Legal Entity that is not the CA but is authorized by the CA, andwhose activities are not within the scope of the appropriate CA audits, to assist in theCertificate Management Process by performing or fulfilling one or more of the CA
requirements found herein.
A globally unique identifier representing a Subscriber.

Doing Business As

DBA

An entity name or trade name used for Subject Identity Information

Domain Authorization
Document
Domain Contact

Domain Label
Domain Name

Documentation provided by, or a CA’s documentation of a communication with, aDomain Name Registrar attesting to the authority of an Applicant to request a Certificate
for a specific domain namespace.
The Domain Name Registrant, technical contact, or administrative contract (or theequivalent under a ccTLD) as listed in the WHOIS record of the Base Domain Name orin a DNS SOA record.
A portion of an FQDN further defined in RFC 8499 Section 2
An ordered list of one or more Domain Labels assigned to a node in the Domain Name
System.
Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
9

Starfield CP-CPS v5.01

Term

Acronym

Domain Namespace

The set of all possible Domain Names that are subordinate to a single node in the
Domain Name System.
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 right tocontrol how a Domain Name is used, such as the natural person or Legal Entity that islisted as the “Registrant” by WHOIS or the Domain Name Registrar.
An entity that manages the reservation of internet domain names.

Domain Name Registrant

Domain Name Registrar
Domain Naming Service

DNS

Expiry Date
Extended Validation

EV

Fully-Qualified Domain
Name
Generic top-level domain

FQDN
gTLD

Government Entity

Governance and Policy
Committee
Hardware Security
ModuleHigh Assurance

GPC
HSM

An internet service used to map IP addresses to domain names.
The “Not After” date in a Certificate that defines the end of a Certificate’s validity
period.
Certificate issued under the Guidelines for the Issuance and Management of Extended
Validation Certificates published by the CA/Browser Forum.
An absolute Domain Name that includes the Domain Labels of all superior nodes in theInternet Domain Name System.
A category of top-level domains maintained by the Internet Assigned Numbers
Authority.
A government-operated legal entity, agency, department, ministry, branch, or similarelement of the government of a country, or political subdivision within such country(such as a state, province, city, county, etc.).
The Starfield committee which creates and maintains the policies related to the Starfield
Public Key Infrastructure. Also known as the Policy Authority Committee (PAC).
A specialized computer hardware system designed to securely store encryption keys.

ICANN

Starfield’s vetting process that verifies the identity of the individual or organization thatrequested the certificate and access to the domain.
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
registered in IANA’s Root Zone Database.
An independent, non-governmental international organization with a membership of 167
national standards bodies.
An Internet domain name that contains at least one label displayed in software
applications, in whole or in part, in non-latin script or alphabet.
The organization responsible for overseeing the allocation unique names and numbers
used in technical standards.
The nonprofit organization overseeing the use of internet domains.

IP

A network layer communications protocol used for addressing and routing.

Internal Name

International Organizationfor Standardization
Internationalized Domain
NameInternet Assigned
Numbers Authority
Internet Corporation for
Assigned Names andNumbers
Internet Protocol

Definition

ISO
IDN
IANA

IP Address

A 32-bit or 128-bit number assigned to a device that uses the Internet Protocol forcommunication
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.
The Internet Assigned Numbers Authority (IANA) or a Regional Internet Registry(RIPE, APNIC, ARIN, AfriNIC, LACNIC).
An entity that issues certificates.

IP Address Contact
IP Address Registration
Authority
IssuerIssuing CA

Key Generation Script

In relation to a particular Certificate, the CA that issued the Certificate. This could beeither a Root CA or a Subordinate CA.
A Private Key is said to be compromised if its value has been disclosed to an
unauthorized person, or an unauthorized person has had access to it.
A documented plan of procedures for the generation of a CA Key Pair.

Key Pair

The Private Key and its associated Public Key.

LDH Label

The label form and syntax definition for host names further defined in RFC 5890 Section
2.3.1
An association, corporation, partnership, proprietorship, trust, government entity or otherentity with legal standing in a country’s legal system.
Starfield’s vetting process that verifies access to the domain.

Key Compromise

Legal Entity
Medium Assurance
National Institute ofStandards and Technology
Non-Reserved LDH Label

NIST

Object Identifier

OID

Onion Domain Name

US Government Department of Commerce agency for advancing measurements, science,and technology.
Non-Reserved LDH labels are the set of valid LDH labels that do not have "--" in thethird and fourth positions as defined in RFC 5890 Section 2.3.1
A unique identifier issued to an organization by IANA.
A Fully Qualified Domain Name ending with the RFC 7686 “.onion” Special-Use
Domain Name.

Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
10

Starfield CP-CPS v5.01

Term

AcronymDefinition

Online Certificate Status
ProtocolOCSP

A standardized query/response protocol whereby a client can request the status of agiven Certificate and be given a response that will indicate whether the Certificate isvalid or revoked.
An online server operated under the authority of the CA and connected to its Repository
for processing Certificate status requests.
A XN-Label that contains valid output of the Punycode algorithm as defined in RFC
3492 Section 6.3 from the fifth and subsequent positions.
The location of any facility (such as a factory, retail store, warehouse, etc.) where theApplicant’s business is conducted.
The entity responsible for identifying and maintaining requirements for a Public Key
Infrastructure
The Starfield committee which creates and maintains the policies related to the Starfield
Public Key Infrastructure. Also known as the Governance and Policy Committee (GPC).
The key of a Key Pair that is kept secret by the holder of the Key Pair, and that is used tocreate Digital Signatures and/or to decrypt electronic records or files that were encryptedwith the corresponding Public Key.
The key of a Key Pair that may be publicly disclosed by the holder of the corresponding
Private Key and that is used by a Relying Party to verify Digital Signatures created withthe holder’s corresponding Private Key and/or to encrypt messages so that they can bedecrypted only with the holder’s corresponding Private Key.
A set of hardware, software, people, procedures, rules, policies, and obligations used tofacilitate the trustworthy creation, issuance, management, and use of Certificates andkeys based on Public Key Cryptography.
A list of usable domain suffixes as defined by ICANN.

OSCP Responder
P-LabelPlace of Business
Policy Authority

PA

Policy Authority
Committee
Private Key

PAC

Public Key

Public Key
Infrastructure

PKI

Public Suffix List

PSL

Publicly-Trusted
Certificate
Qualified Auditor
Random ValueA 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.
A natural person or Legal Entity that meets the requirements of Section 8.2
Identity/Qualifications of Assessor.
A value specified by a CA to the Applicant that exhibits at least 112 bits of entropy.

Registered Domain Name

A Domain Name that has been registered with a Domain Name Registrar.

Registration Authority

RA

Reliable Data Source

Reliable Method ofCommunication
Relying Party
Relying Party Agreement
Repository

Request for Comment
Request Token
Required Website Content
Reseller
Reserved IP Address

RFC

Any Legal Entity that is responsible for identification and authentication of subjects ofCertificates, 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. When “RA” isused as an adjective to describe a role or function, it does not necessarily imply aseparate body, but can be part of the CA.
An identification document or source of data used to verify Subject Identity Informationthat is generally recognized among commercial enterprises and governments as reliable,
and which was created by a third party for a purpose other than the Applicant obtaining a
Certificate.
A method of communication, such as a postal/courier delivery address, telephone
number, or email address, that was verified using a source other than the Applicant
Representative.
An individual or entity that acts in reliance on a Certificate or digital signature associatedwith a Certificate.
An agreement which specifies the stipulations under which a person or organization acts
as a Relying Party.
An online database containing publicly-disclosed PKI governance documents (such as
Certificate Policies and Certification Practice Statements) and Certificate status
information, either in the form of a CRL or an OCSP response.
A publication in a series from the principal technical development and standards-setting
bodies for the Internet, most prominently the Internet Engineering Task Force (IETF).
A value, derived in a method specified by the CA which binds this demonstration ofcontrol to the certificate request.
Either a Random Value or a Request Token, together with additional information thatuniquely identifies the Subscriber, as specified by the CA.
A person or organization which is given permission by Starfield to sell products to
Subscribers
An IPv4 or IPv6 address that is contained in the address block of any entry in either ofthe following IANA registries:
https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-specialregistry.xhtml

Root CAhttps://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-specialregistry.xhtml
The top level Certification Authority whose Root Certificate is distributed by
Application Software Suppliers and that issues Subordinate CA Certificates.
Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
11

Starfield CP-CPS v5.01

Term

Acronym

Root Certificate
Short-lived Subscriber
Certificate

Secure Socket Layer

SSL

Starfield
Starfield PKIStart of Authority

SOA

Subject

Subject Alternative Name

SAN

Subject Identity
Information
Subordinate CA
Subscriber
Subscriber Agreement
Technically Constrained
Subordinate CA
Certificate
Terms of Use

Trustworthy System

Transport Layer Security

TLS

Unified Communications
Certificate
Unregistered Domain
Name
Valid Certificate

UCC

Definition
The self-signed Certificate issued by the Root CA to identify itself and to facilitate
verification of Certificates issued to its Subordinate CAs.
For Certificates issued on or after 15 March 2024 and prior to 15 March 2026, a
Subscriber Certificate with a Validity Period less than or equal to 10 days (864,000
seconds). For Certificates issued on or after 15 March 2026, a Subscriber Certificate witha Validity Period less than or equal to 7 days (604,800 seconds).
Deprecated transport layer protocol for securing communications. Acronym is still usedin lieu of TLS, the superseding protocol. In the context of this document, SSL implies
TLS.
Starfield Technologies, LLC, and its resellers.
The Starfield Public Key Infrastructure that provides Certificates for individuals andentities.
A DNS resource record containing administrative information about the base DNS zone
marking the start of the zone of authority.
The natural person, device, system, unit, or Legal Entity identified in a Certificate as the
Subject. The Subject is either the Subscriber or a device under the control and operationof the Subscriber.
Optional certificate extension defined in RFC 5280.
Information that identifies the Certificate Subject. Subject Identity Information does notinclude a Domain Name listed in the subjectAltName extension or the Subject
commonName field
A Certification Authority whose Certificate is signed by the Root CA, or another
Subordinate CA.
The individual or entity that has been issued a Certificate and is authorized to use thePrivate Key that corresponds to the Public Key in the Certificate.
An agreement which specifies the stipulations under which a person or organization acts
as a Subscriber.
A Subordinate CA certificate which uses a combination of Extended Key Usage settingsand Name Constraint settings to limit the scope within which the Subordinate CA
Certificate may issue Subscriber or additional Subordinate CA Certificates.
Provisions regarding the safekeeping and acceptable uses of a Certificate issued inaccordance with these Requirements when the Applicant/Subscriber is an Affiliate of the
CA or is the CA.
Computer hardware, software, and procedures that are: reasonably secure from 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.
Protocol used for secure communications over the transport layer of networking
leveraging encryption and certificates.
Certificate that includes multiple Fully-Qualified Domain Names in the Subject
Alternative Name extension used for unified communications.
A Domain Name that is not a Registered Domain Name.
A Certificate that passes the validation procedure specified in RFC 5280.

Validation Specialist

Someone who performs the information verification duties specified by these
Requirements.
From RFC 5280: “The period of time from notBefore through notAfter, inclusive.”

Validity Period
WHOIS

A query and response protocol that is widely used for querying databases that store theregistered users or assignees of an Internet resource such as a domain name.
A Certificate containing at least one Wildcard Domain Name in the Subject Alternative
Names in the Certificate.
A string starting with "\*." (U+002A ASTERISK, U+002E FULL STOP) immediately
followed by a Fully-Qualified Domain Name.
A subset of LDH labels further defined in RFC 5890 Section 2.3.1.

Wildcard Certificate
Wildcard Domain Name
XN-Label

1.6.2 References
ETSI EN 319 403, Electronic Signatures and Infrastructures (ESI); Trust Service Provider
Conformity Assessment - Requirements for conformity assessment bodies assessing Trust
Service Providers

Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
12

Starfield CP-CPS v5.01

ETSI EN 319 411-1, Electronic Signatures and Infrastructures (ESI); Policy and security
requirements for Trust Service Providers issuing certificates; Part 1: General requirementsETSI TS 102 042, Electronic Signatures and Infrastructures (ESI); Policy requirements forcertification authorities issuing public key certificates.
FIPS 140-2, Federal Information Processing Standards Publication - Security Requirements For
Cryptographic Modules, Information Technology Laboratory, National Institute of Standards andTechnology, May 25, 2001.
FIPS 140-3, Federal Information Processing Standards Publication - Security Requirements For
Cryptographic Modules, Information Technology Laboratory, National Institute of Standards andTechnology, March 22, 2019.
FIPS 186-4, Federal Information Processing Standards Publication - Digital Signature Standard(DSS), Information Technology Laboratory, National Institute of Standards and Technology,
July 2013.
ISO 21188:2006, Public key infrastructure for financial services – Practices and policy
framework.
Network and Certificate System Security Requirements, Version 1.7
https://cabforum.org/wp-content/uploads/CA-Browser-Forum-Network-Security-Guidelinesv1.7.pdf.
NIST SP 800-89, Recommendation for Obtaining Assurances for Digital Signature Applications
http://csrc.nist.gov/publications/nistpubs/800-89/SP-800-89_November2006.pdf.
RFC2119, Request for Comments: 2119, Key words for use in RFCs to Indicate Requirement
Levels. S. Bradner. March 1997.
RFC3492, Request for Comments: 3492, Punycode: A Bootstring encoding of Unicode forInternationalized Domain Names in Applications (IDNA). A. Costello. March 2003.
RFC3647, Request for Comments: 3647, Internet X.509 Public Key Infrastructure: Certificate
Policy and Certification Practices Framework. S. Chokhani, et al. November 2003.
RFC3912, Request for Comments: 3912, WHOIS Protocol Specification. L. Daigle. September
2004.
RFC3986, Request for Comments: 3986, Uniform Resource Identifier (URI): Generic Syntax. T.
Berners-Lee, et al. January 2005.
RFC4366, Request for Comments: 4366, Transport Layer Security (TLS) Extensions, BlakeWilson, et al, April 2006.
RFC5019, Request for Comments: 5019, The Lightweight Online Certificate Status Protocol(OCSP) Profile for High-Volume Environments. A. Deacon, et al. September 2007.
RFC5280, Request for Comments: 5280, Internet X.509 Public Key Infrastructure: Certificate
and Certificate Revocation List (CRL) Profile. D. Cooper, et al. May 2008.
RFC5890, Request for Comments: 5890, Internationalized Domain Names for Applications(IDNA): Definitions and Document Framework. J. Klensin. August 2010.
RFC5952, Request for Comments: 5952, A Recommendation for IPv6 Address Text
Representation. S. Kawamura, et al. August 2010.
Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
13

Starfield CP-CPS v5.01

RFC6960, Request for Comments: 6960, X.509 Internet Public Key Infrastructure Online
Certificate Status Protocol - OCSP. S. Santesson, et al. June 2013.
RFC6962, Request for Comments: 6962, Certificate Transparency. B. Laurie, et al. June 2013.
RFC7231, Request For Comments: 7231, Hypertext Transfer Protocol (HTTP/1.1): Semantics
and Content. R. Fielding, et al. June 2014.
RFC7482, Request for Comments: 7482, Registration Data Access Protocol (RDAP) Query
Format. A. Newton, et al. March 2015.
RFC7538, Request For Comments: 7538, The Hypertext Transfer Protocol Status Code 308(Permanent Redirect). J. Reschke. April 2015.
RFC8499, Request for Comments: 8499, DNS Terminology. P. Hoffman, et al. January 2019.
RFC8659, Request for Comments: 8659, DNS Certification Authority Authorization (CAA)
Resource Record. P. Hallam-Baker, et al. November 2019.
RFC8738, Request for Comments: 8738, Automated Certificate Management
Environment (ACME) IP Identifier Validation Extension. R.B.Shoemaker, Ed. February
2020.
RFC8954, Request for Comments: 8954, Online Certificate Status Protocol (OCSP) Nonce
Extension. M. Sahni, Ed. November 2020.
WebTrust for Certification Authorities, SSL Baseline with Network Security,
available at https://www.cpacanada.ca/business-and-accounting-resources/audit-andassurance/overview-of-webtrust-services/principles-and-criteria.
X.509, Recommendation ITU-T X.509 (08/2005) | ISO/IEC 9594-8:2005, Information
technology – Open Systems Interconnection – The Directory: Public-key and attribute certificate
frameworks.

Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
14

Starfield CP-CPS v5.01

1.6.3 Conventions
Terms not otherwise defined in these Requirements shall be as defined in applicable agreements,
user manuals, Certificate Policies and Certification Practice Statements, of Starfield.
The key words “MUST”, “MUST NOT”, "REQUIRED", "SHALL", "SHALL NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in these
Requirements shall be interpreted in accordance with RFC 2119.
By convention, this document omits time and time zones when listing effective requirements suchas dates. Except when explicitly specified, the associated time with a date shall be 00:00:00 UTC.

Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
15

Starfield CP-CPS v5.01

2 PUBLICATION AND REPOSITORYRESPONSIBILITIES
2.1

Repositories

In providing Repository services, obligations of the Starfield PKI include:• Storing and distributing public-key certificates (where relevant)• Storing and distributing certificate status information (such as CRLs and/or online certificate
status)• Storing and distributing this CP/CPS and subsequent updates.
• Storing and distributing the Relying Party and Subscriber agreements.
The Starfield Repository is located at https://certs.secureserver.net/repository

2.2

Publication of Certification Information

The Starfield repository shall contain the current and historical versions of this CP/CPS, a fingerprintof the Starfield Root CAs, current CRLs for the Starfield CAs, and other information relevant to
Subscribers and Relying Parties. This CP/CPS is structured in accordance with RFC 3647 inalignment with the most recent published version of the CA/B Forum Baseline Requirements for theIssuance and Management of Publicly-Trusted TLS Server Certificates.

2.3

Time or Frequency of Publication

This CP/CPS is updated and published on no less than an annual basis. CRLs and OCSP responses
are published in accordance with Section 4.9.7 CRL Issuance Frequency and Section 4.9.10 On-line
Revocation Checking Requirements.

2.4

Access Controls on Repositories

Read access to the Starfield repository is unrestricted. Write access to the repository is restricted toauthorized Starfield PKI personnel through the use of appropriate logical access controls.

Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
16

Starfield CP-CPS v5.01

3 IDENTIFICATION AND AUTHENTICATION
3.1

Naming3.1.1 Types of Names
All certificate holders require either a Distinguished Name in the Subject field that is incompliance with the X.500 standard for Distinguished Names, or a set of Subject Alternative
Name values in the Subject Alternative Name extension. In the case where subject identity
information is contained solely in the Subject Alternative Name extension, the Subject field of thecertificate shall be empty. The Starfield PKI approves naming conventions for the creation of
distinguished names and Subject Alternative Name values for certificate applicants.
The Issuer and Subject Distinguished Name fields for Certificates issued by Starfield are
populated in accordance with Section 7.1 Certificate Profile.

3.1.2 Need for Names to be Meaningful
For Starfield PKI certificates that contain a Distinguished Name in the Subject field, said
Distinguished Names shall be meaningful. For Starfield PKI certificates with an empty Subject
field, any information contained in the Subject Alternative Name extension may or may not bemeaningful depending on the type and intended use of the certificate.

3.1.3 Anonymity or Pseudonymity of Subscribers
For Internationalized Domain Names (IDNs), Starfield may include the Punycode representationof the name(s) in one or more Subject fields.

3.1.4 Rules for Interpreting Various Name Forms
Refer to Section 3.1.1 Types of Names

3.1.5 Uniqueness of Names
Refer to Sections 3.1.1 Types of Names and 3.1.6 Recognition, Authentication and Role ofTrademarks.

3.1.6 Recognition, Authentication and Role of Trademarks
Certificate Applicants are prohibited from using names in their Certificate Applications that
infringe upon others’ Intellectual Property Rights. Starfield does not verify whether a Certificate
Applicant has Intellectual Property rights in the name appearing in a Certificate Application nor
does Starfield arbitrate, mediate, prosecute, or otherwise resolve any dispute concerning theownership of any domain name, trade name, trademark, or service mark. Starfield may, without
liability to any Certificate applicant, reject or suspend any Certificate application because of suchdispute.

Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
17

Starfield CP-CPS v5.01

3.2

Initial Identity Validation

For Basic and Medium Assurance Domain Validated SSL Server Certificate Subscribers, Starfield
verifies the following:• the individual requesting the certificate has access to the domain name(s) that are specified in
the certificate application using the methods described in Section 3.2.2.4 Validation of
Domain Authorization or Control.
For High Assurance Organizational Validated SSL Server Certificate Subscribers, Starfield verifies
the following:• the individual requesting the certificate has access to the domain name(s) that are specified in
the certificate application using the methods described in Section 3.2.2.4 Validation of
Domain Authorization or Control.
• the individual requesting the certificate is authorized to do so by the organization named in
the certificate using the methods described in Section 3.2.5 Validation of Authority• the organization name represents an organization validated using the methods described in
Section 3.2.2 Authentication of Organization and Domain Identity.
For Extended Validation SSL Server Certificate Subscribers, Starfield verifies the following inaccordance with the CA/Browser Forum Guidelines for the Issuance and Management of Extended
Validation Certificates:• Legal Existence and Identity• Assumed Name (optional)• Physical Existence• Operational Existence (if records indicate that the organization is less than three years old)
• Domain ownership or exclusive right to use• Name, title, and authority of contract signer, and certificate approverNote: Effective as of 1 October 2020, before using an incorporating or registration agency for validationof an Extended Validation Certificate, that agency is disclosed publicly via
https://ssltools.godaddy.com/compliance/Approved_Incorporating_and_Registration_Agencies.xlsx.
This document, Approved Incorporating and Registration Agencies, contains the name of the agency,
jurisdiction(s) and website information as well as a document history including version numbers andpublication dates for all edits.

3.2.1 Method to Prove Possession of Private Key
The Subscriber’s certificate request must contain the public key to be certified and be digitally
signed with the corresponding private key.

3.2.2 Authentication of Organization and Domain Identity
3.2.2.1

Identity

If the Subject Identity Information is to include the name or address of an organization,
Starfield verifies the identity and address of the organization and that the address is the
Applicant’s address of existence or operation using documentation provided by, or throughcommunication with, at least one of the following:
Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
18

Starfield CP-CPS v5.01

1. A government agency in the jurisdiction of the Applicant’s legal creation, existence, or
recognition;
2. A third party database that is periodically updated and considered a Reliable Data
Source;3. A site visit by Starfield or a third party who is acting as an agent for Starfield; or
4. An Attestation Letter.
Starfield may use the same documentation or communication described in 1 through 4 above toverify both the Applicant’s identity and address, or Starfield may verify the address of the
Applicant (but not the identity of the Applicant) using a utility bill, bank statement, credit card
statement, government-issued tax document, or other form of identification determined to bereliable.

3.2.2.2

DBA/Tradename

If the Subject Identity Information is to include a DBA or tradename, Starfield verifies the
Applicant’s right to use the DBA/tradename using at least one of the following:
1. Documentation provided by, or communication with, a government agency in thejurisdiction of the Applicant’s legal creation, existence, or recognition;
2. A Reliable Data Source;
3. Communication with a government agency responsible for the management of such
DBAs or tradenames;
4. An Attestation Letter accompanied by documentary support; or
5. A utility bill, bank statement, credit card statement, government-issued tax document,or other form of identification that the Starfield determines to be reliable.

3.2.2.3

Verification of Country

If the subject:countryName field is present, then Starfield shall verify the country associatedwith the Subject using one of the following:
1. The IP Address range assignment by country for either
a. The web site’s IP address, as indicated by the DNS record for the web site, orb. The Applicant’s IP address;
2. The ccTLD of the requested Domain Name;
3. Information provided by the Domain Name Registrar; or
4. A method identified in Section 3.2.2.1 Identity.

3.2.2.4

Validation of Domain Authorization or Control

Domain names included in the Subject Common Name or Subject Alternative Name fields ofan End Entity Certificate may be Fully-Qualified or wildcard. Wildcard certificates arevalidated in accordance with [BR 3.2.2.6].
Verification of domain name access is performed when a domain name is first requested for acertificate in a given customer account.
Verification of domain name access may be performed when a Subscriber requests the renewalof a certificate in accordance with Section 4.6 Certificate Renewal.
Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
19

Starfield CP-CPS v5.01

In compliance with the CA / Browser Forum Baseline Requirements for the Issuance andManagement of Publicly-Trusted TLS Server Certificates, for each Fully-Qualified Domain
Name listed in a Certificate, Starfield confirms that, as of the date the Certificate was issued,
the Applicant either is the Domain Name Registrant or has control over the FQDN by using one
or more of the following methods:
Validating the Applicant as a Domain Contact
For certificates issued prior to August 1, 2018 confirming the Applicant as the Domain Name
Registrant directly with the Domain Name Registrar by determining that the domain was
registered using the same account as the certificate.
Email, Fax, SMS, or Postal Mail to Domain Contact
Communicating a Random Value via email, fax, SMS, or postal mail to a Domain Contact
and receiving a confirming response utilizing the Random Value to the request for approval.
Phone Contact with Domain Contact
Confirming the Applicant's control over the requested FQDN by calling the Domain Name
Registrant's phone number and obtaining a response confirming the Applicant's request forvalidation of the FQDN.
Note: Starfield will NOT perform validations using this method after May 31, 2019. Completed
validations using this method SHALL continue to be valid for subsequent issuance per the applicablecertificate data reuse periods.

Constructed Email to Domain Contact
Communicating with the Domain’s administrator by (i) using an email address created by
pre-pending ‘admin’, ‘administrator’, ‘webmaster’, ‘hostmaster’, or ‘postmaster’ in the local
part, followed by the at-sign (“@”), followed by an Authorization Domain Name, (ii)including a Random Value in the email, and (iii) receiving a confirming response utilizing
the Random Value.
Domain Authorization Document
For certificates issued on or after August 1, 2018, this method is not used for validation.
Agreed-Upon Change to Website
Having the Applicant demonstrate practical control over the FQDN by placing a Random
Value generated by Starfield on an online web page located at /.well-known/pki-validation/on the Authorization Domain Name that is accessible by the CA via HTTP/HTTPS over an
Authorized Port.
Note: Starfield will NOT perform validations using this method after June 3, 2020. Completed
validations using this method SHALL continue to be valid for subsequent issuance per the applicablecertificate data reuse periods.

DNS Change
Having the Applicant demonstrate practical control over the FQDN by confirming thepresence of a Random Value generated by Starfield in a DNS TXT or CAA record for an
Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
20

Starfield CP-CPS v5.01

Authorization Domain Name or an Authorization Domain Name that is prefixed with a
Domain Label that begins with an underscore character.
If a Random Value is used, Starfield or Delegated Third Party SHALL provide a Random
Value unique to the certificate request and SHALL not use the Random Value after (i) 30
days or (ii) if the Applicant submitted the certificate request, the timeframe permitted forreuse of validated information relevant to the certificate.
IP Address
No IP address certificates are issued under this CPS.
Test Certificate
Starfield does not validate domain authorization or control by confirming presence of a Test
Certificate.

TLS Using a Random Value
This method of domain validation is not used.
Any Other Method
This method of domain validation is not used.
Validating Applicant as a Domain Contact
Confirming the Applicant is the Domain Name Contact directly with the Domain Name
Registrar by determining that the domain was registered using the same account as thecertificate.
Email to DNS CAA Contact
This method of domain validation is not used.
Email to DNS TXT Contact
This method of domain validation is not used.
Phone Contact with Domain Contact
Confirm the Applicant's control over the FQDN by calling the Domain Contact’s phone
number and obtain a confirming response to validate the ADN. Each phone call MAY
confirm control of multiple ADNs provided that the same Domain Contact phone number islisted for each ADN being verified and they provide a confirming response for each ADN.
In the event that someone other than a Domain Contact is reached, Starfield MAY request to
be transferred to the Domain Contact.
In the event of reaching voicemail, Starfield may leave the Random Value and the ADN(s)being validated. The Random Value MUST be returned to Starfield approve the request.
The Random Value SHALL remain valid for use in a confirming response for no more than
30 days from its creation.
Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
21

Starfield CP-CPS v5.01

Note: Once the FQDN has been validated using this method, Starfield MAY also issue
Certificates for other FQDNs that end with all the Domain Labels of the validated FQDN.
This method is suitable for validating Wildcard Domain Names.
Phone Contact with DNS TXT Record Phone Contact
This method of domain validation is not used.
Phone Contact with DNS CAA Phone Contact
This method of domain validation is not used.
Agreed-Upon Change to Website v2
Confirming the Applicant's control over the FQDN by verifying that the Request Token or
Random Value is contained in the contents of a file.
1. The entire Request Token or Random Value MUST NOT appear in the request used toretrieve the file, and
2. The CA MUST receive a successful HTTP response from the request (meaning a 2xx
HTTP status code must be received).
The file containing the Request Token or Random Value:
1. MUST be located on the Authorization Domain Name, and2. MUST be located under the “/.well-known/pki-validation” directory, and3. MUST be retrieved via either the “http” or “https” scheme, and
4. MUST be accessed over an Authorized Port.
If the CA follows redirects, the following apply:
1. Redirects MUST be initiated at the HTTP protocol layer.
a. For validations performed on or after December 1, 2021, redirects MUST be the resultof a 301, 302, or 307 HTTP status code response, as defined in RFC 7231, Section 6.4, ora 308 HTTP status code response, as defined in RFC 7538, Section 3. Redirects MUST
be to the final value of the Location HTTP response header, as defined in RFC 7231,
Section 7.1.2.
b. For validations performed prior to December 1, 2021, redirects MUST be the result of an
HTTP status code result within the 3xx Redirection class of status codes, as defined in
RFC 7231, Section 6.4. CAs SHOULD limit the accepted status codes and resource
URLs to those defined within 1.a.
2. Redirects MUST be to resource URLs with either the “http” or “https” scheme.
3. Redirects MUST be to resource URLs accessed via Authorized Ports.
If a Random Value is used, then:
1. The CA MUST provide a Random Value unique to the certificate request.
2. The Random Value MUST remain valid for use in a confirming response for no more than
30 days from its creation.

Note:
Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
22

Starfield CP-CPS v5.01

*For Certificates issued prior to December 1, 2021, Starfield MAY also issue Certificates for other
FQDNs that end with all the labels of the validated FQDN. This method is suitable for validating
Wildcard Domain Names.
*For Certificates issued on or after December 1, 2021, Starfield MUST NOT issue Certificates forother FQDNs that end with all the labels of the validated FQDN unless Starfield performs a separate
validation for that FQDN using an authorized method. This method is NOT suitable for validating
Wildcard Domain Names.

Agreed-Upon Change to Website - ACME
Confirming the Applicant's control over a FQDN by validating domain control of the FQDN
using the ACME HTTP Challenge method defined in section 8.3 of RFC 8555.

Note:*For Certificates issued prior to December 1, 2021, Starfield MAY also issue Certificates for other
FQDNs that end with all the labels of the validated FQDN. This method is suitable for validating
Wildcard Domain Names.
*For Certificates issued on or after December 1, 2021, Starfield MUST NOT issue Certificates forother FQDNs that end with all the labels of the validated FQDN unless Starfield performs a separate
validation for that FQDN using an authorized method. This method is NOT suitable for validating
Wildcard Domain Names.

TLS Using ALPN
While the issuing CAs under Starfield’s direct control, do not use this method of validation,
Certainly issuing CAs MAY confirm the Applicant’s control over a FQDN by validating
domain control of the FQDN by negotiating a new application layer protocol using the TLS
Application‐Layer Protocol Negotiation (ALPN) Extension [RFC7301] as defined in RFC
8737. The following are additive requirements to RFC 8737
Note: Once the FQDN has been validated using this method, Starfield MUST NOT issue Certificatesfor other FQDNs that end with all the labels of the validated FQDN unless Starfield performs a
separate validation for that FQDN using an authorized method. This method is NOT suitable forvalidating Wildcard Domain Names.

3.2.2.5

Authentication for an IP Address

No IP address certificates are issued under this CPS.

3.2.2.6

Wildcard Domain Validation

Before issuing a Wildcard Certificate, Starfield MUST establish and follow a documented
procedure that determines if the FQDN portion of any Wildcard Domain Name in theCertificate is “registry‐controlled” or is a “public suffix” (e.g. “*.com”, “*.co.uk”, see RFC
6454 Section 8.2 for further explanation).
If the FQDN portion of any Wildcard Domain Name is “registry‐controlled” or is a "public
suffix”, CAs MUST refuse issuance unless the Applicant proves its rightful control of the entire
Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
23

Starfield CP-CPS v5.01

Domain Namespace. (e.g. CAs MUST NOT issue “*.co.uk” or “*.local”, but MAY issue“*.example.com” to Example Co.).
Determination of what is “registry‐controlled” versus the registerable portion of a Country
Code Top‐Level Domain Namespace is not standardized at the time of writing and is not a
property of the DNS itself. Current best practice is to consult a “public suffix list” such as the
Public Suffix List (PSL), and to retrieve a fresh copy regularly.
If using the PSL, a CA SHOULD consult the “ICANN DOMAINS” section only, not the“PRIVATE DOMAINS” section. The PSL is updated regularly to contain new gTLDsdelegated by ICANN, which are listed in the “ICANN DOMAINS” section. A CA is notprohibited from issuing a Wildcard Certificate to the Registrant of an entire gTLD, provided
that control of the entire namespace is demonstrated in an appropriate way.

3.2.2.7

Data Source Accuracy

Prior to using any data source as a Reliable Data Source, Starfield evaluates the source for its
reliability, accuracy, and resistance to alteration or falsification. Starfield considers thefollowing during its evaluation:
1. The age of the information provided,
2. The frequency of updates to the information source,
3. The data provider and purpose of the data collection,
4. The public accessibility of the data availability, and
5. The relative difficulty in falsifying or altering the data.
Databases maintained by Starfield, its owner, or its affiliated companies do not qualify as a
Reliable Data Source if the primary purpose of the database is to collect information for the
purpose of fulfilling the validation requirements under this section.

3.2.2.8

CAA Records

As part of the Certificate issuance process, the Starfield MUST retrieve and process CAA
records in accordance with RFC 8659 for each dNSName in the subjectAltName extension that
does not contain an Onion Domain Name. If the CA issues, they MUST do so within the TTLof the CAA record, or 8 hours, whichever is greater.
This stipulation does not prevent the CA from checking CAA records at any other time.
When processing CAA records, CAs MUST process the issue, issuewild, and iodef property
tags as specified in RFC 8659, although they are not required to act on the contents of the iodef
property tag. Additional property tags MAY be supported, but MUST NOT conflict with orsupersede the mandatory property tags set out in this document. CAs MUST respect the criticalflag and not issue a certificate if they encounter an unrecognized property tag with this flag set.

Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
24

Starfield CP-CPS v5.01

RFC 8659 requires that CAs “MUST NOT issue a certificate unless the CA determines thateither (1) the certificate request is consistent with the applicable CAA RRset or (2) an
exception specified in the relevant CP or CPS applies.”

Note: Starfield does not issue certificates for Onion Domain Names

3.2.3 Authentication of Individual Identity
For High Assurance Individual Subscribers, Starfield verifies the following:• the individual requesting the certificate has access to the domain name(s) that are specified in
the certificate application using the methods described in Section 3.2.2.4 Validation of
Domain Authorization or Control.
• the identity of the individual named in the certificate application using the following
methods:o Starfield verifies the Applicant’s name using a legible copy, which discernibly shows
the Applicant’s face, of at least one currently valid government‐issued photo ID(passport, drivers license, military ID, national ID, or equivalent document type).
o Starfield verifies the Applicant’s address using a form of identification that the CA
determines to be reliable, such as a government ID, utility bill, or bank or credit card
statement.
o Starfield verifies the certificate request with the Applicant using a Reliable Method ofCommunication.

3.2.4 Non-verified Subscriber Information
Not applicable.

3.2.5 Validation of Authority
If the Applicant for a Certificate containing Subject Identity Information is an organization,
Starfield uses a Reliable Method of Communication including email, telephone, and postal
services to verify the authenticity of the Applicant Representative’s certificate request.
Using a Reliable Method of Communication, Starfield establishes the authenticity of the certificate
request directly with the Applicant Representative or with an authoritative source within the
Applicant’s organization, such as the Applicant’s main business offices, corporate offices, humanresource offices, information technology offices, or other department Starfield deems appropriate.
In addition, Starfield has a process that allows an Applicant to specify the individuals who may
request Certificates. If an Applicant specifies, in writing, the individuals who may request a
Certificate, then Starfield does not accept any certificate requests that are outside thisspecification. Starfield will provide an Applicant with a list of its authorized certificate requesters
upon the Applicant’s verified written request.

Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
25

Starfield CP-CPS v5.01

3.2.6 Criteria for Interoperation
Refer to Section 10.3 Cross CA Certificates for all cross certificates that identify the CA as the
Subject.

3.3

Identification and Authentication for Re-key Requests

3.3.1 Identification and Authentication for Routine Re-key
Subscriber requests for routine re-key are authenticated using a shared secret.

3.3.2 Identification and Authentication for Re-key After Revocation
The process for re-key after revocation of a Subscriber certificate is complete re-enrollment, which
requires the generation of a new Subscriber key pair and the re-performance of the initial
Subscriber identification and authentication procedures specified in Section 3.2 Initial Identity
Validation.

3.4
Identification and Authentication for Revocation
RequestSection 4.9 Certificate Revocation and Suspension describes requirements for identification andauthentication of revocation requests.
When revocation is initiated by Starfield, identification and authentication is not required.

Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
26

Starfield CP-CPS v5.01

4 CERTIFICATE LIFE-CYCLE OPERATIONALREQUIREMENTS
4.1

Certificate Application

Certificate applications must include all information required by the relevant Starfield certificate
application form.

4.1.1 Who Can Submit a Certificate Application
Either the Applicant or an authorized Certificate Requestor may submit certificate requests.
Starfield maintains an internal database of all previously revoked Certificates and previously
rejected certificate requests due to suspected phishing or other fraudulent usage or concerns anduses this information to identify subsequent suspicious certificate requests.

4.1.2 Enrollment Process and Responsibilities
Enrollment requires a completed certificate request, acceptance or execution of a Subscriber
Agreement, and a Certificate Signing Request (CSR) containing the public key to be signed.

4.2

Certificate Application Processing

4.2.1 Performing Identification and Authentication Functions
When a certificate application is received, Starfield performs the validation required for the typeof certificate in question as described in Section 3.2 Initial Identity Validation.
Prior to issuing a certificate, Starfield processes RFC 6844 Certificate Authority Authorization(CAA) records for each FQDN in the certificate according to the requirements defined in the
Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server
Certificates. Starfield recognizes the following set of issuer domain names in CAA "issue" or"issuewild" records as permitting certificate issuance:• godaddy.com• starfieldtech.com
Starfield will only use documents and data to verify certificate information that is in accordancewith the maximum time permitted for reuse as per the Baseline Requirements (BR) and the
Guidelines for the Issuance and Management of Extended Validation Certificates.
Starfield relies on internal and 3rd party data to identify high risk Certificate requests prior to theCertificate’s approval and denies these requests and/or subjects them to additional verification
procedures.
Internationalized Domain Names (IDNs) containing mixed character sets within a label may besubjected to additional verification procedures.
Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
27

Starfield CP-CPS v5.01

In cases where the certificate request does not contain all the necessary information about the
Applicant, the Starfield shall obtain the remaining information from the Applicant or, having
obtained it from a reliable, independent, third-party data source, confirm it with the Applicant.

4.2.2 Approval or Rejection of Certificate Applications
Starfield will reject any Certificate application that cannot be verified. Starfield may also reject acertificate application if Starfield believes that issuing the Certificate could damage or diminish
Starfield’s reputation or business.
Starfield enforces separation of validation duties to ensure that no one person can single-handedly
validate and authorize the issuance of EV Certificates.

4.2.3 Time to Process Certificate Applications
Certificate applications made to CAs under Starfield’s direct control may be rejected if domain
validation is not completed within 45 days from certificate request. The RA can choose to extend
this timeframe on an individual basis.

4.3

Certificate Issuance

4.3.1 CA Actions During Certificate Issuance
Certificates are generated, issued and published only after the RA performs the required
identification and authentication steps in accordance with Section 4.2.1 Performing Identification
and Authentication Functions and Section 3.2 Initial Identity Validation.

4.3.2 Notification to Subscriber by the CA of Issuance of Certificate
Subscribers are notified of issuance via email or API methods.

4.4

Certificate Acceptance

4.4.1 Conduct Constituting Certificate Acceptance
A Subscriber’s receipt of a certificate and subsequent use of the key pair and certificate constitutecertificate acceptance. By accepting a certificate, the Subscriber:• Agrees to be bound by the continuing responsibilities, obligations and duties imposed bythis CP/CPS,• Agrees to be bound by the Subscribing Party agreement, and• Represents and warrants that to its knowledge no unauthorized person has had access tothe private key associated with the certificate, and• Represents and warrants that the certificate information it has supplied during theregistration process is truthful and has been accurately and fully published within thecertificate.

Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
28

Starfield CP-CPS v5.01

4.4.2 Publication of the Certificate by the CA
CA certificates are published in the Starfield repository.
All SSL certificates are published in one or more publicly accessible Certificate Transparency(CT) logs.

4.4.3

Notification of Certificate Issuance by the CA to Other
Entities

No Stipulation.

4.5
4.5.1

Key Pair and Certificate Usage
Subscriber Private Key and Certificate Usage

Subscriber obligations for protection of private keys and usage restrictions are listed in therelevant Starfield Subscriber Agreement.

4.5.2

Relying Party Public Key and Certificate Usage

Relying Party obligations for verification of public keys and usage restrictions are listed in theStarfield Relying Party Agreement.

4.6

Certificate Renewal

4.6.1 Circumstance for Certificate Renewal
Certificate renewal, defined as the process whereby a new certificate with an extended validity
period is created for an existing Distinguished Name, is permitted for CA Certificates.

4.6.2 Who May Request Renewal
Either the Applicant or an authorized Certificate Requestor may submit renewal requests.
Starfield maintains an internal database of all previously revoked Certificates and previously
rejected certificate requests due to suspected phishing or other fraudulent usage or concerns anduses this information to identify subsequent suspicious certificate requests.

4.6.3

Processing Certificate Renewal Requests

Subscribers are permitted to reuse a previous certificate request to replace an expiring or expired
Certificate. Where the Subscriber holds a Certificate and the initial Subscriber identification andauthentication process (as described in Section 3.2 Initial Identity Validation) has been performed
within the maximum time permitted for reuse as per the Baseline Requirements (BR) and the
Guidelines for the Issuance and Management of Extended Validation Certificates, Starfield may
authenticate a renewal certificate request using a shared secret. Starfield will require re‐verification and if Starfield believes that the information has become inaccurate.
Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
29

Starfield CP-CPS v5.01

4.6.4

Notification of New Certificate Issuance to Subscriber

Subscribers are notified of issuance via email or API methods.

4.6.5

Conduct Constituting Acceptance of a Renewal Certificate

As described in Section 4.4.1 Conduct Constituting Certificate Acceptance.

4.6.6

Publication of the Renewal Certificate by the CA

As described in Section 4.4.2 Publication of the Certificate by the CA.

4.6.7

Notification of Certificate Issuance by the CA to Other
Entities

No Stipulation.

4.7
4.7.1

Certificate Re-key
Circumstance for Certificate Re-key

Subscribers are permitted to submit an unlimited number of requests to re-key any valid
Certificate during the validity period of the Certificate. After re‐keying a Certificate, Starfield may
revoke the old Certificate in up to 72 hours.

4.7.2

Who May Request Certification of a New Public Key

Starfield, the Applicant, or an authorized Certificate Requestor may submit re-key requests.

4.7.3

Processing Certificate Re-keying Requests

Re-key requests generally follow the process used for renewals (as described in Section 4.6.3
Processing Certificate Renewal Requests).

4.7.4

Notification of New Certificate Issuance to Subscriber

Subscribers are notified of issuance via email or API methods.

4.7.5

Conduct Constituting Acceptance of a Re-keyed Certificate

As described in Section 4.4.1 Conduct Constituting Certificate Acceptance.

4.7.6

Publication of the Re-keyed Certificate by the CA

As described in Section 4.4.2 Publication of the Certificate by the CA.

Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
30

Starfield CP-CPS v5.01

4.7.7

Notification of Certificate Issuance by the CA to Other
Entities

No Stipulation.

4.8

Certificate Modification

Starfield defines certificate modification as the issuance of a new certificate with some change toinformation contained in the certificate such as the addition or removal of a SAN.

4.8.1

Circumstance for Certificate Modification

Subscribers are permitted to request an unlimited number of modifications to any valid Certificate
during the validity period of the Certificate.

4.8.2

Who May Request Certificate Modification

Starfield, the Subscriber, or an authorized Certificate Requestor may request modification.

4.8.3

Processing Certificate Modification Requests

Modification requests generally follow the process used for renewals (as described in Section
4.6.3 Processing Certificate Renewal Requests).

4.8.4

Notification of New Certificate Issuance to Subscriber

Subscribers are notified of issuance via email or API methods.

4.8.5

Conduct Constituting Acceptance of Modified Certificate

As described in Section 4.4.1 Conduct Constituting Certificate Acceptance.

4.8.6

Publication of the Modified Certificate by the CA

As described in Section 4.4.2 Publication of the Certificate by the CA.

4.8.7

Notification of Certificate Issuance by the CA to Other
Entities

No Stipulation.

4.9

Certificate Revocation and Suspension

Starfield supports certificate revocation for all Starfield CAs. Starfield does not support certificate
suspension.

Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
31

Starfield CP-CPS v5.01

4.9.1 Circumstances for Revocation
4.9.1.1

Reasons for Revoking a Subscriber Certificate

Starfield SHALL revoke a Certificate within 24 hours and using the corresponding CRL
Reason from Section 7.2.2 CRL and CRL Entry Extensions if one or more of the following
occurs:1. The Subscriber requests in writing that Starfield, without specifying a reason, revoke
the Certificate (CRLReason “unspecified (0)” which results in no ReasonCode
extension being provided);
2. The Subscriber notifies Starfield that the original certificate request was not authorized
and does not retroactively grant authorization (CRLReason 9, privilegeWithdrawn);
3. Starfield obtains evidence that the Subscriber’s Private Key corresponding to the Public
Key in the Certificate suffered a Key Compromise (CRLReason 1, keyCompromise);
4. Starfield is made aware of a demonstrated or proven method that can easily compute theSubscriber’s Private Key based on the Public Key in the Certificate, such as a Debianweak key, see https://wiki.debian.org/SSLkeys(CRLReason 1, keyCompromise);
5. Starfield 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
(CRLReason 4, superseded);.
Starfield may revoke a certificate within 24 hours and will revoke a Certificate within 5 days
and use the corresponding CRLReason if one or more of the following occurs:
1. The Certificate no longer complies with the requirements of Section 6.1.5 Key Sizes
and Section 6.1.6 Public Key Parameters Generation and Quality Checking of this
CP/CPS (CRLReason 4, superseded);
2. Starfield obtains evidence that the Certificate was misused (CRLReason 9,
privilegeWithdrawn);
3. Starfield is made aware that a Subscriber has violated one or more of its material
obligations under the Subscriber Agreement or Terms of Use (CRLReason 9,
privilegeWithdrawn);
4. Starfield 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 theDomain Name) (CRLReason 5, cessationOfOperation);
5. Starfield is made aware that a Wildcard Certificate has been used to authenticate afraudulently misleading subordinate Fully‐Qualified Domain Name (CRLReason 9,
privilegeWithdrawn);
6. Starfield is made aware of a material change in the information contained in theCertificate (CRLReason 9, privilegeWithdrawn);
7. Starfield is made aware that the Certificate was not issued in accordance with these
Requirements or this CP/CPS (CRLReason 4, superseded);
8. Starfield determines or is made aware that any of the information appearing in theCertificate is inaccurate (CRLReason 9, privilegeWithdrawn);
Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
32

Starfield CP-CPS v5.01

9. Starfield’s right to issue Certificates under these Requirements expires or is revoked or
terminated, unless Starfield has made arrangements to continue maintaining the
CRL/OCSP Repository (CRLReason "unspecified (0)" which results in no reasonCode
extension being provided in the CRL);
10. Revocation is required by this CP/CPS for a reason that is not otherwise required to be
specified by this section (CRLReason "unspecified (0)" which results in no reasonCode
extension being provided in the CRL); or
11. Starfield 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 (CRLReason #1,
keyCompromise).
If a CRL entry is for a Certificate not subject to these Requirements and was either issued onor-after 2020-09-30 or has a notBefore on-or-after 2020-09-30, the CRLReason MUST NOT
be certificateHold (6). If a CRL entry is for a Certificate subject to these Requirements, the
CRLReason MUST NOT be certificateHold (6).
If a reasonCode CRL entry extension is present, the CRLReason MUST indicate the mostappropriate reason for revocation of the Certificate.
CRLReason MUST be included in the reasonCode extension of the CRL entry corresponding
to a Subscriber Certificate that is revoked after July 15, 2023, unless the CRLReason is"unspecified (0)". Revocation reason code entries for Subscriber Certificates revoked prior to
July 15, 2023, do NOT need to be added or changed.
Only the following CRLReasons MAY be present in the CRL reasonCode extension for
Subscriber Certificates:
keyCompromise (RFC 5280 CRLReason #1): Indicates that it is known or suspected that the
Subscriber’s Private Key has been compromised;affiliationChanged (RFC 5280 CRLReason #3): Indicates that the Subject's name or other
Subject Identity Information in the Certificate has changed, but there is no cause to suspect that
the Certificate's Private Key has been compromised;superseded (RFC 5280 CRLReason #4): Indicates that the Certificate is being replaced
because: the Subscriber has requested a new Certificate, the CA has reasonable evidence thatthe validation of domain authorization or control for any fully‐qualified domain name or IP
address in the Certificate should not be relied upon, or the CA has revoked the Certificate forcompliance reasons such as the Certificate does not comply with the Baseline Requirements or
this CP/CPS;
cessationOfOperation (RFC 5280 CRLReason #5): Indicates that the website with theCertificate is shut down prior to the expiration of the Certificate, or if the Subscriber no longer
owns or controls the Domain Name in the Certificate prior to the expiration of the Certificate;or
privilegeWithdrawn (RFC 5280 CRLReason #9): Indicates that there has been a subscriberside infraction that has not resulted in keyCompromise, such as the Certificate Subscriber
provided misleading information in their Certificate Request or has not upheld their material
obligations under the Subscriber Agreement or Terms of Use.
Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
33

Starfield CP-CPS v5.01

The Subscriber Agreement, or an online resource referenced therein, MUST inform Subscribers
about the revocation reason options listed above and provide explanation about when to chooseeach option. Tools that the CA provides to the Subscriber MUST allow for these options to beeasily specified when the Subscriber requests revocation of their Certificate, with the default
value being that no revocation reason is provided (i.e. the default corresponds to the
CRLReason “unspecified (0)” which results in no reasonCode extension being provided in the
CRL).
The privilegeWithdrawn reasonCode SHOULD NOT be made available to the Subscriber as a
revocation reason option, because the use of this reasonCode is determined by the CA and not
the Subscriber.
When a CA obtains verifiable evidence of Key Compromise for a Certificate whose CRL entry
does not contain a reasonCode extension or has a reasonCode extension with a nonkeyCompromise reason, the CA SHOULD update the CRL entry to enter keyCompromise as
the CRLReason in the reasonCode extension. Additionally, the CA SHOULD update therevocation date in a CRL entry when it is determined that the private key of the certificate wascompromised prior to the revocation date that is indicated in the CRL entry for that certificate.
Note: Backdating the revocationDate field is an exception to best practice described in RFC 5280
section 5.3.2; however, these requirements specify the use of the revocationDate field to support TLS
implementations that process the revocationDate field as the date when the Certificate is firstconsidered to be compromised.

4.9.1.2

Reasons for Revoking a Subordinate CA Certificate

Starfield will revoke a Subordinate CA Certificate within seven (7) days if one or more of thefollowing occurs:
1. The Subordinate CA requests revocation in writing(CRLReason "unspecified (0)"which results in no reasonCode extension being provided in the CRL);;
2. The Subordinate CA notifies Starfield that the original certificate request was not
authorized and does not retroactively grant authorization (CRLReason 9,
privilegeWithdrawn);
3. Starfield obtains evidence that the Subordinate CA’s Private Key corresponding to the
Public Key in the Certificate suffered a Key Compromise or no longer complies withthe requirements of Section 6.1.5 Key Sizes and Section 6.1.6 Public Key Parameters
Generation and Quality Checking of this CP/CPS (CRLReason 1, keyCompromise);
4. Starfield obtains evidence that the Certificate was misused(CRLReason 9,
privilegeWithdrawn);
5. Starfield is made aware that the Certificate was not issued in accordance with or that
Subordinate CA has not complied with this document or the applicable Certificate
Policy or Certification Practice Statement(CRLReason 9, privilegeWithdrawn);
6. Starfield determines that any of the information appearing in the Certificate is
inaccurate or misleading(CRLReason 9, privilegeWithdrawn);
7. Starfield or the Subordinate CA ceases operations for any reason and has not madearrangements for another CA to provide revocation support for the
Certificate(CRLReason 5, cessationOfOperation);
Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
34

Starfield CP-CPS v5.01

8. Starfield’s or the Subordinate CA’s right to issue Certificates under these Requirements
expires or is revoked or terminated, unless Starfield has made arrangements to continue
maintaining the CRL/OCSP Repository(CRLReason "unspecified (0)" which results in
no reasonCode extension being provided in the CRL); or
9. Revocation is required by Starfield’s CP/CPS(CRLReason "unspecified (0)" which
results in no reasonCode extension being provided in the CRL).

4.9.2 Who Can Request Revocation
Subscriber certificate revocation can be initiated by the Subscriber, Starfield, the Issuing CA, or
authorized Resellers. Additionally, revocation requests can be initiated by anyone who can accessthe ACME API endpoint that can complete the revocation procedures in Section 4.9.3 Procedure
for Revocation Request.

4.9.3 Procedure for Revocation Request
Starfield maintains a continuous 24x7 ability to accept and respond to revocation requests andrelated inquiries.
Revocations may be requested:• by Subscribers via their online account, which are authenticated using a shared secret; or• by Subscribers using the appropriate ACME API endpoint, if they can sign the revocation
request with the associated account private key; or• by anyone who can access the appropriate ACME API endpoint and sign a revocation
request with the private key associated with the certificate; or• by anyone who can access appropriate ACME API endpoint and demonstrate control overall domains in the Subject.
If the revocation request cannot be authenticated using a shared secret or through the ACME
endpoint, the RA must perform sufficient procedures to authenticate the revocation request inaccordance with Starfield’s revocation request processing procedures.
For reporting suspected private key compromise, certificate misuse, or other types of fraud,
compromise, misuse, inappropriate conduct, or any other type of suspicious activity with acertificate, contact Starfield at practices@starfieldtech.com.

4.9.4 Revocation Request Grace Period
Starfield validates automated revocation requests (i.e., where a shared secret is correctly provided)on receipt. Starfield commences the validation of non-automated revocation requests within one
business day of receipt.
Starfield immediately processes authenticated revocation requests. A certificate’s revoked statusis reflected on a CRL and in an OCSP response published at intervals specified below. Revokedcertificates are listed in the CRL and in OCSP responses until the certificate expires, with the
exception of Code Signing certificates which are retained on the CRL and in OCSP responses for
10 years after the latter of certificate revocation or expiration.
Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
35

Starfield CP-CPS v5.01

4.9.5 Time Within Which CA Must Process the Revocation Request
Within 24 hours after receiving a Certificate Problem Report, Starfield will investigate the facts
and circumstances related to a Certificate Problem Report and provide a preliminary report on its
findings to both the Subscriber and the entity who filed the Certificate Problem Report.
After reviewing the facts and circumstances, Starfield will work with the Subscriber and any entity
reporting the Certificate Problem Report or other revocation-related notice to establish whether or
not the certificate will be revoked, and if so, a date which Starfield will revoke the certificate. The
period from receipt of the Certificate Problem Report or revocation-related notice to publishedrevocation MUST NOT exceed the time frame set forth in Section 4.9.1.1 Reasons for Revoking a
Subscriber Certificate. The date selected by Starfield will consider the following criteria:
1. The nature of the alleged problem (scope, context, severity, magnitude, risk of harm);
2. The consequences of revocation (direct and collateral impacts to Subscribers and Relying
Parties);
3. The number of Certificate Problem Reports received about a particular Certificate or
Subscriber;
4. The entity making the complaint (for example, a complaint from a law enforcement official thata Web site is engaged in illegal activities should carry more weight than a complaint from a
consumer alleging that they didn't receive the goods they ordered); and5. Relevant legislation.

4.9.6

Revocation Checking Requirement for Relying Parties

Relying Parties are required to check certificate status using the applicable CRL and/or OCSP
before relying upon a certificate.

4.9.7

CRL Issuance Frequency

CRLs for CAs under Starfield’s direct control are issued in accordance with the following table:
CA TypeRoot CAs
Issuing CAs

CRL Publication Frequency
Every 365 days or less and upon certificate revocation
Every 24 hours

The value of the nextUpdate field MUST NOT be more than 365 days beyond the value of the
thisUpdate field for Root CAs and 10 days for Issuing CAs.
If Certainly publishes a CRL, they will do it in compliance with the CA / Browser Forum Baseline
Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates, andtheir CP/CPS.

4.9.8 Maximum Latency for CRLs (if applicable)
No Stipulation.

Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
36

Starfield CP-CPS v5.01

4.9.9 On-line Revocation/Status Checking Availability
Relying Parties are required to check certificate status using the applicable CRL and/or OCSP
before relying upon a certificate.
The following SHALL apply for communicating the status of Certificates which include an
Authority Information Access extension with an id-ad-ocsp accessMethod.
OCSP responses conform to RFC6960 and/or RFC5019. OCSP responses either:1.
Are signed by the CA that issued the Certificates whose revocation status is being
checked, or2.
Are signed by an OCSP Responder whose Certificate is signed by the CA that issued theCertificate whose revocation status is being checked.
In the latter case, the OCSP signing Certificate contains an extension of type id-pkix-ocspnocheck, as defined by RFC6960.

4.9.10 On-line Revocation Checking Requirements
The following SHALL apply for communicating the status of Certificates which include an Authority
Information Access extension with an id-ad-ocsp accessMethod.
OCSP responders operated by Starfield support the HTTP GET method, as described in RFC6960 and/or
RFC5019. The CA MAY process the Nonce extension (`1.3.6.1.5.5.7.48.1.2`) in accordance with RFC
8954.

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 and Subordinate CA Certificates:• Starfield OCSP responses have a validity interval between 24 and 96 hours.
• Starfield updates the information provided via an OCSP at least eight hours prior to the
nextUpdate.
If the OCSP responder receives a request for status of a certificate that has not been issued, thenthe responder does not respond with a "good" status.

4.9.11 Other Forms of Revocation Advertisements Available
Starfield does not require OCSP stapling.

4.9.12 Special Requirements Regarding Key Compromise
There is no deviation from the certificate revocation or Certificate Problem Report procedures
specified above when the revocation of a Subscriber certificate is due to private key compromise.
Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
37

Starfield CP-CPS v5.01

Parties may use the following methods to demonstrate private key compromise:•••

Submission of the private key
Submission of a CSR signed by the private key
Submission of a revoke request following the procedures defined in Section 7.6 of RFC
8555 requiring signing the revocation request with the compromised key

If a key compromise is successfully proven, Starfield will revoke the certificate according to thespecifications in Section 4.9 Certificate Revocation and Suspension.
In addition to the procedures specified above, if deemed necessary, Starfield uses commerciallyreasonable efforts to notify potential Relying Parties if Starfield discovers, or has reason tobelieve, that there has been a compromise of a Starfield CA private key.

4.9.13 Circumstances for Suspension
We do not perform certificate suspension.

4.9.14 Who Can Request Suspension
Not applicable.

4.9.15 Procedure for Suspension Request
Not applicable.

4.9.16 Limits on Suspension Period
Not applicable.

4.10

Certificate Status Services

4.10.1 Operational Characteristics
Starfield publishes certificate status information via CRL and OCSP. Revocation entries remain on
the CRL and OCSP responses until after the certificate’s expiration date.
Starfield published both full master CRLs and partitioned CRLs. URLs to partitioned CRLs areincluded in the certificate and master CRLs are published on the Starfield repository.

4.10.2 Service Availability
Starfield’s CRL and OCSP services incorporate a distributed design intended to provide 24x7
availability.
The Starfield PKI allows Subscribers, Relying Parties, Application Software Vendors, and otherthird parties to report complaints or suspected Private Key compromise, Certificate misuse, orother types of fraud, compromise, misuse, or inappropriate conduct related to Certificates via
email as published in the Starfield repository.
Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
38

Starfield CP-CPS v5.01

Starfield maintains a continuous 24/7 ability to respond to any high priority certificate problem
reports and to revoke certificates in accordance with Section 4.9 Certificate Revocation and
Suspension and/or report the problem to law enforcement officials.

4.10.3 Optional Features
No Stipulation.

4.11

End of Subscription

No Stipulation.

4.12

Key Escrow and Recovery

4.12.1 Key Escrow and Recovery Policy and Practices
The escrow of CA and Subscriber private keys, for purposes of access by law enforcement or any
other reason, is not supported by the Starfield PKI.

4.12.2 Session Key Encapsulation and Recovery Policy andPractices
No Stipulation.

Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
39

Starfield CP-CPS v5.01

5 FACILITY, MANAGEMENT, AND OPERATIONALCONTROLS
Starfield SHALL develop, implement, and maintain a comprehensive security program designed to:
1. Protect the confidentiality, integrity, and availability of Certificate Data and Certificate
Management Processes;
2. Protect against anticipated threats or hazards to the confidentiality, integrity, and availabilityof the Certificate Data and Certificate Management Processes;
3. Protect against unauthorized or unlawful access, use, disclosure, alteration, or destruction of
any Certificate Data or Certificate Management Processes;
4. Protect against accidental loss or destruction of, or damage to, any Certificate Data or
Certificate Management Processes; and5. Comply with all other security requirements applicable to Starfield by law.
The Certificate Management Process MUST include:
1. physical security and environmental controls;
2. system integrity controls, including configuration management, integrity maintenance oftrusted code, and malware detection/prevention;
3. network security and firewall management, including port restrictions and IP address filtering;
4. user management, separate trusted-role assignments, education, awareness, and training; and5. logical access controls, activity logging, and inactivity time-outs to provide individual
accountability.
Starfield’s security program MUST include an annual Risk Assessment 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
Processes;
2. Assesses the likelihood and potential damage of these threats, taking into consideration thesensitivity of the Certificate Data and Certificate Management Processes; and3. Assesses the sufficiency of the policies, procedures, information systems, technology, andother arrangements that Starfield has in place to counter such threats.
Based on the Risk Assessment, Starfield SHALL develop, implement, and maintain a security planconsisting of security procedures, measures, and products designed to achieve the objectives set forth
above and to manage and control the risks identified during the Risk Assessment, commensurate withthe sensitivity of the Certificate Data and Certificate Management Processes. The security plan MUST
include administrative, organizational, technical, and physical safeguards appropriate to the sensitivityof the Certificate Data and Certificate Management Processes. The security plan MUST also take into
account then-available technology and the cost of implementing the specific measures, and SHALL
implement a reasonable level of security appropriate to the harm that might result from a breach of
security and the nature of the data to be protected.

Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
40

Starfield CP-CPS v5.01

5.1

Physical Security Controls

5.1.1 Site Location and Construction
Starfield PKI systems are hosted and managed using secure facilities in the Phoenix, Arizona andAshburn, Virginia metropolitan areas with multiple levels of physical access controls.

5.1.2 Physical Access
Production Starfield PKI systems are housed in a secure facility requiring two factor
authentication and dual control access to any physical device in the CA environment. Physicalaccess to the CA facility is automatically logged and video recorded on a 24x7 basis. Physicalaccess to the CA facility is monitored 24x7 by onsite security personnel.

5.1.3 Power and Air Conditioning
The supply of power to Starfield CA systems is protected through the use of UPS systems andgenerators. Climate control systems have been implemented to ensure that the temperature within
the CA facility is maintained within reasonable operating limits.

5.1.4 Water Exposures
The CA hosting facilities have been verified to reside outside of any designated 100-year flood
plain.

5.1.5 Fire Prevention and Protection
The Starfield CA hosting facility is equipped with a smoke detection system and a pre-action dry
pipe fire suppression system.

5.1.6 Media Storage
Media containing production software, production data, and system audit information is stored
secured with appropriate physical and logical access controls designed to limit access toauthorized personnel.

5.1.7 Waste Disposal
Sensitive documents and materials are shredded before disposal. Media used to collect or transmit
sensitive information are rendered unreadable before disposal. Other waste is disposed of inaccordance with Starfield’s normal waste disposal requirements.

5.1.8 Offsite Backup
Offsite backup media are stored in a physically secure manner using a bonded third-party storage
facility.

Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
41

Starfield CP-CPS v5.01

Cryptographic devices, smart cards, and other devices that may contain private keys or keying
material are physically destroyed or zeroized in accordance the manufacturers’ guidance prior todisposal.

5.2

Procedural Controls

5.2.1 Trusted Roles
All Starfield personnel involved in the operation of the Starfield PKI are considered to serve in“trusted roles.” Within the Starfield PKI, the following trusted roles exist:• Security, responsible for establishing and monitoring compliance with security policies,
procedures, and standards.
• Engineering/Architecture, responsible for the design and development of Starfield PKI
systems.
• PKI Operations, responsible for administering, maintaining and monitoring the systems
supporting the Starfield PKI.
• Key Management, responsible for management of cryptographic materials.
• RA Operations, responsible for processing certificate requests and revocation requests.

5.2.2 Number of Persons Required Per Task
Cryptographically sensitive operations within the Starfield PKI such as CA key generation, CA
key recovery, CA key activation and CA system configuration require the participation of multiple“trusted” individuals in accordance with Section 6.2.2 Private Key Multi-Person Control. Other
operations may require only one trusted individual.

5.2.3 Identification and Authentication for Each Role
Each person performing a trusted role within the Starfield PKI must be authorized by management
to perform such functions and must satisfy the personnel requirements specified in Section 5.3
Personnel Controls.

5.2.4 Roles requiring separation of duties
Approval of EV certificate requests must be performed by a person other than the one who
verified the information in the request.

5.3

Personnel Controls

5.3.1 Qualifications, Experience, and Clearance Requirements
The recruitment and selection practices for Starfield PKI personnel take into account thebackground, qualifications, experience, and clearance requirements of each position, which arecompared against the profiles of potential candidates.

Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
42

Starfield CP-CPS v5.01

5.3.2 Background Check Procedures
Background checks are performed prior to their commencement of employment with Starfield.
Such checks include criminal record and may include other items as applicable to the role.
Starfield employees are required to sign a nondisclosure agreement and are required to adhere toStarfield PKI policies and procedures.

5.3.3 Training Requirements
All Starfield PKI personnel receive on the job training covering some or all of the following topics
as relevant to their role:• Basic PKI concepts• This CP/CPS• Documented Starfield PKI security and operational policies and procedures• The use and operation of PKI system software• Common threats to the validation process including phishing and other social engineering
tactics
Starfield requires all validation specialists to pass an examination provided on this CP/CPS, theGuidelines for Issuance and Management of Extended Validation Certificates and the Baseline
Requirements (BR) prior to validating and approving the issuance of Certificates.
Starfield documents that each validation specialist possesses the skills required by a task before
allowing the validation specialist to perform that task.
Starfield maintains records of training and ensures that personnel entrusted with validation
specialist duties maintain a skill level that enables them to perform such duties satisfactorily.

5.3.4 Retraining Frequency and Requirements
Starfield PKI personnel receive formal or informal training on the use of deployed PKI products
and Starfield PKI policies and procedures at the time a PKI role is first granted and annually.
Security awareness campaigns are ongoing.

5.3.5 Job Rotation Frequency and Sequence
No Stipulation.

5.3.6 Sanctions for Unauthorized Actions
In accordance with corporate polices, appropriate disciplinary actions will be taken for
unauthorized actions or other violations of Starfield PKI policies and procedures.
If a person in a trusted role is cited by Starfield management for unauthorized or inappropriate
actions, the person will be immediately removed from the trusted role following identification of
any unauthorized actions. After management has reviewed and discussed the incident with theemployee involved, management may reassign that employee to a non‐trusted role, dismiss theindividual from employment, or take any other actions as it deems appropriate (and subject torestrictions under applicable laws).
Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
43

Starfield CP-CPS v5.01

5.3.7 Independent Contractor Requirements
Starfield PKI may employ contractors as necessary. Where contractors are used by the Starfield
PKI, they are subject to qualifications and background check procedures comparable to thosespecified in Section 5.3.1 Qualifications, Experience, and Clearance Requirements and Section
5.3.25.3.2 Background Check Procedures, respectively.

5.3.8 Documentation Supplied to Personnel
Starfield PKI personnel are required to read this CP/CPS. They are also provided with Starfield
PKI policies, procedures, and other documentation relevant to their job functions.

5.4

Audit Logging Procedures

5.4.1 Types of Events Recorded
The Starfield PKI logs the following events:• CA certificate and key lifecycle management events including:- 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; and- Introduction of new Certificate Profiles and retirement of existing Certificate Profiles.
• CA and Subscriber certificate life cycle management events- Requests for certificates, renewal, re-key, and revocation- Successful or unsuccessful processing of requests- Generation and issuance of certificates- Revocation of certificates- Issuance of CRLs and generation of OCSP entries- All verification activities required by applicable guidelines; and- Date, time, phone number used, persons spoken to, and end results of verification
telephone calls• Security-sensitive operating system events- Successful and unsuccessful PKI system access attempts;- PKI and security system actions performed;- Security profile changes;- Installation, update, and removal of software;- System crashes, hardware failures, and other anomalies;- Relevant router and firewall activities (as described in Section 5.4.1.1 Router andfirewall activities logs)- Entries to and exits from CA facility• CA facility entry/exit.
• Separation of validation duties between multiple RAs for Extended Validation certificates
All audit logs include, at a minimum:
Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
44

Starfield CP-CPS v5.01

-Date and time of event
Identity of the person making the journal record (when applicable)
Description of the event-

5.4.1.1

Router and firewall activities logs

Logging of router and firewall activities MUST at a minimum include:••••

Successful and unsuccessful login attempts to routers and firewalls
Logging of all administrative actions performed on routers and firewalls, including
configuration changes, firmware updates, and access control modifications
Logging of all changes made to firewall rules, including additions, modifications, anddeletions
Logging of all system events and errors, including hardware failures, software crashes,and system restarts

5.4.2 Frequency of Processing Log
Audit logs are reviewed on an as-needed basis.

5.4.3 Retention Period for Audit Log
Audit logs are retained as follows:
Log Type
Logs of CA key management activity

CA system logs of certificate management activity
Operating system logs
Physical access system logs
Manual logs of physical accessLogs of all certificates, revocations and documentation
relating to verification of certificate requests
Video recording of CA facility access

Retention Period
2 years after the later of the following:• the destruction of the CA Private Key; or• the revocation or expiration of the final CA
Certificate in that set of Certificates that have an
X.509v3 basicConstraints extension with the cA
field set to true and which share a common Public
Key corresponding to the CA Private Key;
2 years
2 years
2 years
2 years
2 years after the expiration of the subscriber certificate
90 days

5.4.4 Protection of Audit Log
Production and archived logical and physical audit logs are protected using a combination ofphysical and logical access controls.

5.4.5 Audit Log Backup Procedures
Audit logs are backed up on a periodic basis.

Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
45

Starfield CP-CPS v5.01

5.4.6 Audit Collection System (Internal vs. External)
Automated audit data is generated and recorded at the application, network, and operating systemlevel. Manually generated audit data is recorded by Starfield employees.

5.4.7 Notification to Event-Causing Subject
Where an event is logged by the audit collection system, no notice is required to be given to theindividual or system that caused the event.

5.4.8 Vulnerability Assessments
Starfield performs periodic vulnerability assessments of its PKI environment
including:•External vulnerability scans are conducted on at least a quarterly basis. Testing includes
applications publicly available.
•
Internal vulnerability scans of internal PKI networks are performed on at least a quarterly
basis.
•
Annually, a penetration test of the entire Starfield PKI is conducted which includes testsof customer facing applications, the certificate vetting application, and critical PKI infrastructure.
Critical and high vulnerabilities identified as part of the assessment are documented and tracked tocompletion. The results of such assessments are used to enhance the security of the environment.
Upon completion of each assessment, a Corrective Action Plan will be developed to mitigate any
pertinent security issues (i.e., findings) and associated risks identified by the assessment. Criticalvulnerabilities that are discovered should be mitigated within 96 hours of discovery. In the eventthat the issue cannot be mitigated with 96 hours, the issue must be documented with justificationof the delay and a timeline for completion.

5.5

Records Archival

The Starfield PKI maintains an archive of relevant records for each CA.

5.5.1 Types of Records Archived
Starfield maintains an archive of logs that include the recorded events specified in Section 5.4.1
Types of Events Recorded.

5.5.2 Retention Period for Archive
Starfield retention period for archives it is made in accordance with Section 5.4.3 Retention period
for audit log

5.5.3 Protection of Archive
See Section 5.4.4 Protection of Audit Log.

Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
46

Starfield CP-CPS v5.01

5.5.4 Archive Backup Procedures
Starfield maintains copies of its archived records at separate locations.

5.5.5 Requirements for Time-Stamping of Records
Starfield PKI system clocks are synchronized with a third-party time source. Automated journal
entries include a system generated date and time field. Manual journal entries include a manuallyentered date and time field.

5.5.6 Archive Collection System (Internal or External)
No Stipulation.

5.5.7 Procedures to Obtain and Verify Archive Information
No Stipulation.

5.6

Key Changeover

Starfield CAs will stop issuing certificates and will be re-keyed or terminated before the maximum
key usage period for certificate signing is reached in accordance with Section 6.3.2 Certificate
Operational Periods and Key Pair Usage Periods. The CA will continue to sign and publish CRLs
until the end of the CA certificate lifetime. The key changeover or CA termination process will be
performed such that it causes minimal disruption to Subscribers and Relying Parties. Affected
entities will be notified prior to the planned key changeover.

5.7

Compromise and Disaster Recovery

5.7.1 Incident and Compromise Handling Procedures
Starfield has documented business continuity and disaster recovery procedures designed to notify
and reasonably protect Application Software Suppliers, Subscribers, and Relying Parties in theevent of a disaster, security compromise, or business failure. Starfield performs tests, reviews, andupdates to these procedures at least annually. These procedures meet the requirements in [BR5.7.1].

5.7.2 Computing Resources, Software, and/or Data are Corrupted
Starfield performs regular system backups that can be utilized to recover in the case of resource,
software, or data corruption. Starfield also keeps copies of CA private keys in a secure off-site
location.

5.7.3 Entity Private Key Compromise Procedures
Starfield has implemented a combination of physical, logical and procedural controls to guard
against CA key compromise. In the event of a known or suspected CA key compromise, Starfieldmanagement will assess the situation and determine the appropriate course of action.
Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
47

Starfield CP-CPS v5.01

5.7.4 Business Continuity Capabilities After a Disaster
Starfield maintains a disaster recovery plan and performs periodic testing of the plan to ensure its
effectiveness in the event of a disaster.

5.8

CA or RA Termination

In the event that it is necessary to terminate the operation of a Starfield CA, Starfield management
will plan and coordinate the termination process with its Subscribers and Relying Parties such that the
impact of the termination is minimized. Starfield will provide as much prior notice as is practicableand reasonable to Subscribers and Relying Parties and preserve relevant records for a period of time
deemed fit for functional and legal purposes. Relevant certificates will be revoked no later than thetime of the termination.

Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
48

Starfield CP-CPS v5.01

6 TECHNICAL SECURITY CONTROLS
6.1

Key Pair Generation and Installation

6.1.1 Key Pair Generation
Starfield CA key pairs are generated in and protected by hardware security modules certified to
FIPS 140-2 Level 3 or FIPS 140-3 Level 3. CA key pair generation requires the participation ofmultiple trusted employees.
Subscriber key pair generation is performed by the Subscriber. It is recommended that the
Subscriber use a FIPS 140-2 Level 3 or FIPS 140-3 Level 3 certified cryptographic module for
key generation.

6.1.2 Private Key Delivery to Subscriber
Starfield CA key pairs do not require delivery as they are generated and managed by the Starfield
PKI. As Subscriber key pairs are generated by the Subscriber, there is no private key
transportation requirement.

6.1.3 Public Key Delivery to Certificate Issuer
CA certificate requests are generated and processed by Starfield employees using a controlled
process that requires the participation of multiple trusted individuals. CA certificate requests are
PKCS #10 requests and accordingly contain the requesting CA’s public key and are digitally
signed by the requesting CA’s private key.
For Subscriber certificate requests, the Subscriber’s public key is submitted to the CA using acertificate request signed with the Subscriber’s private key. This mechanism ensures that:• the public key has not been modified during transit and• the sender possesses the private key corresponding to the transferred public key.

6.1.4 CA Public Key Delivery to Relying Parties
The Starfield Root CA is made available to Relying Parties through its inclusion in common
browser software.
The Starfield Root CA certificates may also be downloaded from the Starfield repository. A 256bit SHA-256 hash of the Starfield Root CA certificates is posted in the Starfield repository so thatusers may verify the authenticity of the Starfield Root CA certificates.

6.1.5 Key Sizes
Starfield CA key pairs used to issue certificates after January 1, 2012 are 2048 bit or higher RSA
keys. Subscriber key pairs in certificates issued after January 1, 2012 are 2048 bit or higher RSA
keys.
Certificates meet the following requirements for algorithm type and key size.
Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
49

Starfield CP-CPS v5.01

6.1.5.1

Root CA Certificates

Digest algorithm

Minimum RSA modulus size (bits)
ECC curve
Minimum DSA modulus anddivisor size (bits)***Validity period beginning on or
before 31 Dec 2010
MD5 (NOT RECOMMENDED),
SHA-1, SHA-256, SHA-384 or
SHA-5122048**NIST P-256, P-384, or P-521
L= 2048 N= 224 or L= 2048 N=
256

Validity period beginning after 31
Dec 2010
SHA-1*, SHA-256, SHA-384 or
SHA-5122048
NIST P-256, P-384, or P-521
L= 2048 N= 224 or L= 2048 N=
256* SHA-1 MAY be used with RSA keys in accordance with the criteria defined in Section 7.1.3.
** A Root CA Certificate issued prior to 31 Dec. 2010 with an RSA key size less than 2048 bits MAY stillserve as a trust anchor for Subscriber Certificates issued in accordance with these Requirements.
*** L and N (the bit lengths of modulus p and divisor q, respectively) are described in the Digital
Signature Standard, FIPS 186-4.

6.1.5.2

Subordinate CA Certificates

Digest algorithm
Minimum RSA modulus size (bits)
ECC curve
Minimum DSA modulus anddivisor size (bits)***Validity period beginning on or
before 31 Dec 2010 and ending on
or before 31 Dec 2013
SHA-1, SHA-256, SHA-384 or
SHA-5121024
NIST P-256, P-384, or P-521
L= 2048, N= 224 or L= 2048, N=
256

Validity period beginning after 31
Dec 2010 or ending after 31 Dec
2013
SHA-1*, SHA-256, SHA-384 or
SHA-5122048
NIST P-256, P-384, or P-521
L= 2048 N= 224 or L= 2048 N=
256* SHA-1 MAY be used with RSA keys in accordance with the criteria defined in Section 7.1.3.
*** L and N (the bit lengths of modulus p and divisor q, respectively) are described in the Digital
Signature Standard, FIPS 186-4.

6.1.5.3

Subscriber Certificates

Digest algorithm
Minimum RSA modulus size (bits)
ECC curve
Minimum DSA modulus anddivisor size (bits)***Validity period ending on or
before 31 Dec 2013
SHA1*, SHA-256, SHA-384 or
SHA-5121024
NIST P-256, P-384, or P-521
L= 2048, N= 224 or L= 2048, N=
256

Validity period ending after 31
Dec 2013
SHA-1*, SHA-256, SHA-384 or
SHA-5122048
NIST P-256, P-384, or P-521
L= 2048 N= 224 or L= 2048 N=
256* SHA-1 MAY be used with RSA keys in accordance with the criteria defined in Section 7.1.3.
*** L and N (the bit lengths of modulus p and divisor q, respectively) are described in the Digital SignatureStandard, FIPS 186-4.
Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
50

Starfield CP-CPS v5.01

6.1.6 Public Key Parameters Generation and Quality Checking
Starfield generates CA Key Pairs using secure algorithms and parameters based on current
research and industry standards. Starfield uses a cryptomodule that conforms to FIPS 186‐4 andprovides random number generation and on‐board generation of up to 4096‐bit RSA Public Keys
and a wide range of ECC curves.
Starfield checks Subscriber RSA public keys to ensure value of this public exponent equates to an
odd number equal to three or more.

6.1.7 Key Usage Purposes
Key pairs may be used as follows:
EntityRoot CAs
Issuing CAs
Subscriber

Permitted Key Usage
Signing of certificates for Subordinate CAs and other purposes as required for theStarfield PKI and CRLs.
Signing of certificates for Subscribers and other purposes as required for the Starfield
PKI and CRLs.
Server authentication, digital signature, key encipherment, data encryption.

The key usage extension is set in accordance with the certificate profile requirements specified in
Section 7.1 Certificate Profile.

6.2
Private Key Protection and Cryptographic Module
Engineering Controls
6.2.1 Cryptographic Module Standards and Controls
The Starfield PKI uses cryptographic modules that are certified to FIPS 140-2 Level 3 or FIPS
140-3 Level 3 and meet industry standards for random number and prime number generation.

6.2.2 Private Key Multi-Person Control
The Root CA is operated in offline mode. The participation of multiple trusted employees isrequired to perform sensitive CA private key operations (including hardware security module(HSM) activation, Sub-CA certificate signing, CRL signing, CA key backup, and CA key
recovery).
The Issuing CA is operated in online mode. The participation of multiple trusted employees isrequired to perform sensitive CA private key operations (including HSM activation, CA key
backup, and CA key recovery).

6.2.3 Private Key Escrow
The escrow of CA and Subscriber private keys, for purposes of access by law enforcement or any
other reason, is not supported by the Starfield PKI.

Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
51

Starfield CP-CPS v5.01

6.2.4 Private Key Backup
Backup copies of CA private keys are stored in encrypted form using cryptographic modules thatmeet the requirements specified in Section 6.2.1 Cryptographic Module Standards and Controls.
Once a CA has reached the end of its maximum usage period as defined in Section 6.3.2
Certificate Operational Periods and Key Pair Usage Periods, HSMs containing the CA private key
will be zeroized and/or securely destroyed.
Subscriber private keys are not backed up by the Starfield PKI.

6.2.5 Private Key Archival
Once a CA has reached the end of its maximum usage period as defined in Section 6.3.2
Certificate Operational Periods and Key Pair Usage Periods, HSMs containing the CA private key
will be zeroized and/or securely destroyed.
Subscriber private keys are not archived by the Starfield PKI.

6.2.6 Private Key Transfer Into or From a Cryptographic Module
CA private keys are generated and used only within hardware cryptographic modules meeting therequirements of Section 6.2.1 Cryptographic Module Standards and Controls. The private key
exists outside hardware cryptographic modules only in encrypted form.

6.2.7 Private key storage on cryptographic module
CA private keys are stored within hardware cryptographic modules meeting the requirements ofSection 6.2.1 Cryptographic Module Standards and Controls.

6.2.8 Method of Activating Private Keys
Hardware modules used for CA private key protection utilize an activation mechanism as
described in Section 6.2.2 Private Key Multi-Person Control.

6.2.9 Method of Deactivating Private Key
CA private keys are de-activated by securing the partition on the HSM device.

6.2.10 Method of Destroying Private Key
CA private key destruction requires the participation of multiple trusted Starfield employees andapproval from Starfield management. When CA key destruction is required, CA private keys will
be completely destroyed through zeroization and/or physical destruction of the device inaccordance with manufacturers’ guidance.

6.2.11 Cryptographic Module Rating
Refer to Section 6.2.1 Cryptographic Module Standards and Controls.
Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
52

Starfield CP-CPS v5.01

6.3

Other Aspects of Key Pair Management

6.3.1 Public Key Archival
Copies of CA and Subscriber certificates are archived in accordance with Section 5.5 Records
Archival.

6.3.2 Certificate Operational Periods and Key Pair Usage Periods
For Starfield PKI CAs and Subscribers, key and certificate usage periods meet the following
requirements.
EntityRoot CAs
Issuing CAs
Subscribers

Maximum Key Usage
Period (for certificate
signing)*
15 years
20 years
N/A

Subscriber Certificates
Basic and Medium Assurance Domain Validated SSL
Server Certificate
High Assurance Organizational Validated SSL Server
Certificate Subscribers
Extended Validation SSL Server Certificate
Subscribers

Maximum Key Usage
Period (for CRL
signing)
20 years
25 years
N/A

Maximum Certificate
Validity Period
30 years
20 years
398 days

Maximum Certificate Validity Period
398 days
398 days
398 days* Maximum Key Usage Period does not apply to certificates that serve an infrastructure purpose,such as OCSP Responder certificates or Timestamp Authority certificates. Timestamp authority
certificates have a maximum validity period of 135 months.

6.4

Activation Data

6.4.1 Activation Data Generation and Installation
HSMs used for CA private key protection are configured to require multiple key shareholders as
described in Section 6.2.2 Private Key Multi-Person Control.

6.4.2 Activation Data Protection
The activation materials are used only when needed and stored in a secure site when not in use.

6.4.3 Other Aspects of Activation Data
No Stipulation.

Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
53

Starfield CP-CPS v5.01

6.5

Computer Security Controls

6.5.1 Specific Computer Security Technical Requirements
Starfield’s systems maintaining CA software and data files are secure from unauthorized access.
In addition, access to production servers is limited to those individuals with a valid businessreason for such access.
Starfield’s production network is separate from other components. This separation prevents
network access except through specific application processes. Starfield has sophisticated access
control technologies in place to protect the production network from unauthorized internal andexternal access and to limit network activities accessing production systems. Access controls in
use include, but are not limited to, multifactor authentication.

6.5.2 Computer Security Rating
No Stipulation.

6.6

Life Cycle Technical Controls

6.6.1 System Development Controls
All CA software is developed in accordance with documented Software Development Life Cycle
processes. Reviews of all changes are made during multiple points of the software development.
Approval to deploy changes requires multiple individuals. All code is verified, using digital
signatures and hashing, before being deployed into the production CA environment.

6.6.2 Security Management Controls
Starfield has tools and processes in place to control and monitor the configurations of the CA
systems. Starfield validates the integrity of all software before release into production.

6.6.3 Life Cycle Security Controls
No Stipulation.

6.7

Network Security Controls

The Starfield network is secured through the use of preventative (properly configured routers andfirewalls) and detective controls (monitoring systems). Starfield performs all CA and RA functions
using networks secured in accordance with the Starfield Operations Guide to ensure the systems are
secure.

6.8

Time-Stamping

Starfield maintains Network Time Protocol (NTP) enabled devices which use the GPS system tosynchronize its clock. The servers, via NTP, then synchronize their system clock to these devices
which are used to generate time stamps.
Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
54

Starfield CP-CPS v5.01

7 CERTIFICATE, CRL, AND OCSP PROFILES
7.1

Certificate Profile

7.1.1 Version Number
Starfield issues X.509 Version 3 certificates.

7.1.2 Certificate Extensions
Extensions used in Starfield certificates are documented in Appendix A.

7.1.3 Algorithm Object Identifiers
Starfield signs certificates with the following algorithms:• Sha1RSA* 1.2.840.113549.1.1.5• sha256RSA 1.2.840.113549.1.1.11• ECDSAsha384 1.2.840.10045.4.3.3* CAs do not issue OCSP, or Subscriber SSL Certificates utilizing the SHA‐1 algorithm.

7.1.4 Name Forms
7.1.4.1

Name Encoding

Every Starfield certificate is uniquely identified by its Subject and incorporate a unique
identifying serial number. Starfield certificates support name chaining as specified in RFC
5280, section 4.1.2.4.

7.1.4.2

Subject Information - Subscriber Certificates

By issuing the Certificate, the Starfield represents that it followed the procedure set forth in its
Certificate Policy and/or Certification Practice Statement to verify that, as of the Certificate’s
issuance date, all of the Subject Information was accurate. Starfield SHALL NOT include a
Domain Name or IP Address in a Subject attribute except as specified in Section 3.2.2.4
Validation of Domain Authorization or Control ..
Subject attributes MUST NOT contain only metadata such as ‘.’, ‘-’, and ’ ’ (i.e. space)characters, and/or any other indication that the value is absent, incomplete, or not applicable.
Subject Alternative Name Extension
Certificate Field: extensions:subjectAltName
Required/Optional: RequiredContents: This extension MUST contain at least one entry. Each entry MUST be one of thefollowing types:
Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
55

Starfield CP-CPS v5.01

•dNSName: The entry MUST contain either a Fully‐Qualified Domain Name or
Wildcard Domain Name that the CA has validated in accordance with Section 3.2.2.4
Validation of Domain Authorization or Control. Wildcard Domain Names MUST be
validated for consistency with Section 3.2.2.6 Wildcard Domain Validation. The
entry MUST NOT contain an Internal Name.
The Fully‐Qualified Domain Name or the FQDN portion of the Wildcard Domain
Name contained in the entry MUST be composed entirely of LDH Labels joined
together by a U+002E FULL STOP (“.”) character. The zero‐length Domain Label
representing the root zone of the Internet Domain Name System MUST NOT be
included (e.g. “example.com” MUST be encoded as “example.com” and MUST NOT
be encoded as “example.com.”).
Effective 2021‐10‐01, the Fully‐Qualified Domain Name or the FQDN portion of the
Wildcard Domain Name MUST consist solely of Domain Labels that are P‐Labels or
Non‐Reserved LDH Labels.
•IPAddress: The entry MUST contain an IPv4 or IPv6 address that the CA has
validated in accordance with Section 3.2.2.5 Authentication for an IP Address. The
entry MUST NOT contain a Reserved IP Address.

Subject Distinguished Name Fields
a. Certificate Field: subject:commonName (OID 2.5.4.3)
Required/Optional: Deprecated (Discouraged, but not prohibited)
Contents: If present, this field MUST contain exactly one entry that is one of the values
contained in the Certificate’s subjectAltName extension (see Section 7.1.4.2.1 Subject
Alternative Name Extension). The value of the field MUST be encoded as follows:•If the value is an IPv4 address, then the value MUST be encoded as an IPv4Address
as specified in RFC 3986, Section 3.2.2.
•If the value is an IPv6 address, then the value MUST be encoded in the text
representation specified in RFC 5952, Section 4.
•If the value is a Fully‐Qualified Domain Name or Wildcard Domain Name, then thevalue MUST be encoded as a character‐for‐character copy of the dNSName entry
value from the subjectAltName extension. Specifically, all Domain Labels of the
Fully‐Qualified Domain Name or FQDN portion of the Wildcard Domain Name must
be encoded as LDH Labels, and P‐Labels MUST NOT be converted to their Unicode
representation.
b. Certificate Field: subject:organizationName (OID 2.5.4.10)
Required/Optional: Optional.
Contents: If present, the subject:organizationName field MUST contain either the
Subject’s name or DBA as verified under Section 3.2.2.2 DBA/Tradename. Starfield may
include information in this field that differs slightly from the verified name, such ascommon variations or abbreviations, provided that Starfield documents the difference andany abbreviations used are locally accepted abbreviations; e.g., if the official record
shows “Company Name Incorporated”, Starfield MAY use “Company Name Inc.” or“Company Name”. Because Subject name attributes for individuals (e.g. givenName
Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
56

Starfield CP-CPS v5.01

(2.5.4.42) and surname (2.5.4.4)) are not broadly supported by application software,
Starfield MAY use the subject:organizationName field to convey a natural person
Subject’s name or DBA.
c. Certificate Field: subject:givenName (2.5.4.42) and subject:surname (2.5.4.4)
Required/Optional: Optional.
Contents: If present, the subject:givenName field and subject:surname field MUST
contain a natural person Subject’s name as verified under Section 3.2.3 Authentication ofIndividual Identity. A Certificate containing a subject:givenName field or
subject:surname field MUST contain the (2.23.140.1.2.3) Certificate Policy OID.
d. Certificate Field: Number and street: subject:streetAddress (OID: 2.5.4.9)
Required/Optional:
Optional if the subject:organizationName field, subject:givenName field, or
subject:surname field are present.
Prohibited if the subject:organizationName field, subject:givenName, andsubject:surname field are absent.
Contents: If present, the subject:streetAddress field MUST contain the Subject’s street
address information as verified under Section 3.2.2.1 Identity.
e. Certificate Field: subject:localityName (OID: 2.5.4.7)
Required/Optional:
Required if the subject:organizationName field, subject:givenName field, or
subject:surname field are present and the subject:stateOrProvinceName field is absent.
Optional if the subject:stateOrProvinceName field and the subject:organizationName
field, subject:givenName field, or subject:surname field are present.
Prohibited if the subject:organizationName field, subject:givenName, andsubject:surname field are absent.
Contents: If present, the subject:localityName field MUST contain the Subject’s locality
information as verified under Section 3.2.2.1 Identity. If the subject:countryName field
specifies the ISO 3166-1 user-assigned code of XX in accordance with Section 7.1.4.2.2(g) Subject Distinguished Name Fields: postalCode, the localityName field MAY containthe Subject’s locality and/or state or province information as verified under Section
3.2.2.1 Identity.
f. Certificate Field: subject:stateOrProvinceName (OID: 2.5.4.8)
Required/Optional:
Required if the subject:organizationName field, subject:givenName field, or
subject:surname field are present and subject:localityName field is absent.
Optional if the subject:localityName field and the subject:organizationName field, thesubject:givenName field, or the subject:surname field are present.
Prohibited if the subject:organizationName field, the subject:givenName field, or
subject:surname field are absent.
Contents: If present, the subject:stateOrProvinceName field MUST contain the Subject’s
state or province information as verified under Section 3.2.2.1 Identity. If thesubject:countryName field specifies the ISO 3166-1 user-assigned code of XX in
accordance with Section 7.1.4.2.2 (g) Subject Distinguished Name Fields: postalCode,Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
57

Starfield CP-CPS v5.01

the subject:stateOrProvinceName field MAY contain the full name of the Subject’s
country information as verified under Section 3.2.2.1 Identity.
g. Certificate Field: subject:postalCode (OID: 2.5.4.17)
Required/Optional:
Optional if the subject:organizationName, subject:givenName field, or subject:surname
fields are present.
Prohibited if the subject:organizationName field, subject:givenName field, or
subject:surname field are absent.
Contents: If present, the subject:postalCode field MUST contain the Subject’s zip or
postal information as verified under Section 3.2.2.1 Identity.
h. Certificate Field: subject:countryName (OID: 2.5.4.6)
Required/Optional:
Required if the subject:organizationName field, subject:givenName, or subject:surname
field are present.
Optional if the subject:organizationName field, subject:givenName field, andsubject:surname field are absent.
Contents: If the subject:organizationName field is present, the subject:countryName
MUST contain the two-letter ISO 3166-1 country code associated with the location of the
Subject verified under Section 3.2.2.1 Identity. If the subject:organizationName field isabsent, the subject:countryName field MAY contain the two-letter ISO 3166-1 countrycode associated with the Subject as verified in accordance with Section 3.2.2.3
Verification of Country. If a Country is not represented by an official ISO 3166-1 countrycode, Starfield MAY specify the ISO 3166-1 user-assigned code of XX indicating that an
official ISO 3166-1 alpha-2 code has not been assigned.
i. Certificate Field: subject:organizationalUnitName (OID: 2.5.4.11)
Required/Optional: Deprecated.
Prohibited if the subject:organizationName is absent or the certificate is issued on orafter September 1, 2022.
Contents: Starfield SHALL implement a process that prevents an OU attribute from
including a name, DBA, tradename, trademark, address, location, or other text that refers
to a specific natural person or Legal Entity unless Starfield has verified this informationin accordance with Section 3.2 Initial Identity Validation and the Certificate also contains
subject:organizationName, subject:givenName, subject:surname, subject:localityName,and subject:countryName attributes, also verified in accordance with Section 3.2.2.1
Identity.
Note: As of July 16, 2021, Starfield no longer includes the OU field on Subscriber Certificates.

j. Other Subject Attributes
Other attributes MAY be present within the subject field. If present, other attributes
MUST contain information that has been verified by Starfield.

Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
58

Starfield CP-CPS v5.01

7.1.4.3
Subject Information - Root Certificates and Subordinate CA
Certificates
By issuing a Subordinate CA Certificate, Starfield represents that it followed the procedure set
forth in its Certificate Policy and/or Certification Practice Statement to verify that, as of theCertificate’s issuance date, all of the Subject Information was accurate.
Subject Distinguished Name Fields
a. Certificate Field: subject:commonName (OID 2.5.4.3)
Required/Optional: RequiredContents: This field MUST be present and the contents SHOULD be an
identifier for the certificate such that the certificate’s Name is unique across all
certificates issued by the issuing certificate.
b. Certificate Field: subject:organizationName (OID 2.5.4.10)
Required/Optional: RequiredContents: This field MUST be present and the contents MUST contain either
the Subject CA’s name or DBA as verified under Section 3.2.2.2
DBA/Tradename. Starfield may include information in this field that differs
slightly from the verified name, such as common variations or abbreviations,provided that Starfield documents the difference and any abbreviations used are
locally accepted abbreviations; e.g., if the official record shows “Company
Name Incorporated”, Starfield MAY use “Company Name Inc.” or “Company
Name”.
c. Certificate Field: subject:countryName (OID: 2.5.4.6)
Required/Optional: RequiredContents: This field MUST contain the two‐letter ISO 3166‐1 country code forthe country in which the CA’s place of business is located.

7.1.5 Name Constraints
Starfield does not perform name constraints.

7.1.6 Certificate Policy Object Identifier
Starfield uses the following certificate policy oids in end-entity certificates:• Medium Assurance certificates - 2.16.840.1.114413.1.7.23.1 and 2.16.840.1.114414.1.7.23.1• High Assurance Server certificates - 2.16.840.1.114413.1.7.23.2 and2.16.840.1.114414.1.7.23.2• Extended Validation certificates - 2.16.840.1.114413.1.7.23.3 and 2.16.840.1.114414.1.7.23.3

7.1.7 Usage of Policy Constraints Extension
No Stipulation.

Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
59

Starfield CP-CPS v5.01

7.1.8 Policy Qualifier Syntax and Semantics
Starfield certificates include a link to our repository where this CPS and other applicableagreements may be viewed.

7.1.9 Processing Semantics for the Critical Certificate Policies
Extension
No Stipulation.

7.2

CRL Profile

7.2.1 Version Number
Starfield issues version 1 and 2 CRLs.

7.2.2 CRL and CRL Entry Extensions
1. reasonCode (OID 2.5.29.21)
If present, this extension MUST NOT be marked critical.
If a CRL entry is for a Root CA or Subordinate CA Certificate, including Cross
Certificates, this CRL entry extension MUST be present. If a CRL entry is for a
Certificate not technically capable of causing issuance, this CRL entry extension
SHOULD be present, but MAY be omitted, subject to the following requirements.
The CRLReason indicated MUST NOT be unspecified (0). If the reason for revocation isunspecified, CAs MUST omit reasonCode entry extension, if allowed by the previous
requirements. If a CRL entry is for a Certificate not subject to these Requirements andwas either issued on-or-after 2020-09-30 or has a notBefore on-or-after 2020-09-30, the
CRLReason MUST NOT be certificateHold (6). If a CRL entry is for a Certificate
subject to these Requirements, the CRLReason MUST NOT be certificateHold (6).
If a reasonCode CRL entry extension is present, the CRLReason MUST indicate the mostappropriate reason for revocation of the certificate.
2. issuingDistributionPoint (OID 2.5.29.28)
Effective 2023-01-15, if a CRL does not contain entries for all revoked unexpired
certificates issued by the CRL issuer, then it MUST contain a critical Issuing Distribution Point
extension and MUST populate the distributionPoint field of that extension.

Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
60

Starfield CP-CPS v5.01

7.2.2.1

Root CAsThe following CRL profile is used for root certificates in the Starfield PKI.
Field
Signature
IssuerThis Update (Effective Date)
Next Update
CRL extensions (V1 and V2)
CRL Number
Authority Key Identifier
Revoked Certificates

CRL Entry Extensions V1 and V2 andoptional for any given CRL entry)
CRL Reason CodeInvalidity Date

Description
SHA-1 or SHA-256
Subject of the corresponding root certificate
Date and time of CRL issuance.
365 or less days after This Update.
Unique value for each CRL issued by the corresponding root
certificate.
SHA-1 hash of the public key of the corresponding root certificate
List of information regarding revoked certificates. CRL entries
include:• Serial Number, identifying the revoked certificate
Revocation Date, including the date and time of certificate
revocation

One of the following bold reason codes:
unspecified(0)
keyCompromise(1)
cACompromise(2)affiliationChanged(3)
superseded(4)
cessationOfOperation (5)removeFromCRL(8)privilegeWithdrawn (9)aACompromise(10)
A GeneralizedTime denoting the effective time when the given
serial number is to be considered invalid.

Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
61

Starfield CP-CPS v5.01

7.2.2.2

Issuing CAs

The following CRL profile is used for Starfield Issuing CAs.
Field
Signature
IssuerThis Update (Effective Date)
Next Update
CRL extensions (V1 and V2)
CRL Number
Authority Key Identifier
Revoked Certificates

CRL Entry Extensions V1 and V2 andoptional for any given CRL entry)
CRL Reason CodeInvalidity Date

7.3

Description
SHA-1 or SHA-256
Subject of the corresponding Issuing CA certificate
Date and time of CRL issuance.
10 or less days after This Update.
Unique value for each CRL issued by the corresponding Issuing CA
certificate.
SHA-1 hash of the public key of the corresponding Issuing CA
certificate
List of information regarding revoked certificates. CRL entries
include:• Serial Number, identifying the revoked certificate• Revocation Date, including the date and time of certificate
revocation

One of the following bold reason codes:
unspecified(0)
keyCompromise(1)
cACompromise(2)affiliationChanged(3)
superseded(4)
cessationOfOperation (5)removeFromCRL(8)privilegeWithdrawn(9)aACompromise(10)
A GeneralizedTime denoting the effective time when the given
serial number is to be considered invalid.

OCSP Profile

If an OCSP response is for a Root CA or Subordinate CA Certificate, including Cross Certificates,
and that certificate has been revoked, then the revocationReason field within the RevokedInfo of
the CertStatus MUST be present. The CRLReason indicated MUST contain a value permitted for
CRLs, as specified in Section 7.2.2 CRL and CRL Entry Extensions.

7.3.1 Version Number
Starfield OCSP responses conform to version 1 of RFC 6960.

7.3.2 OCSP Extensions
The singleExtensions of an OCSP response MUST NOT contain the reasonCode (OID

2.5.29.21) CRL entry extension.

Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
62

Starfield CP-CPS v5.01

8 COMPLIANCE AUDIT AND OTHER ASSESSMENTS
8.1

Frequency or Circumstances of Assessment

The Starfield PKI is subject to an annual WebTrust for Certification Authorities (WebTrust for CAs)
examination. The Starfield PKI is also subject to an annual WebTrust for Extended Validation(WebTrust for EV) examination, as it relates to the issuance of Extended Validation certificates fromthe Starfield issuing CAs.

8.2

Identity/Qualifications of Assessor

Auditors demonstrating proficiency in public key infrastructure technology, information security
tools and techniques, security auditing, and the third-party attestation function shall perform theannual WebTrust for CAs and WebTrust for EV examinations. The audit firm must be currently
licensed to perform WebTrust for CA audits and WebTrust EV Program audits, be a member of theAmerican Institute of Certified Public Accountants (AICPA), and maintain professional
liability/errors & omissions insurance with policy limits of at least one million United States Dollars($1,000,000.00) in coverage.

8.3

Assessor's Relationship to Assessed Entity

The entity that performs the annual audit shall be organizationally independent of Starfield.

8.4

Topics Covered by Assessment

The scope of the annual audit shall include the requirements of this CP/CPS, CA environmental
controls, CA key management, and certificate life cycle management.

8.5

Actions Taken as a Result of Deficiency

Significant deficiencies identified during the compliance audit will result in a determination ofactions to be taken. The Starfield Governance and Policy Committee makes this determination with
input from the auditor. Starfield Management is responsible for ensuring that corrective action plans
are promptly developed and corrective action is taken within a period of time commensurate with thesignificance of such matters identified.
Should a severe deficiency be identified that might compromise the integrity of the Starfield PKI,
Starfield Management will consider, with input from the auditor, whether suspension of Starfield PKI
operations is warranted. Should a severe deficiency be identified that might compromise the integrityof a particular CA, Starfield PKI Management will assess whether suspension of the particular CA’s
operations is warranted.

8.6

Communication of Results

Compliance audit results are communicated to Starfield Management and others deemed appropriate
by Starfield Management. Starfield makes letters showing compliance with annual external audit
reports publicly available in the Starfield repository (certs.secureserver.net/repository). Starfield
ensures that audit results are communicated in a manner that is compliant with [BR 8.6].
Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
63

Starfield CP-CPS v5.01

8.7

Self –Audits

On at least a quarterly basis, Starfield performs regular internal audits against a randomly selected
sample of at least three percent of its SSL/TLS Server Certificates issued since the last internal audit.
Self‐audits on server Certificates are performed in accordance with Guidelines adopted by the CA /Browser Forum.

8.8

Specification Administration

8.8.1 Specification Change Procedures
Modifications to this CP/CPS are approved by the Starfield Governance and Policy Committee
and become effective upon publication in the Starfield repository.

8.8.2 Publication and Notification Policies
This CP/CPS and subsequent revisions are published in the Starfield repository in accordance with
Section 2 Publication and Repository Responsibilities Starfield may change this document at any
time without prior notice.

8.9

CPS Approval Procedures

See Section 8.8.1 Specification Change Procedures.

Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
64

Starfield CP-CPS v5.01

9 OTHER BUSINESS AND LEGAL MATTERS
9.1

Fees

9.1.1 Certificate Issuance or Renewal Fees
Starfield and Customers may charge end-user Subscribers for the issuance, management, andrenewal of Certificates.

9.1.2

Certificate Access Fees

Starfield reserves the right to charge a fee for making a Certificate available in a repository orotherwise.

9.1.3

Revocation or Status Information Access Fees

Starfield does not charge a fee as a condition of making the CRLs required in a repository orotherwise available to Relying Parties. Starfield reserves the right to charge a fee for providing
customized CRLs, OCSP services, or other value-added revocation and status information
services. Starfield does not permit access to revocation information, Certificate status information,or time stamping in its repository by third parties that provide products or services that utilize such
Certificate status information without Starfield’s prior express written consent.

9.1.4

Fees for Other Services

Starfield licenses this CPS under the Creative Commons Attribution-NoDerivatives 4.0
International (CC BY-ND 4.0) license.

9.1.5

Refund Policy

Subscribers may request a refund directly through the entity the certificate was purchased from,and will be subject to the entity’s refund policies.

9.2

Financial Responsibility

Subscribers and Relying Parties shall be responsible for the financial consequences to such
Subscribers, Relying Parties, and to any other persons, entities, or organizations for any transactions
in which such Subscribers or Relying Parties participate and which use Starfield Certificates or any
services provided in respect to Starfield Certificates. Starfield makes no representations and gives nowarranties or conditions regarding the financial efficacy of any transaction completed utilizing a
Starfield Certificate or any services provided in respect to Starfield Certificates and neither Starfield
nor any independent third-party RA operating under a Starfield CA, nor any Resellers, Co-marketers,
nor any subcontractors, distributors, agents, suppliers, employees, or directors of any of the foregoingshall have any liability except as explicitly set forth herein in respect to the use of or reliance on a
Starfield Certificate or any services provided in respect to Starfield Certificates.

Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
65

Starfield CP-CPS v5.01

9.2.1

Insurance Coverage

No Stipulation.

9.2.2

Other Assets

No Stipulation.

9.2.3

Insurance or Warranty Coverage for End-entities

No Stipulation.

9.3
9.3.1

Confidentiality of Business Information
Scope of Confidential Information

Sensitive Starfield PKI information must remain confidential to Starfield. The following
information is considered confidential to Starfield and may not be disclosed:• Starfield PKI policies, procedures and technical documentation supporting this CP/CPS• Subscriber registration records, including:- Certificate applications, whether approved or rejected- Proof of identification documentation and details- Certificate information collected as part of the registration records, beyond that whichis required to be included in Subscriber certificates• Audit trail records• Any private key within the Starfield PKI hierarchy• Compliance audit results except for WebTrust for CAs audit reports which may be
published at the discretion of Starfield Management

9.3.2

Information not Within the Scope of Confidential
Information

This CP/CPS and Certificates and CRLs issued by Starfield are not considered confidential.
Subscriber certificate status information is made available to Relying Parties through the use of
CRLs and OCSP.

9.3.3

Responsibility to Protect Confidential Information

No Stipulation.

9.4
9.4.1

Privacy of Personal Information
Privacy Plan

Starfield processes personal data in accordance with the privacy policy posted here:
https://www.godaddy.com/agreements/showdoc?pageid=PRIVACY&isc=gdbbc687

Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
66

Starfield CP-CPS v5.01

9.4.2

Information Treated as Private

See Section 9.4.1 Privacy Plan.

9.4.3

Information Not Deemed Private

See Section 9.4.1 Privacy Plan.

9.4.4

Responsibility to Protect Private Information

See Section 9.4.1 Privacy Plan.

9.4.5

Notice and Consent to Use Private Information

See Section 9.4.1 Privacy Plan.

9.4.6

Disclosure Pursuant to Judicial or Administrative Process

As a general principle, no document or record (including registration records) belonging to orcontrolled by the Starfield PKI is released to law enforcement agencies or officials except where
the law enforcement official is properly identified and where the release of specific information is:• required by applicable laws or regulations• pursuant to a subpoena or order of a court or other government or regulatory authority withwhich Starfield is legally obligated to comply• pursuant to a demand made by any government regulatory agency or authority withjurisdiction over Starfield.
As a general principle, no document or record belonging to or controlled by the Starfield PKI isreleased to any person except where:• a properly constituted instrument requiring production of the information is produced and• the person requiring production is a person authorized to do so by a court of law and isproperly identified.

9.4.7

Other Information Disclosure Circumstances

No Stipulation.

9.5

Intellectual Property Rights

Intellectual Property Rights among Starfield PKI Participants other than Subscribers and Relying
Parties are governed by the applicable agreements among such Starfield PKI Participants. The
following subsections apply to Intellectual Property Rights in relation to Subscribers and Relying
Parties.

9.5.1 Property Rights in Certificates and Revocation Information
The Intellectual Property Rights pertaining to the Certificates of CAs and revocation informationthat are issued by CAs shall be retained by those CAs. Provided the Certificates are reproduced infull and that use of such Certificates is subject to the Relying Party agreement, Starfield and
Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
67

Starfield CP-CPS v5.01

Subscribers grant permission to reproduce and distribute the Certificates on a nonexclusive
royalty-free basis. Starfield and Subscribers shall grant permission to use revocation information
to perform Relying Party functions subject to the applicable Relying party agreement or any otherapplicable agreements.

9.5.2 Property Rights in the Agreement
Starfield PKI Participants acknowledge that Starfield retains all Intellectual Property Rights in andto this CPS.

9.5.3 Property Rights to Names
Certificate applicants retain all rights, if they have any, in any trademark, service mark, or tradename contained in any Certificate Application and distinguished name within any Certificate
issued to them. Starfield retains all rights it has in any trademark, service mark, trade name, orother identifying trade symbols that it owns.

9.5.4 Property Rights in Keys and Key Material
All Key Pairs corresponding to Certificates of CAs and end-user Subscribers are the property of
those CAs and end-users, regardless of where they are stored physically, and those persons retain
all Intellectual Property Rights in and to those key pairs. Without limiting the generality of theforegoing, Starfield’s Root CA Public keys and the root Certificates containing them are theproperty of Starfield. Starfield grants licenses to software and hardware manufacturers to
reproduce such root Certificates to place copies in trustworthy hardware devices or software.
Finally, without limiting the generality of the foregoing, Secret Shares of a CA’s private key are
the property of the CA, and the CA retains all Intellectual Property Right in and to such Secret
Shares.
The following are the property of Starfield:• This CPS• Starfield-specified Certificate Policies• Policies and procedures supporting the operation of the Starfield PKI• Starfield-specified Object Identifiers (OIDs)• Certificates and CRLs issued by Starfield CAs• Distinguished Names (DNs) used to represent entities within the Starfield PKI• CA and infrastructure key pairs

9.6
9.6.1

Representations and Warranties
CA Representations and Warranties

The warranties, disclaimers of warranty, and limitations of liability among Starfield, its Resellers,
and their respective Customers within the Starfield PKI are set forth and governed by theagreements among them. This document relates only to the warranties that certain CAs (StarfieldCAs) must make to end-Subscribers receiving Certificates from them and to Relying Parties, thedisclaimers of warranties they shall make to those Subscribers and Relying Parties, and thelimitations of liability they can place on those Subscribers and Relying Parties.
Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
68

Starfield CP-CPS v5.01

Starfield uses, and (where required) Resellers shall use, Subscriber agreements and Relying party
agreements in accordance with Section 1.3 PKI Participants. These Subscriber agreements shallmeet the requirements imposed by Starfield (in the case of Resellers). Requirements that
Subscriber agreements contain warranties, disclaimers, and limitations of liability below apply tothose Resellers that use Subscriber agreements. Starfield agrees to such requirements in its
Subscriber agreements. Starfield’s practices concerning warranties, disclaimers, and limitations in
Relying Parties agreements apply to Starfield. Note that terms applicable to Relying Parties shallalso be included in Subscriber agreements, in addition to Relying party agreements, because
subscribers often act as Relying Parties as well.
Applicants, Subscribers, and Relying Parties acknowledge and agree that operations in relation toStarfield Certificates and Starfield Certificate Applications are dependent on the transmission of
information over communication infrastructures such as, without limitation, the Internet,
telephone and telecommunications lines and networks, servers, firewalls, proxies, routers,
switches, and bridges ("Telecommunication Equipment") and that this Telecommunication
Equipment is not under the control of Starfield or any independent third-party RA operating undera Starfield CA, or any Resellers, Co-marketers, or any subcontractors, distributors, agents,
suppliers, employees, or directors of any of the foregoing. Neither Starfield nor any independent
third-party RA operating under a Starfield RA, or any Resellers, Co-marketers, or any
subcontractors, distributors, agents, suppliers, employees, or directorsof any of the foregoing shall be liable for any error, failure, delay, interruption, defect, or
corruption in relation to a Starfield Certificate, a Starfield CRL, a Starfield OCSP Response, or a
Starfield Certificate Application to the extent that such error, failure, delay, interruption, defect, or
corruption is caused by such Telecommunication Equipment.

9.6.1.1
Starfield Certification Authority Warranties to Subscribers andRelying Parties•••

Right to Use Domain Name or IP Address: That, at the time of issuance, Starfield (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 theprocedure when issuing the Certificate; and (iii) accurately described the procedure in the
CA’s Certificate Policy and/or Certification Practice Statement;
Authorization for Certificate: That, at the time of issuance, Starfield (i) implemented 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 Starfield’s Certificate Policy and/or Certification
Practice Statement;
Accuracy of Information: That, at the time of issuance, Starfield (i) implemented aprocedure for verifying the accuracy of all of the information contained in the Certificate(with the exception of the subject:organizationalUnitName attribute); (ii) followed theprocedure when issuing the Certificate; and (iii) accurately described the procedure inStarfield’s Certificate Policy and/or Certification Practice Statement;
Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
69

Starfield CP-CPS v5.01

•

•
•

•
•

9.6.2

No Misleading Information: That, at the time of issuance, Starfield (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 Starfield’sCertificate Policy and/or Certification Practice Statement;
Identity of Applicant: That, if the Certificate contains Subject Identity Information,
Starfield (i) implemented a procedure to verify the identity of the Applicant in accordancewith Section 3; (ii) followed the procedure when issuing the Certificate;
Subscriber Agreement: That, if Starfield and the Subscriber are not Affiliated, theSubscriber and Starfield are parties to a legally valid and enforceable Subscriber Agreementthat satisfies these requirements, or, if Starfield and the Subscriber are Affiliated, theApplicant Representative acknowledged and accepted the Terms of Use;
Status: That Starfield maintains a 24 x 7 publicly-accessible Repository with current
information regarding the status (valid or revoked) of all unexpired Certificates; andRevocation: That Starfield will revoke the Certificate for any of the reasons specified inthis document.

RA Representations and Warranties

No Stipulation.

9.6.3

Subscriber Representations and Warranties

Subscribers are obligated by Starfield’s Subscriber Agreements to warrant that, among otherthings:
•
•
•
•
•
•

•
•

All digital signatures created using the private key corresponding to the public key listed in
the Certificate belong to that Subscriber and the Certificate has been accepted and isfunctional – it has not expired or been revoked - at the time the digital signature is created,
No unauthorized users have had access to the Subscriber's private key,
All representations in the Certificate Application by the Subscriber are true,
The information from the Subscriber in the Certificate is true,
Any usage of the Certificate is for authorized and lawful reasons only, consistent
with this CPS,The Subscriber is not a CA but is an end-user Subscriber and is not using the private key
corresponding to any public key listed in the Certificate for purposes of digitally signing
any Certificate (or any other format of certified public key) or CRL, as a CA orotherwise (with the exception of signing code with a Code Signing Certificate), andThe Subscriber is not using the Certificate Service in any way that infringes upon the rightsof third parties.
The Subscriber is not using their Code Signing Certificate to digitally sign hostile code,
including spyware or other malicious software (malware) downloaded without user
consent.

These requirements shall be in other Subscriber Agreements.

Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
70

Starfield CP-CPS v5.01

9.6.4

Relying Party Representations and Warranties

You warrant and represent that:(a) the Certificate is being used lawfully by You and with authorization;(b) You are using the Certificate in a Relying Party capacity;(c) You disclaim any fiduciary relationship between Starfield and any non-Starfield Certification
Authorities, and between You and any Subscriber; and(d) You understand that a Starfield Subscriber is solely responsible for the generation and securityof the Private Key corresponding to the Public Key contained in the Subscriber’sCertificate, and that the Subscriber may have failed to keep the Certificate secure and if so, thePrivate Key may have become compromised.

9.6.5

Representations and Warranties of Other Participants

No Stipulation.

9.7

Disclaimers of Warranties

STARFIELD, ITS CAS, ITS RESELLERS, CO-MARKETERS, SUBCONTRACTORS,DISTRIBUTORS, AGENTS, SUPPLIERS, AND EMPLOYEES MAKE NO REPRESENTATIONSAND EXPRESSLY DISCLAIM ALL WARRANTIES OF ANY KIND, WHETHER EXPRESS OR
IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, NON-INFRINGEMENT,TITLE, SATISFACTORY TITLE, AND ALSO INCLUDING WARRANTIES THAT ARESTATUTORY OR BY USAGE OF TRADE. STARFIELD MAKES NO WARRANTY THAT ITSSERVICE(S) WILL MEET ANY EXPECTATIONS, OR THAT THE SERVICE(S) WILL BE
UNINTERRUPTED, TIMELY, SECURE, OR ERROR FREE, OR THAT DEFECTS WILL BE
CORRECTED. STARFIELD DOES NOT WARRANT, NOR MAKE ANY REPRESENTATIONSREGARDING THE USE, OR RESULTS OF, ANY OF THE SERVICES WE PROVIDE, IN
TERMS OF THEIR CORRECTNESS, ACCURACY, RELIABILITY, OR OTHERWISE.

9.7.1 Fiduciary Relationships
Starfield is not the agent, fiduciary, trustee, or other representative of Subscribers or Relying
Parties. Starfield’s Subscriber agreements and Relying party agreements shall disclaim, to theextent permitted by law, any fiduciary relationship between Starfield or a non-Starfield CA or RA,
and between a Subscriber or Relying party.

9.8

Limitations of Liability

STARFIELD SHALL NOT BE LIABLE FOR ANY LOSS OF CERTIFICATE SERVICES
UNLESS DUE TO A FAILURE OR BREACH OF THE CERTIFICATE ENCRYPTION.
THE TOTAL CUMULATIVE LIABILITY OF STARFIELD, ANY INDEPENDENT THIRDPARTY RA OPERATING UNDER A STARFIELD CA, ANY RESELLERS, OR COMARKETERS, OR ANY SUBCONTRACTORS, DISTRIBUTORS, AGENTS, SUPPLIERS,EMPLOYEES, OR DIRECTORS OF ANY OF THE FOREGOING TO ANY APPLICANT,SUBSCRIBER, RELYING PARTY OR ANY OTHER PERSON, ENTITY, OR ORGANIZATION
Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
71

Starfield CP-CPS v5.01

ARISING OUT OF OR RELATING TO ANY STARFIELD CERTIFICATE OR ANY SERVICESPROVIDED IN RESPECT TO STARFIELD CERTIFICATES, INCLUDING ANY USE ORRELIANCE ON ANY STARFIELD CERTIFICATE, SHALL NOT EXCEED (A) $0.00 USD FOR
EACH BASIC ASSURANCE CERTIFICATE ("BASIC ASSURANCE CUMULATIVE DAMAGE
LIMIT"); (B) $10,000.00 USD FOR EACH MEDIUM ASSURANCE CERTIFICATE ("MEDIUM
ASSURANCE CUMULATIVE DAMAGE LIMIT"); (C) $25,000.00 USD FOR EACH HIGHASSURANCE CERTIFICATE ("HIGH ASSURANCE CUMULATIVE DAMAGE LIMIT"); OR(D) $50,000.00 USD FOR EACH EXTENDED VALIDATION CERTIFICATE ("EXTENDED
VALIDATION CUMULATIVE DAMAGE LIMIT") (COLLECTIVELY, “CUMULATIVEDAMAGE LIMITS”). THESE CUMULATIVE DAMAGE LIMITS SHALL APPLY PERSTARFIELD CERTIFICATE REGARDLESS OF THE NUMBER OF TRANSACTIONS OR
CAUSES OF ACTION ARISING OUT OF OR RELATED TO SUCH STARFIELD CERTIFICATEOR ANY SERVICES PROVIDED IN RESPECT TO SUCH STARFIELD CERTIFICATE. THE
FOREGOING LIMITATIONS SHALL APPLY TO ANY LIABILITY WHETHER BASED IN
CONTRACT (INCLUDING FUNDAMENTAL BREACH), TORT (INCLUDING NEGLIGENCE),
LEGISLATION OR ANY OTHER THEORY OF LIABILITY, INCLUDING ANY DIRECT,INDIRECT, SPECIAL, STATUTORY, PUNITIVE, EXEMPLARY, CONSEQUENTIAL,RELIANCE, OR INCIDENTAL DAMAGES.
STARFIELD, ANY INDEPENDENT THIRD-PARTY RA OPERATING UNDER A STARFIELD
CA, OR DIRECTORS OF ANY OF THE FOREGOING SHALL NOT BE LIABLE TO ANY
SUBSCRIBER, RELYING PARTY, OR ANY OTHER PERSON, ENTITY, OR ORGANIZATIONFOR ANY LOSSES, COSTS, EXPENSES, LIABILITIES, DAMAGES, CLAIMS ORSETTLEMENT AMOUNTS ARISING OUT OF OR RELATING TO ANY PROCEEDING OR
ALLEGATION THAT A STARFIELD CERTIFICATE OR ANY INFORMATION CONTAINEDIN A STARFIELD CERTIFICATE INFRINGES, MISAPPROPRIATES, DILUTES, UNFAIRLYCOMPETES WITH, OR OTHERWISE VIOLATES ANY PATENT, TRADEMARK,COPYRIGHT, TRADE SECRET, OR ANY INTELLECTUAL PROPERTY RIGHT OR OTHERRIGHT OF ANY PERSON, ENTITY, OR ORGANIZATION IN ANY JURISDICTION.
SHOULD LIABILITY ARISING OUT OF OR RELATING TO A STARFIELD CERTIFICATE ORANY SERVICES PROVIDED IN RESPECT TO A STARFIELD CERTIFICATE EXCEED THE
CUMULATIVE DAMAGE LIMITS, THE AMOUNTS AVAILABLE UNDER THE
CUMULATIVE DAMAGE LIMITS SHALL BE APPORTIONED FIRST TO THE EARLIEST
CLAIMS TO ACHIEVE FINAL DISPUTE RESOLUTION UNLESS OTHERWISE ORDERED BY
A COURT OF COMPETENT JURISDICTION. IN NO EVENT SHALL STARFIELD OR ANY
INDEPENDENT THIRD-PARTY RA OPERATING UNDER ANY STARFIELDCERTIFICATION AUTHORITY, OR ANY RESELLERS, CO-MARKETERS, OR ANY
SUBCONTRACTORS, DISTRIBUTORS, AGENTS, SUPPLIERS, EMPLOYEES, OR
DIRECTORS OF ANY OF THE FOREGOING BE OBLIGATED TO PAY MORE THAN THE
CUMULATIVE DAMAGE LIMITS FOR ANY STARFIELD CERTIFICATE OR ANY SERVICESPROVIDED IN RESPECT TO ANY STARFIELD SERVER CERTIFICATE REGARDLESS OF
APPORTIONMENT AMONG CLAIMANTS.
STARFIELD, INDEPENDENT THIRD-PARTY RAs OPERATING UNDER A STARFIELDCERTIFICATION AUTHORITY, RESELLERS, CO-MARKETERS, OR ANY
SUBCONTRACTORS, DISTRIBUTORS, AGENTS, SUPPLIERS, EMPLOYEES, OR
DIRECTORS OF ANY OF THE FOREGOING SHALL NOT BE LIABLE FOR ANY
Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
72

Starfield CP-CPS v5.01

INCIDENTAL, SPECIAL, STATUTORY, PUNITIVE, EXEMPLARY, INDIRECT, RELIANCE,OR CONSEQUENTIAL DAMAGES (INCLUDING, WITHOUT LIMITATION, DAMAGES FOR
LOSS OF BUSINESS, LOSS OF BUSINESS OPPORTUNITIES, LOSS OF GOODWILL, LOSSOF PROFITS, BUSINESS INTERRUPTION, LOSS OF DATA, LOST SAVINGS OR OTHERSIMILAR PECUNIARY LOSS) WHETHER ARISING FROM CONTRACT (INCLUDINGFUNDAMENTAL BREACH), TORT (INCLUDING NEGLIGENCE), LEGISLATION OR ANYOTHER THEORY OF LIABILITY.
THESE LIMITATIONS SHALL APPLY NOTWITHSTANDING THE FAILURE OF ESSENTIALPURPOSE OF ANY LIMITED REMEDY STATED HEREIN AND EVEN IF
STARFIELD OR ANY INDEPENDENT THIRD-PARTY
OPERATING UNDER A STARFIELD CERTIFICATION AUTHORITY, OR ANY RESELLERS,
CO-MARKETERS, OR ANY SUBCONTRACTORS, DISTRIBUTORS, AGENTS, SUPPLIERS,EMPLOYEES, OR DIRECTORS OF ANY OF THE FOREGOING HAVE BEEN ADVISED OF
THE POSSIBILITY OF THOSE DAMAGES.
SOME JURISDICTIONS DO NOT ALLOW THE EXCLUSION OR LIMITATION OF
LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES, SO THESE LIMITATIONSSET FORTH ABOVE MAY NOT APPLY TO CERTAIN APPLICANTS, SUBSCRIBERS,RELYING PARTIES, OR OTHER PERSONS, ENTITIES, OR ORGANIZATIONS. THE
DISCLAIMERS OF REPRESENTATIONS, WARRANTIES, AND CONDITIONS AND THE
LIMITATIONS OF LIABILITY IN THIS STARFIELD CERTIFICATION PRACTICE
STATEMENT CONSTITUTE AN ESSENTIAL PART OF THE STARFIELD CPS, ANY
SUBSCRIPTION AGREEMENTS, AND ANY RELYING PARTY AGREEMENTS. ALL
APPLICANTS, SUBSCRIBERS, RELYING PARTIES, AND OTHER PERSONS, ENTITIES,AND ORGANIZATIONS ACKNOWLEDGE THAT BUT FOR THESE DISCLAIMERS OF
REPRESENTATIONS, WARRANTIES, AND CONDITIONS AND LIMITATIONS OF
LIABILITY, STARFIELD WOULD NOT ISSUE STARFIELD CERTIFICATES TO
SUBSCRIBERS AND NEITHER STARFIELD NOR ANY INDEPENDENT THIRD-PARTY
REGISTRATION AUTHORITIES OPERATING UNDER A STARFIELD CERTIFICATIONAUTHORITY, NOR ANY RESELLERS, CO-MARKETERS, OR ANY SUBCONTRACTORS,DISTRIBUTORS, AGENTS, SUPPLIERS, EMPLOYEES, OR DIRECTORS OF ANY OF THE
FOREGOING WOULD PROVIDE SERVICES IN RESPECT TO STARFIELD CERTIFICATES
AND THAT THESE PROVISIONS PROVIDE FOR A REASONABLE ALLOCATION OF RISK.

9.8.1.1

Hazardous Activities

Starfield Certificates and the services provided by Starfield in respect to Starfield Certificatesare not designed, manufactured, or intended for use in or in conjunction with hazardous
activities or uses requiring fail-safe performance, including the operation of nuclear facilities,
aircraft navigation or communications systems, air traffic control, medical devices or direct life
support machines. Starfield and any independent third-party RA operating under a Starfield
CA, and any Resellers, Co-marketers, and any subcontractors, distributors, agents, suppliers,
employees, or directors of any of the foregoing specifically disclaim any and all
representations, warranties, and conditions with respect to such uses, whether express, implied,statutory, by usage of trade,or otherwise.

Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
73

Starfield CP-CPS v5.01

9.8.1.2

Other

Without limitation, neither Starfield nor any independent third-party RAs operating under aStarfield CA, nor any Resellers or Co-marketers, or any subcontractors, distributors, agents,
suppliers, employees, or directors of any of the foregoing shall be liable to any Applicants,
Subscribers, Relying Parties or any other person, entity, or organization for any losses, costs,
expenses, liabilities, damages, claims, or settlement amounts arising out of or relating to use of
a Starfield Certificate or any services provided in respect to a Starfield Certificate if:(i) the Starfield Certificate was issued as a result of errors, misrepresentations, or other acts oromissions of a Subscriber or of any other person, entity, or organization;(ii) the Starfield Certificate has expired or has been revoked;(iii) the Starfield Certificate has been modified or otherwise altered;(iv) a Subscriber breached the Starfield CPS or the Subscriber's Subscription Agreement, or a
Relying Party breached the Starfield CPS or the Relying Party's Relying Party Agreement;(v) the Private Key associated with the Starfield Certificate has been Compromised; or(vi) the Starfield Certificate is used other than as permitted by the Starfield CPS or is used incontravention of applicable law.

9.9

Indemnities

9.9.1 Indemnification by Starfield
Starfield shall defend, indemnify, and hold harmless each Application Software Supplier for any
and all claims, damages, and losses suffered by such Application Software Supplier related to a
Certificate issued by Starfield, regardless of the cause of action or legal theory involved. This does
not apply, however, to any claim, damages, or loss suffered by such Application Software
Supplier related to a Certificate issued by Starfield where such claim, damage, or loss was directly
caused by such Application Software Supplier’s software displaying as not trustworthy a
Certificate that is still valid, or displaying as trustworthy: (1) a Certificate that has expired, or (2) a
Certificate that has been revoked (but only in cases where the revocation status is currently
available from Starfield online, and the application software either failed to check suchstatus or ignored an indication of revoked status).

9.9.2 Indemnification by Subscribers
Starfield's Subscriber Agreement and other Subscriber Agreements shall require Subscribers toindemnify, to the extent permitted by law, Starfield and any non-Starfield CAs or RAs against
any and all liabilities, losses, costs, expenses, damages, claims, and settlement amounts (including
reasonable attorney’s fees, court costs, and expert’s fees) arising out of or relating to any use or
reliance by a Relying Party on any Starfield Certificate or any service provided in respect toStarfield Certificates, including:••

Any false statement, omission or misrepresentation of fact that the Subscriber has put on
the Subscriber's Certificate Application,
Any modification made by the Subscriber to the information contained in a Starfield
Certificate,
Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
74

Starfield CP-CPS v5.01

•••

The use of a Starfield Certificate other than as permitted by the Starfield CPS, theSubscription agreement, any Relying Party agreement, and applicable law,
The Subscriber's failure to use a secure system, protect the Subscriber's private key, or tootherwise take the precautions necessary to prevent the compromise, loss,
disclosure, modification, or unauthorized use of the Subscriber's private key, or
The Subscriber's use of a name (including without limitation within a common name,domain name, or e-mail address) that infringes upon the Intellectual Property Rights of athird party.

9.9.3 Indemnification by Relying Parties
Starfield's Subscriber Agreements and Relying Party Agreements shall require Relying Parties toindemnify Starfield and any non-Starfield CAs or RAs against, to the extent permitted by law,
any and all liabilities, losses, costs, expenses, damages, claims, and settlement amounts (including
reasonable attorney’s fees, court costs, and expert’s fees) arising out of or relating to any use or
reliance by a Relying Party on any Starfield Certificate or any service provided in respect toStarfield Certificates, including:
•
•
•
•
•
•

9.10

Any failure by the Relying Party to perform the obligations of a Relying Party,
Lack of proper validation of a Starfield Certificate by a Relying Party,
Use of a Starfield Certificate other than as permitted by the Starfield CPS, the Subscription
agreement, any Relying Party agreement, and applicable law,
Failure by a Relying Party to exercise reasonable judgment in the circumstances in relying
on a Starfield Certificate.
Reliance by a Relying Party on a Certificate that is not reasonable under thecircumstances, or
The failure of a Relying Party to check the status of such Certificate to determine if it isexpired or revoked.

Term and Termination

9.10.1 Term
No Stipulation.

9.10.2 Termination
No Stipulation.

9.10.3 Effect of Termination and Survival
This CP/CPS shall be binding on all successors of the parties.
If any provision of this CP/CPS is found to be unenforceable, the remaining provisions shall beinterpreted to best carry out the reasonable intent of the parties. It is expressly agreed that every
provision of this CP/CPS that provides for a limitation of liability or exclusion of damages,
disclaimer or limitation of any warranties, promises or other obligations, is intended to be
severable and independent of any other provision and is to be enforced as such.
Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
75

Starfield CP-CPS v5.01

This CPS shall be interpreted consistently with what is commercially reasonable in good faithunder the circumstances and considering its international scope and uniform application. Failureby any person to enforce a provision of this CP/CPS will not be deemed a waiver of future
enforcement of that or any other provision.

9.11
Individual Notices and Communications with
Participants
Any notice, demand, or request pertaining to this CP/CPS shall be communicated either using email
consistent with this CP/CPS, or in writing. Electronic communications shall be effective when
received by the intended recipient.

9.12

Amendments

9.12.1 Procedure for Amendment
No Stipulation.

9.12.2 Notification Mechanism and Period
No Stipulation.

9.12.3 Circumstances Under Which OID Must be Changed
No Stipulation.

9.13

Dispute Resolution Provisions

In the event of any dispute involving the services or provisions covered by this CP/CPS, theaggrieved party shall notify Starfield management regarding the dispute. Starfield management will
involve the appropriate Starfield personnel to resolve the dispute.

9.14

Governing Law

The laws of the state of Arizona, USA, shall govern the enforceability, construction, interpretation,and validity of this CPS, subject to any limits appearing in applicable law, and regardless of contract
or other choice of law provisions and without the requirement to establish a commercial nexus in
Arizona, USA. The choice of law is made to create uniform procedures and interpretation for all
Starfield PKI participants, no matter where they are located.
This governing law provision applies only to this CPS. Agreements incorporating the CPS byreference may have their own governing law provisions, provided that this CPS governs theenforceability, construction, interpretation, and validity of the terms of the CPS separate and apartfrom the remaining provisions of any such agreements, subject to any limitations appearing inapplicable law.

Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
76

Starfield CP-CPS v5.01

Any applicable national, state, local and foreign laws, rules, regulations, ordinances, decrees, andorders including, but not limited to, restrictions on exporting or importing software, hardware, or
technical information shall apply to this CPS.

9.15

Compliance with Applicable Law

No Stipulation.

9.16

Miscellaneous Provisions

9.16.1 Entire Agreement
No Stipulation.

9.16.2 Assignment
No Stipulation.

9.16.3 Severability
No Stipulation.

9.16.4 Enforcement
No Stipulation.

9.16.5 Force Majeure
Starfield shall not be responsible for any breach of warranty, delay, or failure in performance
under this CP/CPS that results from events beyond its control including, but not limited to, acts ofGod, acts of war, epidemics, riots, power outages, fire, earthquakes, floods and other disasters.

9.17

Other Provisions

Not applicable.

Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
77

Starfield CP-CPS v5.01

10 APPENDIX A – CERTIFICATE PROFILES
10.1

Root CAs

10.1.1 Starfield Class 2 Certification Authority
The following certificate profile is used for the Starfield Class 2 Certification Authority.
Field
Version
Serial Number
Signature Algorithm Identifier
IssuerValid From
Valid To
Subject

Subject Public Key
Information
Extensions:
Basic Constraints
Authority Key Identifier

Subject Key Identifier

Description
V3
0 (0x0)
sha1RSAOU=Starfield Class 2 Certification Authority
O=Starfield Technologies, Inc.
C=US
June 29, 2004 17:39:16 GMT
June 29, 2034 17:39:16 GMT
OU=Starfield Class 2 Certification Authority
O=Starfield Technologies, Inc.
C=US
RSA (2048 bits)

Subject Type=CA
Path Length Constraint=None
KeyID: bf 5f b7 d1 ce dd 1f 86 f4 5b 55 ac dc d7 10 c2 0e a9 88 e7
Certificate Issuer:
Directory Address:
OU=Starfield Class 2 Certification Authority
O=Starfield Technologies, Inc.
C=US
Certificate SerialNumber=00
bf 5f b7 d1 ce dd 1f 86 f4 5b 55 ac dc d7 10 c2 0e a9 88 e7

Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
78

Starfield CP-CPS v5.01

10.1.2 Starfield Root Certificate Authority – G2
The following certificate profile is used for the Starfield Root Certificate Authority – G2.
Field
Version
Serial Number
Signature Algorithm Identifier
IssuerValid From
Valid To
Subject

Subject Public Key
Information
Extensions:
Basic Constraints (critical)
Key Usage (critical)
Subject Key Identifier

Description
V3
0 (0x0)sha256RSA
CN=Starfield Root Certificate Authority - G2
O=Starfield Technologies, Inc.
L=Scottsdale
S=Arizona
C=US
September 1, 2009 00:00:00 GMT
December 31, 2037 23:59:59 GMT
CN=Starfield Root Certificate Authority - G2
O=Starfield Technologies, Inc.
L=Scottsdale
S=Arizona
C=US
RSA (2048 bits)

Subject Type=CA
Path Length Constraint=None
keyCertSign, cRLSign7c 0c 32 1f a7 d9 30 7f c4 7d 68 a3 62 a8 a1 ce ab 07 5b 27

10.1.3 Go Daddy Class 2 Certification Authority
The following certificate profile is used for the Go Daddy Class 2 Certification Authority.
Field
Version
Serial Number
Signature Algorithm Identifier
IssuerValid From
Valid To
Subject

Subject Public Key Information
Extensions:
Basic Constraints
Authority Key Identifier

Subject Key Identifier

Description
V3
0 (0x0)
sha1RSAOU=Go Daddy Class 2 Certification Authority
O=The Go Daddy Group, Inc.
C=US
June 29, 2004 17:06:20 GMT
June 29, 2034 17:06:20 GMT
OU=Go Daddy Class 2 Certification Authority
O=The Go Daddy Group, Inc.
C=US
RSA (2048 bits)
Subject Type=CA
Path Length Constraint=None
KeyID=d2 c4 b0 d2 91 d4 4c 11 71 b3 61 cb 3d a1 fe dd a8 6a d4 e3Certificate Issuer:
Directory Address:
OU=Go Daddy Class 2 Certification Authority
O=The Go Daddy Group, Inc.
C=US
Certificate SerialNumber=00
d2 c4 b0 d2 91 d4 4c 11 71 b3 61 cb 3d a1 fe dd a8 6a d4 e3Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
79

Starfield CP-CPS v5.01

10.1.4 Go Daddy Root Certificate Authority – G2
The following certificate profile is used for the Go Daddy Root Certificate Authority – G2.
Field
Version
Serial Number
Signature Algorithm Identifier
IssuerValid From
Valid To
Subject

Subject Public Key Information
Extensions:
Basic Constraints (critical)
Key Usage (critical)
Subject Key Identifier

Description
V3
0 (0x0)sha256RSA
CN=Go Daddy Root Certificate Authority - G2
O=GoDaddy.com, Inc.
L=Scottsdale
S=Arizona
C=US
September 1, 2009 00:00:00 GMT
December 31, 2037 23:59:59 GMT
CN=Go Daddy Root Certificate Authority - G2
O=GoDaddy.com, Inc.
L=Scottsdale
S=Arizona
C=US
RSA (2048 bits)
Subject Type=CA
Path Length Constraint=None
keyCertSign, cRLSign3a 9a 85 07 10 67 28 b6 ef f6 bd 05 41 6e 20 c1 94 da 0f de

Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
80

Starfield CP-CPS v5.01

10.1.5 Starfield Services Root Certification Authority
The following certificate profile is used for the Starfield Services Root Certification Authority.
Field
Version
Serial Number
Signature Algorithm Identifier
IssuerValid From
Valid To
Subject

Subject Public Key Information
Extensions:
Key Usage (critical)
Basic Constraints (critical)

Description
V3
0 (0x0)
sha1RSA
CN= Starfield Services Root Certification Authority
OU=http://certificates.starfieldtech.com/repository/
O=Starfield Technologies, Inc.
L=Scottsdale
ST=Arizona
C=US
June 2, 2008 00:00:00 GMT
December 31, 2029 23:59:59 GMT
CN= Starfield Services Root Certification Authority
OU=http://certificates.starfieldtech.com/repository/
O=Starfield Technologies, Inc.
L=Scottsdale
ST=Arizona
C=US
RSA (2048 bits)

Authority Key Identifier

keyCertSign, cRLSign
Subject Type=CA
Path Length Constraint=Noneb4 c6 7f 1a 43 cc 9b 75 5d 2f c4 4b f2 8b 98 10 e9 f1 51 10

Subject Key Identifierb4 c6 7f 1a 43 cc 9b 75 5d 2f c4 4b f2 8b 98 10 e9 f1 51 1010.1.6 GoDaddy Root Certificate Authority - G5.
The following certificate profile is used for the GoDaddy Root Certificate Authority - G5.
Field
Version
Serial Number
Signature Algorithm
Identifier
IssuerValid From
Valid To
Subject

Subject Public Key
Information
Extensions:
Key Usage(critical)
Basic Constraints(critical)

Description
V3
13:7f:6d:56:eb:b7:14:c0:cf:c6:2d:bd:61:85:a0:42
sha256WithRSAEncryption
CN=Go Daddy Root Certificate Authority – G5
O=GoDaddy.com, Inc.
C=US
June 21, 2022 00:00:00 GMT
June 21, 2042 00:00:00 GMT
CN=Go Daddy Root Certificate Authority – G5
O=GoDaddy.com, Inc.
C=US
RSA (4096 bits)

keyCertSign, cRLSign
Subject Type=CA
Path Length Constraint=None
Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
81

Starfield CP-CPS v5.01

FieldSubject Key
Identifier

Description
CF:CF:BB:19:B2:9F:F8:CB:F5:C2:9E:63:84:B1:7B:E6:17:07:31:58

10.1.7 Starfield Root Certificate Authority - G5
The following certificate profile is used for the Starfield Root Certificate Authority - G5.
Field
Version
Serial Number
Signature Algorithm
Identifier
IssuerValid From
Valid To
Subject

Subject Public Key
Information
Extensions:
Key Usage(critical)
Basic Constraints(critical)
Subject Key
Identifier

Description
V3
f0:f8:38:64:b9:0f:43:32:d1:bf:cb:19:1c:ae:8a:32
sha256WithRSAEncryption
CN= Starfield Root Certificate Authority – G5
O= Starfield Technologies, Inc.
C=US
June 21, 2022 00:00:00 GMT
June 21, 2042 00:00:00 GMT
CN= Starfield Root Certificate Authority – G5
O= Starfield Technologies, Inc.
C=US
RSA (4096 bit)

keyCertSign, CRLSign
Subject Type=CA
Path Length Constraint=None
E3:11:A7:2D:79:1E:3D:11:54:C3:69:2D:6B:07:A9:F8:05:03:D9:30

10.1.8 GoDaddy Root Certificate Authority – G6
The following certificate profile is used for the GoDaddy Root Certificate Authority – G6.
Field
Version
Serial Number
Signature
Algorithm
Identifier
IssuerValid From
Valid To
Subject

Subject Public Key
Information
Extensions:
Key Usage(critical)

DescriptionV3
18:3c:e3:59:e1:7c:f2:86:8c:65:a7:0a:46:e0:5c:c3
ecdsa-with-SHA384
CN=Go Daddy Root Certificate Authority – G6
O=GoDaddy.com, Inc.
C=US
June 21, 2022 00:00:00 GMT
June 21, 2052 00:00:00 GMT
CN=Go Daddy Root Certificate Authority – G6
O=GoDaddy.com, Inc.
C=US
ECC, NIST P-384

keyCertSign, cRLSign
Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
82

Starfield CP-CPS v5.01

BasicConstraints(critical)
Subject Key
Identifier

Subject Type=CA
Path Length Constraint=None
59:C1:AE:05:B3:82:9E:CB:31:C3:F5:9B:E3:18:BC:DD:C6:23:A9:BF

10.1.9 Starfield Root Certificate Authority - G6
The following certificate profile is used for the Starfield Root Certificate Authority - G6.
Field
Version
Serial Number
Signature Algorithm
Identifier
IssuerValid From
Valid To
Subject

Subject Public Key
Information
Extensions:
Key Usage(critical)
BasicConstraints(critical)
Subject Key
Identifier

Description
V3
54:27:7b:51:ae:50:1f:7e:a4:51:82:3e:36:06:db:7c
ecdsa-with-SHA384
CN= Starfield Root Certificate Authority - G6
O= Starfield Technologies, Inc.
C=US
June 21, 2022 00:00:00 GMT
June 21, 2052 00:00:00 GMT
CN= Starfield Root Certificate Authority - G6
O= Starfield Technologies, Inc.
C=US
ECC, NIST P-384

keyCertSign, CRLSign
Subject Type=CA
Path Length Constraint=None
1B:C1:8D:B1:2B:19:78:D7:FF:21:82:0C:DE:60:B8:54:0D:7A:93:CC

Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
83

Starfield CP-CPS v5.01

10.2

Issuing CAs

All intermediate certificates issued by any Starfield root certificate are available in the Repository at
https://certs.godaddy.com/repository.

10.2.1 Starfield Issuing (subordinate) CAs
The following certificate profile is used for Starfield Issuing (subordinate) CAs.
Field
Version
Serial Number
Signature
Algorithm
Identifier
IssuerValid From
Valid To
Subject
Subject Public
Key
Information
Extensions:
Key Usage
Extended
Key Usage
Basic
Constraints
CRL
Distribution
PointsCertificate
Policies

Authority
Information
AccessAuthority
Key
Identifier
Subject
Key
Identifier

Description
V3
Identifying number unique within the Starfield PKI
SHA-1, SHA-256, or SHA-384
Unique name matching the corresponding root certificate’s Subject
Not specified
Up to 20 years after Valid From dateUnique name for each Issuing CA
RSA (1024 bits), RSA (2048 bits), RSA (4096 bits) or ECC (384 bits)

Digital Signature, Certificate Signing, CRL Signing
Optional.
When intended to sign SSL/TLS certificates: Server Authentication, Client Authentication
Subject Type=CA
Path Length Constraint=None
Contains the URL of the corresponding root CRL[1]Certificate Policy:
Policy Identifier=All issuance policies[1,1]Policy Qualifier Info:
Policy Qualifier Id=CPS
Qualifier:
URI pointing to Starfield Repository
URL of the appropriate OCSP responder
SHA-1 hash of the corresponding root certificate’s public key
SHA-1 hash of the certificate’s public key

Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
84

Starfield CP-CPS v5.01

10.3

Cross CA Certificates

This section discloses all cross certificates that Starfield is aware of that list a CA covered by thisCPS as the Subject.

10.3.1 Go Daddy Root Certificate Authority - G2 + Go Daddy Class 2
Certification Authority
The following certificate profile is used for the certificate which cross certifies the Go Daddy Root
Certificate Authority - G2 with the Go Daddy Class 2 Certification Authority root.
Field
Version
Serial Number
Signature
Algorithm
Identifier
IssuerValid From
Valid To
Subject

Subject Public
Key
Information
Extensions:
BasicConstraints(critical)
Key Usage(critical)
Subject
Key
Identifier
Authority
Key
Identifier
Authority
Information
AccessCRL
Distribution
PointsCertificate
Policies

Description
V3
1b e7 15
sha256RSA (OID: 1.2.840.113549.1.1.11)

OU=Go Daddy Class 2 Certification Authority
O = The Go Daddy Group, Inc.
C = US
January 1, 2014 07:00:00 GMT
May 30, 2031 07:00:00 GMT
CN = Go Daddy Root Certificate Authority - G2
O = GoDaddy.com, Inc.
L = Scottsdale
S = Arizona
C = USRSA (2048 bit) (OID: 1.2.840.113549.1.1.1)

Subject Type=CA

keyCertSign, cRLSign3a 9a 85 07 10 67 28 b6 ef f6 bd 05 41 6e 20 c1 94 da 0f de

KeyID= d2 c4 b0 d2 91 d4 4c 11 71 b3 61 cb 3d a1 fe dd a8 6a d4 e3[1]Authority Info Access
Access Method=On-line Certificate Status Protocol (1.3.6.1.5.5.7.48.1)
Alternative Name:
URL=http://ocsp.godaddy.com
CRL Distribution Point
Distribution Point Name:
Full Name:
URL = http://crl.godaddy.com/gdroot.crl[1]Certificate Policy:
Policy Identifier=anyPolicy (OID: 2 5 29 32 0)[1,1]Policy Qualifier Info:
Policy Qualifier Id=CPS
Qualifier:https://certs.godaddy.com/repository/
Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
85

Starfield CP-CPS v5.01

Note: The above certificate has been reissued. The prior instance is Valid From May 3, 2011 07:00:00
GMT, has the Serial Number 20 03, and includes Subject: OU=https://certs.starfieldtech.com/repository/.

Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
86

Starfield CP-CPS v5.01

10.3.2 Starfield Root Certificate Authority - G2 + Starfield Class 2
Certification Authority
The following certificate profile is used for the certificate which cross certifies the Starfield Root
Certificate Authority - G2 with the Starfield Class 2 Certification Authority root.
Field
Version
Serial Number
Signature
Algorithm
Identifier
IssuerValid From
Valid To
Subject

Subject Public
Key
Information
Extensions:
BasicConstraints(critical)
Key Usage(critical)
Subject
Key
Identifier
Authority
Key
Identifier
Authority
Information
AccessCRL
Distribution
PointsCertificate
Policies

Description
V3
39 14 84
sha256RSA (OID: 1.2.840.113549.1.1.11)

OU=Starfield Class 2 Certification Authority
O = Starfield Technologies, Inc.
C = US
January 1, 2014 07:00:00 GMT
May 3, 2031 07:00:00 GMT
CN = Starfield Root Certificate Authority - G2
O = Starfield Technologies, Inc.
L = Scottsdale
S = Arizona
C = USRSA (2048 bit) (OID: 1.2.840.113549.1.1.1)

Subject Type=CA

keyCertSign, cRLSign7c 0c 32 1f a7 d9 30 7f c4 7d 68 a3 62 a8 a1 ce ab 07 5b 27

KeyID= bf 5f b7 d1 ce dd 1f 86 f4 5b 55 ac dc d7 10 c2 0e a9 88 e7[1]Authority Info Access
Access Method=On-line Certificate Status Protocol (1.3.6.1.5.5.7.48.1)
Alternative Name:
URL=http://ocsp.starfieldtech.com
CRL Distribution Point
Distribution Point Name:
Full Name:
URL = http://crl.starfieldtech.com/sfroot.crl[1]Certificate Policy:
Policy Identifier=anyPolicy (OID: 2 5 29 32 0)[1,1]Policy Qualifier Info:
Policy Qualifier Id=CPS
Qualifier:https://certs.starfieldtech.com/repository/

Note: The above certificate has been reissued. The prior instance is Valid From May 3, 2011 07:00:00
GMT, has the Serial Number 20 06, and includes Subject: OU=https://certs.starfieldtech.com/repository/.

Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
87

Starfield CP-CPS v5.01

10.3.3 Starfield Services Root Certificate Authority + Starfield
Services Root Certificate Authority
The following certificate profile is used for the certificate which cross certifies the Starfield
Services Root Certificate Authority - G2 with the Starfield Services Root Certificate Authority
root.
Field
Version
Serial Number
Signature
Algorithm
Identifier
IssuerValid From
Valid To
Subject

Subject Public
Key
Information
Extensions:
BasicConstraints(critical)
Key Usage(critical)
Subject
Key
Identifier
Authority
Key
Identifier
Authority
Information
AccessCRL
Distribution
PointsCertificate
Policies

Description
V3
30 dc a9sha256RSA (OID: 1.2.840.113549.1.1.11)

CN=Starfield Services Root Certificate Authority
OU=http://certificates.starfieldtech.com/repository/
O = Starfield Technologies, Inc.
L=Scottsdale
S=Arizona
C = US
January 1, 2014 07:00:00 GMT
May 30, 2031 07:00:00 GMT
CN = Starfield Services Root Certificate Authority - G2
O = Starfield Technologies, Inc.
L = Scottsdale
S = Arizona
C = USRSA (2048 bit) (OID: 1.2.840.113549.1.1.1)

Subject Type=CA

keyCertSign, cRLSign
9c 5f 00 df aa 01 d7 30 2b 38 88 a2 b8 6d 4a 9c f2 11 91 83

KeyID=b4 c6 7f 1a 43 cc 9b 75 5d 2f c4 4b f2 8b 98 10 e9 f1 51 10[1]Authority Info Access
Access Method=On-line Certificate Status Protocol (1.3.6.1.5.5.7.48.1)
Alternative Name:
URL=http://ocsp.starfieldtech.com
CRL Distribution Point
Distribution Point Name:
Full Name:
URL = http://crl.starfieldtech.com/sfsroot.crl[1]Certificate Policy:
Policy Identifier=anyPolicy (OID: 2 5 29 32 0)[1,1]Policy Qualifier Info:
Policy Qualifier Id=CPS
Qualifier:https://certs.starfieldtech.com/repository/

Note: The above certificate has been reissued. The prior instance is Valid From May 3, 2011 07:00:00
GMT, has the Serial Number 20 06, and includes Subject: OU=https://certs.starfieldtech.com/repository/.
Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
88

Starfield CP-CPS v5.01

10.3.4 Starfield Services Root Certificate Authority - G2 + Starfield
Class 2 Certification Authority
The following certificate profile is used for a certificate which cross certifies the Starfield Services
Root Certificate Authority - G2 with the Starfield Class 2 Certification Authority root.
Field
Version
Serial Number
Signature
Algorithm
Identifier
IssuerValid From
Valid To
Subject

Subject Public
Key
Information
Extensions:
BasicConstraints(critical)
Key Usage(critical)
Subject
Key
Identifier
Authority
Key
Identifier
Authority
Information
AccessCRL
Distribution
PointsCertificate
Policies

Description
V3
00 d8 c9 33 43 fe 5d 39 29
sha256RSA (OID: 1.2.840.113549.1.1.11)

OU=Starfield Class 2 Certification Authority
O = Starfield Technologies, Inc.
C = US
September 2, 2009 00:00:00 GMT
June 28, 2034 18:00:00 GMT
CN = Starfield Services Root Certificate Authority - G2
O = Starfield Technologies, Inc.
L = Scottsdale
S = Arizona
C = USRSA (2048 bit) (OID: 1.2.840.113549.1.1.1)

Subject Type=CA

keyCertSign, cRLSign
9c 5f 00 df aa 01 d7 30 2b 38 88 a2 b8 6d 4a 9c f2 11 91 83

KeyID=bf 5f b7 d1 ce dd 1f 86 f4 5b 55 ac dc d7 10 c2 0e a9 88 e7[1]Authority Info Access
Access Method=On-line Certificate Status Protocol (1.3.6.1.5.5.7.48.1)
Alternative Name:
URL=http://o.ss2.us[2]Authority Info Access
Access Method=Certification Authority Issuer (1.3.6.1.5.5.7.48.2)
Alternative Name:
URL=http://x.ss2.us/x.cer
CRL Distribution Point
Distribution Point Name:
Full Name:
URL = http://s.ss2.us/r.crl[1]Certificate Policy:
Policy Identifier=anyPolicy (OID: 2 5 29 32 0)

Note: The above certificate has been reissued. The prior instance has the Serial Number 00 a7 0e 4a 4c 34 82 b7
7f and a Valid To date of June 28, 2034 17:39:16 GMT.

Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
89

Starfield CP-CPS v5.01

10.3.5 Certainly E1 + Starfield Services Root Certificate Authority G2
The following certificate profile is used for the certificate which cross certifies the Certainly E1with the Starfield Services Root Certificate Authority - G2.
Field
Version
Serial Number
Signature
Algorithm
Identifier
IssuerValid From
Valid To
Subject

Subject Public
Key
Information
Extensions:
BasicConstraints(critical)
Key Usage(critical)
Subject
Key
Identifier
Authority
Key
Identifier
Authority
Information
AccessCRL
Distribution
PointsCertificate
Policies

Description
V3
00a207da718baba362
sha256WithRSAEncryption

CN = Starfield Root Certificate Authority - G2
O = Starfield Technologies, Inc.
L = Scottsdale
S = Arizona
C = US
June 22, 2022 00:00:00 GMT
June 21, 2032 23:59:59 GMT
CN = Certainly Intermediate E1
O = Certainly
C = US
ECC, NIST P-384

Subject Type=CA

Digital Signature, Certificate Sign, CRL Sign
0A:98:98:AE:4F:3A:D7:DD:67:86:E7:97:25:5A:9B:23:4F:5B:58:1D

keyid:7C:0C:32:1F:A7:D9:30:7F:C4:7D:68:A3:62:A8:A1:CE:AB:07:5B:27[1]Authority Info Access
Access Method=Certification Authority Issuer (1.3.6.1.5.5.7.48.2)
Alternative Name:
URL=http://certificates.starfieldtech.com/repository/sfroot-g2.crt.cer[1]CRL Distribution Point
Distribution Point Name:
Full Name:
URL=http://crl.starfieldtech.com/sfroot-g2.crl[1]Certificate Policy:
Policy Identifier=2.23.140.1.2.1[2]Certificate Policy:
Policy Identifier=1.3.6.1.4.1.49945.1.1
Qualifier:https://certs.starfieldtech.com/repository/

Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
90

Starfield CP-CPS v5.01

10.3.6 Certainly R1 + Starfield Services Root Certificate Authority G2
The following certificate profile is used for the certificate which cross certifies the Certainly R1with the Starfield Services Root Certificate Authority - G2.
Field
Version
Serial Number
Signature
Algorithm
Identifier
IssuerValid From
Valid To
Subject

Subject Public
Key
Information
Extensions:
BasicConstraints(critical)
Key Usage(critical)
Subject
Key
Identifier
Authority
Key
Identifier
Authority
Information
AccessCRL
Distribution
PointsCertificate
Policies

Description
V3
11831cde4cb573e5
sha256WithRSAEncryption

CN = Starfield Root Certificate Authority - G2
O = Starfield Technologies, Inc.
L = Scottsdale
S = Arizona
C = US
June 22, 2022 00:00:00 GMT
June 21, 2032 23:59:59 GMT
CN = Certainly Intermediate R1
O = Certainly
C = USRSA (2048 bit)

Subject Type=CA

Digital Signature, Certificate Sign, CRL Sign
BD:97:9D:df:A1:D8:1B:25:99:E3:0C:04:06:89:64:12:D7:65:24:C7

keyid:7C:0C:32:1F:A7:D9:30:7F:C4:7D:68:A3:62:A8:a1:CE:ab:07:5B:27[1]Authority Info Access
Access Method=Certification Authority Issuer (1.3.6.1.5.5.7.48.2)
Alternative Name:
URL=http://certificates.starfieldtech.com/repository/sfroot-g2.crt.cer[1]CRL Distribution Point
Distribution Point Name:
Full Name:
URL=http://crl.starfieldtech.com/sfroot-g2.crl[1]Certificate Policy:
Policy Identifier=2.23.140.1.2.1[2]Certificate Policy:
Policy Identifier=1.3.6.1.4.1.49945.1.1
Qualifier:https://certs.starfieldtech.com/repository/

Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
91

Starfield CP-CPS v5.01

10.4

End Entity SSL Certificates

10.4.1 Go Daddy Issuing CA: Subscriber Certificates
The following certificate profile is used for Go Daddy branded Subscriber Certificates issued fromthe Go Daddy Issuing CA. At a minimum, the following fields will be populated as described, in
accordance with IETF RFC 5280.
Field
Version
Serial Number
Signature Algorithm
Identifier
IssuerValid From
Valid To
Subject (Medium
Assurance Certificates
Subject (High
Assurance Certificates

Subject (Extended
Validation
Certificates)

Subject Public Key
Information
Extensions:
Basic Constraints(critical)
Extended Key
Usage
Key Usage(critical)

Description
V3
unique value with 64-bits of entropy for each certificate issued by the Issuing CA
sha256RSA (OID: 1.2.840.113549.1.1.11)
serialNumber = 07969287
CN = Go Daddy Secure Certification Authority
OU=http://certificates.godaddy.com/repository
O = GoDaddy.com, Inc.
L = Scottsdale
S = Arizona
C = US
Date and time of Certificate issuance
A date up to the maximum permitted validity period at the time of issuance after
Certificate issuance (depending on SSL certificate type).
CN = domain name of Subscriber’s web site
OU = “Domain Control Verified” or similar text indicating the assurance level ofthe certificate (on certificates issued prior to July 15, 2021).
CN = domain name of Subscriber’s web site
O = Subscriber’s organization or individual name
L = City/town
S = State
C = Country
CN = domain name of Subscriber’s web site
O = Subscriber’s full legal organization name. An assumed name or DBA may
also be included
L = City/town of place of businessS = State of place of business
C = Country of place of businessserialNumber= Registration number assigned by incorporating authority or dateof incorporation or registration
businessCategory=vetting category used to issue certificate as defined in the
CA/Browser Forum Guidelines for the Issuance and Management of Extended
Validation CertificatesjurisdictionLocalityName= City/town of incorporation or registration (ifapplicable)
jurisdictionStateOrProvinceName= State of incorporation or registration (ifapplicable)
jurisdictionCountryName= Country of incorporation or registration
RSA (2048 bits or greater)

Subject Type=End Entity
Path Length Constraint=None
Server Authentication (1.3.6.1.5.5.7.3.1)
Client Authentication (1.3.6.1.5.5.7.3.2)
Digital Signature, Key Encipherment
Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
92

Starfield CP-CPS v5.01

CRL Distribution
PointsCertificate
Policies (Medium
Assurance
Certificates)

Certificate
Policies (High
Assurance
Certificates)

Certificate
Policies(Extended
Validation
Certificates)
Authority
Information
AccessAuthority Key
Identifier
Subject
Alternative Name

Subject Key
Identifier
1.3.6.1.4.1.11129.
2.4.2 (Extended
Validation
Certificates)

CRL Distribution Point
Distribution Point Name:
Full Name:
URL = <current CRL URI>
The specific URI will vary depending on certificate type and CRL scope.
[1]Certificate Policy:
Policy Identifier=2.16.840.1.114413.1.7.23.1[1,1]Policy Qualifier Info:
Policy Qualifier Id=CPS
Qualifier:
http://certificates.godaddy.com/repository/[1]Certificate Policy:
Policy Identifier=2.16.840.1.114413.1.7.23.2[1,1]Policy Qualifier Info:
Policy Qualifier Id=CPS
Qualifier:
http://certificates.godaddy.com/repository/[1]Certificate Policy:
Policy Identifier=2.16.840.1.114413.1.7.23.3[1,1]Policy Qualifier Info:
Policy Qualifier Id=CPS
Qualifier:
http://certificates.godaddy.com/repository/[1]Authority Info Access
Access Method=On-line Certificate Status Protocol (1.3.6.1.5.5.7.48.1)
Alternative Name:
URL=http://ocsp.godaddy.com[2] Authority Info Access
Access Method=Certification Authority Issuer (1.3.6.1.5.5.7.48.2)
Alternative Name:
URL=http://certificates.godaddy.com/repository/gd_intermediate.crt
KeyID: fd ac 61 32 93 6c 45 d6 e2 ee 85 5f 9a ba e7 76 99 68 cc e7
Required, set to:
1. DNS=Fully-Qualified Domain Name of the Subscriber’s site, domainname remaining after removing “www.” from the left hand portion of
the Fully-Qualified Domain Name.
And/or:
2. DNS=domain name of Subscriber’s site, domain name of additionalsites which have undergone the following verification step as part of theauthentication process: the individual requesting the certificate hasaccess to the domain name(s) that are specified in the certificate
application (per 3.2.12)
160-bit SHA1 hash of the public key contained within this certificate
One or more RFC 6962 Signed Certificate Timestamps

Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
93

Starfield CP-CPS v5.01

10.4.2 Starfield Issuing CA: Subscriber Certificates
The following certificate profile is used for Starfield branded Subscriber Certificates issued fromthe Starfield Issuing CA. At a minimum, the following fields will be populated as described, in
accordance with IETF RFC 5280.
Field
Version
Serial Number
Signature Algorithm
Identifier
IssuerValid From
Valid To
Subject (Medium
Assurance Certificates
Subject (High
Assurance Certificates

Subject (Extended
Validation
Certificates)

Subject Public Key
Information
Extensions:
Basic Constraints(critical)
Extended Key
Usage
Key Usage(critical)
CRL Distribution
PointsDescription
V3
unique value with 64-bits of entropy for each certificate issued by the Issuing CA
sha256RSA (OID: 1.2.840.113549.1.1.11)
serialNumber = 10688435
CN = Starfield Secure Certification Authority
OU=http://certificates.starfieldtech.com/repository
O = Starfield Technologies, Inc.
L = Scottsdale
S = Arizona
C = US
Date and time of Certificate issuance
A date up to the maximum permitted validity period at the time of issuance after
Certificate issuance (depending on SSL certificate type).
CN = domain name of Subscriber’s web site
OU = “Domain Control Verified” or similar text indicating the assurance level ofthe certificate (on certificates issued prior to July 15, 2021).
CN = domain name of Subscriber’s web site
O = Subscriber’s organization or individual name
L = City/town
S = State
C = Country
CN = domain name of Subscriber’s web site
O = Subscriber’s full legal organization name. An assumed name or DBA may
also be included
L = City/town of place of businessS = State of place of business
C = Country of place of businessserialNumber= Registration number assigned by incorporating authority or dateof incorporation or registration
businessCategory=vetting category used to issue certificate as defined in the
CA/Browser Forum Guidelines for the Issuance and Management of Extended
Validation CertificatesjurisdictionLocalityName= City/town of incorporation or registration (ifapplicable)
jurisdictionStateOrProvinceName= State of incorporation or registration (ifapplicable)
jurisdictionCountryName= Country of incorporation or registration
RSA (2048 bits or greater)

Subject Type=End Entity
Path Length Constraint=None
Server Authentication (1.3.6.1.5.5.7.3.1)
Client Authentication (1.3.6.1.5.5.7.3.2)
Digital Signature, Key Encipherment
CRL Distribution Point
Distribution Point Name:
Full Name:
Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
94

Starfield CP-CPS v5.01

Certificate
Policies (Medium
Assurance
Certificates)

Certificate
Policies (High
Assurance
Certificates)

Certificate
Policies(Extended
Validation
Certificates)
Authority
Information
AccessAuthority Key
Identifier
Subject
Alternative Name

Subject Key
Identifier
1.3.6.1.4.1.11129.
2.4.2 (Extended
Validation
Certificates)

URL =<current CRL URI>
The specific URI will vary depending on certificate type and CRL scope.
[1]Certificate Policy:
Policy Identifier=2.16.840.1.114414.1.7.23.1[1,1]Policy Qualifier Info:
Policy Qualifier Id=CPS
Qualifier:
http://certificates.starfieldtech.com/repository/[1]Certificate Policy:
Policy Identifier=2.16.840.1.114414.1.7.23.2[1,1]Policy Qualifier Info:
Policy Qualifier Id=CPS
Qualifier:
http://certificates.starfieldtech.com/repository/[1]Certificate Policy:
Policy Identifier=2.16.840.1.114414.1.7.23.3[1,1]Policy Qualifier Info:
Policy Qualifier Id=CPS
Qualifier:
http://certificates.starfieldtech.com/repository/[1]Authority Info Access
Access Method=On-line Certificate Status Protocol (1.3.6.1.5.5.7.48.1)
Alternative Name:
URL=http://ocsp.starfieldtech.com[2] Authority Info Access
Access Method=Certification Authority Issuer (1.3.6.1.5.5.7.48.2)
Alternative Name:
URL=http://certificates.starfieldtech.com/repository/sf_intermediate.crt
KeyID: 49 4b 52 27 d1 1b bc f2 a1 21 6a 62 7b 51 42 7a 8a d7 d5 56
Required, set to:
1. DNS=Fully-Qualified Domain Name of the Subscriber’s site, domainname remaining after removing “www.” from the left hand portion of
the Fully-Qualified Domain Name.
And/or:
2. DNS=domain name of Subscriber’s site, domain name of additionalsites which have undergone the following verification step as part of theauthentication process: the individual requesting the certificate hasaccess to the domain name(s) that are specified in the certificate
application (per 3.2.12)
160-bit SHA1 hash of the public key contained within this certificate
One or more RFC 6962 Signed Certificate Timestamps

Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
95

Starfield CP-CPS v5.01

10.4.3 Go Daddy Issuing CA – G2: Subscriber Certificates
The following certificate profile is used for Go Daddy branded Subscriber Certificates issued fromthe Go Daddy Issuing CA – G2. At a minimum, the following fields will be populated as
described, in accordance with IETF RFC 5280.
Field
Version
Serial Number
Signature Algorithm
Identifier
IssuerValid From
Valid To
Subject (Basic andMedium Assurance
Certificates
Subject (High Assurance
Certificates

Subject (Extended
Validation Certificates)

Subject Public Key
Information
Extensions:
Basic Constraints(critical)
Extended Key Usage
Key Usage(critical)
CRL Distribution
PointsDescription
V3
unique value with 64-bits of entropy for each certificate issued by the Issuing CA
sha256RSA (OID: 1.2.840.113549.1.1.11)
CN = Go Daddy Secure Certificate Authority - G2
OU=http://certs.godaddy.com/repository/
O = GoDaddy.com, Inc.
L = Scottsdale
S = Arizona
C = US
Date and time of Certificate issuance
A date up to the maximum permitted validity period at the time of issuance after
Certificate issuance (depending on SSL certificate type).
CN = domain name of Subscriber’s web site
OU = “Domain Control Verified” or similar text indicating the assurance level of thecertificate (on certificates issued prior to July 15, 2021).
CN = domain name of Subscriber’s web site
O = Subscriber’s organization or individual name
L = City/town
S = State
C = Country
CN = domain name of Subscriber’s web site
O = Subscriber’s full legal organization name. An assumed name or DBA may also
be included
L = City/town of place of businessS = State of place of business
C = Country of place of businessserialNumber= Registration number assigned by incorporating authority or date ofincorporation or registration
businessCategory=vetting category used to issue certificate as defined in the
CA/Browser Forum Guidelines for the Issuance and Management of Extended
Validation CertificatesjurisdictionLocalityName= City/town of incorporation or registration (if applicable)
jurisdictionStateOrProvinceName= State of incorporation or registration (ifapplicable)
jurisdictionCountryName= Country of incorporation or registration
RSA (2048 bits or greater)

Subject Type=End Entity
Path Length Constraint=None
Server Authentication (1.3.6.1.5.5.7.3.1)
Client Authentication (1.3.6.1.5.5.7.3.2)
Digital Signature, Key Encipherment
CRL Distribution Point
Distribution Point Name:
Full Name:
URL = <current CRL URI>
The specific URI will vary depending on certificate type and CRL scope.
Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
96

Starfield CP-CPS v5.01

Certificate Policies(Basic and Medium
Assurance
Certificates)

Certificate Policies(High Assurance
Certificates)

Certificate Policies(Extended Validation
Certificates)

Authority Information
AccessAuthority Key
Identifier
Subject Alternative
Name

Subject Key Identifier
1.3.6.1.4.1.11129.2.4.2(Extended Validation
Certificates)[1]Certificate Policy:
Policy Identifier=2.16.840.1.114413.1.7.23.1[1,1]Policy Qualifier Info:
Policy Qualifier Id=CPS
Qualifier:
http://certificates.godaddy.com/repository/[2]Certificate Policy:
Policy Identifier=2.23.140.1.2.1[1]Certificate Policy:
Policy Identifier=2.16.840.1.114413.1.7.23.2[1,1]Policy Qualifier Info:
Policy Qualifier Id=CPS
Qualifier:
http://certificates.godaddy.com/repository/[2]Certificate Policy:
Policy Identifier=2.23.140.1.2.2 (OV) or 2.23.140.1.2.3 (IV)[1]Certificate Policy:
Policy Identifier=2.16.840.1.114413.1.7.23.3[1,1]Policy Qualifier Info:
Policy Qualifier Id=CPS
Qualifier:
http://certificates.godaddy.com/repository/[2]Certificate Policy:
Policy Identifier=2.23.140.1.1[1]Authority Info Access
Access Method=On-line Certificate Status Protocol (1.3.6.1.5.5.7.48.1)
Alternative Name:
URL=http://ocsp.godaddy.com[2] Authority Info Access
Access Method=Certification Authority Issuer (1.3.6.1.5.5.7.48.2)
Alternative Name:
URL=http://certificates.godaddy.com/repository/gdig2.crt
KeyID: 40 c2 bd 27 8e cc 34 83 30 a2 33 d7 fb 6c b3 f0 b4 2c 80 ce
Required, set to:
1. DNS=Fully-Qualified Domain Name of the Subscriber’s site, domain nameremaining after removing “www.” from the left hand portion of the FullyQualified Domain Name.
And/or:
2. DNS=domain name of Subscriber’s site, domain name of additional sites
which have undergone the following verification step as part of theauthentication process: the individual requesting the certificate has access tothe domain name(s) that are specified in the certificate application (per3.2.12)160-bit SHA1 hash of the public key contained within this certificate
One or more RFC 6962 Signed Certificate Timestamps

Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
97

Starfield CP-CPS v5.01

10.4.4 Starfield Issuing CA – G2: Subscriber Certificates
The following certificate profile is used for Starfield branded Subscriber Certificates issued fromthe Starfield Issuing CA – G2. At a minimum, the following fields will be populated as described,
in accordance with IETF RFC 5280.
Field
Version
Serial Number
Signature Algorithm
Identifier
IssuerDescription
V3
unique value with 64-bits of entropy for each certificate issued by the Issuing CA
sha256RSA (OID: 1.2.840.113549.1.1.11)

Valid From
Valid To
Subject (Basic andMedium Assurance
Certificates
Subject (High Assurance
Certificates

Subject (Extended
Validation Certificates)

Subject Public Key
Information
Extensions:
Basic Constraints(critical)
Extended Key Usage
Key Usage(critical)
CRL Distribution
Points

CN = Starfield Secure Certificate Authority - G2
OU=http://certs.starfield.com/repository/
O = Starfield Technologies, Inc.
L = Scottsdale
S = Arizona
C = US
Date and time of Certificate issuance
A date up to the maximum permitted validity period at the time of issuance after
Certificate issuance (depending on SSL certificate type).
CN = domain name of Subscriber’s web site
OU = “Domain Control Verified” or similar text indicating the assurance level of thecertificate (on certificates issued prior to July 15, 2021).
CN = domain name of Subscriber’s web site
O = Subscriber’s organization or individual name
L = City/town
S = State
C = Country
CN = domain name of Subscriber’s web site
O = Subscriber’s full legal organization name. An assumed name or DBA may also
be included
L = City/town of place of businessS = State of place of business
C = Country of place of businessserialNumber= Registration number assigned by incorporating authority or date ofincorporation or registration
businessCategory=vetting category used to issue certificate as defined in the
CA/Browser Forum Guidelines for the Issuance and Management of Extended
Validation CertificatesjurisdictionLocalityName= City/town of incorporation or registration (if applicable)
jurisdictionStateOrProvinceName= State of incorporation or registration (ifapplicable)
jurisdictionCountryName= Country of incorporation or registration
RSA (2048 bits or greater)

Subject Type=End Entity
Path Length Constraint=None
Server Authentication (1.3.6.1.5.5.7.3.1)
Client Authentication (1.3.6.1.5.5.7.3.2)
Digital Signature, Key Encipherment
CRL Distribution Point
Distribution Point Name:
Full Name:
URL = <current CRL URI>
The specific URI will vary depending on certificate type and CRL scope.

Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
98

Starfield CP-CPS v5.01

Certificate Policies(Basic and Medium
Assurance
Certificates)[1]Certificate Policy:
Policy Identifier=2.16.840.1.114414.1.7.23.1[1,1]Policy Qualifier Info:
Policy Qualifier Id=CPS
Qualifier:
http://certificates.starfieldtech.com/repository/[2]Certificate Policy:
Policy Identifier=2.23.140.1.2.1

Certificate Policies(High Assurance
Certificates)[1]Certificate Policy:
Policy Identifier=2.16.840.1.114414.1.7.23.2[1,1]Policy Qualifier Info:
Policy Qualifier Id=CPS
Qualifier:
http://certificates.starfieldtech.com/repository/[2]Certificate Policy:
Policy Identifier=2.23.140.1.2.2 (OV) or 2.23.140.1.2.3 (IV)

Certificate Policies(Extended Validation
Certificates)[1]Certificate Policy:
Policy Identifier=2.16.840.1.114414.1.7.23.3[1,1]Policy Qualifier Info:
Policy Qualifier Id=CPS
Qualifier:
http://certificates.starfieldtech.com/repository/[2]Certificate Policy:
Policy Identifier=2.23.140.1.1

Authority Information
AccessAuthority Key
Identifier
Subject Alternative
Name

Subject Key Identifier
1.3.6.1.4.1.11129.2.4.2(Extended Validation
Certificates)[1]Authority Info Access
Access Method=On-line Certificate Status Protocol (1.3.6.1.5.5.7.48.1)
Alternative Name:
URL=http://ocsp.starfieldtech.com[2] Authority Info Access
Access Method=Certification Authority Issuer (1.3.6.1.5.5.7.48.2)
Alternative Name:
URL=http://certificates.starfieldtech.com/repository/sfig2.crt
KeyID: 25 45 81 68 50 26 38 3d 3b 2d 2c be cd 6a d9 b6 3d b3 66 63
Required, set to:
1. DNS=Fully-Qualified Domain Name of the Subscriber’s site, domain nameremaining after removing “www.” from the left hand portion of the FullyQualified Domain Name.
And/or:
2. DNS=domain name of Subscriber’s site, domain name of additional sites
which have undergone the following verification step as part of theauthentication process: the individual requesting the certificate has access tothe domain name(s) that are specified in the certificate application (per3.2.12)160-bit SHA1 hash of the public key contained within this certificate
One or more RFC 6962 Signed Certificate Timestamps

Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
99

Starfield CP-CPS v5.01

10.5

End Entity Code Signing Certificates10.5.1 Go Daddy Issuing CA: Subscriber Certificates
As of May 30, 2021, Starfield no longer issues High Assurance Code Signing Certificates,
however the following certificate profile was used for Go Daddy branded Subscriber Certificatesissued from the Go Daddy Issuing CA. At a minimum, the following fields were populated as
described, in accordance with IETF RFC 5280.
Field
Version
Serial Number
Signature
Algorithm
Identifier
IssuerValid From
Valid To
Subject

Subject Public
Key Information
Extensions:
Basic Constraints(critical)
Extended Key
Usage
Key Usage(critical)
CRL Distribution
PointsCertificate
Policies

Authority
Information
AccessDescription
V3
unique value for each certificate issued by the Issuing CA
sha256RSA (OID: 1.2.840.113549.1.1.11)

serialNumber = 07969287
CN = Go Daddy Secure Certification Authority
OU=http://certificates.godaddy.com/repository
O = GoDaddy.com, Inc.
L = Scottsdale
S = Arizona
C = US
Date and time of Certificate issuance
A date up to 39 months after Certificate issuance
CN = Subscriber's organization name
O = Subscriber’s organization name
L = City/town
S = State
C = Country
RSA (2048 bits or greater)

Subject Type=End Entity
Path Length Constraint=None
Code Signing (1.3.6.1.5.5.7.3.3)
Digital Signature
CRL Distribution Point
Distribution Point Name:
Full Name:
URL = <current CRL URI>
The specific URI will vary depending on certificate type and CRL scope.
[1]Certificate Policy:
Policy Identifier=2.16.840.1.114413.1.7.23.2[1,1]Policy Qualifier Info:
Policy Qualifier Id=CPS
Qualifier:
http://certificates.godaddy.com/repository[1]Authority Info Access
Access Method=On-line Certificate Status Protocol (1.3.6.1.5.5.7.48.1)
Alternative Name:
URL=http://ocsp.godaddy.com[2] Authority Info Access
Access Method=Certification Authority Issuer (1.3.6.1.5.5.7.48.2)
Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
100

Starfield CP-CPS v5.01

Authority Key
Identifier
Subject Key
Identifier

Alternative Name:
URL=http://certificates.godaddy.com/repository/gd_intermediate.crt
fd ac 61 32 93 6c 45 d6 e2 ee 85 5f 9a ba e7 76 99 68 cc e7
160-bit SHA1 hash of the public key contained within this certificate

Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
101

Starfield CP-CPS v5.01

10.5.2 Starfield Issuing CA: Subscriber Certificates
As of May 30, 2021, Starfield no longer issues High Assurance Code Signing Certificates,
however the following certificate profile was used for Starfield branded Subscriber Certificatesissued from the Starfield Issuing CA. At a minimum, the following fields were populated as
described, in accordance with IETF RFC 5280.
Field
Version
Serial Number
Signature
Algorithm
Identifier
IssuerValid From
Valid To
Subject

Subject Public
Key Information
Extensions:
Basic Constraints(critical)
Extended Key
Usage
Key Usage(critical)
CRL Distribution
PointsCertificate
Policies (High
Assurance
Certificates)

Authority
Information
AccessAuthority Key
Identifier

Description
V3
unique value for each certificate issued by the Issuing CA
sha256RSA (OID: 1.2.840.113549.1.1.11)

serialNumber = 10688435
CN = Starfield Secure Certification Authority
OU=http://certificates.starfieldtech.com/repository
O = Starfield Technologies, Inc.
L = Scottsdale
S = Arizona
C = US
Date and time of Certificate issuance
A date up to 39 months after Certificate issuance
CN = Subscriber's organization name
O = Subscriber’s organization name
L = City/town
S = State
C = Country
RSA (2048 bits or greater)

Subject Type=End Entity
Path Length Constraint=None
Code Signing (1.3.6.1.5.5.7.3.3)
Digital Signature
CRL Distribution Point
Distribution Point Name:
Full Name:
URL = <current CRL URI>
The specific URI will vary depending on certificate type and CRL scope.
[1]Certificate Policy:
Policy Identifier=2.16.840.1.114414.1.7.23.2[1,1]Policy Qualifier Info:
Policy Qualifier Id=CPS
Qualifier:
http://certificates.starfieldtech.com/repository[1]Authority Info Access
Access Method=On-line Certificate Status Protocol (1.3.6.1.5.5.7.48.1)
Alternative Name:
URL=http://ocsp.starfieldtech.com[2] Authority Info Access
Access Method=Certification Authority Issuer (1.3.6.1.5.5.7.48.2)
Alternative Name:
URL=http://certificates.starfieldtech.com/repository/sf_intermediate.crt
49 4b 52 27 d1 1b bc f2 a1 21 6a 62 7b 51 42 7a 8a d7 d5 56
Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
102

Starfield CP-CPS v5.01

FieldSubject Key
Identifier

Description
160-bit SHA1 hash of the public key contained within this certificate

Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
103

Starfield CP-CPS v5.01

10.5.3 Go Daddy Secure Certificate Authority – G2 AND Go Daddy
Secure Extended Validation Code Signing CA – G2:
Subscriber Certificates
As of May 30, 2021, Starfield no longer issues High Assurance Code Signing Certificates,
however the following certificate profile was used for Go Daddy branded Subscriber Certificatesissued from the Go Daddy Secure Certificate Authority – G2 or the Go Daddy Secure Extended
Validation Code Signing CA – G2. At a minimum, the following fields were populated as
described, in accordance with IETF RFC 5280.
Field
Version
Serial Number
Signature
Algorithm
Identifier
IssuerValid From
Valid To
Subject

Subject (Extended
Validation
Certificates)

Subject Public
Key Information
Extensions:
Basic Constraints(critical)
Extended Key
Usage
Key Usage(critical)
CRL Distribution
PointsCertificate
Policies (High
Assurance
Certificates)

Description
V3
unique value for each certificate issued by the Issuing CA
sha256RSA (OID: 1.2.840.113549.1.1.11)

Subject of corresponding Issuing CA certificate
Date and time of Certificate issuance
A date up to 39 months after Certificate issuance
CN = Subscriber's organization name
O = Subscriber’s organization name
L = City/town
S = State
C = Country
O = Subscriber’s full legal organization name. An assumed name or DBA may also be
included
L = City/town of place of businessS = State of place of business
C = Country of place of businessserialNumber= Registration number assigned by incorporating authority or date ofincorporation or registration
businessCategory=vetting category used to issue certificate as defined in the
CA/Browser Forum Guidelines for the Issuance and Management of Extended
Validation CertificatesjurisdictionLocalityName= City/town of incorporation or registration (if applicable)
jurisdictionStateOrProvinceName= State of incorporation or registration (if applicable)
jurisdictionCountryName= Country of incorporation or registration
RSA (2048 bits or greater)

Subject Type=End Entity
Path Length Constraint=None
Code Signing (1.3.6.1.5.5.7.3.3)
Optional: Kernel Mode Code Signing (1.3.6.1.4.1.311.61.1.1)
Digital Signature
CRL Distribution Point
Distribution Point Name:
Full Name:
URL = <current CRL URI>
The specific URI will vary depending on certificate type and CRL scope.
[1]Certificate Policy:
Policy Identifier=2.16.840.1.114413.1.7.23.2[1,1]Policy Qualifier Info:
Policy Qualifier Id=CPS
Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
104

Starfield CP-CPS v5.01

Certificate
Policies (Extended
Validation
Certificates)

Authority
Information
AccessAuthority Key
Identifier
Subject Key
Identifier

Qualifier:
http://certificates.godaddy.com/repository[2]Certificate Policy:
Policy Identifier=2.23.140.1.4.1[1]Certificate Policy:
Policy Identifier=2.16.840.1.114413.1.7.24.3[1,1]Policy Qualifier Info:
Policy Qualifier Id=CPS
Qualifier:
http://certificates.godaddy.com/repository/[2]Certificate Policy:
Policy Identifier=2.23.140.1.3[1]Authority Info Access
Access Method=On-line Certificate Status Protocol (1.3.6.1.5.5.7.48.1)
Alternative Name:
URL=http://ocsp.godaddy.com[2] Authority Info Access
Access Method=Certification Authority Issuer (1.3.6.1.5.5.7.48.2)
Alternative Name: URL=http://certificates.godaddy.com/repository/gdig2.crt
SHA-1 hash of the public of the corresponding Issuing CA
SHA-1 hash of the public key contained within this certificate

Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
105

Starfield CP-CPS v5.01

10.5.4 Starfield Secure Certificate Authority – G2 AND Starfield
Secure Extended Validation Code Signing CA – G2:
Subscriber Certificates
As of May 30, 2021, Starfield no longer issues High Assurance Code Signing Certificates,
however the following certificate profile was used for Starfield branded Subscriber Certificatesissued from the Starfield Secure Certificate Authority – G2 or the Starfield Secure Extended
Validation Code Signing CA – G2. At a minimum, the following fields were populated as
described, in accordance with IETF RFC 5280.
Field
Version
Serial Number
Signature
Algorithm
Identifier
IssuerValid From
Valid To
Subject

Subject (Extended
Validation
Certificates)

Subject Public
Key Information
Extensions:
Basic Constraints(critical)
Extended Key
Usage
Key Usage(critical)
CRL Distribution
PointsCertificate
Policies

Description
V3
unique value for each certificate issued by the Issuing CA
sha256RSA (OID: 1.2.840.113549.1.1.11)

Subject of corresponding Issuing CA certificate
Date and time of Certificate issuance
A date up to 39 months after Certificate issuance
CN = Subscriber's organization name
O = Subscriber’s organization name
L = City/town
S = State
C = Country
O = Subscriber’s full legal organization name. An assumed name or DBA may also be
included
L = City/town of place of businessS = State of place of business
C = Country of place of businessserialNumber= Registration number assigned by incorporating authority or date ofincorporation or registration
businessCategory=vetting category used to issue certificate as defined in the
CA/Browser Forum Guidelines for the Issuance and Management of Extended
Validation CertificatesjurisdictionLocalityName= City/town of incorporation or registration (if applicable)
jurisdictionStateOrProvinceName= State of incorporation or registration (if applicable)
jurisdictionCountryName= Country of incorporation or registration
RSA (2048 bits or greater)

Subject Type=End Entity
Path Length Constraint=None
Code Signing (1.3.6.1.5.5.7.3.3)
Optional: Kernel Mode Code Signing (1.3.6.1.4.1.311.61.1.1)
Digital Signature
CRL Distribution Point
Distribution Point Name:
Full Name:
URL = <current CRL URI>
The specific URI will vary depending on certificate type and CRL scope.
[1]Certificate Policy:
Policy Identifier=2.16.840.1.114414.1.7.23.2[1,1]Policy Qualifier Info:
Policy Qualifier Id=CPS
Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
106

Starfield CP-CPS v5.01

Certificate
Policies (Extended
Validation
Certificates)

Authority
Information
AccessAuthority Key
Identifier
Subject Key
Identifier

Qualifier:
http://certificates.starfieldtech.com/repository/[2]Certificate Policy:
Policy Identifier=2.23.140.1.4.1[1]Certificate Policy:
Policy Identifier=2.16.840.1.114414.1.7.24.3[1,1]Policy Qualifier Info:
Policy Qualifier Id=CPS
Qualifier:
http://certificates.starfieldtech.com/repository/[2]Certificate Policy:
Policy Identifier=2.23.140.1.3[1]Authority Info Access
Access Method=On-line Certificate Status Protocol (1.3.6.1.5.5.7.48.1)
Alternative Name:
URL=http://ocsp.starfieldtech.com[2] Authority Info Access
Access Method=Certification Authority Issuer (1.3.6.1.5.5.7.48.2)
Alternative Name:
URL=http://certificates.starfieldtech.com/repository/gdig2.crt
SHA-1 hash of the public of the corresponding Issuing CA
SHA-1 hash of the public key contained within this certificate

Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
107

Starfield CP-CPS v5.01

11 APPENDIX B: TEST SITESThe URL’s for test sites can be found in the table below.
CA
GoDaddy
GoDaddy G2
Starfield
Starfield G2
Starfield
Services

Valid
https://valid.gdi.catest.go
daddy.com
https://valid.gdig2.catest.
godaddy.com
https://valid.sfi.catest.star
fieldtech.com
https://valid.sfig2.catest.s
tarfieldtech.com

Revokedhttps://revoked.gdi.catest.godaddy.com
https://revoked.gdig2.catest.goda
ddy.comhttps://revoked.sfi.catest.starfieldtech.com
https://revoked.sfig2.catest.starfie
ldtech.com

Expiredhttps://expired.gdi.catest.godaddy.com
https://expired.gdig2.catest.goda
ddy.comhttps://expired.sfi.catest.starfieldt
ech.comhttps://expired.sfig2.catest.starfie
ldtech.com
https://expired.sfs.catest.starfieldtech.com

Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
108

Starfield CP-CPS v5.01

Copyright © 2004-2024 Starfield Technologies, LLC All rights reserved.
109

Starfield CP-CPS v5.01