Chevron Intranet Certification Authority G2 v1pki.chevron.com/policy/Chevron PKI Certification Authority G2 v1.pdf · COMPANY CONFIDENTIAL Chevron Public Key Infrastructure Certification

COMPANY CONFIDENTIAL

Chevron Public Key Infrastructure

Certification Authority G2

Set of Provisions

Version 1.0

Revised: February 12, 2019

Contents

© 2019 Chevron U.S.A. Inc. All rights reserved.


Chevron PKI Certification Authority G2 (Revised: February 12, 2019) ii

Contents

1 Introduction ............................................................................................. 1

1.1 Overview ........................................................................................................ 1

1.2 Document Name and Identification ............................................................. 4

1.3 PKI Participants ............................................................................................ 4

1.3.1 Certification Authorities ............................................................................. 4 1.3.1.1 Chevron Root CA ....................................................................................... 4 1.3.1.2 Chevron Issuing Certification Authorities ................................................... 4

1.3.2 Registration Authorities............................................................................. 5

1.3.3 Subscribers ................................................................................................. 5

1.3.4 Relying Parties ........................................................................................... 5

1.3.5 Other Participants ...................................................................................... 5

1.4 Certificate Usage .......................................................................................... 5

1.4.1 Appropriate Certificate Uses ..................................................................... 6

1.4.2 Prohibited Certificate Uses ........................................................................ 6

1.5 Policy Administration ................................................................................... 6

1.5.1 Organization Administering the Document ............................................. 6

1.5.2 Contact Person ........................................................................................... 6

1.5.3 Person Determining SoP Suitability for the Policy ................................. 6

1.5.4 SoP Approval Procedure ........................................................................... 7

1.6 Definitions and Acronyms ........................................................................... 7

2 Publication and Repository Responsibilities ..................................... 14

2.1 Repositories ................................................................................................ 14

2.2 Publication of Certification Information ................................................... 14

2.3 Time or Frequency of Publication ............................................................. 14

2.4 Access Control on Repositories ............................................................... 14

3 Identification and Authentication ........................................................ 15

3.1 Naming ........................................................................................................ 15

3.1.1 Types of Names ........................................................................................ 15

3.1.2 Need for Names to be Meaningful ........................................................... 15

3.1.3 Anonymity or Pseudonymity of Subscribers ......................................... 15

3.1.4 Rules for Interpreting Various Name Forms .......................................... 15

3.1.5 Uniqueness of Names .............................................................................. 15

3.1.6 Recognition, Authentication, and Role of Trademarks ......................... 15

3.2 Initial Identity Validation ............................................................................ 16

3.2.1 Method to Prove Possession of Private Key ......................................... 16

3.2.2 Authentication of Organization Identity ................................................. 16

3.2.3 Authentication of Individual Identity ...................................................... 16 3.2.3.1 Authentication for Role-based Client Certificates .................................... 17


Chevron PKI Certification Authority G2 (Revised: February 12, 2019) iii

3.2.3.2 Authentication for Group Client Certificates ............................................. 17 3.2.3.3 Authentication of Devices ........................................................................ 18 3.2.3.4 Authentication of SSL/TLS Web Services and Applications .................... 18

3.2.4 Non-Verified Subscriber Information ...................................................... 18

3.2.5 Validation of Authority ............................................................................. 18

3.2.6 Criteria for Interoperation ........................................................................ 18

3.3 Identification and Authentication for Rekey Requests ............................ 18

3.3.1 Identification and Authentication for Routine Rekey ............................ 18

3.3.2 Identification and Authentication for Rekey After Revocation ............ 19

3.4 Identification and Authentication for Revocation Requests ................... 19

4 Certificate Life Cycle Operational Requirements ............................... 20

4.1 Certificate Application ............................................................................... 20

4.1.1 Who Can Submit a Certificate Application ............................................. 20

4.1.2 Enrollment Process and Responsibilities .............................................. 20

4.1.3 Life Cycle Requirements for Manually-Enrolled Device Certificates ... 20 4.1.3.1 Certificate Application for Manually-Enrolled Device Certificates ............ 20

4.1.4 Life Cycle Requirements for Auto-Enrolled Device Certificates .......... 20 4.1.4.1 Certificate Application for Auto-Enrolled Device Certificates ................... 21

4.2 Certificate Application Processing ........................................................... 21

4.2.1 Performing Identification and Authentication Functions ..................... 21

4.2.2 Approval or Rejection of Certificate Applications ................................. 21

4.2.3 Time to Process Certificate Applications ............................................... 21

4.3 Certificate Issuance .................................................................................... 21

4.3.1 Certificate Issuance for Manually Enrolled Device Certificates ........... 21

4.3.2 Certificate Issuance for Auto-Enrolled Device Certificates .................. 22

4.3.3 Notification to Subscriber by the CA of Issuance of Certificate .......... 22

4.4 Certificate Acceptance ............................................................................... 22

4.4.1 Certificate Acceptance for Manually Enrolled Device Certificates ...... 22

4.4.2 Certificate Acceptance for Auto-Enrolled Device Certificates ............. 22

4.4.3 Publication of the Certificate by the CA ................................................. 22

4.5 Key Pair and Certificate Usage .................................................................. 22

4.5.1 Key Pair and Certificate Usage for Manually-Enrolled Device Certificates ......................................................................................................... 22

4.5.2 Key Pair and Certificate Usage for Auto-Enrolled Device Certificates 23

4.5.3 Subscriber Private Key and Certificate Usage ...................................... 23

4.5.4 Relying Party Public Key and Certificate Usage ................................... 23

4.6 Certificate Renewal .................................................................................... 23

4.7 Certificate Rekey ........................................................................................ 23

4.7.1 Certificate Rekey for Manually-Enrolled Device Certificates ............... 24

4.7.2 Certificate Rekey for Auto-Enrolled Device Certificates ....................... 24

4.8 Certificate Modification .............................................................................. 24


Chevron PKI Certification Authority G2 (Revised: February 12, 2019) iv

4.9 Certificate Revocation and Suspension ................................................... 24

4.9.1 Circumstances for Revocation ................................................................ 24

4.9.2 Who Can Request Revocation ................................................................ 25

4.9.3 Certificate Revocation for Human/Client Certificates ........................... 25

4.9.4 Certificate Revocation and Suspension for Device Certificates .......... 26

4.9.5 Revocation Request Grace Period .......................................................... 26

4.9.6 Time Within Which CA Must Process the Revocation Request ........... 26

4.9.7 CRL Issuance Frequency......................................................................... 26

4.10 Certificate Status Services ...................................................................... 26

4.11 End of Subscription.................................................................................. 26

4.12 Key Escrow and Recovery ....................................................................... 26

5 Facility, Management, and Operational Controls ............................... 27

5.1 Physical Controls ....................................................................................... 27

5.1.1 Site Location and Construction .............................................................. 27

5.1.2 Physical Access ....................................................................................... 27

5.1.3 Power and Air Conditioning .................................................................... 27

5.1.4 Water Exposures ...................................................................................... 27

5.1.5 Fire Prevention and Protection ............................................................... 27

5.1.6 Media Storage ........................................................................................... 28

5.1.7 Waste Disposal ......................................................................................... 28

5.1.8 Off-Site Backup ........................................................................................ 28

5.2 Procedural Controls ................................................................................... 28

5.2.1 Trusted Roles ........................................................................................... 28

5.2.2 Number of Persons Required per Task .................................................. 29

5.2.3 Identification and Authentication for Each Role ................................... 29

5.2.4 Roles Requiring Separation of Duties .................................................... 29

5.3 Personnel Controls .................................................................................... 29

5.3.1 Qualifications, Experience, and Clearance Requirements ................... 29

5.3.2 Background Check Procedures .............................................................. 30

5.3.3 Training Requirements ............................................................................ 30

5.3.4 Retraining Frequency and Requirements .............................................. 30

5.3.5 Job Rotation Frequency and Sequence ................................................. 30

5.3.6 Sanctions for Unauthorized Actions ...................................................... 31

5.3.7 Independent Contractor Requirements .................................................. 31

5.3.8 Documentation Supplied to Personnel .................................................. 31

5.4 Audit Logging Procedures ......................................................................... 31

5.4.1 Types of Events Recorded ...................................................................... 31

5.4.2 Frequency of Processing Log ................................................................. 35

5.4.3 Retention Period for Audit Log ............................................................... 35

5.4.4 Protection of Audit Log ............................................................................ 35


Chevron PKI Certification Authority G2 (Revised: February 12, 2019) v

5.4.5 Audit Log Backup Procedures ................................................................ 35

5.4.6 Audit Collection System (Internal vs. External) ..................................... 36

5.4.7 Notification to Event Causing Subject ................................................... 36

5.4.8 Vulnerability Assessments ...................................................................... 36

5.5 Records Archival ........................................................................................ 36

5.5.1 Types of Records Archived ..................................................................... 36

5.5.2 Retention Period for Archive ................................................................... 36

5.5.3 Protection of Archive ............................................................................... 36

5.5.4 Archive Backup Procedures.................................................................... 36

5.5.5 Requirements for Time-Stamping of Records ....................................... 36

5.5.6 Archive Collection System (Internal vs. External) ................................. 37

5.5.7 Procedures to Obtain and Verify Archive Information .......................... 37

5.6 Key Changeover ......................................................................................... 37

5.7 Compromise and Disaster Recovery ........................................................ 37

5.7.1 Incident and Compromise Handling Procedures .................................. 37

5.7.2 Computing Resources, Software, and/or Data Are Corrupted ............. 37

5.7.3 Entity Private Key Compromise Procedures ......................................... 38

5.7.4 Business Continuity Capabilities after a Disaster ................................. 38

5.8 CA or Registration Authority Termination ................................................ 38

6 Technical Security Controls ................................................................. 39

6.1 Key Pair Generation and Installation ........................................................ 39

6.1.1 Key Pair Generation ................................................................................. 39 6.1.1.1 Issuing CA ................................................................................................ 39 6.1.1.2 End Entity Key Pair Generation ............................................................... 39

6.1.2 Private Key Delivery to Subscriber ......................................................... 39 6.1.2.1 Intranet Issuing CA .................................................................................. 39 6.1.2.2 End Entities .............................................................................................. 40

6.1.3 Public Key Delivery to Certificate Issuer ................................................ 40

6.1.4 CA Public Key Delivery to Relying Parties ............................................. 40

6.1.5 Key Sizes ................................................................................................... 40

6.1.6 Public Key Parameters Generation and Quality Checking ................... 40

6.1.7 Key Usage Purposes ................................................................................ 41

6.2 Private Key Protection and Cryptographic Module Engineering Controls ........................................................................................................................... 41

6.2.1 Cryptographic Module Standards and Controls .................................... 41

6.2.2 Private Key (M of N) Multi-Person Control ............................................. 41

6.2.3 Private Key Escrow .................................................................................. 41

6.2.4 Private Key Backup .................................................................................. 42

6.2.5 Private Key Archival ................................................................................. 42

6.2.6 Private Key Transfer into or from Cryptographic Module .................... 42

6.2.7 Private Key Storage on Cryptographic Module ..................................... 42


Chevron PKI Certification Authority G2 (Revised: February 12, 2019) vi

6.2.8 Method of Activating Private Key ........................................................... 42 6.2.8.1 End User Keys ......................................................................................... 42 6.2.8.2 Code Signing Keys .................................................................................. 42 6.2.8.3 Device Certificate with Manual Enrollment .............................................. 42 6.2.8.4 Device Certificate with Auto-Enrollment .................................................. 43

6.2.9 Method of Deactivating Private Key ....................................................... 43

6.2.10 Method of Destroying Private Key ........................................................ 43

6.2.11 Cryptographic Module Rating ............................................................... 43

6.3 Other Aspects of Key Pair Management ................................................... 43

6.3.1 Public Key Archival .................................................................................. 43

6.3.2 Certificate Operational Periods and Key Pair Usage Periods .............. 43

6.4 Activation Data ........................................................................................... 44

6.4.1 Activation Data Generation and Installation .......................................... 44

6.4.2 Activation Data Protection ....................................................................... 44

6.4.3 Other Aspects of Activation Data ........................................................... 44

6.5 Computer Security Controls ...................................................................... 44

6.5.1 Specific Computer Security Technical Requirements .......................... 44

6.5.2 Computer Security Rating ....................................................................... 44

6.6 Life Cycle Technical Controls ................................................................... 44

6.6.1 System Development Controls ............................................................... 44

6.6.2 Security Management Controls ............................................................... 45

6.6.3 Life Cycle Security Controls.................................................................... 45

6.7 Network Security Controls ......................................................................... 45

6.8 Time-Stamping ............................................................................................ 45

7 Certificate, CRL, and OCSP Profiles ................................................... 46

7.1 Certificate Profile ........................................................................................ 46

7.1.1 Name Forms .............................................................................................. 46

7.1.2 Certificate Formats ................................................................................... 46 7.1.2.1 Chevron Root CA G2 (Trust Anchor) ....................................................... 46 7.1.2.2 Chevron Intermediate CAs....................................................................... 47 7.1.2.3 Chevron Issuing CAs ............................................................................... 48 7.1.2.4 Chevron End Entity Identity Certificates .................................................. 48 7.1.2.5 Chevron End Entity Signing Certificates .................................................. 49 7.1.2.6 Chevron End Entity Encryption Certificates ............................................. 50 7.1.2.7 Chevron End Entity Dual-Key Signing and Encryption Certificates ......... 50 7.1.2.8 Chevron Content Signer Certificate ......................................................... 51 7.1.2.9 Chevron Code Signer Certificate ............................................................. 52 7.1.2.10 Device/Server/SSL-TLS Certificate ....................................................... 52 7.1.2.11 Short-Lived SSL/TLS Certificates for Cloud .......................................... 53

7.1.3 Extended Key Usage ................................................................................ 54

7.2 CRL Profile .................................................................................................. 56

7.3 OCSP Profile ............................................................................................... 56

8 Compliance Audit and other Assessments ........................................ 57

8.1 Frequency or Circumstances of Assessment .......................................... 57


Chevron PKI Certification Authority G2 (Revised: February 12, 2019) vii

8.2 Identity/Qualifications of Assessor ........................................................... 57

8.3 Assessor’s Relationship to Assessed Entity ........................................... 57

8.4 Topics Covered by Assessment ............................................................... 57

8.5 Actions Taken as a Result of Deficiency .................................................. 58

8.6 Communication of Results ........................................................................ 58

9 Other Business and Legal Matters ...................................................... 59

9.1 Fees ............................................................................................................. 59

9.2 Financial Responsibility ............................................................................. 59

9.2.1 Insurance Coverage ................................................................................. 59

9.2.2 Other Assets ............................................................................................. 59

9.2.3 Insurance or Warranty Coverage for End Entities ................................ 59

9.3 Confidentiality of Business Information ................................................... 59

9.3.1 Scope of Confidential Information .......................................................... 59

9.3.2 Information Not Within the Scope of Confidential Information ............ 59

9.3.3 Responsibility to Protect Confidential Information ............................... 60

9.4 Privacy of Personal Information ................................................................ 60

9.4.1 Privacy Plan .............................................................................................. 60

9.4.2 Information Treated as Private ................................................................ 60

9.4.3 Information Not Deemed Private ............................................................. 60

9.4.4 Responsibility to Protect Private Information ....................................... 60

9.4.5 Notice and Consent to Use Private Information .................................... 60

9.4.6 Disclosure Pursuant to Judicial or Administrative Process ................ 60

9.4.7 Other Information Disclosure Circumstances ....................................... 60

9.8 Intellectual Property Rights ....................................................................... 61

9.9 Representations and Warranties ............................................................... 61

9.9.1 CA Representations and Warranties ...................................................... 61

9.9.2 Registration Authority Representations and Warranties ..................... 61

9.9.3 Subscriber Representations and Warranties ......................................... 61

9.9.4 Relying Party Representations and Warranties .................................... 61

9.9.5 Representations and Warranties of Other Participants ........................ 62

9.10 Disclaimers of Warranties ........................................................................ 62

9.11 Limitations of Liability .............................................................................. 62

9.12 Indemnities ................................................................................................ 62

9.13 Term and Termination .............................................................................. 62

9.13.1 Term ......................................................................................................... 62

9.13.2 Termination ............................................................................................. 62

9.13.3 Effect of Termination and Survival ....................................................... 62

9.14 Individual Notices and Communications with Participants .................. 62

9.15 Amendments ............................................................................................. 63


Chevron PKI Certification Authority G2 (Revised: February 12, 2019) viii

9.15.1 Procedure for Amendment .................................................................... 63

9.15.2 Notification Mechanism and Period ...................................................... 63

9.15.3 Circumstances Under which OID Must be Changed ........................... 63

9.16 Dispute Resolution Provisions ................................................................ 63

9.17 Governing Law .......................................................................................... 64

9.18 Compliance with Applicable Law ............................................................ 64

9.19 Miscellaneous Provisions ........................................................................ 64

9.19.1 Entire Agreement.................................................................................... 64

9.19.2 Assignment ............................................................................................. 64

9.19.3 Severability ............................................................................................. 64

9.19.4 Enforcement (Attorneys’ Fees and Waiver of Rights) ........................ 64

9.19.5 Force Majeure ......................................................................................... 65

9.20 Other Provisions ....................................................................................... 65

9.20.1 Conflict of Provisions ............................................................................ 65

9.20.2 Limitation Period on Actions ................................................................. 65


Chevron Intranet Certification Authority G2 (Revised: April 9, 2018)

1

1 Introduction

1.1 Overview

This combined Certificate Policy (CP) and Certification Practices Statement (CPS) or

Set of Provisions (SoP), written in accordance with the RFC 3647 framework, defines the requirements applicable to the Certification Authority(ies) (CA) within the Public

Key Infrastructure (PKI) operated by Chevron U.S.A. Inc. (Chevron) and its affiliates.

This SoP defines a Chevron PKI for use solely by Chevron, Chevron employees, Chevron contractors, joint venture employees, and joint venture contractors. Persons

or entities outside Chevron are not authorized to receive or rely on certificates issued within the Chevron PKI except as provided by separate written agreement, that is a

Relying Party Agreement or Subscriber Agreement, with Chevron. The Chevron PKI is hierarchical in form with a single Root and Issuing CAs that are subordinate to that

Root. These CAs are collectively known as the Chevron PKI Domain G2. The term “G2” refers to the Root CA having a signature hash of SHA2, and the fact that this

PKI represents Chevron’s move from a private internally managed CA infrastructure

to using a PKI service provider (currently DigiCert Managed PKI) (the PKI Service Provider) to host the CA infrastructure. The relationships among the CAs are

illustrated in Figure 1, although this illustration only represents the initial configuration in production at this writing and is not completely illustrative of the

future configuration. The Chevron Root CA G2 and the Chevron Issuing CAs share a common SoP.

Any subordinate Chevron Issuing CA is referred to as Issuing CA further in this document unless stated otherwise.

Figure 1. Relationships among Chevron Certification Authorities

The governing bodies of this PKI are the Chevron Policy Management Authority (PMA), the Chevron Policy Authority (PA), the Chevron Identity Management and

Architecture Authority (IMAA), and the Chevron General Manager of Information Risk Strategy and Management (GM-IRSM). The PMA, PA, IMAA, and GM-IRSM will be

staffed from within Chevron. The PMA will consist of one or more members from the Chevron Council of Chief Information Officers (CIOs), the PA, IMAA, and GM-IRSM.

The relationships are illustrated in Figure 2.

Chevron Root CA G2

Chevron Intranet CA-1


Chevron PKI Certification Authority G2 (Revised: February 12, 2019) 2

Chevron Root CA G2 and Chevron Issuing CAs are managed by and hosted at the PKI Service Provider’s PKI Data Center site. The PKI Service Provider manages the

Chevron CA infrastructure according to the PKI Service Provider’s CP/CPS and sections 5 and 6 of this SoP and provides PKI services to Chevron entities as

software as a service (SaaS).

Figure 2. Chevron PKI

The PMA is the broad policymaker with enterprise-wide oversight authority for the

overall operation of the Chevron PKI. Its responsibilities include, but are not limited to:

• Approving the SoPs for CAs.

• Approving trust relationships with Bridge Certification Authorities (BCAs).

• Exercising oversight authority for the PKI as a whole.

• Appointing the PA and IMAA.

• Reviewing the reports of the auditors regarding the PKI.

• Approving new CA hierarchy changes.

• Approving major PKI design changes.

The PA is responsible for reviewing:

• The legal and contractual aspects of the SoP documents for Chevron.

• The legal and contractual aspects of any Cross-Certification Agreements with

external CAs.

• Any agreements with BCAs.

• The SoP documents to ensure consistency.

The IMAA is responsible for:

• Operating the PKI in accordance with approved documents.

• Ensuring that certificates are issued in accordance with the respective

documents.



• Providing technical guidance regarding those documents.

• Creating facilities and a management structure consistent with the SoPs.

• Overseeing the operations of the PKI.

• Developing a business continuity plan for the PKI.

The GM-IRSM is responsible for:

• Advising the PMA on information security and PKI-related issues.

• Ensuring that PKI operations conforms to Chevron’s security policy and

standards.

The relationships among the Chevron PKI Domain G2, End Entities and Relying Parties are governed by the terms and conditions in the following documents, where

applicable:

• Chevron Intranet Set of Provisions

• Cross-Certification Agreements

• Bridge Certification Agreements

• Relying Party Agreements

• Subscriber Agreements.

Issuing CAs may issue certificates to individuals and devices for several purposes

including but not limited to the list in section 1.4.

None of the Issuing CAs will issue subordinate CA certificates.



1.2 Document Name and Identification

This document is called the “Chevron PKI CA G2 Set of Provisions.” The Object Identifier (OID) for this SoP is 1.3.6.1.4.1.6646.114176.37.2.1.20.1.

This SoP is represented by an OID, which is a numeric string contained in each certificate issued by this Intranet Issuing CA. Also, pursuant to RFC 5280, the

policyQualifierInfo field may contain the Uniform Resource Identifier (URI) of this SoP. To ensure interoperability and uniqueness of that OID for customers, Chevron

has registered the OIDs following the procedures specified in ISO/IEC and ITU

standards.

Chevron U.S.A. Inc. is registered as 1.3.6.1.4.1.6646.

This SoP has been assigned a unique OID subordinate to the Chevron OID, having a root of 1.3.6.1.4.1.6646.114176.37.2.1.20.x, where x began at 1 and is incremented

by 1 for each revision of the Chevron Issuing CA SoP.

1.3 PKI Participants

The Chevron PKI accommodates a worldwide, public and widely distributed community of wired and wireless users with diverse needs for communications and

information security.

This SoP discusses a Chevron PKI Domain G2 illustrated in Figure 1. Additional CAs

may be added later. The entities participating in the Chevron PKI are the Chevron Root CA, the Issuing CAs, the Subscribers of the Root, and Relying Parties. Except as

expressly authorized by separate agreement with Chevron, no person or entity outside Chevron shall have any rights or obligations under this SoP.

1.3.1 Certification Authorities

Where necessary, this SoP distinguishes the different users and roles accessing the CA functions. Where this distinction is not required, the term “Certification Authority”

is used to refer to the total Certification Authority entity, including the software,

hardware and its operations.

1.3.1.1 Chevron Root CA

The Certification Authority that:

• Creates, signs, distributes, and revokes CA and Cross Certificates, as

appropriate, binding the X.509 version 3 Distinguished Name of the Subordinate Issuing CA with its respective private signature verification key

and its public encryption key. The Chevron Root CA does not issue end entity certificates.

• Promulgates certificate status through Certificate Revocation Lists (CRLs).

• Designs, implements, and operates its certification practices to reasonably

achieve the requirements of the SoP.

1.3.1.2 Chevron Issuing Cert i f icat ion Authori t ies

Within the Chevron PKI there are multiple Issuing CAs, each subordinate to the Chevron Root CA G2. Each Issuing CA is regulated by this SoP. Each Issuing CA:



• Creates, signs, distributes, and revokes certificates binding the X.509 version 3 Distinguished Name of Subscribers with its respective private signature

verification key and its public encryption key.

• Promulgates certificate status through CRLs distributed by Hypertext Transfer

Protocol (HTTP). The Chevron PKI may also distribute certificate status through Online Certificate Status Protocol (OCSP).

• Designs, implements, and operates its certification practices to reasonably achieve the requirements of this SoP.

1.3.2 Registration Authorities

Chevron end entity registration services are responsible for verifying the identity of

end entities that have applied for certificates.

1.3.3 Subscribers

The Chevron PKI may issue certificates to Web servers, Applications, employees,

computers, servers and other network devices.

1.3.4 Relying Parties

A Relying Party is an individual or software agent that relies on the data within a

certificate in making decisions.

Except as expressly authorized by separate agreement with Chevron, no person or

entity outside Chevron shall be considered a Relying Party.

1.3.5 Other Participants

No stipulation.

1.4 Certificate Usage

This SoP is applicable to certificates issued by the Chevron Issuing CAs for:

• Applications that use SSL/TLS like certificates (devices)

• Authentication (individuals or devices)

• CA/Trusted Role Authentication

• Code Signing (individuals)

• Computers (devices)

• Data Recovery Agent (individuals)

• Digital Signature (individuals)

• Email/File Encryption (individuals)

• Internet Protocol Security (IPSec) (devices)

• Kerberos Authentication (devices)

• Key Recovery Agent (individuals)

• Mobile Device (individual device)

• Network Devices (devices)



• VPN Server (devices)

• Web Server (SSL/TLS) (devices)

• Wi-Fi Server (devices)

1.4.1 Appropriate Certificate Uses

In general, certificates can be used for establishing privacy or integrity for

applications containing sensitive data such as, but not limited to:

• Information provided to Chevron or affiliates by its business partners under a

non-disclosure agreement.

• Geo-technical, marketing, product planning or other Chevron confidential or

restricted information.

• Non-public financial information.

• Personnel information including position, salary, benefits, and health.

• Legal records that are not public: litigation, contracts, and settlements.

• Electronic commerce transactions including EDI, email, and Web services.

Furthermore, certificates can be used for authenticating the end entity for securing access to applications and network resources.

These certificates are approved for use with the production Chevron IT infrastructure, which includes: Microsoft® desktop and server operating systems,

their associated Back Office servers and clients, and other applications contained

within the Global Information Link (GIL) workstation and server software image.

Section 4 of this SoP, which elaborates on the life cycle processes for each type of

end entity certificate, provides a more detailed explanation of the appropriate uses for each certificate type.

1.4.2 Prohibited Certificate Uses

All other applications not listed in this SoP as acceptable are expressly prohibited.

1.5 Policy Administration

1.5.1 Organization Administering the Document

The Chevron PA administers this SoP as part of the Set of Provisions adopted by the

Chevron PMA, and such policies may be amended from time to time.

1.5.2 Contact Person

Contact your Chevron Sponsor for questions regarding this policy. Your Chevron Sponsor will be able to submit your question on your behalf to the Chevron IT

Service Desk. A person from IT will be assigned to address the service request.

1.5.3 Person Determining SoP Suitability for the Policy

No stipulation.



1.5.4 SoP Approval Procedure

The Chevron PMA shall approve this SoP and any subsequent changes; see sections 9.10 and 9.12 for additional information.

1.6 Definitions and Acronyms

The terms and acronyms used in this PKI, but not necessarily in this SoP, are defined below; the source of a definition is cited when known. Note that certain technical

terms are case sensitive and may begin with a lowercase letter, for example, commonName.

ACS – Administrative Card Share is part of an administrator card set authorized to

participate in M of N administration of HSMs.

Activation data – Data values, other than keys, that are required to operate

cryptographic modules and that need to be protected, for example, a PIN, a passphrase, or a manually held key share. (RFC 3647)

Affiliate – A legal entity that controls, is controlled by, or is under common control with another legal entity.

AES – Advance Encryption Standard

AICPA – American Institute of Certified Public Accountants

Applicant – See Requestor.

Arc – A unique path from the root of the global OID registration tree to a particular node within that tree. Comprised of one or more sub-arcs.

ARL – Authority Revocation List, a CRL that lists revoked CA certificates.

ASN.1 – Abstract Symbolic Notation 1, a formal mathematical way of defining and

relating objects. Used in many RFCs and technical specifications.

Authorization code – A five-digit code that is used by the subscriber to authenticate

with the Help Desk. It is maintained by the subscriber in the corporate directory so that is it only known by the subscriber and may only be displayed by the Help Desk.

Global Badging Coordinator – A person acting in an LRA role (see LRA definition) who

verifies the identity of an individual.

Base CSP serial number – Each SmartBadge 2 smart card is assigned a unique

identifier called the base CSP serial number. Chevron Buildings Management performs a batch inventory process when the smart cards are received from the

manufacturer; during that process the base CSP serial number is randomly generated in GUID format.

Blocking – Violation of smart card security policies can result in the "blocking" of the smart card, rendering it inactive.

CA – Certification Authority.

CA-certificate – A certificate for one CA’s public key issued by another CA.

CCTV – Closed Circuit TV.

CDP – Certificate Revocation List Distribution Point.

Certificate Manager – A trusted role in Microsoft® CA Server that is authorized to

approve, deny, and revoke certificates.



Certification path – An ordered sequence of certificates which, together with the public key of the initial object in the path, can be processed to obtain that of the final

object in the path. (RFC 3647)

Certificate Policy (CP) – A named set of rules that indicate the applicability of a PKI

to a particular community and/or class of application with common security and/or trust requirements.

Certification Practices Statement (CPS) – A statement of the practices that a CA employs in issuing, managing, revoking, and renewing or rekeying certificates. (RFC

3647)

Chevron PKI Design Team – Persons who design the Chevron PKI who are also responsible for advanced technical support functions.

CMC – Certificate Management Messages over Cryptographic Message Syntax; a message format used to convey a request for one or more certificates to a

registration manager or certificate manager. See RFC 5272. Incorporates PKCS #7 and PKCS #10.

CMS – Card Management System; the system that acts as the Registration Authority and connects to the Issuing CAs to perform certificate issuance, revocation, and life

cycle management duties. The CMS may include servers at entity facilities that

securely connect to the CAs, and may have certificate and card issuance capabilities, together with card printing services, as applicable.

commonName (CN) – The Common Name attribute type specifies an identifier of an object. A Common Name is not a directory name, it is a (possibly ambiguous) name

by which the object is commonly known in some limited scope (such as an organization) and conforms to the naming conventions of the country or culture with

which it is associated. (Recommendation X.520)

CPA – Certified Public Accountant

CRL – Certificate Revocation List

Cross-certificate – A certificate issued to a CA by another CA to provide trusted interoperability and to support trust chaining (see Certification Path).

CSP – Cryptographic Service Provider; a Microsoft® term for an object that provides cryptographic services such as key pair generation. It can reside on the Windows®

operating system, a smart card, or an HSM.

CSR – Certificate Signing Request

CUID - During the manufacturing process, each SmartBadge is assigned its own unique Card Unit ID.

DES – Data Encryption Standard, a symmetric encryption algorithm.

DRP – Disaster Recovery Plan

DMZ – Demilitarized Zone; a portion of an organization’s network outside of the

Intranet but still under that organization’s management and control.

DN – Distinguished Name

End Entity (EE) – A subject of a certificate who is not a CA in the PKI.

FBCA – Federal Bridge Certification Authority



FIPS – Federal Information Processing Standards; developed by the United States Federal Government.

FIPS 140-1 and FIPS 140-2 – Standards for cryptographic modules. FIPS 140-2 has superseded FIPS 140-1.

GUID – An acronym for Globally Unique Identifier; a 128-bit number used to identify resources and is also known as Universal Unique ID (UUID-RFC 4122) in the serial

number of a certificate.

Hardware Security Module (HSM) – A hardware device designed to provide

cryptographic functions, especially the safekeeping of a private key.

HID – Hughes Intrusion Detection; a physical access control system based on induction powered microchips and radio frequency antennas.

HTTP – Hyper Text Transfer Protocol

HVAC – Heating, Ventilating, and Air Conditioning

IEC – International Electrotechnical Commission

IKE – Internet Key Exchange; see RFCs 7427, 7670, and 8247.

IMAA – Identity Management and Architectural Authority

Interim replacement SmartBadge – A SmartBadge used by the subscriber who has

either lost or damaged their SmartBadge and cannot get an immediate replacement.

IP champion – A representative of an operating company or reporting unit who has significant responsibilities for communicating Information Protection principles within

that reporting unit. Also, the IP champion confirms the status of IP compliance to the reporting unit officer for representation in the corporate compliance program.

IP Coordinator – Assist the IP champion and Information Protection groups in carrying out their responsibilities. IP Coordinators provide technical guidance,

education efforts, and project management to IP issues and compliance.

IPSEC – Internet Protocol Security

ISO – International Standards Organization

Issuer – The name of the CA that signs the certificate; a certificate attribute field.

Issuing Certification Authority (Issuing CA) – In the context of a particular certificate,

the Issuing CA is the CA that issued the certificate (see also Subject Certification Authority). (RFC 3647)

KGC – Key Generation Ceremony; the complex procedure for the generation of a CA’s private key.

LDAP – Lightweight Directory Access Protocol

Local Registration Authority (LRA) – Persons or systems that have been delegated

authority to perform a portion of the registration process by the Registration Agent.

For the Chevron PKI there will be three clearly defined LRA roles:

• Global Badging Coordinators who issue smart cards to individuals.

• Certificate Managers who will approve a device’s application for a certificate.

• SBAs who issue t-Cards.



Middleware – Computer software that connects software components or applications. Middleware is used to execute cryptographic functions on the smart card, such as

key pair generation, passing credentials from a smart card to a computer operating system, encryption, decryption, changing the PIN, and unblocking the card.

Modification – (Certificate Modification) the issuance of a certificate to replace an existing certificate due to change in a Subscriber’s information other than their public

key. For example, a change in an individual’s DN due to a change in name.

M of N – M is the minimum required of a known number. See also Secret Shares.

NIST – National Institute of Technology and Standards; a United States government

agency.

notAfter – The date and time after which a certificate expires; an attribute field.

Object – A program or data element, as in object-oriented programming.

Object Identifier (OID) – A unique numerical value (distinguishable from all other

such values) that is associated with an object (ITU-T X680). Often associates a PKI’s policies and/or level of assurance to a Relying Party as well as certificate attributes.

Referenced in many RFCs and used in the ASN.1 encoding of certificates.

OCS – Operator Card Set; authorized to participate in M of N activation of a CA’s

private keys and other highly secure cryptographic operations.

OCSP – Online Certificate Status Protocol (RFC 6960)

OTP - One-time password

PA – Policy Authority

Passphrase – An alphanumeric character string that can be easily remembered, and

frequently used to control access to a smart card; like a PIN or password but offering greater protection for the same length.

PIN – A Personal Identification Number, or alphanumeric password, used to protect the private keys on a smart card or ATM card.

PKCS #1 – The RSA Cryptography Standard; published by RSA Security. The RSA

algorithm.

PKCS #7 – Cryptographic Message Syntax Standard; used for distributing

certificates.

PKCS #10 – A standard for certificate requests; published by RSA Security.

PKCS #12 – Personal Information Exchange Syntax; published by RSA Security.

PKE – Public Key Enabling

PKI – Public Key Infrastructure

PKI Service Provider – An entity or affiliate that hosts CA(s), certificates, and online

repositories for hosting certificate status through CRL/OCSP services.

PMA – Policy Management Authority

Policy qualifier – Policy-dependent information that may accompany a CP identifier in

an X.509 certificate. (RFC 3647)

Registration Agent (RA) – A human entity that is responsible for identity proofing

certificate requestors and has certain duties and responsibilities for handling



certificate issuance, renewal, rekey and revocation, as well as verifying identity proofing conducted by LRAs.

Registration Authority (RA) – An entity that is responsible for one or more of the following functions: the identification and authentication of certificate requestors, the

approval or rejection of certificate applications, initiating certificate revocations or suspensions under certain circumstances, processing subscriber requests to revoke

or suspend their certificates, and approving or rejecting requests by subscribers to renew or rekey their certificates. RAs may sign end entity or device certificate

requests (for example, a Registration Authority is delegated certain tasks on behalf

of a CA). Note: The term Local Registration Authority (LRA) is sometimes used in other documents for the same concept. (RFC 3647) Also see LRA.

Rekey – (Certificate Rekey) ceasing use of a key pair and then generating a new unique key pair to replace it. The CA must certify the new public key. Rekey differs

from renewal where a previously generated key pair remains in use and only a new certificate is requested.

Relying Party – A recipient or consumer of a certificate who acts in reliance on that certificate and/or digital signatures verified by that certificate. In this document, the

terms "certificate user" and "Relying Party" are used interchangeably. (RFC 3647)

Relying Party Agreement (RPA) – An agreement between a certification authority and relying party that typically establishes the rights and responsibilities between those

parties regarding the verification of digital signatures or other uses of certificates. (RFC 3647)

Renewal – (Certificate Renewal) issuance of a new certificate to the subscriber that may have a new validity date, but without changing the subscriber’s or any other

participant’s public key or any other information in the certificate. (RFC 3647)

Repository – A system for storing and retrieving certificates or other information

relevant to certificates.

Requestor – An entity (see Users) who is requesting a certificate to be issued by submitting a certificate signing request (CSR).

RSA – The acronym for the inventors of the RSA algorithm - Ron Rivest, Adi Shamir, and Leonard Adleman.

RSA Security – A publicly held corporation listed on the New York Stock Exchange.

Safe Custodian – A trusted role in the Chevron PKI who is responsible for securing

sensitive PKI keying material in their safe.

Secret shares – A set of smart cards, PINs, and so on, used for M of N control (where

M is the appropriate multiple of Trusted Roles out of a known number of them) of a

CA’s private key. These smart cards differ from the smart cards that are issued to individuals.

Shareholder – An individual authorized to hold a secret share.

Security World – An nCipher framework that maps security policies onto a flexible

hardware-based security infrastructure. It provides for the total life cycle management of security-critical encryption keys.

Set of Provisions (SoP) – A collection of practice and/or policy statements, spanning a range of standard topics, for use in expressing a CP or CPS employing the

approach described in RFC 3647.



SID – Security Identifier; a logical security feature of the Microsoft® Windows® architecture.

S/MIME – Secure Multipurpose Internet Mail Extensions

SSL/TLS – Secure Sockets Layer/Transport Layer Security; both are secure transport

protocols where TLS is a successor of SSL.

Sponsor – An individual authorized by their management to enroll devices, or a

Chevron employee who endorses the subscriber by authorizing the SBA to submit an application.

SoP – Set of Provisions; a CP, CPS, or similar document that may follow the RFC

3647 “Framework.”

subjectAltName – A certificate attribute field that typically contains DNS names of

servers, URLs or the subject’s UPN or email address and is listed as an extension and formatted in accordance with approved certificate profiles.

Subscriber – A subject of a certificate and is accurately represented in the Subject field of the certificate. (RFC 3647)

Transport Layer Security (TLS) and its predecessor, Secure Sockets Layer (SSL) - cryptographic protocols designed to provide communication security over a computer

network.

Truncation – The policy of not issuing certificates with expiration dates later than that of the expiration date of the signing CA.

Trust Anchor – Valid paths begin with certificates issued by a trust anchor. Typically, the root CA in a PKI is the trust anchor.

Trusted Agent – An individual who is a Trusted Role, is assigned by and affiliated with the Chevron PKI, and performs identity proofing services for the Registration

Authority. TAs shall not have access to the CMS or CA to conduct certificate issuance, revocation or any other certificate life cycle management duties.

Trusted Role – Those individuals who perform a role such as M of N, that is critical to

the operation or integrity of this PKI.

Trusted Time Source – An extremely accurate clock, typically at NIST.

Trustworthy Systems – An operating system or certificate authority that complies with a designated design standard. This may refer to an internal Chevron standard or

a published external standard such as the Common Criteria or WebTrust.

UPN – User Principal Name; a unique name of a user account defined in a directory.

UPS – Uninterruptible Power Supply

URI – Universal Resource Identifier; a URL, FTP address, email address, and so on.

Users – In this SoP there are several different users identified, with all having

different roles, duties, responsibilities, and/or actions. In most uses in this SoP, the term “user” denotes a human subscriber/owner of a certificate. The broad term

“users” includes:

• Human entities (“users”)

• Device entities (including applications and services) (“devices”)

• System or service entities (services/systems/entities)



WebTrust – The WebTrust Principles and Criteria for Certification Authorities is a framework for Auditors to assess CAs against a known body of principles based on

ISO 21188.

X.500 – A recommendation promulgated by ITU/T for specifying directory service

and its protocols. It is a common standard for repositories.

X.509 – A public key certificate specification originally developed as part of the X.500

directory specification, often used in public key systems. Now effectively governed by IETF standards.

3DES – Triple DES; a symmetric encryption algorithm similar to DES, but much

stronger.



2 Publication and Repository Responsibilities

This PKI shall operate a Repository in which the SoP documents, certificates issued

to Subordinate CAs and end entities, and their respective CRLs and delta CRLs are stored.

2.1 Repositories

The PKI Service Provider operates a publicly hosted Repository for this PKI on behalf

of Chevron. The Repository is a logical construction and may be composed of several discrete servers providing their services through different Internet protocols such as

HTTP and OCSP. The PKI Service Provider repository is available 24 hours per day 7 days per week and its systems are described in more detail in section 5.

The PKI Service Provider repository includes the CRLs, certificate requests and certificates issued. Policies and practices are hosted by Chevron.

2.2 Publication of Certification Information

CA certificates, CRLs and delta CRLs are published in the Chevron Repository on the

Chevron Intranet via a web site/portal, with the URL included in the certificate details.

2.3 Time or Frequency of Publication

CRLs and delta CRLs issued by the Intranet Issuing CA are published in accordance with section 4 of this SoP.

2.4 Access Control on Repositories

The certificates, CRLs and delta CRLs published to the Chevron Repository will be

internally accessible from the Repository. Chevron IT has access controls to prevent anyone other than an authorized individual, authorized system proxy, or authorized

system agent from deleting, altering or updating the contents of the Repository.



3 Identification and Authentication

3.1 Naming

3.1.1 Types of Names

The certificates issued by Chevron Issuing CAs shall have the name Chevron in the

Organization field of the Issuing Authority and comply with the ITU X.500 standards.

The subject of Chevron PKI certificates must have an unambiguous Subject Name

that is either a:

• fully qualified distinguished name (FQDN) in Active Directory®,

• a common name in Active Directory®,

• or according to entity standard naming convention, as shown in section 7.1.

3.1.2 Need for Names to be Meaningful

All certificates issued by a Chevron PKI CA shall include an identifier that represents

the end entity to which each certificate was issued. For individuals, this identifier may not necessarily directly correspond to the subject’s legal name. For servers and

network devices, the name will be that which is assigned under Chevron’s policies for naming servers and devices.

3.1.3 Anonymity or Pseudonymity of Subscribers

This policy does allow for the use of pseudonymous names in certificates. Subscribers are not permitted to use pseudonyms.

3.1.4 Rules for Interpreting Various Name Forms

Distinguished Names in certificates conform to the ITU X.500 standards and ASN.1

syntax. RFC 4514 gives more details on how Distinguished Names are handled.

3.1.5 Uniqueness of Names

All certificates issued by this Intranet Issuing CA shall include a unique identifier that

represents the individual or device to which the certificate was issued. The Chevron PKI Issuing CAs shall take steps to ensure that each identifier is unique, so that no

two certificates within the Chevron PKI will have the same identifier for different individuals or devices. In the event of name collisions either the Chevron CMS or the

CA shall notify the requesting agent (Registration Agent/Automatic service) of the collision to fix the collision or automatically append information to the name to

resolve it.

3.1.6 Recognition, Authentication, and Role of Trademarks

The Chevron PKI issues certificates in accordance with the Chevron policy on Business Conduct and Ethics Code. No subscriber may request a certificate that

violates intellectual property rights of another entity.



3.2 Initial Identity Validation

The Chevron PKI may issue certificates to both humans and devices such as database servers and Web server SSL/TLS. To authoritatively identify those

requesting a certificate, Chevron may use any combination of online network communication, telephonetic communication, postal mail, and in-person id-proofing.

3.2.1 Method to Prove Possession of Private Key

Issuing CAs, prior to the issuance of an end entity certificate, require proof of possession of a private key before creating and signing a certificate containing the

associated public key. In the case of end user identity certificate requests, the

enrollment service will ensure that a key presented for identity validation has been issued by Chevron. In the case of device (applications or services) SSL/TLS

certificates, the end entity will generate either a CMC or PKCS #10 request. Such a request consists of three parts: certification request information, a signature

algorithm identifier, and the digital signature of the requestor on the certification request information. The end entity will forward the request to an Issuing CA directly

through an API to the PKI Service Provider’s Certificate Central portal, or through the Chevron CMS. That Issuing CA fulfills the request by authenticating the requesting

entity and verifying the entity’s signature and, if the request is valid, constructing an

X.509 certificate.

3.2.2 Authentication of Organization Identity

Chevron verifies the business unit of requestors who request device certificates such

as for SSL. The business unit within Chevron requesting an SSL/TLS certificate will have its affiliation verified through organization charts, HR or other internal sources

to be part of the Chevron business enterprise.

3.2.3 Authentication of Individual Identity

Each type of certificate has both a local and a remote authentication process. This

requires interaction with an Applicant and an authenticator who verifies the request. In the case of the local authentication process, the authenticator has face-to-face

contact with the subscriber. For the remote authentication process, the identity of

the requester can be validated via Chevron’s IAM services. Regardless of the process for identity verification, the following requirements shall be met:



Table 1. Identity Verification Requirements

Certificate Type ID Verification Process

SSL/TLS

The human sponsor for a Chevron business unit requesting an

SSL/TLS server certificate shall appear in-person before a Registration Agent and present a valid government photo identification, or, the human sponsor shall use his or her Chevron

email signing certificate to send a copy of his or her government photo identification in a digitally signed email from a Chevron domain

email account.

Device Certificates See section 3.2.3.3

Human Certificates Requestors who are Chevron employees, contractors, temporary

workers and supply chain partners who are eligible for a Chevron digital certificate shall prove identity through one of the following

methods:

In-Person - the requestor shall appear before a Registration Agent with one government issued photo identity document from the Federal Form I-9. The document shall be unexpired and have accurate name information on it matching the name of the requestor.

Chevron may electronically verify by record check the requestor

information on the document.

Remote - the requestor shall have a Chevron sponsor who can vouch

for the business need for the requestor to receive a credential. The Requestor shall email, postal mail, fax or hand deliver to the sponsor,

photographic copies of the requisite identity documents for In-Person proofing. The requestor's sponsor shall either hand deliver or digitally

sign an email with the requestor's identity document copies.

In-Person Antecedent - In the case of Chevron employees and contractors who were previously identity proofed during the hiring process with a proofing process that meets the requirements for In-

Person or Remote, the requestor may appear before the Registration Agent and re-validate identity using known attributes or shared

secrets.

3.2.3.1 Authenticat ion for Role -based Cl ient Cert i f icates

Any Chevron Trusted Role working in the Chevron PKI environment or in a capacity

of sensitivity to warrant this type of credential shall have his or her identity proofed

with one of the methods described in section 3.2.3.

3.2.3.2 Authenticat ion for Group Cl ient Cert i f icates

No stipulation.



3.2.3.3 Authenticat ion of Devices

The Chevron PKI requires a human sponsor to represent devices. The human sponsor is verified in accordance with the requirements in this section. The human

sponsor of a device or device enrollment service is responsible for informing the CA

of any change of sponsor status that removes the assigned sponsor from responsibility for the device. The human sponsor is also responsible for requesting

revocation of the device certificate when applicable.

3.2.3.4 Authenticat ion of SSL/TLS Web Services and Appl icat ions

The Chevron PKI allows for some web services and applications to conduct automatic authentication for SSL/TLS certificate issuance. In these cases, the device (server)

holding the service or application contains a pre-issued authentication certificate by which it can authenticate through a PKI Service Provider’s API to the PKI Service

Provider’s certificate issuance platform.

3.2.4 Non-Verified Subscriber Information

All Subscriber information given that is not verified will not be included in the

certificate, according to section 3.2.3.

3.2.5 Validation of Authority

The Registration Agent will confirm that the individual/sponsor making the request is

indeed an authorized administrator for the device. For auto-enrollment, Registration

Agent approval is automatic, if the enrollment service presented has a valid computer account.

For access to The PKI Service Provider’s portal system Chevron subscribers must prove representation of a Chevron business unit.

3.2.6 Criteria for Interoperation

No stipulation.

If at some time in the future interoperability with non-Chevron entities becomes a

business requirement, criteria for interoperation with this PKI will be determined by the PA and IMAA and approved by the PMA.

3.3 Identification and Authentication for Rekey Requests

Subscribers may request rekey of a certificate before the certificate has expired. The

Chevron PKI CA will create a new certificate with the same contents as the previous one, and a new public key based on CSR submitted by requester.

3.3.1 Identification and Authentication for Routine Rekey

The Subscriber is authenticated before rekey using the following means:

• They must authenticate themselves to the network using their credential

provided by the Chevron IAM.

• Username and password in accordance with service provider requirements

may allow for Issuing CA administrators.

• For device and SSL/TLS certificates, the device administrator or sponsor will authenticate themselves over a protected channel via authentication method



supported by the PKI Service Provider, or in the same manner as in section 3.2.3.

3.3.2 Identification and Authentication for Rekey After Revocation

Subscribers of certificates that have been revoked for any reason will undergo the same identity proofing process as described in section 3.2.3.

3.4 Identification and Authentication for Revocation Requests

Requests to revoke an end entity certificate must be presented to the Certificate Manager by an authorized requestor whose identity is verified according to certificate

type.

The details of who is authorized to request revocation for each type of end entity certificate, and the associated method of verification by the Certificate Manager are

described in section 4.9.



4 Certificate Life Cycle Operational Requirements

This section gives details on the different Chevron certificate models and their

respective life cycles.

4.1 Certificate Application

4.1.1 Who Can Submit a Certificate Application

Subscribers, Requestors and those who are authorized agents of requestors are

authorized to request certificates. An authorized agent is an individual who is

recognized by the Chevron PKI to have authority to request certificates.

4.1.2 Enrollment Process and Responsibilities

The enrollment process may include any of the following methods:

• Submitting a certificate application,

• Generating a key pair,

• Delivering the public key to Chevron,

• Agreeing to the applicable Subscriber Agreement,

• Paying any applicable fees, and

• Requestors are ultimately responsible for any data submitted in the certificate

request, including data submitted by an agent on behalf of the requestor.

4.1.3 Life Cycle Requirements for Manually-Enrolled Device Certificates

Manually-Enrolled Device Certificates are issued to devices that are used for hosting internal Chevron applications – applications that are accessible only by Chevron

employees and contractors. They are distinguished from other device certificates by two factors. First, the method of key pair generation uses a cryptographic service

provider that is local to the given device. Second, the enrollment process is manual,

where the device administrator composes a certificate application, submits it for approval, and may only install the certificate after it has been approved by the CA.

Some examples of the devices secured are web servers, VPN servers, and Exchange Instant Messaging servers.

4.1.3.1 Cert i f icate Appl icat ion for Manual ly -Enrol led Device Cert i f icates

The device’s administrator accesses an application or script that creates the key pair,

builds a request file that contains the device’s public key and subject name, and signs the request file with the device’s private key. Some devices require the

resultant certificate signing request (CSR) to be pasted to the PKI Service Provider portal and submit the request to the Certificate Manager for approval.

4.1.4 Life Cycle Requirements for Auto-Enrolled Device Certificates

Auto-Enrolled device certificates are issued to devices and web servers for SSL/TLS

that are used for hosting internal Chevron applications and web servers– applications that are accessible only by application owners. Certificate enrollment leverages the

PKI Service Provider’s REST (Representational State Transfer) API (Application Programming Interface). The PKI Service Provider’s REST API allows the application



owner to manage the entire life cycle of certificates, including: CSR submission, certificate issuance, renewal and revocation.

4.1.4.1 Cert i f icate Appl icat ion for Auto-Enrol led Device Cert i f ica tes

Auto-enrollment for a device certificate is made under the context of the local system

(computer) account.

An authorized administrator responsible for a device’s maintenance or on behalf of a

sponsor may configure auto-enrollment for Computer, Kerberos Authentication, IPSec (IKE intermediate), web server, and other device certificates. When auto-

enrollment is configured, the specified certificate types are issued automatically to all computers that are within the scope of the Public Key Group Policy and to all

computers that have “auto-enroll” permissions for that certificate type.

4.2 Certificate Application Processing

4.2.1 Performing Identification and Authentication Functions

Certificate Manager verifies the application details and other information in accordance with section 3.2. Once all information in the certificate request is

validated and satisfies the policy requirements, the certificate issuance can take place.

For SSL/TLS and device certificates, the sponsor or device administrator uses his or her credentials to access the PKI Service Provider’s Certificate Central services portal

to upload the CSR. The fact that a sponsor or administrator has credentials to the Certificate Central portal is proof of identity validation and this credential is issued in

conformance with section 3.2.5.

4.2.2 Approval or Rejection of Certificate Applications

The Chevron CA has the authority to approve or reject certificate application, if the CA believes that issuing the certificate will be detrimental to Chevron Business

priorities. Chevron Certificate Managers approve or reject certificate applications, including those requests going through the PKI Service Provider’s Certificate Central

portal.

4.2.3 Time to Process Certificate Applications

For human subscribers, such as for the Chevron Smart Badge issuance, time to

process certificate applications is covered in Service Level Agreements (SLA).

4.3 Certificate Issuance

Issuing CAs have established and automated procedures for processing and issuing certificates. Once an issuance is complete, the certificate data is stored in a database

and the certificates with the associated key pairs are sent to the Subscriber/Sponsor/Device.

4.3.1 Certificate Issuance for Manually Enrolled Device Certificates

The certificate application submitted by the Requester shall contain a CSR. The Certificate Manager accesses an enrollment application that submits the CSR to the

CA. The CA verifies the signature and syntactical correctness of the request, issues the certificate, and returns the completed certificate to the subscriber.



4.3.2 Certificate Issuance for Auto-Enrolled Device Certificates

The Issuing CA verifies the signature and syntactical correctness of the request, issues the certificate, and returns it to the device or auto-enrollment service that

submitted the request.

4.3.3 Notification to Subscriber by the CA of Issuance of Certificate

CAs operating under this policy shall inform the subscriber (or other certificate

subject) of the creation of a certificate and make the certificate available to the subscriber. For device certificates, the CA shall issue the certificate according to the

certificate requesting protocol used by the device (this may be automated) and, if the protocol does not provide inherent notification, also notify the authorized

organizational representative of the issuance (this may be in batch).

4.4 Certificate Acceptance

Subscribers are solely responsible for accepting and installing certificates.

4.4.1 Certificate Acceptance for Manually Enrolled Device Certificates

Device administrators install their completed certificate on their device by accessing

the email attachment or the URL they received from the Issuing CA or enrollment service. Unless they reject the certificate in a timely manner, by notifying the

Certificate Manager through the revocation process in section 4.9, they have been deemed to accept the certificate.

Device certificates are not published to the repository.

4.4.2 Certificate Acceptance for Auto-Enrolled Device Certificates

Device and SSL/TLS certificates that were auto-enrolled will have the requested certificate delivered to the device. The device shall validate the certificate came from

the correct issuing CA and validate the signature on the certificate before accepting the certificate.

Device certificates are not published to the repository.

4.4.3 Publication of the Certificate by the CA

The PKI Service Provider hosts the public keys of Chevron CA certificates in the PKI

Service Provider’s repository. End-user certificates, including Device certificates are stored in the Issuing CA repository and sent to them, or downloaded by the

Subscriber/Sponsor/Device, as applicable.

4.5 Key Pair and Certificate Usage

4.5.1 Key Pair and Certificate Usage for Manually-Enrolled Device Certificates

The device administrator responsible for a device may, after acceptance, use the private key and the corresponding certificate for only one or more of the purposes

specifically indicated within the key usage attribute in the certificate.



4.5.2 Key Pair and Certificate Usage for Auto-Enrolled Device Certificates

The device administrator responsible for a device may, after acceptance, use the private key and the corresponding certificate for only one or more of the purposes

specifically indicated within the key usage attribute in the certificate.

4.5.3 Subscriber Private Key and Certificate Usage

Human Subscribers of certificates issued by the Chevron PKI are obligated by the

new hire and annual training agreements to protect the private key of their digital certificates. Subscribers are told to remember and not reveal the card PIN.

Subscribers are to stop using these certificates upon knowledge of compromise, expiration, or revocation of the certificates. Subscribers are to only use the

certificates in accordance with the certificate purpose and policies, and Chevron

policy.

4.5.4 Relying Party Public Key and Certificate Usage

Currently the Chevron PKI is only for internal use and the only Relying Parties are

Chevron personnel and devices.

In future PKI operations that expand to cover supply chain partners and possible

other Trust Framework or cross-certified partners, Chevron recommends that Relying Parties use discretion and verify any certificate presented by following the Trust

Chain, checking the CRL, and verifying the certificate policies. Chevron makes no warrants or guarantees regarding certificates presented to a Relying Party.

4.6 Certificate Renewal

Renewing a certificate means creating a new certificate with the same name, key

and other information as the old one, but with a new extended validity period and a new serial number. The old certificates may or may not be revoked but must not be

further rekeyed, renewed or updated.

Device certificates may be renewed with a Certificate Manager’s approval.

Chevron may renew a non-device certificate under the following conditions:

• The certificate’s public key has not expired,

• There is no change needed in biographic and biometric data in the certificate,

and

• The private key has not been compromised.

Only the certificate subject or authorized representative of the subject may request a certificate to be renewed.

Identity proofing for renewed certificates is the same as those described in section 3. If a human subscriber is requesting a certificate to be renewed, Chevron may choose

to verify the original identity information has not changed and issue the renewed certificate.

4.7 Certificate Rekey

Rekeying a certificate means creating a new public key, with associated serial

number and is only done in cases where no biographic data needs to be changed in the certificate.



A rekeyed certificate may have a new validity date, key identifiers, repository locations (see section 2.1) and signing key.

Only the certificate subject or authorized representative of the subject may request a certificate to be rekeyed.

Identity proofing for rekeyed certificates is the same as those described in section 3. If a human subscriber is requesting a certificate to be rekeyed, Chevron may choose

to verify the original identity information has not changed and issue the rekeyed certificate.

4.7.1 Certificate Rekey for Manually-Enrolled Device Certificates

The device administrator may decide to rekey at any time; however, the most

common case for rekey is when the certificate is near expiration. The device administrator is made aware of certificate expiration by a weekly email sent by the

CA that has a list of all device certificates due to expire within 60 days.

The processes and actions of all the related participants (device administrator,

authorized requestor, Certificate Manager, CA) for rekeying the device certificates are the same as initial enrollment.

4.7.2 Certificate Rekey for Auto-Enrolled Device Certificates

If there is any reason to rekey a device, the PKI Service Provider’s REST API supports rekey, and device administrators or sponsors may request the PKI Service

Provider to generate the new keys and to generate a request for a certificate

containing that new public key. Otherwise, the rekey process is identical to original certificate issuance.

4.8 Certificate Modification

Modifying a certificate means creating a certificate that has the same or new keys, along with changing certain biographic information such as email address or other

non-essential parts of objects and attributes in the certificate.

Device certificate modification is not permitted within this PKI.

Certificates issued to human subscribers may be modified at Chevron’s discretion. A

circumstance of changed name requires a new certificate and new public/private key pair to be generated.

Only the certificate subject may request a certificate to be modified.

4.9 Certificate Revocation and Suspension

4.9.1 Circumstances for Revocation

Revoking a certificate permanently ends the operational period of the certificate prior

to the end of the validity of the certificate. Before revoking a certificate, Chevron will verify the identity of the person requesting revocation to ensure that the person is

authorized to request the certificate to be revoked. Circumstances for revocation

include:

• The Subject or Subscriber of the certificate requests revocation,

• The Subscriber did not originally request the certificate to be issued and did not retroactively grant authorization,



• Either the certificate’s private key or the private key used to sign the certificate is found to be compromised,

• The Subscriber breached the terms and conditions of the Subscriber Agreement,

• The Subscriber, sponsor, or authorized agent that was issued the certificates has lost its rights to a name, trademark, device, IP address, domain name, or

other attribute that was associated with the certificate,

• The Subscriber or sponsor has lost his or her affiliation with the company that

the certificate was issued under,

• The certificate was not issued in accordance with this SoP,

• Chevron receives a lawful and binding order from a government or regulatory

body to revoke the certificate,

• Chevron or the PKI Service Provider ceases operations and did not arrange for

another CA to provide revocation support for the certificate,

• Any information appearing in the certificate was or becomes inaccurate or

misleading, or

• When a certificate with a duplicate name has been discovered.

4.9.2 Who Can Request Revocation

The Subscriber, any authorized agent of the Subscriber, a member of a Chevron

Trust Framework, or a cross-signed entity may request a certificate to be revoked. Chevron reserves the right to revoke certificates at its discretion. Third parties may

request certificates to be revoked for problems related to fraud, misuse, or compromise. Certificates may be revoked only on proper authentication of an

authorized person or entity and must specify the reason for revocation per section 4.9.1.

4.9.3 Certificate Revocation for Human/Client Certificates

For certificates issued to human entities, Chevron processes a certificate revocation request in the following manner:

• Chevron will log the identity of any entity making a certificate revocation

request, and may include its own reasons for revocation in the log,

• Chevron may request confirmation of a revocation from a known

administrative or authoritative source via out-of-band methods such as telephone, fax, and so on,

• For revocation requests from third parties, Chevron will investigate the request and decide whether to proceed with the revocation based on the

following criteria:

o The nature of the alleged problem,

o The number of reports received about a particular certificate or

website hosting a device certificate,

o The identity of the complainants, and

o Relevant legislation.



• Once Chevron validates that the revocation request is appropriate, Chevron Registration Agents will revoke the certificate and the CA will place the

certificate’s serial number on the CRL.

4.9.4 Certificate Revocation and Suspension for Device Certificates

The most common circumstances for revoking device certificates are when the device

is either being rebuilt or retired, or the website with an SSL certificate is found to be compromised.

The device administrator originates the request by filling out a revocation form with the name of the device, the organization or domain of the device, and information

qualifying the certificate such as serial number or issuance date and forwards the

form to be digitally signed by an authorized requestor who forwards the digitally signed certificate revocation request form to the Certificate Manager.

4.9.5 Revocation Request Grace Period

Chevron Subscribers are to request revocation as soon as the need for it is known. Chevron Subscribers must report the reason for revocation to his or her supervisor

or IT representative who owns or is responsible for an asset such as a Device or Service, as soon as possible.

4.9.6 Time Within Which CA Must Process the Revocation Request

The PKI Service Provider will revoke a CA certificate within one hour of notice from the PKI Service Provider’s Policy Authority or an authorized representative from the

Chevron Policy Authority. All other certificates will be revoked as quickly as possible once a properly authenticated and authorized request is received.

4.9.7 CRL Issuance Frequency

The PKI Service Provider’s policy is for CAs managed by the PKI Service Provider to

publish CRLs at least every 24 hours.

4.10 Certificate Status Services

Certificate status information is available via CRL and OCSP responder for device and

all end entity certificates in this SoP.

4.11 End of Subscription

No stipulation.

4.12 Key Escrow and Recovery

No stipulation.



5 Facility, Management, and Operational Controls

This section outlines the physical, logical, procedural, and personnel security controls

required for the Chevron PKI CAs managed by the PKI Service Provider. The room containing each Chevron PKI CA is in secure and geographically diverse data centers.

The data centers are equipped with physical and logical controls to make CA operations inaccessible to non-trusted personnel. Alarm systems are deployed to

notify data center security personnel of violations. Only designated System

Administrators can log on to access the CAs through the PKI Service Provider CertCentral system.

5.1 Physical Controls

5.1.1 Site Location and Construction

The PKI Service Provider performs CA operations from a secure data center equipped with logical and physical controls that make the CA operations inaccessible to non‐trusted personnel. The site location and construction, when combined with other physical security protection mechanisms such as guards, door locks, and intrusion

sensors, shall provide robust protection against unauthorized access to CA

equipment and records.

5.1.2 Physical Access

Access to data center server rooms and work areas containing sensitive information

are physically restricted to authorized personnel. All office doors have a lock, and all entrance doors to the data center facility are always locked. These data center doors

are accessible by an access card, which is issued to the PKI Service Provider Trusted Roles upon confirmation of a clean background check. The data centers, server

cages, and offices are monitored by CCTV. The secured cage requires biometric and dual custodian personnel for access, and all access is logged.

5.1.3 Power and Air Conditioning

The CA hosting facilities shall maintain primary and backup:

• Power systems to ensure continuous, uninterrupted supply of electric power.

• Heating/ventilation/air conditioning systems to control temperature and

relative humidity.

5.1.4 Water Exposures

The CA hosting facility shall be protected from water exposure.

5.1.5 Fire Prevention and Protection

The CA hosting facility shall be equipped with fire suppression mechanisms.



5.1.6 Media Storage

All media containing production software and data, audit, archive or backup information is stored within facilities or in a secure off-site storage facility with

appropriate physical and logical access controls designed to limit access to authorized personnel and to protect such media from accidental damage due to

environmental hazards such as seismic, water, fire, and electromagnetism.

5.1.7 Waste Disposal

Sensitive paper documents and materials are shredded before disposal. Media used

to collect or transmit sensitive information are rendered unreadable before disposal. Cryptographic devices are physically destroyed, or “zeroized,” in accordance with the

manufacturer’s guidance before disposal.

5.1.8 Off-Site Backup

Issuing CA management personnel perform backups of critical system data, audit log

data and other sensitive information. Off-site backup media are stored inside an

insured institution. Backups are encrypted at rest.

5.2 Procedural Controls

5.2.1 Trusted Roles

There are two categories of trusted roles that are authorized to perform specified

administrative and technical functions. RA Trusted role holders in either category must be Chevron employees and require access to a cryptographic object, either in

the form of a smart card, cryptographic module card share, or safe code share, to

carry out their responsibilities.

CA trusted roles managed by the PKI Service Provider are subject to the same

requirements as Chevron TRs. The next table gives the list of CA TRs:

Table 2. Issuing CA Trusted Roles

Trusted Role Duties

CA Administrator The CA Administrator configures and maintains the

CA settings.

Certificate Manager The Certificate Manager approves certificate

enrollments and revocation requests.

Auditor Role The Auditor Role is responsible for reviewing, maintaining, and archiving audit logs and performing or overseeing internal compliance audits to

determine if the Issuer CA is operating in

accordance with this CP.

Chevron considers the categories of personnel identified in this section as Trusted

Persons having Trusted Positions. Chevron employees seeking to become Trusted Persons by obtaining Trusted Positions must successfully complete the screening

requirements established by Chevron and will be appointed by the IMAA. The PKI

Service Provider manages their own trusted personnel in accordance with the requirements of sections 5.2 and 5.3.



5.2.2 Number of Persons Required per Task

The PKI Service Provider shall require that at least two people acting in a trusted role (one shall be a CA Administrator and the other cannot be an Auditor) take action

requiring a trusted role, such as activating the Issuer CA’s Private Keys, generating a CA Key Pair, or creating a backup of a CA Private Key. The Auditor may serve to

fulfill the requirement of multi-party control for physical access to the CA system, but logical access shall not be achieved using personnel that serve in the Auditor role.

5.2.3 Identification and Authentication for Each Role

Before employees exercise the responsibilities of a Trusted Role:

• Chevron will have confirmed the identity of the employee by following

background-checking procedures described in section 5.3.2 of this SoP.

• The IMAA will approve the employee’s assignment to that Trusted Role.

• The PKI Service Provider will confirm the identity and approve the

appointment of employees to the CA trusted role positions.

As appropriate to the specific Trusted Role, access rights, electronic credentials,

passphrases or safe combinations will be established for the Trusted Individual.

5.2.4 Roles Requiring Separation of Duties

Within each Intranet Issuing CA, no individual shall concurrently serve in more than

one of the following Trusted Roles: CA Administrator, Certificate Manager. However, CA Administrators and Certificate Managers may not serve Auditor Role.

5.3 Personnel Controls

5.3.1 Qualifications, Experience, and Clearance Requirements

Individuals assigned to Trusted Roles must present proof of the requisite

background, qualifications, and experience needed to perform their prospective job responsibilities competently and satisfactorily.

The background and clearance requirements for these roles are the same as those for the positions within the corporation occupied by these individuals. All are Chevron

employees or contractors.

The IMAA may waive the Chevron length of service at requirement if the employee

has equivalent work experience and the requisite technical skills from their tenure at

other entities.

The PKI Service Provider’s trusted roles are required to also have the requisite

qualifications for the trusted position, experience in PKI and CA operations, and either have an existing valid clearance or undergo a background check to receive

one.



5.3.2 Background Check Procedures

Chevron and the PKI Service Provider will complete a background check before assigning any employee to a Trusted Role. In most cases, the background check

performed during the hiring process will be leveraged. To the extent that any of the requirements imposed by this section cannot be met due to a prohibition or limitation

in local law or other circumstances, Chevron will use a substitute investigative technique permitted by law that provides substantially similar information including,

but not limited to, obtaining a background check performed by the applicable governmental agency.

5.3.3 Training Requirements

Individuals assigned to Trusted Roles shall be given the appropriate training to

perform their job responsibilities competently and satisfactorily. Depending on their specific role, the training may include:

• The Hardware Security Module (HSM) cryptographic hardware and software,

• PKI and certificate lifecycle management,

• Software versions used by the PKI Service Provider for CAs,

• Windows® Server, Windows® and/or Linux workstation administration,

• Chevron PKI Design,

• Disaster Recovery Planning (DRP),

• Chevron policies and procedures, and

• PKI Service Provider security principles and practices.

Training is given both through formal class-style training with documentation, as well

as on-the-job mentoring and shadowing to bring Trusted Roles up-to-speed as quickly and thoroughly as possible.

Both Chevron and the PKI Service Provider maintains records of Trusted Roles and their training status, what level of training was given and how the trainee performs

the job in the first weeks of acceptance of the role.

5.3.4 Retraining Frequency and Requirements

Chevron will provide refresher training and updates to its personnel to the extent

and frequency required to ensure that such personnel maintain the required level of proficiency to perform their job responsibilities competently and satisfactorily.

Security awareness training is provided on an ongoing basis.

5.3.5 Job Rotation Frequency and Sequence

No stipulation.



5.3.6 Sanctions for Unauthorized Actions

Personnel performing unauthorized actions are subject to disciplinary actions consistent with existing Chevron human resources practices. Also, the IMAA

chairperson has the authority to temporarily suspend personnel from performing functions within either Issuing CA if deemed necessary for the security of that CA.

The PKI Service Provider Trusted Roles are also subject to administrative or disciplinary actions for failing to comply with the PKI Service Provider’s CP and/or

CPS. Trusted personnel who fail to comply will be removed from the trusted position and will not be returned to that position pending official review from the

management.

5.3.7 Independent Contractor Requirements

The Chevron Issuing CA follows standard Chevron policy and practices regarding external contracting. These policies and practices call for personnel requirements

similar to those for internal employees. Within the scope of CA operations, the IMAA chairperson must approve contracts for such external resources. All trusted Chevron

and PKI Service Provider independent contractors are subject to the requirements and duties in section 5.3 and the set of sanctions in section 5.3.6.

5.3.8 Documentation Supplied to Personnel

Individuals assigned to Trusted Roles must acknowledge in writing that they understand the responsibilities of their trusted role and its entry/exit requirements.

Chevron personnel will be given a copy of this SoP, while the PKI Service Provider personnel will be given copies of the PKI Service Provider CP and CPS and any

practices and SOPs that pertains to the job.

5.4 Audit Logging Procedures

5.4.1 Types of Events Recorded

All significant events occurring on a Root and/or Issuing CA shall be recorded. The PKI Service Provider enables essential event auditing of its CA and repository

applications to record the events in the table below. For each event, the PKI Service Provider records the date, time, type of event, success or failure, and logged users

or system that caused the event.

The PKI Service Provider makes all event records available to both internal and external auditors for review and compliance.

The logs may include, but are not limited to, the following events:

Table 3. Auditable Events

Auditable Event

SECURITY AUDIT

Any changes to the Audit parameters, such as, audit frequency, type of event audited

Any attempt to delete or modify the Audit logs

Obtaining a third-party time-stamp



Auditable Event

Authentication to Systems

Successful and unsuccessful attempts to assume a role

The value of maximum number of authentication attempts is changed

The number of unsuccessful authentication attempts exceeds the maximum authentication attempts during user login

A person or device unlocks an account that has been locked because of unsuccessful authentication attempts

A person or device changes the type of authenticator, for example, from a password to a biometric

LOCAL DATA ENTRY

All security-relevant data that is entered in the system

REMOTE DATA ENTRY

All security-relevant messages that are received by the system

DATA EXPORT AND OUTPUT

All successful and unsuccessful requests for confidential and security-relevant information

KEY GENERATION

Whenever a CA generates a key (not mandatory for single session or one-time use symmetric keys)

CA KEY LIFECYCLE MANAGEMENT

Key generation, backup, storage, recovery, archival, and destruction

Cryptographic device life cycle management events

CA AND SUBSCRIBER CERTIFCATE LIFECYCLE MANAGMENT

All verification activities stipulated in the WebTrust Baseline Requirements, the PKI Service Provider CPS and this SoP

Acceptance and rejection of certificate requests

Certificate issuance

Generation of CRLs and OCSP entries

PRIVATE KEY LOAD AND STORAGE

The loading of Component Private Keys

All access to Certificate subject Private Keys retained within the CA for key recovery purposes



Auditable Event

TRUSTED PUBLIC KEY ENTRY, DELETION AND STORAGE

All changes to the trusted Component Public Keys, including additions and deletions

SECRET KEY STORAGE

The manual entry of secret keys used for authentication

PRIVATE AND SECRET KEY EXPORT

The export of private and secret keys (keys used for a single session or message are excluded)

CERTIFICATE REGISTRATION

All Certificate Requests, including for initial issuance, renewal, rekey, and

revocation

CERTIFICATE REVOCATION

All Certificate revocation requests

CERTIFICATE STATUS CHANGE APPROVAL

The approval or rejection of a Certificate status change request

CA CONFIGURATION

Any security-relevant changes to the configuration of a CA system component

ACCOUNT ADMINISTRATION

Roles and users are added or deleted

The access control privileges of a user account or a role are modified

CERTIFICATE PROFILE MANAGEMENT

All changes to the Certificate profile

REVOCATION PROFILE MANAGEMENT

All changes to the revocation profile

CERTIFICATE REVOCATION LIST PROFILE MANAGEMENT

All changes to the Certificate revocation list profile

Generation of CRLs and OCSP entries

TIME STAMPING

Clock synchronization

MISCELLANEOUS

Appointment of an individual to a Trusted Role

Designation of personnel for multi-party control

Installation of the Operating System



Auditable Event

Installation of the PKI Application

Installation of hardware cryptographic modules

Removal of hardware cryptographic modules

Destruction of cryptographic modules

System Startup

Logon attempts to PKI Application

Receipt of hardware/software

Attempts to set passwords

Attempts to modify passwords

Back up of the internal CA database

Restoration from back up of the internal CA database

File manipulation (such as, creation, renaming, moving)

Posting of any material to a PKI Repository

Access to the internal CA database

All Certificate compromise notification requests

Loading HSMs with Certificates

Shipment of HSMs

Zeroizing and Destroying HSMs

Rekey of the Component

CONFIGURATION CHANGES

Hardware

Software

Operating System

Patches

Security Profiles

PHYSICAL ACCESS / SITE SECURITY

Personnel Access to room housing Component

Access to the Component

Known or suspected violations of physical security

Firewall and router activities

Entries to and exit from the CA facility, any secure PKI operations room, and security system actions performed

ANOMALIES



Auditable Event

Software error conditions

Software check integrity failures

Receipt of improper messages

Misrouted messages

Network attacks (suspected or confirmed)

Equipment failure

Electrical power outages

Uninterruptible Power Supply (UPS) failure

Obvious and significant network service or access failures

Violations of Certificate Policy

Violations of Certification Practice Statement

Resetting Operating System clock

5.4.2 Frequency of Processing Log

Events that represent a service interruption or suspicious/unauthorized activity are

monitored in real time through alerts that are sent to a 24 x 7 enterprise server monitoring staff, who responds to the event by notifying the PKI Support team.

Issues that are deemed critical will be investigated, documented, and resolved.

5.4.3 Retention Period for Audit Log

Audit logs will be archived from the Issuing CA and retained for at least seven (7)

years. The PKI Service Provider retains the logs onsite until after they are reviewed.

5.4.4 Protection of Audit Log

CA audit logs are retained on the originating equipment until after it is copied by a

system administrator. The PKI Service Provider’s CA systems are configured to only:

• Allow authorized people to have read access to logs,

• Allow authorized people to archive logs, and

• Ensure that audit logs are not modified.

The PKI Service Provider’s offsite archive location is a safe and secure storage

facility.

5.4.5 Audit Log Backup Procedures

The Issuer CA audit logs will be backed up monthly and stored in a separate off-site

location.



5.4.6 Audit Collection System (Internal vs. External)

Audit logs are automatically started on system startup and end at system shutdown. If an automated logging system fails and the integrity or confidentiality of the

protected system is at risk, the PKI Service Provider will consider suspending the CA’s operations until the problem is remediated.

5.4.7 Notification to Event Causing Subject

No stipulation.

5.4.8 Vulnerability Assessments

Events in the audit process are logged, in part, to monitor system vulnerabilities.

Security vulnerability assessments shall be performed by the PKI Service Provider. The results of assessments will be available to those individuals who are conducting

the Chevron PKI compliance assessment on an as needed basis.

5.5 Records Archival

5.5.1 Types of Records Archived

Issuing CA shall archive all sensitive events, including those described in section 5.4.1 in this SoP, the private encryption keys corresponding to the public keys that it

has certified for individual secure email, the certificates it issues and the public keys contained therein, the published CRLs, delta CRLs, ARLs and delta ARLs, and any

related paper records such as cross-certification requests, cross-certification agreements, and request for revocation of cross-certification certificates.

5.5.2 Retention Period for Archive

Archived audit logs will be stored in a secure off-site location by the PKI Service Provider and retained for at least seven (7) years.

5.5.3 Protection of Archive

Production and archived logical and physical audit logs are protected using a

combination of physical and logical access controls.

5.5.4 Archive Backup Procedures

Archived copies of data and records are stored at locations separate from the

operations centers. See note in section 5.4.5.

The PKI Service Provider creates an archive disk of the data mentioned in section

5.5.1 and each archive file is hashed to produce checksums that are stored separate from the data to ensure file integrity later, as needed.

5.5.5 Requirements for Time-Stamping of Records

The Issuing CA shall automatically time‐stamp archive records as they are created.

Cryptographic time‐stamping of archive records is not required; however, the Issuing

CA shall synchronize its system time at least every eight hours using a real-time

value traceable to a recognized UTC(k) laboratory or National Measurement Institute.



5.5.6 Archive Collection System (Internal vs. External)

The Issuing CA shall archive information internally.

5.5.7 Procedures to Obtain and Verify Archive Information

The archive data can be retrieved and verified to ensure that no damage or loss of

data has occurred by using the hash created as per section 5.5.4. If any sign of data loss, compromise, or loss integrity has occurred, the backup archive is retrieved and

becomes the new master archive, and a new backup is produced.

5.6 Key Changeover

The PKI Service Provider will cease to use any expiring CA private key to sign

certificates, except to sign CRLs and OCSP responder processes. Once a new CA

private key is generated, all subsequent certificates issued by that CA will be with the new private key.

5.7 Compromise and Disaster Recovery

5.7.1 Incident and Compromise Handling Procedures

Any charge or suspicion of compromise of the CA certificate must be brought to the attention of the IMAA by the PKI Service Provider. While written correspondence is

requested, any commercially acceptable means of communication may be used for the initial contact provided written confirmation is submitted in a timely manner. The

chairperson of the IMAA will log any reported claim of compromise and order a

prompt investigation. The resolution of the claim will be logged, and the log will be retained for seven (7) years. All such investigations will be completely documented,

and the documentation will be retained for seven (7) years. If sufficient information has been obtained to substantiate the validity of such a claim, the PA and IMAA shall

assess the severity of the compromise to determine operational viability. The PMA, on advisement from the PA and IMAA, shall determine the corrective measures

deemed to be appropriate.

In the event of the compromise of an end entity’s private key, that certificate will be

revoked and a new CRL or delta CRL issued as described in section 5.7.3.

5.7.2 Computing Resources, Software, and/or Data Are Corrupted

If computing resources, software and/or data are corrupted, the respective Intranet Issuing CA’s operations will be suspended. An investigation will be conducted to

ascertain the cause and the extent of the corruption, and the Intranet Issuing CA IMAA will also assess the integrity of the Chevron PKI along with PKI Service

Provider.

The impacted Issuing CA will be restored to the last good backup before the

corruption occurred. Subscribers will be notified of the corruption, and all certificates issued between the time of corruption and CA service re-establishment will be re-

issued.



5.7.3 Entity Private Key Compromise Procedures

In the event of the compromise of an Intranet Issuing CA’s private key, all active certificates issued by it must be revoked. A new certificate will be issued only after

the PA and IMAA have been satisfied that the compromise has been rectified and that all liability issues have been resolved.

For end entities, the certificates in question will be brought to the attention of the Certificate Manager. While written correspondence is requested, any commercially

acceptable means of communication may be used for the initial contact provided written confirmation is submitted in a timely manner. The Certificate Manager will

immediately revoke the certificates in question. The individual must then request a

replacement certificate. See the End-Entity Certificate Life Cycle Management Design document for details.

Refer to the DigiCert CPS section 5.7.3 for a complete description of how the PKI Service Provider handles entity private key compromise.

5.7.4 Business Continuity Capabilities after a Disaster

The PKI Service Provider implements data backup and recovery procedures as part of Business Continuity Management Plan (BCMP). In the case of a disaster, if the

primary CA becomes inoperative, the secondary site will be re-initiated and will be given priority to provision certificates and their status to entities.

5.8 CA or Registration Authority Termination

Before any Chevron CA is terminated, Chevron and the PKI Service Provider will

assess any CA’s request for termination. A request for termination from either a Root or Issuing CA must be submitted in writing and delivered to the respective PMA. If

the PMA determines that termination of the CA is deemed necessary, the Intranet Issuing CA IMAA shall commence a termination request to the PKI Service Provider.



6 Technical Security Controls

6.1 Key Pair Generation and Installation

6.1.1 Key Pair Generation

6.1.1.1 Issuing CA

Each Issuing CA uses HSM cryptographic hardware and software that meets the requirements of FIPS-140 Level 3 and provides separation of administrative duties

from operational duties. The HSM cryptographic hardware provides protection of each Intranet Issuing CA’s key pair.

Each Intranet Issuing CA’s key pair is generated in accordance with PKI Service Provider requirements during a scripted key ceremony.

The encryption algorithm and key length are specified in section 6.1.5.

The PKI Service Provider creates auditable evidence during any key signing ceremony. External Auditors review all PKI Service Provider key signing ceremonies

on a WebTrust and FPKI approved audit schedule at least semi-annually.

6.1.1.2 End Enti ty Key Pair Generat ion

Generation of an end entity’s key pairs varies according to the type of end entity.

6.1.1.2.1 End User Cert if icate

End User certificates are issued by a Registration Agent after proper identity

proofing as described in section 3.2. The End User supplies appropriate biographic and biometric data and the RA will include the data in the certificate

request.

6.1.1.2.2 Code Signing Cert if icates

See section 6.1.1.2.3

6.1.1.2.3 Device Certif icate with Manual Enrollment

The device’s administrator designates the Cryptographic Service Provider (CSP).

Windows® Server supports both hardware and software CSPs.

6.1.1.2.4 Device Certif icate with Auto-Enrollment

The device’s designated CSP generates the key pair on request of the auto-

enrollment function.

6.1.2 Private Key Delivery to Subscriber

6.1.2.1 Intranet Issuing CA

The Issuing CA will protect the private key from activation, compromise or modification during transmission of the private key to the Applicant. The Issuing CA

will also ensure that the correct private key, tokens, and/or activation data is issued to the correct Applicant.



6.1.2.2 End Enti t ies

End User certificates may be issued to hardware cryptographic modules such as a smart card, or may be issued to a user’s computer browser, as appropriate. The

Subscriber must acknowledge receipt of the certificate.

6.1.2.2.1 Code Signing

See section 6.1.2.2.2

6.1.2.2.2 Device Certif icate with Manual Enrollment

The device’s administrator or sponsor acts as the Applicant and must sign the

Subscriber Agreement to acknowledge the key delivery to the device.

6.1.2.2.3 Device Certif icate with Auto-Enrollment

See section 6.1.4

6.1.3 Public Key Delivery to Certificate Issuer

Each end entity submits its public key to an Intranet Issuing CA electronically or manually using either a CMC or PKCS #10 CSR.

6.1.4 CA Public Key Delivery to Relying Parties

Chevron makes the Root CA certificate available to Subscribers and Relying Parties by publishing it at http://pki.chevron.com/aia/Chevron%20Root%20CA G2(x).crt.

The x indicates the generation of the CA certificate; it is incremented by 1 every time

the Root certificate is rekeyed or renewed.

Chevron makes the Intermediate CA certificates available to Subscribers and Relying

Parties by publishing them at http://pki.chevron.com/aia/Chevron%20Intranet%20CAIntermediate%%2010(x).crt

which will be available internally to Chevron and externally to the public. The x indicates the generation of the CA certificate; it is incremented by 1 every time an

Intermediate certificate is rekeyed or renewed.

The Issuing CA Certificates are also available internally to Chevron via paths defined

in the corresponding CA certificate.

Chevron makes the Issuing CA certificates available to Subscribers and Relying Parties by publishing them via paths defined in the corresponding CA certificate,

which will be available both internally to Chevron and externally to the public. The x indicates the generation of the CA certificate; it is incremented by 1 every time an

Intermediate certificate is rekeyed or renewed, except for the first generation that has no subscript.

6.1.5 Key Sizes

All certificate key pairs that expire before 12/31/2030 are at least 2048-bit RSA. All certificate key pairs that expire after 12/31/2030 are at least 3072-bit RSA. All

signature hashes must be sha256 with RSA algorithm.

6.1.6 Public Key Parameters Generation and Quality Checking

The required Key Parameters will be generated in software in accordance with FIPS 186-3 (ANSI X9.31) or a PMA-approved equivalent standard.

The quality of the generated Key Parameters shall be verified by software in accordance with FIPS 186-3 or a PMA-approved equivalent standard.

http://pki.chevron.com/aia/Chevron%20Root%20CA%20G2.crt

http://pki.chevron.com/aia/Chevron%20Intranet%20CA%201(x).crt



6.1.7 Key Usage Purposes

For X.509 v3 certificates, Chevron populates the keyUsage, extKeyUsage, and other attribute fields in accordance with RFC 6818. These key usages are set according to

the following:

• Certificates used for digital signatures shall set the digitalSignature usage,

• Certificates used for digital encryption shall set the keyEncipherment usage,

• CA Certificates shall set the CRLSign and keyCertSign usage,

• Certificates used for authentication shall set the digitalSignature usage.

These are the minimum requirements. See section 7.1 for more details.

6.2 Private Key Protection and Cryptographic Module Engineering Controls

Chevron uses a combination of physical, logical, and procedural controls to ensure

the security of each Intranet Issuing CA’s private keys implemented by the PKI

Service Provider.

6.2.1 Cryptographic Module Standards and Controls

The HSM cryptographic modules used by the Intranet Issuing CAs are certified to the

requirements of FIPS 140-2 Level 3.

End Users will protect their private keys in the token, hardware or software, in which

they were issued. Subscribers must not reveal their PIN to any other person, and when the private key is in use, shall not walk away from their workstation without

pulling the card or locking the workstation.

The following end entities will protect their private keys by storing them in the

system or user profile, a secure directory on the device’s hard drive:

• Device Certificate with Manual Enrollment

• Device Certificate with Auto-Enrollment

6.2.2 Private Key (M of N) Multi-Person Control

PKI Service Provider shall implement multi-person private key controls. Backups of CA keys are stored offsite and only accessible by multi-person control. Key backups

require the same controls as those used for operational keys.

6.2.3 Private Key Escrow

No Issuing CA’s private keys are escrowed. No other end entity private keys are

escrowed.



6.2.4 Private Key Backup

Issuing CA key private key(s) are securely stored in a secure off-site location by the PKI Service Provider. The key material shall be protected by multi-person access

control. When CA private keys are transferred to other media outside of the operational FIPS 140 HSM, the keys are stored in an encrypted form during

transport. Other details of key backup are found in sections 5.4 and 5.5 except for the archive details.

End Users are advised to create backup copies of software certificate private keys, and the certificate will require the user to encrypt the backed up key and secure with

a PIN.

6.2.5 Private Key Archival

The PKI Service Provider does not archive private keys.

6.2.6 Private Key Transfer into or from Cryptographic Module

Chevron Issuing CA key pairs will be generated on the hardware cryptographic

modules in which the keys will be used. Also, PKI Service Provider makes copies of such CA key pairs for routine recovery and disaster recovery purposes. Where CA

key pairs are used in another hardware cryptographic module, such key pairs are always transported between modules in encrypted form. The private key never

leaves the cryptographic module in unencrypted form.

6.2.7 Private Key Storage on Cryptographic Module

Immediately before activation, an Issuing CA’s private key is copied in encrypted

form from the hard drive and stored in encrypted form on the HSM. Once activated, the plaintext private key is stored in volatile memory within the HSM. The PKI

Service Provider’s HSM are rated at FIP 140 Level 3 and EAL 4+. Root CA private

keys are stored in cryptographic modules in accordance with the requirements and procedures in sections 6.2.2, 6.2.4, and 6.2.6.

6.2.8 Method of Activating Private Key

The Issuing CA’s are activated by the PKI Service Provider, and in accordance with the specifications of the HSM manufacturer. Each Intranet Issuing CA’s private key

can be activated only in the HSM that has the key to decrypt the private key.

At a minimum, the factors used to protect an end entity’s private key are:

6.2.8.1 End User Keys

End Users are solely responsible for protecting and activating their private keys.

Chevron policy requires at least a 4-digit PIN for smart card badges. Any software certificate issued to End Users shall be protected in accordance with the Chevron

policy for passwords.

6.2.8.2 Code Signing Keys

See 6.2.8.3

6.2.8.3 Device Cert i f icate with Manual Enrol lment

The private key is activated to the operating system on successful startup.



6.2.8.4 Device Cert i f icate with Auto -Enrol lment

The private key is activated to the operating system on successful startup.

6.2.9 Method of Deactivating Private Key

The PKI Service Provider’s HSMs require the private keys to be deactivated by use of

a logout procedure when not in use. The PKI Service Provider never leaves HSMs in

an active unlocked or unattended state.

6.2.10 Method of Destroying Private Key

PKI Service Provider Trusted Roles destroy CAs private key when no longer needed.

Trusted Roles will be zeroized in the HSM and associated backup tokens in accordance with the cryptographic device manufacturer specifications.

End Users must destroy their private keys when the certificate is revoked, expired, or no longer needed. End Users may turn their smart card badge in to a manager or

HR in these cases and the appropriate Chevron personnel will shred the card.

For Code Signing and Device certificates the appropriate administrator or Sponsor

shall delete the certificate and its private key from all known storage partitions.

6.2.11 Cryptographic Module Rating

See section 6.2.1.

6.3 Other Aspects of Key Pair Management

6.3.1 Public Key Archival

See section 5.5.

6.3.2 Certificate Operational Periods and Key Pair Usage Periods

The key pair usage period of certificates and keys issued under the Chevron PKI are as follows:

Table 4. Certificate Key Pair Usage Periods and Key Types

Key Type Private Key Use Certificate Term

Root Cas 20 years 25 years Signing CAs 12 years 15 years Subscriber Identity or Signature 3 years 3 years Subscriber Encryption 3 years 3 years OCSP Responder 3 years 31 days SSL/TLS No stipulation 825 days Short-Lived SSL/TLS 30 days 30 days Code Signing No stipulation 39 months Device 2 years 2 years



6.4 Activation Data

6.4.1 Activation Data Generation and Installation

The PKI Service Provider activates Chevron CA private keys in accordance to HSM manufacture specification along with multi-person policies enforcements and in

accordance with the procedures detailed in section 6.2 and 5.2.2.

6.4.2 Activation Data Protection

The PKI Service Provider protects the tokens and other data used to unlock the

private keys of CAs in the Chevron PKI. Protection mechanisms include using role-based physical controls and instructing Trusted Role personnel to memorize and not

write down passwords or share the passwords with other people. The PKI Service

Provider locks accounts used to access CAs if a certain number of failed password attempts are made to unlock a CA.

6.4.3 Other Aspects of Activation Data

No stipulation.

6.5 Computer Security Controls

6.5.1 Specific Computer Security Technical Requirements

PKI Service Provider ensures that the systems maintaining CA software and data files

are Trustworthy and Hardened Systems that are secure from unauthorized access. All CA systems are scanned for malicious code and protected against malware

including viruses through anti-malware software, airgaps, network segmentation,

and offline storage.

The CA systems and those workstations connecting to them are configured to:

• Authenticate the identity of any person accessing the system,

• Manage privileges of users and limit access to assigned roles,

• Generate auditable records of all transactions,

• Enforce domain integrity boundaries for critical processes, and

• Support recovery from key or system failure.

6.5.2 Computer Security Rating

No stipulation.

6.6 Life Cycle Technical Controls

6.6.1 System Development Controls

PKI Service Provider implements mechanisms for purchases and development of

systems for operating PKI services. The software is developed in accordance with the secure system development standards and practices.

Applications are tested, developed, and implemented in accordance with industry development and change management standards.



6.6.2 Security Management Controls

PKI Service Provider has mechanisms and/or policies in place to control and monitor the configuration of its CA systems. Antivirus software has been installed on all the

servers.

6.6.3 Life Cycle Security Controls

No stipulation.

6.7 Network Security Controls

PKI Service Provider ensures that Issuing CA server is located behind a firewall and boundary controls are configured that limits access to IP addresses, ports and

protocols required for Issuing CA and OCSP servers.

The repositories managed by the PKI Service Provider are connected to the internet and provide continuous service.

Boundary control devices used to protect CAs or repositories shall deny all, but the necessary services required to administer the PKI.

All equipment that the PKI Service Provider employs for the Root and Issuing CAs shall use appropriate network security controls. Networking equipment shall have

unused network ports and services turned off. Any network software present in the PKI shall be only for the use of the equipment in the PKI.

The PKI Service Provider continually monitors the network and devices for evidence

of malware and conducts periodic internal penetration testing to find vulnerabilities.

6.8 Time-Stamping

Time-stamping device may not be used to validate signing signatures by PKI Service

Provider; however, a trusted time source is required, and each server is synchronized through the Master Active Directory® NTP Time Server with the NIST

time standard.



7 Certificate, CRL, and OCSP Profiles

7.1 Certificate Profile

All certificates will be issued in the X.509 v3 format and will include a reference to

the Chevron OID for this SoP within the certificatePolicies extension field.

Certificates issued under this SoP use these IETF Standard RFC 5754 OIDs:

Sha256WithRSAEncryption – for signatures

RSAEncryption – for subject public key information

7.1.1 Name Forms

The Subject and Issuer fields of certificates issued by the Chevron PKI are populated

with a unique Distinguished Name, in conformance with RFC 6818.

Chevron CAs have the following name form:

• CN - Descriptive name for the CA – Recommended

• OU – As needed – Optional

• O – Issuer/company name - Required

• C – Country name- Required

Chevron non-CA certificates have the following name form (inclusive of all

certificates issued by Chevron that are not CAs):

• Additional naming attributes for uniquely identifying the subject including CN

(commonName), SN (serialNumber), etc. – Required

• OU – as needed – Optional

• O – Issuer/company name – Required

• C – Country name - Required

7.1.2 Certificate Formats

Chevron certificates are issued in conformance with the following formats:

7.1.2.1 Chevron Root CA G2 (Trust Anchor)

Table 5. Chevron Root CA G2 (Trust Anchor)

Attribute Value

Version V3

Serial Number Must be unique

Signature algorithm per section 6.1.5

Issuer Distinguished

Name

CN=Chevron Root CA G2

O=Chevron

C=US

Validity Period Expressed in UTC time until 2049 (certificate shall be renewed every 6

years)



7.1.2.2 Chevron Intermediate CAs

Table 6. Chevron Intermediate CAs

Subject Distinguished

Name


O=Chevron Corporation

C=US

Subject Public key RSA 2048 bits

Issuer’s Signature Per section 6.1.5

Key Usage (critical) digitalSignature, Certificate Signing, Off-line CRL Signing, CRL Signing

(86)

Basic Constraints (critical) Subject Type=CA

Path Length Constraint=0

Subject Key Identifier Octet String

Attribute Value

Version V3


Issuer Signature

algorithm per section 6.1.5


Name



C=US

Validity Period Expressed in UTC time (certificate shall be renewed every 6 years)


Name CN=<Chevron Intermediate CA>


C=US



Authority Key Identifier Octet String


Certificate Policies See section 1.2

Key Usage (critical) digitalSignature, keyCertSign, CRLSign

Name Constraints

(critical)

Optional, permitted subtrees for DN, RFC 5322, and DNS name


Path Length Constraint=None

Authority Information

Access See section 7.2see

CRL Distribution Points See section 7.2seee



7.1.2.3 Chevron Issuing CAs

Table 7. Chevron Issuing CAs

7.1.2.4 Chevron End Ent i ty Identi ty Cert i f icates

Table 8. Chevron End Entity Identity Certificates

Attribute Value

Version V3


Issuer Signature

algorithm

per section 6.1.5


Name

CN=Chevron Root CA G2 O=Chevron Corporation C=US

Validity Period Expressed in UTC time (certificate shall be renewed every 6 years)


Name CN=<Chevron Issuing CA>


C=US





Certificate Policies See section 1.2

http://policy.pki.chevron.com/policy

Key Usage (critical) digitalSignature, keyCertSign, cRLSign

Name Constraints

(critical) Optional, permitted subtrees for DN, RFC 5322, and DNS name




Access

See section 7.2see

CRL Distribution Points See section 7.2seee

Attribute Value

Version V3

Serial Number Must be unique to a given CA

Issuer Signature



Name

CN=<Chevron Issuing CA>


C=US

Validity Period 3 years Expressed in UTC time



7.1.2.5 Chevron End Ent i ty Signing Cert i f icates

Table 9. Chevron End Entity Signing Certificates


Name

X.500 subject DN as specified in section 7.1.1





Certificate Policies Per section 1.2

Key Usage (critical) digitalSignature

Extended Key Usage

(critical)

Per section 7.1.3

Subject Alternative Name URI, or otherName:principleName if id-kp-smartcardlogon is used, or

RFC 5322 email address of Subscriber


Access Per section 7.2

CRL Distribution Points Per section 7.2

Attribute Value

Version V3


Issuer Signature

algorithm

per section 6.1.5




C=US



Name








Extended Key Usage

(critical)

Per section 7.1.3

Subject Alternative Name RFC 5322 email address of Subscriber (required) URI (optional),

otherName:principleName (optional)






7.1.2.6 Chevron End Ent i ty Encrypt ion Cert i f icates

Table 10. Chevron End Entity Encryption Certificates

7.1.2.7 Chevron End Ent i ty Dual-Key Signing and Encrypt ion Cert i f ic ates

Table 11. Chevron End Entity Dual Key Signing and Encryption Certificates

Attribute Value

Version V3


Issuer Signature

algorithm

per section 6.1.5




C=US



Name







Key Usage (critical) keyEncipherment

Extended Key Usage

(critical)

Per section 7.1.3






Attribute Value

Version V3


Issuer Signature

algorithm

per section 6.1.5




C=US



Name






7.1.2.8 Chevron Content Signer Cert i f icate

Table 12. Chevron Content Signer Certificate




Key Usage (critical) digitalSignature, keyEncipherment

Extended Key Usage

(critical) Per section 7.1.3






Attribute Value

Version V3


Issuer Signature

algorithm

per section 6.1.5




C=US



Name X.500 subject DN as specified in section 7.1.1







Extended Key Usage

(critical)

Per section 7.1.3

Subject Alternative Name Optional


Access

id-ad-caIssuers access method entry contains HTTP URL for

.p7c file containing Certificates issued to Issuing CA

id-ad-ocsp access method entry contains HTTP URL for the

Issuing CA OCSP Responder




7.1.2.9 Chevron Code Signer Cert i f icate

Table 13. Chevron Code Signer Certificate

7.1.2.10 Device/Server /SSL -TLS Cert i f icate

Table 14. Device/Server/SSL-TLS Certificate

Attribute Value

Version V3


Issuer Signature

algorithm

per section 6.1.5




C=US



Name








Extended Key Usage

(critical)

Per section 7.1.3

Subject Alternative Name DN of the person controlling the code signing keys


Access id-ad-caIssuers access method entry contains HTTP URL for

.p7c file containing Certificates issued to Issuing CA




Attribute Value

Version V3


Issuer Signature



Name Unique X.500 subject DN as specified in section 7.1.1

Validity Period 2 years maximum Expressed in UTC time


Name





7.1.2.11 Short -Lived SSL/TLS Cert i f icates for Cloud

Table 15. Short-Lived SSL-TLS Certificates for Cloud





Key Usage (critical) keyEncipherment, digitalSignature

Extended Key Usage


Subject Alternative Name Always present, one or more Host URL, IP Address, or Host Name

Basic Constraints (critical) Subject Type=End Entity



Access id-ad-caIssuers access method entry contains HTTP URL for

.p7c or .crt file containing Certificates issued to Issuing CA




Attribute Value

Version V3


Issuer Signature

algorithm

per section 6.1.5


Name

Unique X.500 subject DN as specified in section 7.1.1

Validity Period 30 days maximum Expressed in UTC time


Name X.500 subject DN as specified in section 7.1.1






Key Usage (critical) keyEncipherment, digitalSignature

Extended Key Usage


Subject Alternative Name Always present, one or more Host URL, IP Address, or Host Name

Basic Constraints (critical) Subject Type=End Entity




7.1.3 Extended Key Usage

Table 16. Extended Key Usage

Type

Required

-Name

Required-

OID

Optional-

Name

Optional-

OID

Prohibited-

Name

Prohibited-

OID

CA None None All

Human Identity

Certificates

Client Authentic

ation

1.3.6.1.5.5

.7.3.2

Any EKU

that is consistent with Key

Usage

Any EKU not

consistent with Key

Usage

2.5.29.37.0

Smart

Card

Logon

1.3.6.1.4.1

.311.20.2.

2

anyExtended

KeyUsage

Human Signing

Certificates

Secure

Email

1.3.6.1.5.5

.7.3.4

Any EKU that is consistent

with Key

Usage

Any EKU not consistent with Key

Usage

anyExtended

KeyUsage

2.5.29.37.0

Human Encryption

Certificates

Secure

Email

1.3.6.1.5.5

.7.3.4

Any EKU

that is consistent with Key

Usage

Any EKU not consistent

with Key

Usage

anyExtended

KeyUsage

2.5.29.37.0


Access

id-ad-caIssuers access method entry contains HTTP URL for.p7c or .crt

file containing Certificates issued to Issuing CA






Type

Required

-Name

Required-

OID

Optional-

Name

Optional-

OID

Prohibited-

Name

Prohibited-

OID

Human

Dual-Use Signing and Encryption

Certificates

Client Authentic

ation

1.3.6.1.5.5

.7.3.2

Document

Signing

1.3.6.1.4.1.3

11.10.3.12

Any EKU not consistent with Key

Usage

Smart Card

Logon

1.3.6.1.4.1.311.20.2.

2


with Key

Usage

anyExtended

KeyUsage 2.5.29.37.0

Secure

Email

1.3.6.1.5.5

.7.3.4

Content Signing

Certificate

None


with Key

Usage

Any EKU not consistent

with Key

Usage

anyExtended

KeyUsage 2.5.29.37.0

Code Signing

Certificate

id-kp-codesigni

ng

1.3.6.1.5.5

.7.3.3

Life-Time

Signing

1.3.6.1.4.1.3

11.10.3.13 All Others

Device Authentication

Certificates

id-kp-serverAut

h

1 3 6 1 5 5

7 3 1 None All Others

id-kp-

clientAuth

1.3.6.1.5.5

.7.3.2



Type

Required

-Name

Required-

OID

Optional-

Name

Optional-

OID

Prohibited-

Name

Prohibited-

OID

Web

Server/SSL-TLS

Certificates

id-kp-

serverAut

h

1 3 6 1 5 5

7 3 1 None All Others

id-kp-

clientAuth

1.3.6.1.5.5

.7.3.2

7.2 CRL Profile

Chevron CRLs and ARLs are issued in X.509 v3 format. Combined delta CRLs and

delta ARLs will be issued.

7.3 OCSP Profile

This PKI may support either version 1 or version 2 of OCSP, per the practices of the

PKI Service Provider’s managed PKI.



8 Compliance Audit and other Assessments

The PKI Service Provider’s practices for compliance audits are designed to meet or

exceed generally accepted industry standards for compliance, including the latest versions for the WebTrust Programs for Certification Authorities.

8.1 Frequency or Circumstances of Assessment

An assessment of the PKI Service Provider’s operations is in compliance with the

DigiCert CPS and is performed at least once a year and is:

• A WebTrust for Certification Authorities audit, and

• An examination by external audit firm.

A reassessment shall be required every 12 months.

This SoP shall be reviewed every 12 months to ensure it remains up-to-date.

8.2 Identity/Qualifications of Assessor

The assessor who performs the audit shall be approved by the PKI Service Provider,

meet the requirements of the WebTrust Baseline Requirements section 8.2, and may

be a licensed Certified Public Accountant (USA) or Chartered Accountant (Canada). Also, the assessor may hold the Certified Information Systems Auditor (CISA),

Certified Information Systems Manager (CISM) or Certified Information Systems Security Practitioner (CISSP) designations, or other appropriate certifications. The

assessor should have experience in the application of public key cryptographic technologies and general computer security.

8.3 Assessor’s Relationship to Assessed Entity

If the assessment is not a self-assessment, the assessor shall be independent of the

PKI under audit, as well as any service providers to the PKI under audit. For internal auditors, independence is defined in the Information Audit and Control Association’s

IS Auditing Guideline – Organisational Relationship and Independence.

PKI Service Provider shall use external auditors engaged in public practice, as

defined by Generally Accepted Auditing Standards.

8.4 Topics Covered by Assessment

The assessment compares the operations of the PKI Service Provider to the criteria in the WebTrust Principles and Criteria for Certification Authorities. The WebTrust

document describes a consistent set of measurement criteria for audit practitioners to use in testing and evaluating CA practices, and is organized into three broad

areas:

• CA Business Practices

• CA Service Integrity

• CA Environmental Controls.



8.5 Actions Taken as a Result of Deficiency

If a deficiency has been identified, PKI Service Provider shall document and implement resolution of noncompliance to satisfy contractual obligations with

Chevron.

8.6 Communication of Results

PKI Service Provider obligated to report to Chevron PMA results of audit.



9 Other Business and Legal Matters

9.1 Fees

No stipulation.

9.2 Financial Responsibility

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 Confidentiality of Business Information

Except for PKI information that is specifically identified as confidential or is regulated by the data privacy laws of the applicable jurisdictions as personally identifiable

information, all PKI information will be considered public information. A non-exclusive list of some specific examples of confidential information and non-

confidential information appears in the following sections.

9.3.1 Scope of Confidential Information

Each Intranet Issuing CA’s private keys and that of the CMS are confidential. Each PKI end entity’s private key is confidential.

Information held in audit trails is considered confidential to Chevron and shall not be released outside the corporation unless required by law. HSM activation data is

considered confidential.

Corporate information held by the Issuing CAs other than that, which is explicitly

made available as part of a certificate, CRL, SoP, or otherwise publicly disclosed, is considered confidential.

When Chevron revokes a certificate, a reason code may, but need not be, included in

the CRL and delta CRL entries for the revoked certificate. This reason code is not considered confidential and can be shared with all other users and Relying Parties;

however, the details concerning the revocation are considered confidential.

The assessor’s management letter is considered confidential and may not be

released except with prior approval of the PMA or unless required by law.

9.3.2 Information Not Within the Scope of Confidential Information

Information included in certificates, CRLs, delta CRLs, ARLs and delta ARLs is not

considered confidential. Information in any Chevron PKI SoP is not considered confidential. The external auditor’s opinion letter is not considered confidential.



9.3.3 Responsibility to Protect Confidential Information

The individuals assigned to Trusted Roles are obligated to protect confidential information and not to disclose such information unless required by law, regulation,

or order of a court of competent jurisdiction. Any request for release of information shall be authenticated and approved by Chevron’s legal department before the

release of that information.

9.4 Privacy of Personal Information

This PKI will protect the privacy of any personal information it may contain and abide

by the privacy laws and regulations of the respective countries within which it

operates.

9.4.1 Privacy Plan

Each CA will conform to Chevron’s privacy plan.

9.4.2 Information Treated as Private

The privacy of information will be determined under the applicable laws of the countries in which Chevron operates.

9.4.3 Information Not Deemed Private

No stipulation.

9.4.4 Responsibility to Protect Private Information

Under the laws of the countries wherein it operates, especially the EU, Chevron has

an obligation to protect private information.

9.4.5 Notice and Consent to Use Private Information

Chevron PKI administrators, certificate managers and users shall not use their

private information for authenticating to Chevron PKI nor include that information in certificates.

9.4.6 Disclosure Pursuant to Judicial or Administrative Process

As with other services, the Chevron PKI will comply with legal requirements to

release information to law enforcement officials, consistent with the Chevron corporate policies.

Chevron PKI participants acknowledge that Chevron shall be entitled to disclose Private Information if, in good faith, Chevron believes disclosure is necessary in

response to judicial, administrative or other legal process during the discovery process in a civil or administrative action such as subpoenas, interrogatories, and

requests for admission and requests for production of documents. This section is subject to applicable privacy laws.

9.4.7 Other Information Disclosure Circumstances

No stipulation.



9.8 Intellectual Property Rights

Certificates, CRLs and delta CRLs issued by Chevron are the property of Chevron.

This Set of Provisions is the property of Chevron.

The DNs used to represent entities within the Chevron PKI domain, in the directory and in certificates issued to end entities within that domain, include a Relative

Distinguished Name (RDN) for Chevron, and as such are the property of Chevron.

9.9 Representations and Warranties

9.9.1 CA Representations and Warranties

No stipulation.

9.9.2 Registration Authority Representations and Warranties

No stipulation.

9.9.3 Subscriber Representations and Warranties

The Subscribers of this CA are:

• Devices (for example, routers, web servers or switches), or

The administrators, who are natural persons, responsible for a device (for example, a router, web server, and so on) that receives a certificate from either Intranet Issuing

CA are obligated to:

• Make true representation at all times to the Issuing CA and Registration

Authority regarding information contained in their device’s certificate.

• Deploy the certificate exclusively for legal and authorized business with Chevron, consistent with the Intranet Issuing CA SoP.

• Protect the device’s private keys by storing them in a manner commensurate with the sensitivity and risk of the application or applications supported by

that device.

• Maintain cryptographic material in a secure manner according to established

procedures for handling such material as stated in the Subscriber Agreement.

• Deploy the certificates and related technology in compliance with the laws

and regulations of the countries where they operate.

• Inform the local Registration Agent immediately of a change to any information included in a certificate or certificate application request.

• Inform the local Registration Agent immediately of any suspected or actual compromise of the private keys.

9.9.4 Relying Party Representations and Warranties

Notwithstanding the remainder of this section, only entities expressly authorized by separate agreement with Chevron may act as Relying Parties or otherwise rely on a

certificate issued under this SoP.



9.9.5 Representations and Warranties of Other Participants

No stipulation.

9.10 Disclaimers of Warranties

Chevron makes no representations or warranties whatsoever, express or implied,

including without limitation, any representation with respect to any claim, cause of action, or any other matter arising from or related to this SoP.

9.11 Limitations of Liability

Chevron and all CAs in the Chevron PKI shall not be liable to any relying party for

any direct, indirect, incidental, consequential or punitive damages whatsoever, for any matter arising out of or relating to this agreement or its subject matter, whether

such liability is asserted on the basis of contract, tort, or any other theory of liability, and even if Chevron has been advised of the possibility of such damages. Further,

this SoP does not create any right or obligation on behalf of any person or entity outside Chevron. Notwithstanding, this section is not intended to abrogate any

obligations prescribed under state, federal, or international law.

9.12 Indemnities

No stipulation.

9.13 Term and Termination

This Set of Provisions shall become effective on its approval by the PMA and shall

remain in effect until terminated by the PMA or superseded by a revised Set of Provisions.

9.13.1 Term

No stipulation.

9.13.2 Termination

The PMA may terminate this PKI on 30 days’ notice to the Subscribers.

9.13.3 Effect of Termination and Survival

Chevron will communicate the conditions and effect of this SoP’s termination via the

Chevron Repository http://policy.pki.chevron.com/policy. The communication will specify which provisions survive termination. At a minimum, all responsibilities

related to protecting confidential information will survive termination. All Subscriber Agreements remain effective until the certificate is revoked or expired, even if this

SoP terminates.

9.14 Individual Notices and Communications with Participants

No stipulation.

http://policy.pki.chevron.com/policy



9.15 Amendments

9.15.1 Procedure for Amendment

Any proposal for modification shall be submitted to the PMA. Any proposed changes to this SoP that the PMA has deemed to have significant impact, shall undergo a

review and comment period.

9.15.2 Notification Mechanism and Period

Changes to this SoP, which significantly impact the SoP, as determined by the PMA,

shall undergo an appropriate public review and comment period.

The PMA shall review all comments, and publicly respond to them. Cross-Certified

CAs shall be explicitly notified of the proposed modification through their designated

contact person. If the PMA decides to make no changes during the review period, the initially proposed modified document shall become final and shall be published in the

Repository.

Participating Subscribers, Sponsors, and Relying Parties should periodically check the

Repository for notice of intended modifications to this SoP.

9.15.3 Circumstances Under which OID Must be Changed

Changes to this SoP that, in the judgment of the PMA may have significant impact,

will once effective, require an increment to the last arc of the OID.

9.16 Dispute Resolution Provisions

Any dispute between Chevron PKI users, one acting as a Subscriber and one acting as a Relying Party or between Chevron users and an Issuing CA or Registration

Authority, shall first be reported to the Chevron IMAA for resolution. In the event the IMAA cannot resolve the dispute, the PMA shall be the final arbiter.

Any dispute between the Chevron PKI and other PKIs where Chevron has established Cross-Certification Agreements, Bridge Certification Agreements, a joint venture, or

Relying Party Agreement, shall commence pursuant to this section of this agreement. For joint ventures, for any conflict between the dispute resolution provisions of this

SoP and the joint venture founding agreements, the joint venture founding

agreements shall control.

If a dispute arises out of or relates to this Agreement, or the breach thereof, and the

dispute cannot be settled, the parties agree first to try in good faith to settle the dispute by mediation administered by mutually agreed on mediation service before

resorting to arbitration. The parties shall settle any dispute arising out of or related to this Agreement, or the breach thereof, by arbitration. A single arbitrator shall be

agreed on by the parties, or if the parties cannot agree on an arbitrator within 30 days, the parties agree that a single arbitrator shall be appointed by the American

Arbitration Association. The arbitrator may award attorneys' fees and costs as part of

the award. The award of the arbitrator shall be non-binding.

No waiver of any provision hereof or of any right or remedy hereunder shall be

effective unless in writing and signed by the party against whom such waiver is sought to be enforced. No delay in exercising, no course of dealing with respect to,

or no partial exercise of any right or remedy hereunder shall constitute a waiver of any other right or remedy, or future exercise thereof.



If any provision of this Agreement is determined to be invalid under any applicable statute or rule of law, it is to that extent to be deemed omitted, and the balance of

the Agreement shall remain enforceable.

9.17 Governing Law

The laws of the State of California, excluding its conflict of laws rules, shall govern

the construction, validity, interpretation, enforceability and performance of this SoP and any Subscriber Agreement. Any dispute related to this SoP, any Subscriber

Agreement or any certificate issued by Issuing CAs or any services provided by

Issuing CAs shall be brought in the courts of the State of California, and each person, entity, or organization hereby agrees that such courts shall have personal and

exclusive jurisdiction over such disputes. If any matter arising from this agreement is filed in court, the parties to such action waive any right to a jury trial. For joint

ventures, for any conflict between the governing law provisions of this SoP and the joint venture founding agreements, the joint venture founding agreements shall

control.

9.18 Compliance with Applicable Law

This SoP is subject to any applicable national and foreign laws, rules, regulations, ordinances, decrees and orders including, but not limited to, restrictions on exporting

or importing software, hardware or technical information.

9.19 Miscellaneous Provisions

9.19.1 Entire Agreement

This SoP constitutes the entire understanding between the parties and supersedes all

other terms, whether express or implied by law. No modification of this SoP shall be

of any force or effect unless in writing and signed by an authorized signatory. Failure to enforce any or all these sections in a particular instance or instances shall not

constitute a waiver thereof or preclude subsequent enforcement thereof. All provisions in this SoP, which by their nature extend beyond the term of the

performance of the services such as, without limitation, those concerning confidential information and intellectual property rights, shall survive such term until fulfilled and

will apply to any party’s successors and assigns.

9.19.2 Assignment

No stipulation.

9.19.3 Severability

Whenever possible, each provision of SoP, and any Subscriber Agreements shall be interpreted in such manner as to be effective and valid under applicable law. If any

part or parts of these terms are held to be invalid, the remainder shall remain valid

and enforceable.

9.19.4 Enforcement (Attorneys’ Fees and Waiver of Rights)

No stipulation.



9.19.5 Force Majeure

Under this SoP, the PKI shall be relieved from any liability whatsoever for any losses, costs, expenses, liabilities, damages or claims, arising out of or related to delays in

performance or from failure to perform due to any natural causes beyond reasonable control.

9.20 Other Provisions

9.20.1 Conflict of Provisions

In the event of a conflict between the provisions of this SoP and any Subscriber Agreement, the order of precedence shall be the SoP, then the Subscriber

Agreement.

9.20.2 Limitation Period on Actions

Any legal actions involving a dispute that is related to this PKI or any services provided involving a certificate issued by this PKI shall be commenced within one

year after either the expiration or revocation of such certificate in dispute, or the date of provision of the disputed service or services involving the PKI certificate,

whichever is earlier. If any action arising out of a dispute related to a certificate issued by this PKI or any service involving certificates issued by this PKI is not

commenced prior to such time, any such action shall be barred.

Documents

Chevron Intranet Certification Authority G2 v1pki.chevron.com/policy/Chevron PKI Certification Authority G2 v1.pdf · COMPANY CONFIDENTIAL Chevron Public Key Infrastructure Certification