fortior solutions tscp pki credential service certificate ... · tscp pki credential service...

TSCP PKI Credential Service

Certificate Policy

of 105

Key Information:

Formal title: Fortior Solutions Public Key Infrastructure, Credential Issuing and Management Service X.509 Certificate Policy

Principal Policy OID: 1.3.6.1.4.1.38948.2.1 { iso (1) org (3) dod (6) internet (1) private (4) enterprise (1) Fortior Solutions (38948) FSPMA (2) FSPMA‐Policies (1) }

URL https://www.fortiorsolutions.com/certificates/

Filename Fortior Solutions TSCP PKI Credential Service Certificate Policy v2.1

Responsible authority: Fortior Solutions Policy Management Authority (FSPMA)

Version: 2.1

Effective date: Jan 2019

Classification / Distribution

Company public / Public distribution

Point‐of‐Contact: Fortior Solutions Fortior Solutions Policy Management Authority 5800 NE Pinefarm Ct., Hillsboro, OR 97124 United States of America email: [email protected] Phone: +1 503‐924‐5236

Fortior Solutions Credential Service X.509 Certificate Policy Version: 2.1

of 105

This page intentionally devoid of useful information

3/5/2019

X Dave ByrumDave ByrumFortior Solutions PMA ChairSigned by: David Allen Byrum SID10001286


of 105

APPROVALS Each formal release of this Certificate Policy (CP) requires approval by the Fortior Solutions Policy Management Authority (FSPMA).

Approval control: Version identification has three levels requiring the approval authority identified below according to level. Version identification is a simple integer sequencing at each level.

Version: A formal release of this CP which has a significant policy change requiring a vote by the FSPMA to approve;

Sub‐version: A formal release of this CP which has a no significant policy change and therefore does NOT require a vote by the FSPMA to approve;

Draft: A draft of this CP intended for review and/or recommendation as the next formal release.

When the identification at a given level is incremented all subordinate levels revert to zero. Only the first two levels need be shown in formal releases (level three is by default zero in any formal release). During the drafting of revisions this record shall record all draft versions and their approvals until such time as a formal release is approved. Records of ALL past drafting releases shall be preserved within the FSPMA for archival purposes.

On its effective date a formal version of this CP shall become the applicable version of the policy for all operational purposes and shall supersede all previous versions which shall thereby become redundant. The FSPMA shall preserve records of all past versions.

Approval authorities:

Top‐level: Fortior Solutions PMA; Second level: As top‐level; Third level: Author / Editor – for informal PMA member and development / editorial team review.

Approval record:

Version Approval date Summary of Changes

0.1 TBD Initial Rough Draft

1.0 09/15/2016 Final version approved by TSCP PMA

1.1 10/15/2016 Minor Updates as result of Compliance Audit

1.2 04/26/2018 Corporate Name Change

2.0 09/18/2018 More changes to reflect company name change and Sync with TSCP

2.1 1/10/2019 Minor updates as result of TSCP mapping and clarity for auditing.


of 105

CONTENTS

Contents ........................................................................................................................................................................................ 4

1 INTRODUCTION ................................................................................................................................................................... 13

1.1 Overview ..................................................................................................................................................................... 13

1.1.1 Certificate Policy ................................................................................................................................................. 13

1.1.2 Relationship between this CP and the CPSs ....................................................................................................... 13

1.1.3 Scope ................................................................................................................................................................... 13

1.2 Document Name and Identification ........................................................................................................................... 14

1.2.1 Object Identifiers (OIDs) ..................................................................................................................................... 14

1.3 PKI Participants ........................................................................................................................................................... 16

1.3.1 PKI Authorities .................................................................................................................................................... 16

1.3.2 Registration Authority (RA) ................................................................................................................................. 18

1.3.3 Subscribers .......................................................................................................................................................... 18

1.3.4 Relying Parties ..................................................................................................................................................... 18

1.3.5 Other Participants ............................................................................................................................................... 19

1.4 Certificate Usage ......................................................................................................................................................... 19

1.4.1 Appropriate Certificate Uses ............................................................................................................................... 19

1.4.2 Prohibited Certificate Uses ................................................................................................................................. 20

1.5 Policy Administration .................................................................................................................................................. 20

1.5.1 Organization Administering this Document ....................................................................................................... 20

1.5.2 Contact Person .................................................................................................................................................... 20

1.5.3 Person Determining CPS Suitability for the Policy .............................................................................................. 20

1.5.4 Fortior Solutions PKI CPS Approval Procedures .................................................................................................. 20

1.5.5 Waivers ............................................................................................................................................................... 20

1.6 Definitions and Acronyms ........................................................................................................................................... 20

2 Publication and PKI Repository Responsibilities ................................................................................................................. 21

2.1 PKI Repositories .......................................................................................................................................................... 21

2.1.1 Repository Obligations ............................................................................................................................................... 21

2.2 Publication of Certificate Information ........................................................................................................................ 21

2.2.1 Publication of CA Information............................................................................................................................. 21

2.2.2 Interoperability ................................................................................................................................................... 21

2.3 Time or Frequency of Publication ............................................................................................................................... 21

2.4 Access Controls on PKI Repositories ........................................................................................................................... 21

3 Identification and Authentication ...................................................................................................................................... 22

3.1 Naming ........................................................................................................................................................................ 22


of 105

3.1.1 Types of Names ................................................................................................................................................... 22

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

3.1.3 Anonymity or Pseudonymity of Subscribers ....................................................................................................... 22

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

3.1.5 Uniqueness of Names ......................................................................................................................................... 23

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

3.1.7 Name Claim Dispute Resolution Procedure ........................................................................................................ 23

3.2 Initial Identity Validation............................................................................................................................................. 23

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

3.2.2 Authentication of Organization Identity ............................................................................................................. 23

3.2.3 Authentication of Individual Identity .................................................................................................................. 23

3.2.4 Non‐verified Subscriber Information .................................................................................................................. 25

3.2.5 Validation of Authority ....................................................................................................................................... 25

3.2.6 Criteria for Interoperation .................................................................................................................................. 26

3.3 Identification and Authentication for Re‐Key Requests ............................................................................................. 26

3.3.1 Identification and Authentication for Routine Re‐Key ....................................................................................... 26

3.3.2 Identification and Authentication for Re‐Key After Revocation ......................................................................... 26

3.4 Identification and Authentication for Revocation Request ........................................................................................ 26

4 Certificate Life‐Cycle Operational Requirements ............................................................................................................... 27

4.1 Certificate Application ................................................................................................................................................ 27

4.1.1 Submission of Certificate Application ................................................................................................................. 27

4.1.2 Enrolment Process and Responsibilities ............................................................................................................. 27

4.2 Certificate Application Processing .............................................................................................................................. 27

4.2.1 Performing Identification and Authentication Functions ................................................................................... 27

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

4.2.3 Time to Process Certificate Applications ............................................................................................................ 27

4.3 Certificate Issuance ..................................................................................................................................................... 28

4.3.1 CA Actions during Certificate Issuance ............................................................................................................... 28

4.3.2 Notification to Subscriber of Certificate Issuance .............................................................................................. 28

4.4 Certificate Acceptance ................................................................................................................................................ 28

4.4.1 Conduct Constituting Certificate Acceptance ..................................................................................................... 28

4.4.2 Publication of the Certificate by the CA .............................................................................................................. 28

4.4.3 Notification of Certificate Issuance by the CA to other Entities ......................................................................... 28

4.5 Key Pair and Certificate Usage .................................................................................................................................... 28

4.5.1 Subscriber Private Key and Certificate Usage ..................................................................................................... 28

4.5.2 Relying Party Public Key and Certificate Usage .................................................................................................. 28


of 105

4.6 Certificate Renewal ..................................................................................................................................................... 29

4.6.1 Circumstance for Certificate Renewal ................................................................................................................ 29

4.6.2 Who May Request Renewal ................................................................................................................................ 29

4.6.3 Processing Certificate Renewal Requests ........................................................................................................... 29

4.6.4 Notification of New Certificate Issuance to Subscriber ...................................................................................... 29

4.6.5 Conduct Constituting Acceptance of a Renewal Certificate ............................................................................... 29

4.6.6 Publication of the Renewal Certificate by the CA ............................................................................................... 29

4.6.7 Notification of Certificate Issuance by the CA to other Entities ......................................................................... 29

4.7 Certificate Re‐Key ....................................................................................................................................................... 29

4.7.1 Circumstance for Certificate Re‐Key ................................................................................................................... 30

4.7.2 Who may Request Certification of a New Public Key ......................................................................................... 30

4.7.3 Processing Certificate Re‐Keying Requests ......................................................................................................... 30

4.7.4 Notification of new Certificate Issuance to Subscriber ....................................................................................... 30

4.7.5 Conduct Constituting Acceptance of a Re‐Keyed Certificate .............................................................................. 30

4.7.6 Publication of the Re‐Keyed Certificate by the CA ............................................................................................. 30

4.7.7 Notification of Certificate Issuance by the CA to Other Entities ........................................................................ 30

4.8 Certificate Modification .............................................................................................................................................. 30

4.8.1 Circumstance for Certificate Modification .......................................................................................................... 30

4.8.2 Who may Request Certificate Modification ....................................................................................................... 30

4.8.3 Processing Certificate Modification Requests .................................................................................................... 31

4.8.4 Notification of New Certificate Issuance to Subscriber ...................................................................................... 31

4.8.5 Conduct Constituting Acceptance of Modified Certificate ................................................................................. 31

4.8.6 Publication of the Modified Certificate by the CA .............................................................................................. 31

4.8.7 Notification of Certificate Issuance by the CA to Other Entities ........................................................................ 31

4.9 Certificate Revocation and Suspension ...................................................................................................................... 31

4.9.1 Circumstances for Revocation ............................................................................................................................ 31

4.9.2 Who can Request Revocation ............................................................................................................................. 32

4.9.3 Procedure for Revocation Request ..................................................................................................................... 32

4.9.4 Revocation Request Grace Period ...................................................................................................................... 33

4.9.5 Time Within Which the CA Must Process the Revocation Request .................................................................... 33

4.9.6 Revocation Checking Requirement for Relying Parties ...................................................................................... 33

4.9.7 CRL Issuance Frequency ...................................................................................................................................... 33

4.9.8 Maximum Latency for CRLs ................................................................................................................................. 34

4.9.9 On‐Line Revocation/Status Checking Availability ............................................................................................... 34

4.9.10 On‐Line Revocation Checking Requirements ...................................................................................................... 34

4.9.11 Other Forms of Revocation Advertisements Available ....................................................................................... 34


of 105

4.9.12 Special Requirements Related to Key Compromise ........................................................................................... 34

4.9.13 Circumstances for Suspension ............................................................................................................................ 35

4.9.14 Who can Request Suspension ............................................................................................................................. 35

4.9.15 Procedure for Suspension Request ..................................................................................................................... 35

4.9.16 Limits on Suspension Period ............................................................................................................................... 35

4.10 Certificate Status Services ........................................................................................................................................... 35

4.10.1 Operational Characteristics ................................................................................................................................ 35

4.10.2 Service Availability .............................................................................................................................................. 35

4.10.3 Optional Features ............................................................................................................................................... 35

4.11 End of Subscription ..................................................................................................................................................... 35

4.12 Key Escrow and Recovery ........................................................................................................................................... 35

4.12.1 Key Escrow and Recovery Policy and Practices................................................................................................... 35

4.12.2 Session Key Encapsulation and Recovery Policy and Practices .......................................................................... 35

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

5.1 Physical Controls ......................................................................................................................................................... 37

5.1.1 Site Location and Construction ........................................................................................................................... 37

5.1.2 Physical Access .................................................................................................................................................... 37

5.1.3 Power and Air Conditioning ................................................................................................................................ 38

5.1.4 Water Exposures ................................................................................................................................................. 38

5.1.5 Fire Prevention and Protection ........................................................................................................................... 38

5.1.6 Media Storage ..................................................................................................................................................... 38

5.1.7 Waste Disposal .................................................................................................................................................... 38

5.1.8 Off‐Site Backup ................................................................................................................................................... 38

5.2 Procedural Controls .................................................................................................................................................... 38

5.2.1 Trusted Roles ...................................................................................................................................................... 38

5.2.2 Number of Persons Required Per Task ............................................................................................................... 41

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

5.2.4 Roles Requiring Separation of Duties ................................................................................................................. 41

5.3 Personnel Controls ...................................................................................................................................................... 42

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

5.3.2 Background Check Procedures ........................................................................................................................... 42

5.3.3 Training Requirements ........................................................................................................................................ 43

5.3.4 Retraining Frequency and Requirements ........................................................................................................... 43

5.3.5 Job Rotation Frequency and Sequence ............................................................................................................... 43

5.3.6 Sanctions for Unauthorized Actions ................................................................................................................... 43

5.3.7 Independent Contractor Requirements .............................................................................................................. 43


of 105

5.3.8 Documentation Supplied to Personnel ............................................................................................................... 43

5.4 Audit Logging Procedures ........................................................................................................................................... 44

5.4.1 Types of Events Recorded ................................................................................................................................... 44

5.4.2 Frequency of Processing Audit Logs ................................................................................................................... 47

5.4.3 Retention Period for Audit Logs .......................................................................................................................... 48

5.4.4 Protection of Audit Log ....................................................................................................................................... 48

5.4.5 Audit Log Backup Procedures ............................................................................................................................. 48

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

5.4.7 Notification to Event‐Causing Subject ................................................................................................................ 48

5.4.8 Vulnerability Assessments .................................................................................................................................. 48

5.5 Records Archival ......................................................................................................................................................... 48

5.5.1 Types of Records Archived .................................................................................................................................. 48

5.5.2 Retention Period for Archive .............................................................................................................................. 50

5.5.3 Protection of Archive .......................................................................................................................................... 50

5.5.4 Archive Backup Procedures ................................................................................................................................ 50

5.5.5 Requirements for Time‐Stamping of Records..................................................................................................... 50

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

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

5.6 Key Changeover .......................................................................................................................................................... 50

5.7 Compromise and Disaster Recovery ........................................................................................................................... 51

5.7.1 Incident and Compromise Handling Procedures ................................................................................................ 51

5.7.2 Computing Resources, Software, and/or Data are Corrupted ........................................................................... 51

5.7.3 Private Key Compromise Procedures ................................................................................................................. 51

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

5.8 CA, CMS, CSA, or RA Termination ............................................................................................................................... 52

6 Technical Security Controls ................................................................................................................................................ 54

6.1 Key Pair Generation and Installation .......................................................................................................................... 54

6.1.1 Key Pair Generation ............................................................................................................................................ 54

6.1.2 Private Key Delivery to Subscriber ...................................................................................................................... 55

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

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

6.1.5 Key Sizes .............................................................................................................................................................. 56

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

6.1.7 Key Usage Purposes ............................................................................................................................................ 57

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

6.2.1 Cryptographic Module Standards and Controls ................................................................................................. 57


of 105

6.2.2 Private Key Multi‐Person Control ....................................................................................................................... 58

6.2.3 Private Key Escrow .............................................................................................................................................. 58

6.2.4 Private Key Backup .............................................................................................................................................. 58

6.2.5 Private Key Archival ............................................................................................................................................ 59

6.2.6 Private Key Transfer Into or From a Cryptographic Module ............................................................................... 59

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

6.2.8 Method of Activating Private Key ....................................................................................................................... 59

6.2.9 Method of Deactivating Private Key ................................................................................................................... 59

6.2.10 Method of Destroying Private Key ...................................................................................................................... 59

6.2.11 Cryptographic Module Rating ............................................................................................................................. 60

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

6.3.1 Public Key Archival .............................................................................................................................................. 60

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

6.4 Activation Data ........................................................................................................................................................... 60

6.4.1 Activation Data Generation and Installation ...................................................................................................... 60

6.4.2 Activation Data Protection .................................................................................................................................. 61

6.4.3 Other Aspects of Activation Data ........................................................................................................................ 61

6.5 Computer Security Controls ........................................................................................................................................ 61

6.5.1 Specific Computer Security Technical Requirements ......................................................................................... 61

6.5.2 Computer Security Rating ................................................................................................................................... 62

6.6 Life‐Cycle Technical Controls ...................................................................................................................................... 62

6.6.1 System Development Controls ........................................................................................................................... 62

6.6.2 Security Management Controls .......................................................................................................................... 62

6.6.3 Life‐Cycle Security Controls ................................................................................................................................ 62

6.7 Network Security Controls .......................................................................................................................................... 63

6.8 Time‐Stamping ............................................................................................................................................................ 63

7 PKI Interoperability Profiles for Repository, Certificate, CRL, and OCSP ............................................................................ 64

7.1 Repository Profile ............................................................................................................................................................. 64

7.1.1 Protocol ...................................................................................................................................................................... 64

7.1.2 Authentication ........................................................................................................................................................... 64

7.1.3 Naming ....................................................................................................................................................................... 64

7.1.4 Object Class ................................................................................................................................................................ 64

7.1.5 Attributes ................................................................................................................................................................... 64

7.2 Certificate Profile ........................................................................................................................................................ 65

7.2.1 Version Numbers ................................................................................................................................................ 65

7.2.2 Certificate Extensions ......................................................................................................................................... 65


of 105

7.2.3 Algorithm Object Identifiers ............................................................................................................................... 65

7.2.4 Name Forms ........................................................................................................................................................ 65

7.2.5 Name Constraints ............................................................................................................................................... 66

7.2.6 Certificate Policy Object Identifier ...................................................................................................................... 66

7.2.7 Usage of Policy Constraints Extension ................................................................................................................ 66

7.2.8 Policy Qualifiers Syntax and Semantics .............................................................................................................. 66

7.2.9 Processing Semantics for the Critical Certificate Policies Extension .................................................................. 66

7.3 CRL Profile ................................................................................................................................................................... 66

7.3.1 Version Numbers ................................................................................................................................................ 66

7.3.2 CRL and CRL Entry Extensions ............................................................................................................................. 66

7.4 OCSP Profile ................................................................................................................................................................ 67

7.4.1 Version Numbers ................................................................................................................................................ 67

7.4.2 OCSP Extensions .................................................................................................................................................. 67

8 Compliance Audit and Other Assessments ........................................................................................................................ 68

8.1 Frequency or Circumstances of Assessments ............................................................................................................. 68

8.2 Identity and Qualifications of Assessor ....................................................................................................................... 68

8.3 Assessor's Relationship to Assessed Entity ................................................................................................................. 68

8.4 Topics Covered by Assessment ................................................................................................................................... 68

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

8.6 Communication of Results .......................................................................................................................................... 69

9 Other Business and Legal Matters ...................................................................................................................................... 70

9.1 Fees ............................................................................................................................................................................. 70

9.1.1 Certificate Issuance or Renewal Fees ................................................................................................................. 70

9.1.2 Certificate Access Fee ......................................................................................................................................... 70

9.1.3 Revocation or Status Information Access Fees ................................................................................................... 70

9.1.4 Fees for Other Services ....................................................................................................................................... 70

9.1.5 Refund Policy ...................................................................................................................................................... 70

9.2 Financial Responsibility ............................................................................................................................................... 70

9.2.1 Insurance Coverage ............................................................................................................................................. 70

9.2.2 Other Assets ........................................................................................................................................................ 70

9.2.3 Insurance or Warranty Coverage for End‐Entities .............................................................................................. 70

9.3 Confidentiality of Business Information ..................................................................................................................... 70

9.4 Privacy of Personal Information ................................................................................................................................. 71

9.5 Intellectual Property Rights ........................................................................................................................................ 71

9.5.1 Property Rights in Certificates and Revocation Information .............................................................................. 71

9.5.2 Property Rights in this CP and related CPSs ........................................................................................................ 71


of 105

9.5.3 Property Rights in Names ................................................................................................................................... 71

9.5.4 Property Rights in Keys ....................................................................................................................................... 71

9.6 Representations and Warranties ................................................................................................................................ 71

9.6.1 The Fortior Solutions PKI CA Representations and Warranties .......................................................................... 71

9.6.2 Subscribers .......................................................................................................................................................... 72

9.6.3 Relying Parties ..................................................................................................................................................... 72

9.6.4 Affiliated Organizations ...................................................................................................................................... 73

9.6.5 Other Participants ............................................................................................................................................... 73

9.7 Disclaimers of Warranties ........................................................................................................................................... 73

9.8 Limitations of Liabilities .............................................................................................................................................. 73

9.9 Indemnities ................................................................................................................................................................. 74

9.9.2 Indemnification by Relying Parties and Subscribers ........................................................................................... 74

9.10 Term and Termination ................................................................................................................................................ 74

9.10.1 Term .................................................................................................................................................................... 74

9.10.2 Termination ......................................................................................................................................................... 74

9.10.3 Effect of Termination and Survival ..................................................................................................................... 75

9.11 Individual Notices and Communications with Participants ........................................................................................ 75

9.12 Amendments ............................................................................................................................................................... 75

9.12.1 Procedure for Amendment ................................................................................................................................. 75

9.12.2 Notification Mechanism and Period ................................................................................................................... 75

9.13 Dispute Resolution Provisions .................................................................................................................................... 75

9.13.1 Disputes between Fortior Solutions and Third Parties ....................................................................................... 75

9.13.2 Alternate Dispute Resolution Provisions ............................................................................................................ 75

9.14 Governing Law .............................................................................................................................................................. 76

9.15 Compliance with Applicable Law ................................................................................................................................ 76

9.16 Miscellaneous Provisions ............................................................................................................................................ 76

9.16.1 Entire Agreement ............................................................................................................................................... 76

9.16.2 Assignment .............................................................................................................................................................. 76

9.16.3 Severability .......................................................................................................................................................... 76

9.16.4 Waiver of Rights ....................................................................................................................................................... 76

9.16.5 Force Majeure ..................................................................................................................................................... 77

9.17 Other Provisions .......................................................................................................................................................... 77

10 Certificate, CRL, and OCSP Formats ................................................................................................................................ 78

10.1 PKI Root CA Certificate (Trust Anchor) ....................................................................................................................... 78

10.2 PKI Intermediate CA Certificate .................................................................................................................................. 78

10.3 PKI Signing CA Certificate ............................................................................................................................................ 79


of 105

10.4 PKI Principle CA to TSCP Bridge CA Certificate ........................................................................................................... 79

10.5 Subscriber Identity Certificate .................................................................................................................................... 80

10.6 Subscriber Signature Certificate ................................................................................................................................. 80

10.7 Subscriber Encryption Certificate ............................................................................................................................... 81

10.8 Card Authentication Certificate .................................................................................................................................. 82

10.9 Role Signature Certificate ........................................................................................................................................... 82

10.10 Role Encryption Certificate ..................................................................................................................................... 83

10.11 Content Signer Certificate ....................................................................................................................................... 84

10.12 Code signer certificate ............................................................................................................................................ 85

10.13 Device or Server Certificate .................................................................................................................................... 85

10.14 OCSP Responder Certificate ......................................................................................................................................... 86

10.15 CRL Format ................................................................................................................................................................... 86

10.15.1 Full and Complete CRL .................................................................................................................................... 86

10.15.2 Distribution Point Based Partitioned CRL .............................................................................................................. 87

10.16 OCSP Request Format .................................................................................................................................................. 88

10.17 OCSP Response Format................................................................................................................................................ 88

10.18 Extended Key Usage ...................................................................................................................................................... 89

11 BIBLIOGRAPHY ....................................................................................................................................................................... 91

12 ACRONYMS ............................................................................................................................................................................ 93

13 GLOSSARY .............................................................................................................................................................................. 95

Appendix A – PIV‐Interoperable Smart Card Definition ........................................................................................................... 103

Appendix B ‐ CARD MANAGEMENT SYSTEM REQUIREMENTS ................................................................................................. 105


of 105

1 INTRODUCTION

This document is Fortior Solutions’ Certificate Policy (CP) for its Credential Issuance and Management Service Public Key Infrastructure (hereafter ‘Fortior Solutions PKI’). As such, the policies found in this CP may be used by a Relying Party to trust certificates issued by the Fortior Solutions PKI. The policies in this CP represent five different assurance levels:

Medium

Medium‐CBP

Medium‐Hardware

Medium‐CBP‐Hardware

PIV‐I

This CP conforms to the Internet Engineering Task Force’s (IETF) RFC 3647, “Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practice Statement Framework” of 2003‐11 RFC 3647. The structure of sections 1 to 9 inclusive of this CP follow the Outline of a Set of Provisions defined in section 6 of RFC 3647 and additional sections are appended thereafter in order to convey additional necessary information.

1.1 Overview

1.1.1 Certificate Policy The Fortior Solutions PKI certificate policy Object Identifiers (OIDs) correspond to specific assurance levels established by this CP, and shall be available to Relying Parties. Certificates issued under the policies in this CP shall assert the appropriate level of assurance. In this CP and its associated CPS, references to a specific assurance level or certificate associated with an assurance level will be italicized as this example for FS‐PKI‐PIV‐I‐hw for the Fortior Solutions PKI PIV‐I hardware assurance level.

Fortior Solutions’ PKI shall not assert TSCP Bridge Certification Authority (TBCA) CP OIDS in any issued certificates, other than the policyMappings extension in order to establish the equivalency between a TBCA OID and an OID in the Fortior Solutions CP.

1.1.2 Relationship between this CP and the CPSs This CP documents the requirements for certificate assurance levels the Fortior Solutions PKI infrastructure must meet, thus giving any Relying Party confidence that the certificate they are presented with may be trusted. The Fortior Solutions PKI Certification Practice Statement (CPS) puts in practice the policy requirements stated in this CP.

1.1.3 Scope The Fortior Solutions PKI is a Trust network that its Subscribers and Relying Parties may use to provide interoperability with Federal Government and commercial entities. The Fortior Solutions PKI CAs shall issue PIV‐I certificates only to properly identified and vetted Subscribers. The Fortior Solutions PKI CAs that issue certificates at the PIV‐I Assurance Level (AL) 4 shall meet all requirements of PIV‐I laid out in FIPS 2011 and the ‘Personal Identity Verification Interoperability For Non‐Federal Issuers’ (Issued by the Federal CIO Council in May 2009), as

1 Since PIV‐I is not strictly a federal program and not run under federal government Relying Parties, private companies that issue PIV‐I certificates cannot comply with every requirement stated in FIPS 201. There are a few requirements in FIPS 201 that only federal government entities can meet. To this end, this CP states requirements that make it 'compatible' with FIPS 201, not 'compliant.'


of 105

well as the X.509 Certificate Policy For the Federal Bridge Certification Authority (FBCA) current version. This CP documents the specific requirements the Fortior Solutions PKI shall follow when issuing those certificates.

1.2 DocumentNameandIdentification

There are nine policies specified in this CP. There are three policies specific to PIV‐I, and two main policies one for Hardware and one for Software that are subdivided into regular AL 3 Software, CBP Software and Software for Devices, and one for Hardware that is generally AL 4 including regular Hardware, CBP Hardware and Software or Hardware for Devices. Each level of assurance has an associated OID to be asserted in certificates. PIV‐I OIDs shall be issued in accordance with the strictest practices prescribed in Fortior Solutions PKI CPS.

1.2.1 Object Identifiers (OIDs) OIDs defined within this CP are subordinate to Fortior Solutions’ IANA‐registered Private Enterprise Number (IANA‐PEN‐arc). The FSPMA has the authority to allocate sub‐assignments beneath Fortior Solutions’ PMA arc, which is defined thus:

IANA‐PEN‐arc ::= { iso (1) org (3) dod (6) internet (1) private (4) enterprise (1) } 1.3.6.1.4.1.

Fortior Solutions ::= { IANA‐PEN‐arc 38948 } 1.3.6.1.4.1.38948 Ref. http://www.iana.org/assignments/enterprise‐numbers)

FSPMA ::= { Fortior Solutions 2 } 1.3.6.1.4.1.38948.2

FSPMA‐Policies ::= { FSPMA 1 }

1.3.6.1.4.1.38948.2.1

FSPKIRootCA ::= { FSPMA 2 }

1.3.6.1.4.1.38948.2.3

FSPKI ::= { FSPMA‐Policies 2 }

1.3.6.1.4.1.38948.2.1.2

OIDs defined by this CP stem from the first numbers of 1.3.6.1.4.1.38948.2.1.2 for the FS‐PKI OID and are as follows with each new number in the table below appending onto the FS‐PKI OID:

FS‐PKI‐MediumSw ::= { FSPKI 1 }

FS‐PKI‐MediumHw ::= { FSPKI 2 }

FS‐PKI‐MediumSwDev ::= { FSPKI 10 }

FS‐PKI‐MediumHwDev ::= { FSPKI 11 }

FS‐PKI‐MediumCBPSw ::= { FSPKI 4 }

FS‐PKI‐MediumCBPHw ::= { FSPKI 5 }

FS‐PKI‐PIV‐I‐hw ::= { FSPKI 7 }

FS‐PKI‐PIV‐I‐cardAuth ::= { FSPKI 8 }


of 105

FS‐PKI‐PIV‐I‐contentSign ::= { FSPKI 9 } Unless otherwise stated, a requirement stated in this CP applies to all Assurance Levels.

The Fortior Solutions PKI PIV‐I Content Signing certificate is reserved for use by the CMS to sign PIV‐I card security objects.

Unless otherwise stated, a requirement stated for the Medium‐Hardware Assurance Level also applies to the Fortior Solutions PKI PIV‐I Assurance Level.

The requirements for FS‐PKI‐MediumSwDev and FS‐PKI‐MediumHwDev are the same as the requirements for the Medium Assurance policy, with the exception of identity proofing, re‐key, and activation data. FS‐PKI‐MediumSwDev and FS‐PKI‐MediumHwDev policies are restricted to devices and systems. The term “device” refers to a non‐person entity, i.,e., hardware device or software application.


of 105

Figure 1 – OID Architecture

1.3 PKIParticipants

This section documents the requirements for the various roles used in the Fortior Solutions PKI. Throughout this CP when the CP refers to the term ‘Fortior Solutions PKI’ generally the components alluded to in this label include the CA(s) CSA and CMS. Where the term has more limited scope, the specific components will be called out.

1.3.1 PKI Authorities

1.3.1.1 Fortior Solutions Legally obligating Fortior Solutions to relevant contracts, policies, and PKI Bridge Service Agreements

(MTFSAs) or similar agreements with cross‐certified Entities

1.3.1.2 Fortior Solutions Policy Management Authority (FSPMA) The FSPMA has the following general responsibilities, in accordance with the further terms of the FSPMA Charter:

Maintenance and Approval of this CP, its associated Certificate Practice Statement (CPS), its Key Recovery Practice Statement (KRPS), its Registration Authority Practice Statement (RPS), various Standard Operating Procedures (SOP), other associated documentation, and any revisions to these documents; and

Upon completion and maintenance of an agreement maintaining cross‐certification compliance with the Transglobal Secure Collaboration Program Bridge Certification Authority (TSCP)

A complete description of FSPMA roles and responsibilities is provided in the FSPMA Charter.

1.3.1.2 F o r t i o r S o l u t i o n s Operational Authority (OA) The Fortior Solutions OA is responsible for operating the Fortior Solutions PKI CAs in a manner commensurate with the requirements in this CP. This work includes the following:

a. Issuing certificates;

b. Revoking certificates;

c. Issuing periodic Certificate Revocation Lists (CRL);

d. Making CRLs available by Lightweight Directory Access Protocol (LDAP) and/or Hypertext Transfer Protocol (HTTP) as directed in later sections of this CP; and

e. Managing the Key Escrow Database (KED) and requests for escrowed private keys.

1.3.1.2.1 Fortior Solutions Operational Authority Manager The Fortior Solutions PKI Program Manager is also the Operational Authority Manager and is the individual within Fortior Solutions who has principal responsibility for overseeing the proper operation of the Fortior Solutions PKI CAs including the Fortior Solutions PKI Repository, as well as the Card Management System (CMS) and who oversees appointment of the Operational Authority Staff.

1.3.1.3 Fortior Solutions PKI Root CA The Fortior Soltuions PKI Root CA is authorized to be the self‐signed Root CA for the Fortior Solutions PKI and issues the PKI Intermediate CAs. The Fortior Solutions PKI Root CA is maintained offline when not in operation. When required the Fortior Solutions. PKI Root CA will be brought online behind robust physical and logical boundaries to issue Intermediate CAs, CA revocations, and a year’s worth of 30 day CRLs, as appropriate, then it is shut down and stored back in the offline secure storage container.


of 105

1.3.1.4 Fortior Solutions PKI Intermediate CA The Fortior Solutions PKI Root CA issues Intermediate CAs. PKI Intermediate CAs only issue Fortior Solutions PKI Signing CAs, cross‐certificates, and CRLs, as appropriate. PKI Intermediate CAs are operated online and issue daily CRLs. The Intermediate PCA is the CA that issues cross‐certificates to the TSCP Bridge.

1.3.1.5 Fortior Solutions PKI Signing CA The Signing CAs associated with this CP are Signing CAs that issue certificates in accordance with the Assurance Levels covered in this CP. They shall only issue certificates to End‐Entities; they shall not issue certificates to other CAs.

As operated by the OA, the Fortior Solutions PKI Signing CAs shall be responsible for all aspects of the issuance and management of end‐entity certificates as required by this CP, including the following:

a. Control over the registration process;

b. The identification and authentication process;

c. The certificate manufacturing process;

d. The publication of certificates;

e. The revocation of certificates; and

f. Ensuring that all aspects of the services, operations, and infrastructure related to certificates issued under this CP are performed in accordance with the requirements, representations, and warranties of this CP.

1.3.1.6 Principal Certification Authority (PCA) A PCA is a CA within a PKI that has been designated to interoperate directly with an external domain CA (i.e., through the exchange of cross‐certificates) and perform the role of signing new subordinate CAs as necessary for the Fortior Solutions PKI.

The Fortior Solutions PKI Intermediate PCA is a PCA in the Fortior Solutions PKI. Its sole PCA functions shall be to enable cross‐certification with the TSCP Bridge and sign the Fortior Solutions PKI Signing CAs and other future subordinate CA certificates that Fortior Solutions will stand up.

As operated by the Fortior Solutions PKI OA, the Fortior Solutions PKI Intermediate PCA (in its PCA capacity) is responsible for all aspects of the issuance and management of cross‐certificates issued to the TSCP Bridge, including the following:

a. Control over the registration process;

b. The identification and authentication process;

c. The cross‐certificate manufacturing process;

d. The publication of cross‐certificates;

e. The revocation of cross‐certificates; and

f. Ensuring that all aspects of the services, operations, and infrastructure related to cross‐certificates issued under this CP are performed in accordance with the requirements, representations, and warranties of this CP.

1.3.1.7 Certificate Status Authority (CSA) A CSA is an authority that provides status of certificates or certification paths. CSAs can be operated in conjunction with the CAs or independent of the CAs. Examples of CSAs include the following:

a. Online Certificate Status Protocol (OCSP) Responders that provide revocation status of certificates; or


of 105

b. Simple Certificate Validation Protocol (SCVP) Servers that validate certification paths or provide revocation status checking services.

OCSP Responders that are keyless and simply repeat responses signed by other Responders and SCVP Servers that do not provide certificate validation services adhere to the same security requirements as Repositories.

When Fortior Solutions PKI Signing CAs issues certificates at the FS‐PKI‐PIV‐I Assurance Levels, it shall provide an OCSP Responder. Furthermore, this OCSP Responder may be issued a CA‐delegated certificate in order to ensure interoperability with Relying Parties.

The Fortior Solutions PKI Root CA 2018 does not provide certificate Status information via OCSP, and therefore shall not provide an OCSP Responder.

1.3.1.8 Card Management System (CMS) A CMS is responsible for managing smart card token content. In the context of this CP, the Fortior Solutions PKI CMS requirements are mandatory for all Assurance Levels. The FSPMA bears the responsibility for ensuring that the Fortior Solutions PKI CMS meets the requirements described in this CP, including the requirements in section 1.4.1 and 12. The CMS shall not be issued certificates that express the FS‐PKI‐PIV‐I‐hw or FS‐PKI‐PIV‐I‐cardAuth policy OIDs.

1.3.2 Registration Authority (RA) An RA is the entity that collects and verifies each Subscriber's identity and information that are to be entered into his or her public key certificate. An RA interacts with the CA to enter and approve the Subscriber certificate request information. The Fortior Solutions PKI OA acts as the RA for all Fortior Solutions PKI CAs. It performs its function in accordance with the Fortior Solutions PKI CPS approved by the FSPMA.

1.3.2.1 Trusted Agent (TA) A TA is a person who may verify Subscriber identity and information on behalf of an RA. A TA shall not have privileges on the CA. Information shall be verified in accordance with section 3.2 and communicated to the RA in a secure manner.

1.3.3 Subscribers A Subscriber is the entity whose name appears as the subject in an end‐entity certificate, agrees to use its key and certificate in accordance with the certificate policy asserted in the certificate, and does not itself issue certificates with the FS‐PKI‐PIV‐I assurance level. CAs are sometimes technically considered “subscribers” in a PKI. However, the term “Subscriber” as used in this document refers only to those entities or persons who request certificates for uses other than signing and issuing certificates or certificate status information. These proper uses include applying a digital signature to a document, encrypting documents, card authentication, and other uses.

Other properly designated Subscribers include servers and devices that have a human Sponsor that bears responsibility for the certificate issued to the server or device.

1.3.3.1 Organizational Affiliation Affiliated Organizations will be required to authorize the affiliation of Subscribers with the organization, and will be required to inform the Fortior Solutions PKI CA in writing of any severance of affiliation with any current Subscriber.

Subscriber certificates may be issued in conjunction with an organization that has a relationship with the Subscriber; this is termed affiliation. For the FS‐PKI‐PIV‐I assurance level the organizational affiliation shall be indicated in a relative distinguished name in the subject field in the certificate, and the certificate shall be revoked in accordance with Section 4.9.1 when affiliation is terminated.

1.3.4 Relying Parties A Relying Party is the entity that relies on the validity of the binding of the Subscriber's name to a public key. The Relying Party is responsible for deciding whether and how to check the validity of the certificate by checking the appropriate certificate status information. The Relying Party can use the certificate to verify the integrity of a


of 105

digitally signed message, to identify the creator of a message, or to establish confidential communications with the holder of the certificate. A Relying Party may use information in the certificate (such as certificate policy identifiers) to determine the suitability of the certificate for a particular use.

1.3.5 Other Participants The Fortior Solutions PKI operating under this CP may require the services of other authorities. The Fortior Solutions PKI CPS shall define the services, identify the parties responsible for providing such services, and the mechanisms used to support these services. Other authorities that may provide services to Fortior Solutions’ PKI may include:

The Fortior Solutions IDMS

The Fortior Solutions Information Technology group

The Fortior Solutions Information Assurance group

1.4 CertificateUsage

1.4.1 Appropriate Certificate Uses The sensitivity of the information processed or protected using certificates issued by the Fortior Solutions PKI CA will vary. Entities must evaluate the environment and the associated threats and vulnerabilities and determine the level of risk they are willing to accept based on the sensitivity or significance of the information. This evaluation is done by each Entity for each application and is not controlled by this CP.

The certificate levels of assurance contained in this CP as in section 1.2 are set forth below, as well as a brief and non‐binding description of the applicability for applications suited to each level.

Assurance Level Applicability

FS‐PKI‐PIV‐I‐cardAuth This level is relevant to environments where risks and consequences of data compromise are high. This includes contactless smart card readers where use of an activation PIN is not practical.

FS‐PKI‐MediumHw, FS‐PKI‐MediumCBPHw, or

FS‐PKI‐MediumHwDev

This level is relevant to environments where risks and consequences of data compromise are moderate. These certificates are issued to human Subscribers or devices and servers. Private Keys are stored in hardware at this Assurance Level.

FS‐PKI‐PIV‐I‐hw or

FS‐PKI‐PIV‐I‐contentSign

This level is relevant to environments where risks and consequences of data compromise are high. This may include transactions having substantial monetary value or risk of fraud, or involving access to private information where the likelihood of malicious access is substantial. FS‐PKI‐PIV‐I‐contentSigning is only issued to the CMS. FS‐PKI‐PIV‐I‐hardware Subscriber Private Keys are stored in hardware at this Assurance Level.

FS‐PKI‐MediumSw, FS‐PKI‐MediumCBPSw, or FS‐PKI‐MediumSwDev

This level is relevant to environments where risks and consequences of data compromise are moderate. These certificates may be issued to human Subscribers or devices and servers. Private Keys are stored in software at this Assurance Level.

The Relying Party must first determine the level of assurance required for an application, and then select the certificate appropriate for meeting the needs of that application.


of 105

This will be determined by evaluating the various risk factors including the value of the information, the threat environment, and the existing protection of the information environment. These determinations are made by the Relying Party and are not controlled by the FSPMA or OA.

1.4.2 Prohibited Certificate Uses No stipulation.

1.5 PolicyAdministration

1.5.1 Organization Administering this Document The FSPMA is responsible for all aspects of this CP.

1.5.2 Contact Person Questions regarding this CP shall be directed to the Point of Contact defined on the cover page of this CP.

1.5.3 Person Determining CPS Suitability for the Policy The FSPMA shall approve the Fortior Solutions PKI CPS and commission an analysis to determine whether that CPS conforms to the Fortior Solutions PKI CP. Information regarding this compliance analysis is found in section 8.

1.5.4 Fortior Solutions PKI CPS Approval Procedures By its very name, a CPS details “how” to implement the policies in this CP. Just as the FSPMA is responsible for approving this CP, the FSPMA is also responsible for the Fortior Solutions PKI CPS(s).

1.5.5 Waivers There shall be no waivers to this CP.

1.6 DefinitionsandAcronyms

See sections 12 and 13


of 105

2 PUBLICATIONANDPKIREPOSITORYRESPONSIBILITIES

2.1 PKIRepositories

The Fortior Solutions PKI shall make its PKI Repositories available to Relying Parties over the Internet. These Repositories shall provide the appropriate information, including but not limited to, CA certificates, CRLs, and Authority Revocation Lists (ARLs).

Fortior Solutions PKI shall be interoperable with the TBCA repository.

2.1.1 Repository Obligations The Fortior Solutions PKI OA may use a variety of mechanisms for posting information into the repositories as required by this CP. These mechanisms shall, at a minimum include the following:

a. Web Server System accessible through the Hypertext Transport Protocol (HTTP)

b. Availability of the information as required by the certificate information posting and retrieval stipulations of this CP; and

c. Access control mechanisms when needed to protect repository information as described in later sections.

2.2 PublicationofCertificateInformation

2.2.1 Publication of CA Information The Fortior Solutions PKI shall publish such information concerning the Fortior Solutions PKI CAs necessary to support their use and operation by Relying Parties. Valid Uniform Resource Information shall be made available to Relying Parties.

All CAs, at a minimum, shall post CA certificates and CRLs.

The Fortior Solutions PKI Repositories hosted by the OA containing certificates and certificate status information shall provide 24 hour per day/365 day per year availability. Fortior Solutions shall implement features to provide high levels of PKI Repository reliability (99% availability or better per year and scheduled downtime of 0.5% or less annually).

2.2.2 Interoperability See section 2.1

2.3 TimeorFrequencyofPublication

Certificates and certificate status information shall be published according to the stipulations of section 4 of this CP.

2.4 AccessControlsonPKIRepositories

Any PKI Repository information not intended for public dissemination or modification shall be protected. Public keys and certificate status information in the Fortior Solutions PKI Repository shall be publicly available over the Internet to Federal Relying Parties as per section 2.1.


of 105

3 IDENTIFICATIONANDAUTHENTICATION

3.1 Naming

3.1.1 Types of Names The Fortior Solutions PKI CAs shall generate and issue certificates with a unique and non‐null X.500 Distinguished Name (DN) in the Issuer and Subject fields, and the certificates may include additional names via the subjectAltName extension, provided it is marked noncritical, and is in accordance with the profiles in section 10.

For certificates issued to human Subscribers, the subject DN shall either contain the value ‘Unaffiliated’ in the last organizational unit (ou) attribute or shall contain the affiliated organization name in an appropriate relative distinguished name attribute (i.e., organization (o), organizational unit (ou), or domain component (dc) attribute). An affiliated Subscriber’s DN would look something like this:

cn=John Doe, ou=<Company X>, o=Fortior Solutions

, c=US

FS‐PKI‐PIV‐I‐contentSign certificates shall clearly indicate Fortior Solutions as the organization administering the CMS.

FS‐PKI‐PIV‐I‐cardAuth certificate’s subject DN shall not contain the common name (cn). Instead, the DN shall populate the serialNumber attribute with the Universally Unique Identifier (UUID) associated with the card as defined by RFC 4122.

For FS‐PKI‐PIV‐I‐cardAuth certificates, the subject DN shall either contain the value ‘Unaffiliated’ in the last organizational unit (ou) attribute or shall contain the affiliated organization name in an appropriate relative distinguished name attribute (i.e., organization (o), organizational unit (ou), or domain component (dc) attribute). FS‐PKI‐PIV‐I‐cardAuth certificates shall also contain a non‐null Subject Name and Subject Alternative Name.

When issuing any FS‐PKI certificate to unaffiliated individuals, the DN shall include ‘ou=unaffiliated, o=Fortior Solutions’ along with any other required DN attributes for the DN written for the specific individual. An example DN for unaffiliated would look like this:

cn=John Doe, ou=unaffiliated, o=Fortior Solutions, c=US

3.1.2 Need for Names to be Meaningful The certificates issued pursuant to this CP are meaningful only if the names that appear in the certificates can be understood and used by Relying Parties. Names used in the certificates must identify the person or object to which they are assigned in a meaningful way. Additionally, all DNs must be unique to prevent accidental or deliberate reuse of DNs. See section 3.1.5 for more details on name uniqueness.

Appropriate DNs with a Common Name (CN) that is understandable for humans shall be used in Identity, Signature, Encryption, and Device certificates. Legal names are appropriate for humans, while IP address, Fully Qualified Doman Name (FQDN), or model name and serial number may be used for devices and other equipment.

All DNs shall accurately reflect the organization with whom the Subject is affiliated. When User Principal Name (UPN) is used it shall be unique and accurately reflect organizational structure.

3.1.3 Anonymity or Pseudonymity of Subscribers CA certificates shall not contain anonymous or pseudonymous identities.

DNs in certificates issued to Subscribers and devices may contain a pseudonym to meet local privacy regulations as long as name space uniqueness requirements are met and as long as such name is unique and traceable to the actual entity.

3.1.4 Rules for Interpreting Various Name Forms


of 105

Rules for interpreting name forms shall be contained in the applicable certificate profile name form in section 7.1.4. The Fortior Solutions PKI is responsible for controlling the name space as per the rules for interpreting UUIDs found in RFC 4122.

3.1.5 Uniqueness of Names Name uniqueness shall be enforced in certificates issued by the Fortior Solutions PKI CAs. The CMS shall enforce name uniqueness within the X.500 name space, in which they have been authorized. However, name uniqueness is not violated when multiple certificates are issued to the same entity.

The OA shall be responsible for ensuring name uniqueness in certificates issued by the Fortior Solutions PKI CAs. The Fortior Solutions PKI CPS shall define the following:

The name forms used in the architecture

How the Fortior Solutions PKI CAs will allocate names within the Subscriber community to guarantee name uniqueness among current and past Subscribers or between the subscribers of two different organizations, (e.g., if “Jane Doe” leaves a CA’s community of Subscribers, and a new, different “Jane Doe” enters the community of Subscribers) a unique name shall be provided in the Subject DN belonging to the second person.

The name space used for all Subject DNs shall be as indicated in section 7.2.4.

3.1.6 Recognition, Authentication, and Role of Trademarks No stipulation

3.1.7 Name Claim Dispute Resolution Procedure The FSPMA shall resolve or cause to be resolved any name collision brought to its attention that may affect interoperability.

3.2 InitialIdentityValidation

3.2.1 Method to Prove Possession of Private Key In all cases where the party named in a certificate generates their own keys they shall be required to prove possession of the private key corresponding to the public key in the certificate Request. For signature keys, this may be done by the entity using its private key to sign a value and providing that value to the Fortior Solutions PKI CA. The Fortior Solutions PKI CA shall then validate the signature using the party‘s public key. The FSPMA may allow other mechanisms that are at least as secure as those described here.

3.2.2 Authentication of Organization Identity The existence of an affiliated organization shall be verified prior to issuing any end user certificates on its behalf.

Before processing requests for end‐user certificates other than for unaffiliated subscribers, the subscriber’s organization shall be verified with the affiliated organization, and the request shall include the name and address of the organization. The RA shall verify the information, in addition to the authenticity of the requesting representative and the representative‘s authorization to act in the name of the organization.

3.2.3 Authentication of Individual Identity FS‐PKI‐PIV‐I certificates shall be issued only to human subscribers. Other certificates may be issued to devices upon authentication of the Subscriber in the case of Derived keys, or a human Sponsor in the case of other devices.

3.2.3.1 Authentication of Human Subscribers For the FS‐PKI‐PIV‐I Assurance Level identity shall be established by in‐person proofing before the RA, or a Trusted Agent, while for Assurance Levels other than FS‐PKI‐PIV‐I Assurance Levels, an entity certified by a State or Federal Entity as being authorized to confirm identities; information provided shall be verified to ensure legitimacy. For Assurance Levels other than FS‐PKI‐PIV‐I the applicant shall present one valid National Government‐issued photo


of 105

ID, or two valid non‐National Government IDs, one of which shall be a recent photo ID (i.e., driver's license). For all supported assurance levels, identity shall be established no more than thirty (30) days before initial certificate issuance.

Authentication of individual identity using antecedent in‐person identity‐proofing data is not supported by this CP. The RA shall ensure that the applicant's identity information is verified and checked in accordance with this CP and the Fortior Solutions PKI CPS. The RA shall ensure that the applicant's identity information and public key are properly bound, and the RA shall record the process that was followed for issuance of each certificate. Process information shall depend upon the certificate level of assurance and shall be addressed in the Fortior Solutions PKI CPS. The process documentation shall include the following:

a. The identity of the person performing the identity verification;

b. A signed declaration by that person that he or she verified the identity of the applicant as required by this certificate policy using the format set forth at 28 U.S.C. 1746 (declaration under penalty of perjury) or comparable procedure under local law. The signature on the declaration may be either a handwritten or digital signature using a certificate that is of equal or higher level of assurance as the credential being issued;

c. Unique identifying numbers from the ID of the verifier and from an ID of the applicant; d. The date and time of the verification; and

e. A declaration of identity signed by the applicant using a handwritten signature or appropriate digital signature (see Practice Note) and performed in the presence of the person performing the identity authentication, using the format set forth at 28 U.S.C. 1746 (declaration under penalty of perjury) or comparable procedure under local law;

Practice Note: In those cases in which the individual is in possession of a valid digital signature credential of equal or higher level of assurance or the signature certificate is generated immediately upon authentication of the applicant’s identity, the applicant may sign the declaration of identity and certificate of acceptance using the digital credential. In the latter case, if the applicant fails to sign the declaration of identity then the certificate must be revoked.

At the FS‐PKI‐PIV‐I‐hw and FS‐PKI‐PIV‐I‐cardAuth Assurance Levels, the following additional requirements shall apply:

a. In‐person antecedent method shall not be used;

b. Identity proofing shall be performed by an RA or TA only;

c. The applicant shall present two identity source documents in original form and the forms shall be examined to verify authenticity. Allowable identity source documents are listed in Form I‐9, OMB No. 1115‐0136, Employment Eligibility Verification although the instruction contained in federal Form I‐9 for acceptable documents for employment shall not be followed. At least one document shall be a valid State or Federal Government‐issued photo ID;

d. Two electronic fingerprints shall be collected and stored on the card for automated authentication during card usage (see section 11 for additional requirements);

e. An electronic facial image shall be collected. The facial image shall be printed on the card, and stored on the card for visual authentication during card usage. A new facial image shall be collected each time a card is issued (see section 11 for additional requirements); and

f. The identity proofing, registration, and issuance process shall adhere to the principle of separation of duties to ensure that no single individual has the capability to issue a credential without the cooperation of another authorized person.

3.2.3.2 Authentication of Human Subscribers for Role-Based Certificates Role‐based certificates shall not be issued under the FS PKI PIV‐I assurance levels.


of 105

For assurance levels other than FS‐PKI‐PIV‐I there may be human subscribers who wish to be issued role‐based certificates. In this case, these certificates shall identify a specific role in which the subscriber is authorized to act. Role‐based certificates shall be issued to individual subscribers and protected in the same manner as individual certificates. The signature key pair will be unique to each individual role‐based certificate and the encryption key pair and encryption certificate may be shared. The subscriber’s name shall not be used and the role‐based certificates shall be issued in the interest of supporting accepted business practices.

The Fortior Solutions PKI shall record the information identified in Section 3.2.3.1 for a sponsor associated with the role before issuing a role‐based certificate. The sponsor must hold an individual certificate in his/her own name issued by the same CA at the same or higher assurance level as the role‐based certificate. Sponsors shall have the same organization affiliation as those the sponsor is authorizing for role‐based certificates.

The procedures for issuing role‐based tokens must comply with all other stipulations of this CP (e.g., key generation, private key protection, and Subscriber obligations). The Fortior Solutions PKI CPS shall have further details on how role‐based certificates are handled.

3.2.3.3 Authentication of Human Subscribers for Group Certificates Not Supported

3.2.3.4 Authentication of Component Identities Some computing and communications components (routers, firewalls, servers, etc.) will be named as certificate subjects. In such cases, the component (usually referred to as a ‘device’) shall have a human sponsor (the ‘PKI Sponsor’). In the case a human sponsor is changed, the new sponsor shall review the status of each device under his/her sponsorship to ensure it is still authorized to receive certificates. These certificates shall be issued only to entities that are affiliated with Fortior Solutions. The CPS shall describe procedures to ensure that certificate accountability is maintained.

The PKI Sponsor shall be responsible for providing the following registration information:

a. Equipment identification (i.e., serial number) or service name (i.e., DNS name) sufficient to uniquely identify the Subject;

b. Equipment public keys;

c. Equipment authorizations and attributes (if any are to be included in the certificate); and

d. Contact information to enable the CA or RA to communicate with the sponsor when required.

The registration information supplied by the PKI Sponsor shall be verified to an Assurance Level commensurate with the certificate Assurance Level being requested. Any time a device certificate is renewed or re‐issued, these next verification steps shall be followed.

Acceptable methods for performing this authentication and integrity checking shall include, but need not be limited to:

a. Verification of digitally signed messages sent from the PKI Sponsor (using certificates of equivalent or greater assurance than that being requested); or

b. In‐person registration by the PKI Sponsor, with the identity of the PKI Sponsor confirmed in accordance with the requirements of section 3.2.3.

3.2.4 Non-verified Subscriber Information Information that is not verified shall not be included in certificates.

3.2.5 Validation of Authority Certificates that contain explicit or implicit organizational affiliation shall be issued only after ascertaining the applicant has the authorization to act on behalf of the organization in the asserted capacity. Approval of the FSPMA is required prior to issuing a CA certificate in the Fortior Solutions PKI.


of 105

3.2.6 Criteria for Interoperation The Fortior Solutions PKI shall not serve as its own PIV‐I Bridge connected to the TSCP Bridge. In any cases where an external PKI‐domain CA wishes to interoperate with the Fortior Solutions PKI, the external PKI shall adhere to the following requirements in addition to all requirements in this CP:

a. Have a contractual relationship with Fortior Solutions;

b. Have a CP and CPS mapped to and determined by the FSPMA to be in conformance with this CP;

c. Operate a PKI that has undergone a successful compliance audit pursuant to section 8 of this CP and as set forth in the Subject CA CP;

d. Issue certificates compliant with the profiles described in this CP, and make certificate status information available in compliance with this CP; and

e. Provide CA certificate and certificate status information to the Relying Parties in compliance with this CP.

3.3 IdentificationandAuthenticationforRe‐KeyRequests

3.3.1 Identification and Authentication for Routine Re-Key Subscribers shall be authenticated through use of their current valid and unexpired Signing Key or by using the initial identity‐proofing process as described in section 3.2.

Subscribers with FS‐PKI‐MediumSw, FS‐PKI‐MediumHw, FS‐PKI‐MediumCBPSw, FS‐PKI‐MediumCBPHw and/or FS‐PKI‐PIV‐I‐cardAuth certificates shall re‐establish identity through the initial identity‐proofing process at least once every nine years.

For FS‐PKI‐MediumSwDev and FS‐PKI‐MediumHwDev certificates, identity may be established through the use of current signature key or using means commensurate with the strength of the certificate being requested, except that identity shall be established through initial registration process at least once every nine years from the time of initial registration.

When a current public key certificate is used for identification and authentication purposes, the expiration date of the new certificate shall not extend beyond the initial identity‐proofing times specified in the paragraphs above, and the Assurance Level of the new certificate shall not exceed the Assurance Level of the certificate being used for identification and authentication purposes.

A CA shall be authenticated through use of a private key and corresponding valid certificate or one of the initial identity proofing processes described in Section 3.2.3.1 and 3.2.3.2. If it has been more than three years since a CA was identified as required in Section 3.2, identity shall be re‐established through the initial identity proofing process.

3.3.2 Identification and Authentication for Re-Key After Revocation Once a certificate has been revoked, the certificate subject (i.e., Subscriber or device) shall be authenticated by using the initial identity‐proofing process as described in section 3.2 or through use of another current, valid public key certificate in accordance with section 3.3.1.

3.4 IdentificationandAuthenticationforRevocationRequest

Revocation requests shall always be authenticated. Requests to revoke a certificate may be authenticated using that certificate's associated public key, regardless of whether the certificate has been compromised.


of 105

4 CERTIFICATELIFE‐CYCLEOPERATIONALREQUIREMENTS

Communication among the CA, RA, Trusted Agent, other parties confirming identities, and Subscriber shall have requisite security services (i.e., source authentication, integrity, non‐repudiation, or confidentiality) applied to them commensurate with the Assurance Level of the certificate being managed. For example, packages secured and transported in a tamper‐evident manner by a certified mail carrier meet the integrity and confidentiality requirements for all Assurance Levels asserted in this CP. When cryptography is used, the mechanism shall be at least as strong as the certificates being managed. For example, a web site secured using an SSL certificate issued under FS‐PKI‐MediumHw policy and set up with appropriate algorithms and key sizes satisfies integrity and confidentiality requirements for FS‐PKI‐MediumHw certificate management.

The content of communication shall dictate if some, all, or none of the security services are required.

4.1 CertificateApplication

4.1.1 Submission of Certificate Application Only an RA acting on behalf of the Subscriber shall submit a certificate application to the CA.

In some cases devices may be issued a trusted certificate. For these situations, a PKI Sponsor shall submit identity information to an RA who shall submit the request. This sponsor shall have already gone through the process of identity vetting and have in their possession a valid and current PIV‐I credential.

4.1.2 Enrolment Process and Responsibilities Applicants for public key certificates shall be responsible for providing accurate information in their applications for certification, and the Fortior Solutions PKI shall ensure the following actions take place:

a. Check and record identity of Subscriber (per section 3.2);

b. Verify the applicant’s authority to request the certificate by using a point of contact or other verifiable means of determining authorization; and

c. Generate and confirm the functionality of a Public/Private Key pair for each certificate required.

The FSPMA shall authorize the Fortior Solutions PKI Root CA to issue a certificate to the Fortior Solutions PKI CA and any future CA that Fortior Solutions may wish to add to the Fortior Solutions PKI.

4.2 CertificateApplicationProcessing

It is the responsibility of the RA, or, in the case of a CA certificate, the FSPMA, to verify that the information in a certificate application is accurate. Verification of accurate information may be done by trusted databases that are protected by appropriate security controls as per sections 5 and 6. Other methods may also be used, and the Fortior Solutions PKI CPS shall specify procedures to verify information in certificate applications.

4.2.1 Performing Identification and Authentication Functions Identity‐proofing shall be performed as specified in section 3.2, 3.3, and 3.4 of this CP.

Prior to certificate issuance, a Subscriber shall be required to sign a Subscriber Agreement containing the requirements that the Subscriber shall protect the private key and use the certificate and private key for authorized purposes only.

4.2.2 Approval or Rejection of Certificate Applications The FSPMA, Fortior Solutions, or any of its RAs may approve or reject a certificate.

4.2.3 Time to Process Certificate Applications Certificate application processing from the time the request/application is posted on the CA or RA system to certificate issuance shall not exceed thirty (30) days.


of 105

4.3 CertificateIssuance

Upon receiving a request for a certificate, the RA shall respond in accordance with the requirements set forth in the CPS. When information is obtained through one or more data sources, the Fortior Solutions PKI shall ensure there is an auditable chain of custody.

4.3.1 CA Actions during Certificate Issuance The CA shall:

Verify the source of a certificate request before issuance;

Check certificates to ensure that all fields and extensions are properly populated; and

Post the certificate as set forth in this CP, after generation, verification, and acceptance.

In addition, the Fortior Solutions PKI CA shall at all times authenticate any certificate request in order to verify the source of the request.

4.3.2 Notification to Subscriber of Certificate Issuance The Fortior Solutions PKI shall notify Subscribers of certificate issuance.

4.4 CertificateAcceptance

4.4.1 Conduct Constituting Certificate Acceptance Failure to object to receipt or use of the certificate shall indicate acceptance of it.

4.4.2 Publication of the Certificate by the CA All CA certificates whether initially issued or renewed shall be published in the PKI repository accessible to the Internet.

4.4.3 Notification of Certificate Issuance by the CA to other Entities The TPMA shall be notified upon issuing any new CA under the cross‐certification between the Fortior Solutions PKI and the TSCP Bridge.

The TPMA shall be notified at least two weeks and one day prior to the issuance of a new CA certificate, whether it be internal or external to the Fortior Solutions PKI domain. The notice period begins upon written acknowledgement of the TPMA. All new artifacts (CA certificates, CRL DP, AIA and/or SIA URLs, etc.) resulting from the CA certificate issuance shall be provided to the TPMA and FPKIPA within 24 hours following issuance.

4.5 KeyPairandCertificateUsage

4.5.1 Subscriber Private Key and Certificate Usage Subscribers and CAs shall protect their private keys from access by any other party. The Subscriber shall agree to the Subscriber Agreement and accept the certificate before the private key corresponding to the public key in the certificate may be used.

Subscribers and CAs shall use their private keys for the purposes as constrained by the extensions (such as key usage, extended key usage, certificate policies, etc.) in the certificates issued to them.

4.5.2 Relying Party Public Key and Certificate Usage Relying Parties shall accept and use public key certificates and their associated public keys for the purposes intended as constrained by the extensions (such as key usage, extended key usage, certificate policies, etc.) in the certificates.


of 105

4.6 CertificateRenewal

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.2 The old certificate may or may not be revoked, but must not be further re‐ keyed, renewed, or updated.

4.6.1 Circumstance for Certificate Renewal A certificate may be renewed if the public key has not reached the end of its validity period, the associated private key has not been revoked or compromised, and the Subscriber name and attributes are unchanged. In addition, the validity period of the certificate must not exceed the remaining lifetime of the private key, as specified in section 6.3.2. The identity proofing requirement listed in section 3.3.1 shall also be met.

Certificates may also be renewed when the CA that issued the certificates is re‐keyed.

4.6.2 Who May Request Renewal A Subject may request the renewal of its certificate.

A PKI Sponsor may request renewal of Device certificate.

A CA may request renewal of its Subscriber certificates, i.e., when the CA re‐keys.

4.6.3 Processing Certificate Renewal Requests A certificate renewal shall be achieved using one of the following processes, with the caveat that the keys may not change:

a. Initial registration process as described in section 3.2; or

b. Identification & Authentication for Re‐key as described in section 3.3, except the old key shall also be used as the new key.

For cross‐certificates issued by a Fortior Solutions PKI CA, certificate renewal also requires that a valid agreement exists between the FSPMA and the Subject CA, and the term of the agreement is beyond the expiry period for the new certificate.

4.6.4 Notification of New Certificate Issuance to Subscriber See section 4.3.2.

4.6.5 Conduct Constituting Acceptance of a Renewal Certificate See section 4.4.1.

4.6.6 Publication of the Renewal Certificate by the CA See section 4.4.2.

4.6.7 Notification of Certificate Issuance by the CA to other Entities See section 4.4.3.

4.7 CertificateRe‐Key

Re‐keying a certificate consists of creating new certificates with a new and different private key (and serial number) and corresponding new and different public key, while retaining the remaining contents of the old certificate that describe the subject. The new certificate may be assigned a different validity period, key

2 Renewal is supported by this CP primarily for OCSP Responder certificates (renewed monthly) and external PKI‐domain Cross‐

certificates (renewed according to a MoU, for example annually).


of 105

identifiers, specify a different CRL distribution point, and/or be signed with a different key. Re‐key of a certificate does not require a change to the subject Distinguished Name or subject Alternative Name(s) and does not violate the requirement for name uniqueness.

4.7.1 Circumstance for Certificate Re-Key A CA may issue a new certificate to the Subject when the Subject has generated a new key pair and is entitled to a certificate.

4.7.2 Who may Request Certification of a New Public Key A Subject may request re‐key of its certificate.

A PKI Sponsor may request re‐key of a Device certificate.

CAs may request re‐key without a corresponding request from a Subscriber.

4.7.3 Processing Certificate Re-Keying Requests A certificate re‐key shall be achieved using one of the following processes:


b. Identification and Authentication for Re‐Key as described in section 3.3.

To re‐key a cross‐certificate between the Fortior Solutions PKI and an external PKI domains' CAs (such as with the TSCP Bridge), certificate re‐key also requires that a valid agreement exists between Fortior Solutions and the other CA, and the term of the agreement is beyond the expiry period for the new certificate.

4.7.4 Notification of new Certificate Issuance to Subscriber See section 4.3.2.

4.7.5 Conduct Constituting Acceptance of a Re-Keyed Certificate See section 4.4.1

4.7.6 Publication of the Re-Keyed Certificate by the CA See section 4.4.2.

4.7.7 Notification of Certificate Issuance by the CA to Other Entities See section 4.4.3.

4.8 CertificateModification

Updating a certificate means creating a new certificate that has the same or a different key and a different serial number, and that it differs in one or more other fields, from the old certificate. For example, a Signing CA may choose to update a certificate of a Subscriber whose characteristics have changed (i.e., has just received a medical degree). The old certificate may or may not be revoked, but must not be further re‐ keyed, renewed, or updated.

Further, if an individual's name changes (i.e., due to marriage), then proof of the name change must be provided to the RA or the Trusted Agent in order for an updated certificate having the new name to be issued.

4.8.1 Circumstance for Certificate Modification A CA may issue a new certificate to the Subject when some of the Subject information has changed, i.e., name change due to change in marital status, change in subject attributes, etc., and the Subject continues to be entitled to a certificate.

4.8.2 Who may Request Certificate Modification


of 105

A Subject may request modification of its certificate.

A PKI Sponsor may request modification of a Device certificate.

The FSPMA may request modification of a CA certificate.

4.8.3 Processing Certificate Modification Requests A certificate modification shall be achieved using one of the following processes:


b. Identification & Authentication for Re‐key as described in section 3.3. In addition, the validation of the changed subject information shall be in accordance with the initial identity‐proofing process as described in section 3.2.

For cross‐certificates issued by a Fortior Solutions PKI CA, certificate modification also requires that a valid agreement exists between the FSPMA and the TSCP Bridge, and the term of the agreement is beyond the expiry period for the new certificate.

4.8.4 Notification of New Certificate Issuance to Subscriber See section 4.3.2.

4.8.5 Conduct Constituting Acceptance of Modified Certificate See section 4.4.1.

4.8.6 Publication of the Modified Certificate by the CA See section 4.4.2.

4.8.7 Notification of Certificate Issuance by the CA to Other Entities See section 4.4.3.

4.9 CertificateRevocationandSuspension

Revocation requests must be authenticated. Requests to revoke a certificate may be authenticated using that certificate’s associated private key, and by other verifiable means. However, the compromised private key shall not be used to authenticate a revocation.

4.9.1 Circumstances for Revocation A certificate shall be revoked when the binding between the Subject and the Subject's public key defined within a certificate is no longer considered valid. Examples of circumstances that invalidate the binding include the following3:

a. Identifying information or affiliation components of any names in the certificate become invalid;

b. An Organization terminates its relationship with the CA such that it no longer provides affiliation information;

c. Privilege attributes asserted in the Subject’s certificate are reduced;

d. The Subject can be shown to have violated the stipulations of its agreement;

3 No privilege attributes are asserted in any current certificate Profile. In the event that any future profile allows for privilege

attributes, reduction of privileges must be added to the list of reasons for revocation.


of 105

e. The private key, or the media holding the private key, is suspected of compromise and upon receipt of an authenticated request from an appropriate entity as per section 4.9.2; or

f. The Subject or other authorized party (as defined in this CP or in the respective CPS) asks for his/her certificate to be revoked;

For certificates that express an organizational affiliation, that organization must inform the Fortior Solutions PKI of any changes in the subscriber affiliation. If the affiliated organization no longer authorizes the affiliation of a Subscriber, the Fortior Solutions PKI shall revoke any certificates issued to that Subscriber containing the organizational affiliation. If an organization terminates its relationship with the Fortior Solutions PKI such that it no longer provides affiliation information, the Fortior Solutions PKI shall revoke all certificates affiliated with that organization.

Whenever any of the above circumstances occurs, the associated certificate shall be revoked and placed on the CRL and posted into the repositories. Revoked certificates shall be included on all new publications of the certificate status information until the certificates expire. In addition, if it is determined that a private key used to sign requests for one or more certificates may have been compromised, all certificates authorized by that compromised key, directly or indirectly, shall be revoked or shall be verified as appropriately issued.

4.9.2 Who can Request Revocation The following Subjects are authorized to request revocation of a certificate issued on behalf of their affiliated organization:

a. A certificate Subject;

b. Human supervisor of a human subject;

c. Human Resources (HR) person for the human subject; and

d. PKI Sponsor for a component.

Additionally the issuing CA, an RA, or PMA may request revocation of a certificate, including on behalf of unaffiliated Subscribers.

In the case of CA certificates issued to another PKI‐domain (such as the TSCP Bridge) by the Fortior Solutions PKI CA, the external PKI‐domain or the FSPMA may request revocation of a certificate.

For CA certificates, authorized individuals representing the OA may request revocation of certificates.

4.9.3 Procedure for Revocation Request Certificates shall be revoked upon receipt of sufficient evidence of compromise or loss of the Subscriber’s private key. A request to revoke a certificate shall identify the certificate to be revoked, explain the reason for revocation, and allow the request to be authenticated (i.e., digitally or manually signed).

The FSPMA may unilaterally revoke a CA certificate it has authorized to be issued. Generally, the certificate will be revoked based on the subject request, authorized representative of subject request, or FSPMA request. Upon receipt of a revocation request, the Fortior Solutions PKI CA shall authenticate the request and then revoke the certificate.

When any certificate is revoked for reason of key compromise any keys derived from the original keys shall also be revoked.

For hardware assurance levels other than FS‐PKI‐PIV‐I‐hw revocation is optional if all of the following conditions are met:

the revocation request was not for key compromise;

the hardware token does not permit the user to export the signature private key;

the Subscriber surrendered the token to the PKI;


of 105

the token was initialized or destroyed promptly upon surrender;

the token has been protected from malicious use between surrender and zeroization or destruction.

For FS‐PKI‐PIV‐I‐hw and in all other cases not identified above, revocation of the certificates is mandatory. Even where all the above conditions have been met, revocation of the associated certificates is recommended.

At the FS‐PKI‐MediumHw and FS‐PKI‐MediumCBPHw assurance levels a Subscriber ceasing its relationship with an organization that sponsored the certificate shall, prior to departure, surrender to the organization (through an accountable mechanism) all cryptographic hardware tokens that were issued by or on behalf of the sponsoring organization. The certificates shall be revoked, the token shall be disposed of in accordance with section 6.2.10 promptly upon surrender, and it shall be protected from malicious use between surrender and such disposition.

If a Subscriber leaves an organization and the hardware tokens cannot be obtained from the Subscriber, then all Subscriber certificates associated with the non‐retrieved tokens shall be immediately revoked for the reason of key compromise. Whenever possible PIV‐I cards shall be collected and destroyed when the cards are no longer valid for any reason. Record of the destruction of PIV‐I cards shall be made.

4.9.4 Revocation Request Grace Period There is no revocation grace period. The parties identified in section 4.9.2 must request revocation upon identifying the need for revocation.

4.9.5 Time Within Which the CA Must Process the Revocation Request The Fortior Solutions PKI CA shall revoke all authenticated revocation requests for CA certificates within six (6) hours of receipt of request.

All authenticated requests to revoke certificates validated within two (2) hours of CRL issuance shall be processed before the following CRL is published.

4.9.6 Revocation Checking Requirement for Relying Parties Use of revoked certificates could have damaging or catastrophic consequences in certain applications. The matter of how often new revocation data should be obtained is a determination to be made by the Relying Party. If it is temporarily infeasible to obtain revocation information, then the Relying Party must either reject use of the certificate, or make an informed decision to accept the risk, responsibility, and consequences for using a certificate whose authenticity or validity cannot be guaranteed to the standards of this policy. Such use may occasionally be necessary to meet urgent operational requirements.

4.9.7 CRL Issuance Frequency CRLs shall be issued periodically as per the following table, even if there are no changes to be made, to ensure timeliness of information. In cases of CA key compromise, see section 4.9.12 for CRL issuance requirements.

The offline Fortior Solutions PKI Root CA shall issue CRLs at least once every 30 days, except when required for reason of key compromise as specified in section 4.9.12.

The Fortior Solutions PKI CA(s) shall ensure that superseded certificate status information is removed from the PKI Repository upon publishing of the latest certificate status information.

Certificate status information shall be published not later than the next scheduled update. This will facilitate the local caching of certificate status information for offline or remote operation and will help to reduce latency between creation and availability.

The following table provides CRL issuance frequency requirements.


of 105

Assurance Level Maximum Interval for Routine CRL Issuance

Medium (all policies) 24 hours

PIV‐I (all policies) 24 hours

4.9.8 Maximum Latency for CRLs Fortior Solutions PKI CRLs shall be published within 4 hours of generation. Additionally, each CRL shall be published no later than the time specified in the nextUpdate field of the previously issued CRL for the same scope.

Fortior Solutions PKI CAs shall coordinate with Repositories to reduce the latency between the moment the CA desires the CRL to be published and the moment the CRL is available to Relying Parties within the applicable Repositories.

The maximum latency between the moment a revocation request is validated and the moment the revocation information is published and available to Relying Parties shall be no greater than 24 hours.

4.9.9 On-Line Revocation/Status Checking Availability In addition to CRLs, CAs and Relying Party client software may support on‐line status checking. Client software using on‐line status checking need not obtain or process CRLs.

If on‐line revocation/status checking is supported by a Fortior Solutions PKI CA, the latency of certificate status information distributed on‐line by the CA or its delegated status responders shall meet or exceed the requirements for CRL issuance stated in 4.9.7.

For certificates at FS‐PKI‐PIV‐I Assurance Levels, CAs shall support on‐line status checking via OCSP using the CA‐delegated trust model in RFC 6960.

4.9.10 On-Line Revocation Checking Requirements The Fortior Solutions PKI Repository shall contain and publish a list of all OCSP Responders operated by the Fortior Solutions PKI CA, including updating and maintaining the OCSP responder entries in the TSCP Bridge list.

4.9.11 Other Forms of Revocation Advertisements Available Any alternate forms used to disseminate revocation information shall be implemented in a manner consistent with the security and latency requirements for the implementation of CRLs and on‐line revocation and status checking in sections 4.9.7 and 4.9.8 and will be described in the Fortior Solutions PKI CPS.

4.9.11.1 Checking Requirements for Other Forms of Revocation Advertisements No stipulation.

4.9.12 Special Requirements Related to Key Compromise In the case of the offline Fortior Solutions PKI Root CA key compromise, the cross‐certificate with the TSCP Bridge shall be revoked and a CRL published at the earliest feasible time. When a Signing CA key is compromised the Root CA shall issue an updated CRL at the earliest feasible time.

For all CAs including Signing CAs when a private key is compromised or suspected of compromise, the FSPMA shall notify the TSCP Bridge, and the affected key shall be revoked immediately and a CRL must be issued as per the MTFSA between TSCP and Fortior Solutions and the schedule below:


of 105

Assurance Level Maximum Interval for Emergency CRL Issuance

Medium (all policies) 18 hours after notification

PIV‐I (all policies) 18 hours after notification

4.9.13 Circumstances for Suspension Not supported.

4.9.14 Who can Request Suspension Not supported.

4.9.15 Procedure for Suspension Request Not supported.

4.9.16 Limits on Suspension Period Not supported.

4.10 CertificateStatusServices

The Fortior Solutions PKI does not support SCVP.

4.10.1 Operational Characteristics No stipulation.

4.10.2 Service Availability Relying Parties are bound to their obligations and the stipulations of this CP irrespective of the availability of the certificate status service.

4.10.3 Optional Features No stipulation.

4.11 EndofSubscription

Revoking certificates that have expired prior to or upon end of subscription is not required. Unexpired CA certificates shall always be revoked at the end of subscription.

4.12 KeyEscrowandRecovery

4.12.1 Key Escrow and Recovery Policy and Practices Under no circumstances shall a CA or End‐Entity Signature key be escrowed. The Fortior Solutions PKI shall develop a Key Recovery Practices Statement (KRPS) which has been analysed by an independent compliance auditor and complies with the FPKI KRP.

Key Recovery practices shall satisfy privacy and security requirements defined in this CP. For private keys corresponding to a human subscriber encryption certificate, key escrow and recovery procedures are mandatory. For private keys corresponding to a device subscriber encryption certificate, key escrow and recovery procedures are mandatory unless the data protected by the keys will not require recovery under any circumstances.

4.12.2 Session Key Encapsulation and Recovery Policy and Practices


of 105

This CP neither requires nor prohibits the Fortior Solutions PKI to have the capability of recovering session keys. If session keys are recoverable, Fortior Solutions KRPS shall describe the practices applicable to session key escrow and recovery.


of 105

5 FACILITY,MANAGEMENT,ANDOPERATIONALCONTROLS

5.1 PhysicalControls

5.1.1 Site Location and Construction The location and construction of the facilities housing the Fortior Solutions PKI including both CA and CMS equipment shall be consistent with facilities used to house high value, sensitive information. The site location and construction, when combined with other physical security protection mechanisms such as guards and intrusion sensors, shall provide robust protection against unauthorized access to the CA equipment and records.

5.1.2 Physical Access

5.1.2.1 CA Physical Access Fortior Solutions PKI equipment shall always be protected from unauthorized access, and access shall only be in‐person; remote access is not allowed. The physical security requirements pertaining to CA equipment shall be commensurate with FS‐PKI‐PIV‐I assurance, and are as follows:

a. Ensure no unauthorized access to the hardware is permitted;

b. Ensure all removable media and paper containing sensitive plain‐text information is stored in secure containers;

c. Be manually or electronically monitored for unauthorized intrusion at all times;

d. Ensure an access log is maintained and inspected periodically;

e. Provide at least three (3) layers of increasing security such as perimeter, building, and CA room; and

f. Require two (2) person physical access control to the cryptographic module, computer system, and other sensitive CA equipment.

Removable cryptographic modules shall be deactivated prior to storage. When not in use, removable cryptographic modules, activation information used to access or enable cryptographic modules shall be placed in secure containers. Activation data shall either be memorized, or recorded and stored in a manner commensurate with the security afforded the cryptographic module, and shall not be stored with the cryptographic module.

A security check of the facility housing the Fortior Solutions PKI equipment shall occur if the facility is to be left unattended. At a minimum, the check shall verify the following:

a. The equipment is in a state appropriate to the current mode of operation (i.e., that cryptographic modules are in place when ―’open’, and secured when ―’closed’);

b. For the off‐line Fortior Solutions PKI Root CA, all equipment other than the PKI Repository is shut down;

c. Any security containers are properly secured;

d. Physical security systems (i.e., door locks, vent covers) are functioning properly; and

e. The area is secured against unauthorized access.

A person or group of persons shall be made explicitly responsible for making such checks. When a group of persons is responsible, a log identifying the person performing a check at each instance shall be maintained. If the facility is not continuously attended, the last person to depart shall initial a sign‐out sheet that indicates the date and time, and asserts that all necessary physical protection mechanisms are in place and activated.

5.1.2.2 RA Equipment Physical Access Fortior Solutions PKI RA equipment shall be protected from unauthorized access while the RA cryptographic module is installed and activated. The RA shall implement physical access controls to reduce the risk of equipment


of 105

tampering even when the cryptographic module is not installed and activated. These security mechanisms shall be commensurate with the level of threat in the RA equipment environment.

5.1.2.3 CSA Equipment Physical Access Physical access control requirements for CSA equipment shall meet the same access controls as that required for CAs in section 5.1.2.1.

5.1.2.4 CMS Equipment Physical Access Physical access control requirements for CMS equipment containing an FS‐PKI‐PIV‐I Content Signing keys shall meet the same access controls as that required for CAs in section 5.1.2.1.

5.1.3 Power and Air Conditioning Fortior Solutions PKI CAs shall have backup power sufficient to automatically lock out input, finish any pending actions, and record the state of the equipment before lack of power or air conditioning causes a shutdown. Fortior Solutions PKI Repositories shall be provided with Uninterrupted Power sufficient for a minimum of six (6) hours operation in the absence of commercial power, to support continuity of operations.

5.1.4 Water Exposures Fortior Solutions PKI equipment (including CA, CSA and CMS) shall be installed such that it is not in danger of exposure to water (e.g., on tables or elevated floors).

Water exposure from fire prevention and protection measures (e.g., sprinkler systems) are excluded from this requirement.

5.1.5 Fire Prevention and Protection No stipulation.

5.1.6 Media Storage Fortior Solutions PKI CA media shall be stored so as to protect it from theft, unauthorized access, and damage (water, fire, electromagnetic). Media that contains audit, archive, or backup information shall be duplicated and stored in a location separate from the CA location.

5.1.7 Waste Disposal Sensitive waste material including PII shall be disposed of in a secure fashion.

5.1.8 Off-Site Backup Full system backups of the Fortior Solutions PKI CAs, sufficient to recover from system failure, shall be made on a periodic schedule, described in the Fortior Solutions PKI CPS. Backups shall be performed and stored offsite not less than once every seven (7) days. At least one (1) full backup copy shall be stored at an offsite location (at a location separate from the CA equipment). Only the latest full backup need be retained. The backup data shall be protected with physical and procedural controls commensurate to the assurance level of the operational CA.

5.2 ProceduralControls

5.2.1 Trusted Roles A trusted role is one whose incumbent performs functions that can introduce security problems if not carried out properly, whether accidentally or maliciously. The people selected to fill these roles in the Fortior Solutions PKI must be extraordinarily responsible or the integrity of the CA is weakened. The functions performed in these roles form the basis of trust for all uses of the CA. Two approaches are taken to increase the likelihood that these roles can be successfully carried out. The first ensures that the person filling the role is trustworthy and properly trained. The second distributes the functions among more than one person, so that any malicious activity would require collusion.


of 105

The requirements of this policy are drawn in terms of four roles:

a. Administrator – authorized to install, configure, and maintain the CA, establish and maintain user accounts, configure profiles and audit parameters, and generate component keys;

b. Officer – authorized to request or to approve certificates or certificate revocations;

c. Auditor – authorized to view and maintain audit logs; and

d. Operator – authorized to perform system backup and recovery.

The following sections define these and other trusted roles.

5.2.1.1 CA System Administrator The CA System Administrators shall be responsible for the following:

a. Installation, configuration, and maintenance of the CA;

b. Establishing and maintaining CA system accounts;

c. Configuring certificate profiles or templates and audit parameters; and

d. Generating and backing up CA keys.

System Administrators shall not issue certificates to Subscribers.

5.2.1.2 Officers The Officer role is geared toward managing and maintaining CMS and CA responsibilities. The Officers shall be responsible for the following:

a. Registering new Subscribers and requesting certificate issuance utilizing secure communications as per sections 6.1.2 and 6.1.3;

b. Verifying the identity of Subscribers in accordance with section 3.2;

c. Approving and executing certificate issuance;

d. Receiving and distributing Subscriber certificates; and

e. Requesting, approving, and executing certificate revocation.

Officers also develop and maintain the CMS and CA software and supporting applications. The responsibilities and controls for Officers shall be explicitly described in the Fortior Solutions PKI CPS.

5.2.1.3 Auditor Auditors shall be responsible for the following:

a. Reviewing, maintaining, and archiving audit logs; and

b. Performing or overseeing internal compliance audits to ensure that the CA is operating in accordance with the Fortior Solutions PKI CPS.

5.2.1.4 Operator Operators shall be responsible for the routine operation of the CA equipment and operations such as system backups and recovery or changing recording media.

5.2.1.5 Registration Authority Registration Authorities are Officers and have the exact same responsibilities as Officers found in section 5.2.1.2 with the exception that RAs are charged with the issuance and revocation processes for Subscriber certificates only, and have no specific roles in managing or maintaining the CMS or CA infrastructure.


of 105

The RA role is highly dependent on public key infrastructure implementations and local requirements. The responsibilities and controls for RAs shall be explicitly described in the CPS of the Fortior Solutions PKI CA.

5.2.1.6 CSA Roles The Fortior Solutions PKI CSA shall have at least the following roles:

a. CSA Administrators who shall be responsible for the following:

i. Installation, configuration, and maintenance of the CSA;

ii. Establishing and maintaining CSA system accounts;

iii. Configuring CSA application and audit parameters; and

iv. Generating and backing up CSA keys.

b. CSA Auditors who shall be responsible for the following:

i. Reviewing, maintaining, and archiving audit logs;

ii. Performing or overseeing internal compliance audits to ensure that the CSA is operating in accordance with the applicable CPSs.

c. CSA Operators who shall be responsible for the following:

i. Routine operation of the CSA equipment; and

ii. Operations such as system backups and recovery or changing recording media.

5.2.1.7 CMS Roles The Fortior Solutions PKI CMS shall have at least the following roles:

a. CMS Administrators who shall be responsible for the following:

i. Installation, configuration, and maintenance of the CMS;

ii. Establishing and maintaining CMS system accounts;

iii. Configuring CMS application and audit parameters; and

iv. Generating and backing up CMS keys.

b. CMS Auditors who shall be responsible for the following:

i. Reviewing, maintaining, and archiving audit logs; and

ii. Performing or overseeing internal compliance audits to ensure that the CMS is operating in accordance with the applicable CPSs.

c. CMS Operators who shall be responsible for the following:

Routine operation of the CMS equipment; and

Operations such as system backups and recovery or changing recording media.

5.2.1.8 PKI Sponsor A PKI Sponsor is a Subscriber for devices in the Fortior Solutions PKI network. Alternatively, a PKI Sponsor may be an authorized official in an affiliated organization who may conduct pre‐enrollment activities for authorized Subscribers. The PKI Sponsor follows procedures detailed in the Fortior Solutions PKI CPS and handbooks/SOPs to pre‐enroll Subscribers, or to register components (routers, web servers, firewalls, etc.) in accordance with section 3.2.4, and is responsible for meeting the obligations of Subscribers as defined throughout this document.


of 105

A PKI Sponsor need not be a trusted role, but should have been issued a credential at an Assurance Level that is equal to or higher than that of the credential that they are sponsoring.

5.2.1.9 Trusted Agent A Trusted Agent is a Subscriber who assists the RA to pre‐register new Subscribers and bears the following responsibilities:

a. Verify and capture identity in accordance with section 3.2; and

b. Securely communicating Subscriber identity information to the RA.

A Trusted Agent shall be a trusted role.

5.2.2 Number of Persons Required Per Task Two or more persons shall be required to perform the following tasks:

a. CA and CSA signing key, and FS‐PKI‐PIV‐I‐contSign key generation;

b. CA and CSA signing key, and FS‐PKI‐PIV‐I‐contSign key activation; and

c. CA and CSA private key, and FS‐PKI‐PIV‐I‐contSign key backup.

Where multiparty control is required, at least one of the participants shall be an Administrator. All participants shall serve in a trusted role as defined in section 5.2.1.

Multiparty control shall not be achieved using personnel that serve in the Auditor Role.

Due to the criticality of PKI and the nature of emergencies and disasters, it is recommended that multiple persons are assigned to all roles in order to support continuity of operations.

5.2.3 Identification and Authentication for Each Role An individual shall identify and authenticate him/herself before being permitted to perform any actions set forth above for that role or identity.

An individual in a trusted role shall authenticate to components of the Fortior Solutions PKI using a method commensurate with FS‐PKI‐PIV‐I‐hw.

5.2.4 Roles Requiring Separation of Duties Role separation, when required as set forth below, may be enforced either by the CA or CMS equipment, or procedurally, or by both means and shall comply with this section as well as requiring two person control as per section 5.2.2 without regard to the titles or numbers of Trusted Roles.

Requirements for the separation of roles, and limitations on use of procedural mechanisms to implement role separation, are described below for each level of assurance:

Medium (all policies)

Individual Fortior Solutions PKI personnel shall be specifically designated to the four roles defined in section 5.2.1. Individuals may only assume one of the Officer, Administrator, and Auditor roles, but any individual may assume the Operator role. The CA, CMS, and RA software and hardware shall identify and authenticate its users and shall ensure that no user identity can assume both an Administrator and an Officer role, assume both the Administrator and Auditor roles, and assume both the Auditor and Officer roles. No individual shall have more than one identity.

PIV‐I

Individual personnel shall be specifically designated to the four roles defined in Section 5.2.1 above. Role separation duties follow the requirements for Medium assurance above.

Individuals may assume more than one role, except as follows:


of 105

a. Individuals who assume a Registration Authority or Security Officer role may not assume a System Administrator role;

b. Individuals who assume an Auditor role shall not assume any other role on the Fortior Solutions PKI component; and

c. Under no circumstances shall any of the four roles perform its own compliance auditor function.

No individual fulfilling any of the roles outlined in section 5.2.1 shall be assigned more than one identity.

5.3 PersonnelControls

5.3.1 Qualifications, Experience, and Clearance Requirements A group of individuals responsible and accountable for the operation of each Fortior Solutions PKI CA, CMS, and CSA shall be identified. The trusted roles of these individuals per section 5.2.1 shall be identified.

All persons filling trusted roles shall be selected on the basis of loyalty, trustworthiness, and integrity, and shall be subject to background investigation. Personnel appointed to Fortior Solutions PKI CA trusted roles, CSA trusted roles, and CMS trusted roles shall:

a. Have successfully completed an appropriate training program;

b. Have demonstrated the ability to perform their duties;

c. Be trustworthy;

d. Have no other duties that would interfere or conflict with their duties for the trusted role;

e. Have not been previously relieved of duties for reasons of negligence or non‐performance of duties;

f. Have not been denied a security clearance, or had a security clearance revoked;

g. Have not been convicted of a felony offence or other serious crime which affects his/her suitability for the position; and

h. Be appointed in writing by an approving authority.4

Each person filling a trusted role shall satisfy at least one of the following requirements:

a. The person shall be a US citizen; or

b. The person shall have a security clearance equivalent to U.S. Secret or higher issued by a NATO member nation or major non‐NATO ally as defined by the International Traffic in Arms Regulation (ITAR) – 22 CFR 120.32.

5.3.2 Background Check Procedures All persons filling Fortior Solutions PKI CA trusted roles, CSA trusted roles, and CMS trusted roles shall have completed a favourable background investigation. The scope of the background check shall include the following areas covering the past five (5) years:

a. Employment;

b. Education (regardless of the date of award, the highest educational degree shall be verified);

4 Practice Note: In order to make the determination if a person was denied clearance or had clearance revoked for cause, it is sufficient to rely on the local Facility Security Officer (FSO) database, Joint Personnel Adjudication System (JPAS), and assertions by the person on security clearance forms.


of 105

c. Place of residence (3 years);

d. Law Enforcement; and

e. References.

Adjudication of the background investigation shall be performed by a competent adjudication authority using a process consistent with United States Executive Order 12968 August 1995, or equivalent.

The results of these checks shall not be released except as required in section 9.3 and section 9.4.

Background check procedures shall be described in the CPS.

If a formal clearance or other US Federal government approved check is the basis for background check, the background refresh shall be in accordance with the corresponding formal clearance or other check. Otherwise, the background check shall be refreshed every ten years.

Interim clearance for Trusted Roles is not supported.

5.3.3 Training Requirements All personnel performing duties with respect to the operation of the Fortior Solutions PKI CA, CMS, CSA, or an RA shall receive comprehensive training. Training shall be conducted in the following areas:

a. CA/CMS/CSA/RA security principles and mechanisms;

b. All PKI software versions in use on the CA system;

c. All PKI duties they are expected to perform; and

d. Disaster recovery and business continuity procedures.

Documentation shall be maintained identifying all personnel who received training and the level of training completed. Where competence was demonstrated in lieu of training, supporting documentation shall be maintained.

5.3.4 Retraining Frequency and Requirements All Trusted Roles and others who support them shall be aware of changes in the Fortior Solutions PKI CA, CMS, CSA, or RA operations, as applicable. A training awareness plan shall be in place to deal with any significant change to the operations, and the execution of such plan shall be documented. Examples of such changes are CA software or hardware upgrade, RA software upgrades, changes in automated security systems, and relocation of equipment.

Documentation shall be maintained identifying all personnel who received training and the level of training completed. Where competence was demonstrated in lieu of training, supporting documentation shall be maintained.

5.3.5 Job Rotation Frequency and Sequence No stipulation.

5.3.6 Sanctions for Unauthorized Actions The FSPMA shall take appropriate administrative and disciplinary actions against personnel who violate this policy.

5.3.7 Independent Contractor Requirements Contractor personnel employed to perform functions pertaining to CA, CSA, CMS, or RA operations shall meet applicable requirements set forth in this CP (i.e., all requirements of section 5.3).

5.3.8 Documentation Supplied to Personnel


of 105

The FSPMA shall make available to its Fortior Solutions PKI CA, CMS, and CSA personnel the Certificate Policies they support, including the CPS, RPS and any relevant statutes, policies, or contracts. Other technical, operations, and administrative documents (i.e., Administrator Manual, User Manual, etc.) shall be provided in order for the trusted personnel to perform their duties.

Documentation shall be maintained identifying all personnel who received training and the level of training completed.

5.4 AuditLoggingProcedures

Audit log files shall be generated for all events relating to the security of the CAs, CMSs, CSAs, and RAs. For CAs operated in a virtual machine environment (VME), audit logs shall be generated for all applicable events on both the virtual machine (VM) and the isolation kernel (i.e., hypervisor). Where possible, the security audit logs shall be automatically collected. Where this is not possible, a logbook, paper form, or other physical mechanism shall be used. All security audit logs, both electronic and non‐electronic, shall be retained and made available during compliance audits. The security audit logs for each auditable event defined in this Section shall be maintained in accordance with section 5.5.2.

5.4.1 Types of Events Recorded All security auditing capabilities, either manual or automatic, of the Fortior Solutions PKI CA, CMS, CSA, and RA operating system and the CA, CMS, CSA, and RA applications required by this CP shall be enabled. As a result, most of the events identified in the table shall be automatically recorded, and when no automated tool is available a manual process shall be used.

At a minimum, each audit record shall include the following (either recorded automatically or manually for each auditable event):

a. The type of event;

b. The date and time the event occurred;

c. Success or failure where appropriate;

d. The identity of the entity and/or operator that caused the event; and

e. A message from any source requesting an action by a CA is an auditable event. That message must include message date and time, source, destination and contents.

The following events shall be audited:

Auditable Event CA CSA RA CMS

SECURITY AUDIT

Any changes to the Audit parameters, i.e., audit frequency, type of event audited

X X X X

Any attempt to delete or modify the Audit logs X X X X

Obtaining a third-party time-stamp X X X X

IDENTITY-PROOFING

Successful and unsuccessful attempts to assume a role X X X X

The value of maximum number of authentication attempts is changed

X X X X

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

X X X X


of 105

A person or device unlocks an account that has been locked as a result of unsuccessful authentication attempts

X X X X

A person or device changes the type of authenticator, i.e., from a password to a biometric

X X X X

LOCAL DATA ENTRY

All security-relevant data that is entered in the system X X X X

REMOTE DATA ENTRY

All security-relevant messages that are received by the system

X X X X

DATA EXPORT AND OUTPUT

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

X X X X

KEY GENERATION

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

X X X X

PRIVATE KEY LOAD AND STORAGE


The loading of Component Private Keys X X X X

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

X N/A N/A X

TRUSTED PUBLIC KEY ENTRY, DELETION AND STORAGE

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

X X X X

SECRET KEY STORAGE

The manual entry of secret keys used for authentication X X X X

PRIVATE AND SECRET KEY EXPORT

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

X X X X

CERTIFICATE REGISTRATION

All Certificate Requests X N/A X X

CERTIFICATE REVOCATION

All Certificate revocation requests X N/A X X

CERTIFICATE STATUS CHANGE APPROVAL

The approval or rejection of a Certificate status change request

X N/A N/A X

CA CONFIGURATION


of 105

Any security-relevant changes to the configuration of the Component

X X X X

ACCOUNT ADMINISTRATION

Roles and users are added or deleted X - - X

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

X - - X

CERTIFICATE PROFILE MANAGEMENT

All changes to the Certificate profile X N/A N/A X

CERTIFICATE STATUS AUTHORITY MANAGEMENT

All changes to the CSA profile (i.e. OCSP profile) N/A X N/A N/A

REVOCATION PROFILE MANAGEMENT

All changes to the revocation profile X N/A N/A N/A

CERTIFICATE REVOCATION LIST PROFILE MANAGEMENT

All changes to the Certificate revocation list profile X N/A N/A N/A

MISCELLANEOUS


Appointment of an individual to a Trusted Role X X X X

Designation of personnel for multiparty control X - N/A X

Installation of the Operating System X X X X

Installation of the PKI Application X X X X

Installation of hardware cryptographic modules X X X X

Removal of hardware cryptographic modules X X X X

Destruction of cryptographic modules X X X X

System Startup X X X X

Logon attempts to PKI Application X X X X

Receipt of hardware / software X X X X

Attempts to set passwords X X X X

Attempts to modify passwords X X X X

Back up of the internal CA database X - - X

Restoration from back up of the internal CA database X - - X

File manipulation (i.e., creation, renaming, moving) X - - -

Posting of any material to a PKI Repository X - - -

Access to the internal CA database X X - -

All Certificate compromise notification requests X N/A X X

Loading tokens with Certificates X N/A X X


of 105

Shipment of Tokens X N/A X X

Zeroing and Destroying Tokens X N/A X X

Re-key of the Component X X X X

CONFIGURATION CHANGES

Hardware X X - X

Software X X X X

Operating System X X X X

Patches X X - X

Security Profiles X X X X

PHYSICAL ACCESS / SITE SECURITY

Personnel Access to room housing Component X - - X

Access to the Component X X - X

Known or suspected violations of physical security X X X X


ANOMALIES

Software error conditions X X X X

Software check integrity failures X X X X

Receipt of improper messages X X X X

Misrouted messages X X X X

Network attacks (suspected or confirmed) X X X X

Equipment failure X - - X

Electrical power outages X - - X

Uninterruptible Power Supply (UPS) failure X - - X

Obvious and significant network service or access failures X - - X

Violations of Certificate Policy X X X X

Violations of Certification Practice Statement X X X X

Resetting Operating System clock X X X X

5.4.2 Frequency of Processing Audit Logs Audit logs shall be reviewed at least once every thirty (30) days.

Statistically significant sample of security audit data generated by the Fortior Solutions PKI CA, CMS, CSA, or RA since the last review shall be examined (where the confidence intervals for each category of security audit data are determined by the security ramifications of the category and the availability of tools to perform such a review), as well as a reasonable search for any evidence of malicious activity. The Auditor shall explain all significant events in an audit log summary.


of 105

Such reviews involve verifying that the log has not been tampered with, there is no discontinuity or other loss of audit data, and then briefly inspecting all log entries, with a more thorough investigation of any alerts or irregularities in the logs.

Actions taken as a result of these reviews shall be documented.

5.4.3 Retention Period for Audit Logs Fortior Solutions PKI audit logs shall be retained onsite for at least sixty (60) days as well as being retained in the manner described in section 5.5. For the CA, CMS, and CSA, an Auditor shall be the only person responsible for managing the audit log (i.e., review, backup, rotate, delete, etc.). For any logs pertaining to the RA workstation, a System Administrator other than the RA shall be responsible for managing the audit log.

5.4.4 Protection of Audit Log System configuration and procedures shall be implemented together to ensure the following:

1. Only authorized people, per section 5.4.3, shall have read access to the logs;

2. Only authorized people, per section 5.4.3, shall may archive audit logs; and

3. Audit logs are not modified.

The person performing the audit log archive need not have modify access, but procedures must be implemented to protect archived data from destruction prior to the end of the audit log retention period (note that deletion requires modification access).

Audit logs shall be moved to a safe, secure storage location separate from the CA equipment.

It is acceptable for the system to over‐write audit logs after they have been backed‐up and archived.

5.4.5 Audit Log Backup Procedures Audit logs and audit summaries shall be backed up at least once every thirty (30) days. A copy of the audit log shall be sent off‐site in accordance with the practice prescribed in the CPS every thirty (30) days.

5.4.6 Audit Collection System (Internal vs. External) The audit log collection system may or may not be external to the Fortior Solutions PKI CA, CMS, CSA, or RA. Audit processes shall be invoked at system start‐up, and cease only at system shutdown. Should it become apparent that an automated audit system has failed, and the integrity of the system or confidentiality of the information protected by the system is at risk, then the FSPMA shall determine whether to suspend CA operation until the problem is remedied.

5.4.7 Notification to Event-Causing Subject This CP imposes no requirement to provide notice that an event was audited to the individual, organization, device, or application that caused the event.

5.4.8 Vulnerability Assessments No stipulation beyond section 5.4.2.

5.5 RecordsArchival

5.5.1 Types of Records Archived Fortior Solutions PKI CA, CMS, CSA, and RA archive records shall be sufficiently detailed to establish the proper operation of the component or the validity of any certificate (including those revoked or expired) issued by the CA. The Fortior Solutions PKI shall comply with the record retention policies in section 5.5.2.


of 105

Data To Be Archived CA CSA CMS RA

CA accreditation X N/A N/A N/A

Certificate Policy X X X X

Certification Practice Statement X X X X

Contractual obligations X X X X

Other agreements concerning operations of the CA X N/A N/A N/A

System and equipment configuration X X X X

Modifications and updates to system or configuration X X X X

Certificate requests X N/A X N/A

Revocation requests X N/A X N/A

Subscriber identity Authentication data as per Section 3.2.3 X N/A X X

Documentation of receipt and acceptance of certificates X N/A X X

Subscriber Agreements X N/A X X

Documentation of receipt of tokens X N/A X X

All certificates issued or published X N/A X N/A

Record of CA Re‐key X N/A N/A N/A

All CRLs issued and/or published X N/A N/A N/A

Other data or applications to verify archive contents X X X X

Compliance Auditor reports X X X X

Any changes to the Audit parameters, e.g., audit frequency, type of event audited X X X X

Any attempt to delete or modify the Audit logs X X X X

Whenever the CA generates a key. (Not mandatory for single session or one‐time use symmetric keys)

X N/A N/A N/A

All access to certificate subject private keys retained within the CA for key recovery purposes

X N/A X N/A

All changes to the trusted public keys, including additions and deletions X N/A X N/A

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

X N/A X X

The approval or rejection of a certificate status change request X N/A X X

Appointment of an individual to a Trusted Role X X X X

Destruction of cryptographic modules X X X X

All certificate compromise notifications X N/A X X

Remedial action taken as a result of violations of physical security X X X X

Violations of Certificate Policy X X X X

Violations of Certification Practice Statement X X X X

All Audit Logs X X X X


of 105

Data To Be Archived CA CSA CMS RA

Documentation required by compliance auditors X X X X

5.5.2 Retention Period for Archive The retention period for archive data is ten (10) years and six (6) months for all certificates.

Applications required to process the archive data shall be maintained for the minimum retention period specified above.

5.5.3 Protection of Archive No unauthorized user shall be permitted to write to, modify, or delete the archive. For the Fortior Solutions PKI CA, CMS, CSA, and RA the authorized individuals are Auditors. The contents of the archive shall not be released except in accordance with sections 9.3 and 9.4 and as determined by the FSPMA for the Fortior Solutions PKI CA. Records of individual transactions may be released upon request of any Subscribers involved in the transaction or their legally recognized agents. Archive media shall be stored in a safe, secure storage facility separate from the component (CA, CMS, CSA, or RA) with physical and procedural security controls equivalent or better than those of the Fortior Solutions PKI.

If the original archive media cannot retain the data for the entire duration of the required retention period, a method for transferring and retaining the data shall be defined in the CPS.

5.5.4 Archive Backup Procedures The Fortior Solutions PKI CPS or a referenced document shall describe how archive records are backed up, and how the archive backups are managed.

5.5.5 Requirements for Time-Stamping of Records Fortior Solutions PKI CA archive records shall be automatically time‐stamped as they are created. The Fortior Solutions PKI CPS shall describe how system clocks used for time‐stamping are maintained in synchrony with an authoritative time standard.

5.5.6 Archive Collection System (Internal vs. External) No stipulation.

5.5.7 Procedures to Obtain and Verify Archive Information Procedures detailing how to create, verify, package, and transmit archive information shall be published in the Fortior Solutions PKI CPS.

Release of archive information shall be as per section 5.5.3.

5.6 KeyChangeover

To minimize risk from compromise of the Fortior Solutions PKI CA‘s private signing key, that key may be changed often; from that time on, only the new key shall be used for certificate signing purposes. The older, but still valid, certificate will be available to verify old signatures until all of the certificates signed using the associated private key have also expired, at which point the CA may issue a final CRL using the old key, with a nextUpdate time beyond the validity period of all certificates it issued. If the old private key is used to sign CRLs that cover certificates signed with that key, then the old key shall be retained and protected. The CA key changeover process is described in the Fortior Solutions PKI CPS.


of 105

5.7 CompromiseandDisasterRecovery

5.7.1 Incident and Compromise Handling Procedures If the Fortior Solutions PKI CA, CSA, or CMS detects a potential hacking or cracking attempt or other form of compromise, it shall perform an investigation in order to determine the nature and the degree of damage. If the CA, CSA, or CMS key is suspected of compromise, the procedures outlined in section 5.7.3 shall be followed. Otherwise, the scope of potential damage shall be assessed in order to determine if the CA, CSA, or CMS needs to be rebuilt, only some certificates need to be revoked, and/or the CA, CSA, or CMS key needs to be declared compromised.

The FSPMA and the TSCP Bridge PMA, shall be notified if any of the following cases occur:

a. Suspected or detected compromise of a Fortior Solutions PKI CA system;

b. Physical or electronic attempts to penetrate a Fortior Solutions PKI CA system;

c. Denial of service attacks on a Fortior Solutions PKI CA component; or

d. Any incident preventing a Fortior Solutions PKI CA from issuing a CRL within twenty‐four (24) hours of the time specified in the next update field of its currently valid CRL.

The FSPMA and the TSCP Bridge PMA shall be notified if any of the following cases occur:

a. A CA certificate revocation for any reason is planned; or

b. Any incident preventing a relevant CA from issuing a CRL within twenty‐four (24) hours of the time specified in the next update field of its currently valid CRL.

These measures will allow the Fortior Solutions PKI and the TSCP Bridge, to protect their interests as Relying Parties. The Fortior Solutions PKI OA shall re‐establish operational capabilities as quickly as possible in accordance with procedures set forth in the Fortior Solutions PKI CPS.

The Fortior Solutions PKI CMS shall have documented incident‐handling procedures that are approved by the FSPMA. If the CMS is compromised, all certificates issued to the CMS shall be revoked, if applicable. The damage caused by the CMS compromise shall be assessed and all Subscriber certificates that may have been compromised shall be revoked, and Subscribers shall be notified of such revocation. The CMS shall be re‐established.

5.7.2 Computing Resources, Software, and/or Data are Corrupted If Fortior Solutions PKI CA or CSA equipment is damaged or rendered inoperative, but the signature keys are not destroyed, the operation shall be re‐established as quickly as possible, giving priority to the ability to generate certificate status information. Before returning to full operation, ensure that the system’s integrity has been restored.

If a Fortior Solutions PKI CA cannot issue a CRL prior to the time specified in the next update field of its currently valid CRL, then all CAs that have been issued certificates by that CA shall be securely (with confidentiality, source authentication, and integrity security services applied) notified immediately. This will allow the TSCP Bridge to protect their Subscribers' interests as Relying Parties. The CA shall re‐establish revocation capabilities as quickly as possible in accordance with procedures set forth in the Fortior Solutions PKI CPS. If revocation capability cannot be established in a reasonable time‐frame, the CA shall determine whether to request revocation of its certificate(s). If the CA is a Root CA, the FSPMA shall determine whether to notify the TSCP Bridge and all Subscribers (as applicable) that use the CA as a trust anchor to delete the trust anchor.

5.7.3 Private Key Compromise Procedures If a Fortior Solutions PKI CA‘s signature keys are compromised, lost, or are suspected of compromise:

a. The FSPMA shall be notified by phone challenge and response or digitally signed email at the earliest feasible time;


of 105

b. The TSCP Bridge shall be notified by digitally signed email of the compromise and the steps taken to remediate;

c. A new CA key pair shall be generated by the CA as per section 4;

d. New CA certificates shall be requested in accordance with the initial registration process set elsewhere in this CPS;

e. The CA shall request all Subscribers to re‐key using the procedures outlined in section 3.3.2; and

f. If the CA is the Root CA, it shall provide the TSCP Bridge and all Subscribers as applicable the new trust anchor using secure means.

The FSPMA shall also investigate what caused the compromise or loss, and what measures must be taken to preclude recurrence.

If a CSA key is compromised, all certificates issued to the CSA shall be revoked, if applicable. The CSA will generate a new key pair and request new certificate(s), if applicable. If the CSA is a trust anchor, the relying parties will be provided with the new trust anchor in a secure manner (so that the trust anchor integrity is maintained) to replace the compromised trust anchor.

If a Fortior Solutions PKI CMS key is compromised, all certificates issued to the CMS shall be revoked. The CMS will generate a new key pair and request new certificate(s).

If a RA's signature keys are compromised, lost, or are suspected of compromise:

a. The RA certificate shall be immediately revoked;

b. A new RA key pair shall be generated in accordance with procedures set forth in the Fortior Solutions PKI CPS;

c. A new RA certificate shall be requested in accordance with the initial registration process set elsewhere in this CP;

d. All certificate registration requests approved by the RA since the date of the suspected compromise shall be reviewed to determine which ones are legitimate; and

e. For those certificate Requests or approvals that cannot be ascertained as legitimate, the resultant certificates shall be revoked and their subjects (i.e., Subscribers) shall be notified of revocation.

5.7.4 Business Continuity Capabilities after a Disaster In the event that all copies of the CA Signing Key are destroyed, the FSPMA shall request that its CA certificates be revoked. The CA shall follow the procedures for CA key loss in section 5.7.3 above.

5.8 CA,CMS,CSA,orRATermination

In the event of a CA termination, the FSPMA shall request all certificates including cross‐certificates issued to its CA(s) be revoked and the FSPMA shall provide notice to the TSCP Bridge PMA prior to the termination. In the case of a Fortior Solutions PKI CA termination the TSCP Bridge PMA will be given as much advance notice as circumstances permit, and attempts to provide alternative sources of interoperation will be sought. Any non‐expired certificates issued by the CA being terminated shall be revoked and a final long term CRL with the nextUpdate time beyond the validity period of all certificates it issued shall be generated. Once this final CRL has been issued, the private signing key(s) of the CA will be destroyed. The final CRL shall be available for all relying parties until the validity period of all issued certificates has passed. In addition:

a. A CA, CMS, CSA, and RA shall archive all audit logs and other records prior to termination.

b. A CA, CMS, CSA, and RA shall destroy all its private keys upon termination.


of 105

c. CA, CMS, CSA, and RA archive records shall be transferred to the control of the FSPMA which will ensure proper long term archival as per retention period requirements.

d. If a Root CA is terminated, the FSPMA shall use secure means to notify the Subscribers to delete all trust anchors representing the terminated CA.


of 105

6 TECHNICALSECURITYCONTROLS

6.1 KeyPairGenerationandInstallation

6.1.1 Key Pair Generation Keys created for all Fortior Solutions PKI certificates with the exception of FS‐PKI‐MediumSw and FS‐PKI‐MediumCBPSw shall be generated on FIPS 140 approved hardware. Subscriber key generation shall be performed using a FIPS approved method.

The following table provides the specific requirements for key pair generation in the Fortior Solutions PKI for each certificate type:

Entity FIPS 140‐1/2 Level Hardware or Software

Key Storage Restricted to the Module on Which the Key was Generated

CA 3 Hardware Same CMS 35 Hardware Same RA 2 Hardware Same OCSP Responder 2 Hardware Same Content Signing 2 Hardware Same

Card Authentication 2 (section 10 also

applies)

Hardware Same

Subscriber Identity or Signature

2 (For FS‐PKI‐PIV‐I‐

hardware section 10 also

applies)

Hardware Same

Subscriber Encryption 2 (For FS‐PKI‐PIV‐I‐

hardware section 10 also

applies)

Hardware No Requirement

Server 2 Hardware Same

Subscriber Identity or Signature

1 Software Same

Subscriber Encryption 1 Software Same

Random numbers for FS‐PKI‐MediumHw and FS‐PKI‐MediumCBPHw assurance level keys shall be generated in FIPS 140‐2 Level 2‐validated hardware cryptographic modules.

5 Although the requirement is for only FIPS 140‐2 Level 2 compliance, the CMS is a de‐facto Key Server according to the practices described

in the FPKI KRPS. Therefore, since the Fortior Solutions CMS operating under this policy is also handling Encryption keys, to prevent

confusion, the more stringent requirement of Level 3 imposed by the FPKI KRP is called out here.


of 105

When private keys are not generated on the token to be used, originally generated private keys shall be destroyed after they have been transferred to the token. This does not prohibit the key generating modules to further act as the key escrow module.

Multiparty control shall be used for CA key pair generation, as specified in section 5.2.2. The CA key pair generation process shall create a verifiable audit trail that the security requirements for procedures were followed. The documentation of the procedure shall be detailed enough to show that appropriate role separation was used. An independent third party shall validate the process by either witnessing the key generation or by examining the signed and documented record of the key generation.

Activation of the Fortior Solutions PKI CMS Master Key shall require strong authentication of Trusted Roles. Key diversification operations by the CMS shall also occur on the CMS hardware cryptographic module. The diversified keys shall only be stored in hardware cryptographic modules that support FS‐PKI‐PIV‐I‐hw. The CMS Master Key and diversified keys shall be protected from unauthorized disclosure and distribution. Card management shall be configured such that only the Fortior Solutions PKI CMS can manage issued cards.

6.1.2 Private Key Delivery to Subscriber Fortior Solutions PKI CAs shall generate their own key pair and therefore do not need private key delivery.

If Subscribers generate their own key pairs, then there is no need to deliver private keys, and this section does not apply.

When Fortior Solutions PKI CAs or RAs generate keys on behalf of the Subscriber, then the private key shall be delivered securely to the Subscriber. Private keys may be delivered electronically or may be delivered on a hardware cryptographic module. In all cases, the following requirements shall be met:

a. Anyone who generates a private signing key for a Subscriber shall not retain any copy of the key after delivery of the private key to the Subscriber;

b. The private key shall be protected from activation, compromise, or modification during the delivery process;

c. The Subscriber shall acknowledge receipt of the private key(s); and

d. Delivery shall be accomplished in a way that ensures that the correct tokens and activation data are provided to the correct Subscribers:

i. For hardware modules, accountability for the location and state of the module shall be maintained until the Subscriber accepts possession of it; and

ii. For electronic delivery of private keys, the key material shall be encrypted using a cryptographic algorithm and key size at least as strong as the private key. Activation data shall be delivered using a separate secure channel.

The Fortior Solutions PKI CA, or CMS, or the RA shall maintain a record of the Subscriber acknowledgement of receipt of the token.

6.1.3 Public Key Delivery to Certificate Issuer Where the Subscriber or RA generates key pairs, the public key and the Subscriber‘s identity shall be delivered securely to the CA for certificate issuance. The delivery mechanism shall bind the Subscriber‘s verified identity to the public key. If cryptography is used to achieve this binding, it shall be at least as strong as the CA keys used to sign the certificate.

6.1.4 CA Public Key Delivery to Relying Parties The new or updated public key pair of a trust anchor shall be provided to the Subscribers acting as Relying Parties in a secure manner so that the trust anchor is not vulnerable to modification or substitution. The new public keys may be distributed in a self‐signed certificate, in a key rollover certificate, or in a new CA certificate (e.g., cross‐


of 105

certificate) obtained from the Fortior Solutions PKI. Acceptable methods for delivery of trust anchor include but are not limited to the following:

a. The CA loading a trust anchor onto tokens delivered to Subscribers via secure mechanisms;

b. Secure distribution of a trust anchor through secure out‐of‐band mechanisms;

c. Comparison of certificate hash (fingerprint) against trust anchor hash made available via authenticated out‐of‐band sources (note that fingerprints or hashes published in‐band along with the certificate are not acceptable as an authentication mechanism); or,

d. Downloading trust anchor from web sites secured with a currently valid certificate of equal or greater Assurance Level than the certificate being downloaded and the trust anchor is not in the certification chain for the Web site certificate.

Additionally:

a. Key rollover certificates are signed with the CA’s current private key, so secure distribution is not required; and,

b. CA certificates that are signed by another CA’s current private key are protected, so secure distribution is not required.

6.1.5 Key Sizes If the FSPMA determines that the security of a particular algorithm may be compromised, it may require the CAs to revoke the affected certificates.

All certificates (including self‐signed certificates), CRLs, and other protocols used by the PKI (i.e., Transport Layer Security (TLS)) shall use the following algorithm suites.

Cryptographic Function Expire before 12/31/2030 Expire after 12/31/2030

Public keys in CA, Identity, PIV‐I Authentication, PIV‐I Card Authentication, and Digital Signature Certificates; CRL Signatures; and OCSP (FIPS 186‐3)

2048 bit RSA, 224 bit ECDSA in prime field, or 233 bit ECDSA in

binary field

3072 bit RSA, 256 bit ECDSA in prime field, or 283 bit ECDSA in

binary field

Public Keys in Encryption Certificates (PKCS 1 for RSA and NIST SP 800‐56A for ECDH)

2048 bit RSA, 224 bit ECDH in prime field, or 233 bit ECDH in

binary field

3072 bit RSA, 256 bit ECDSA in prime field, or 283 bit ECDSA in binary field

Symmetric Encryption 3 Key TDES or AES AES

Cryptographic Function Issued before 12/31/2030 Issued after 12/31/2030

Hashing Algorithm for Certificates

SHA‐256 SHA‐256

CRLs, OCSP Responder certificates, and OCSP Responses shall use the same or stronger signature algorithms, key sizes, and hash algorithms as used by the CA to sign the certificate in question.


of 105

All FS‐PKI‐PIV‐I‐hw, FS‐PKI‐PIV‐I‐cardAuth, and FS‐PKI‐PIV‐I‐contSign certificates shall contain public keys and algorithms that conform to NIST SP 800‐78.

6.1.6 Public Key Parameters Generation and Quality Checking RSA keys shall be generated in accordance with FIPS 186‐3. Prime numbers for RSA shall be generated and tested for primality in accordance with FIPS 186‐3.

ECDSA and ECDH keys shall be generated in accordance with FIPS 186‐3. Curves from FIPS 186‐3 shall be used.

6.1.7 Key Usage Purposes The use of a specific key is determined by the key usage extension in the X.509 certificate.

In particular:

a. Certificates to be used for Digital Signatures shall set the digitalSignature and nonRepudiation bits;

b. Certificates to be used for encryption shall set the keyEncipherment bit;

c. Certificates to be used for key agreement shall set the keyAgreement bit;

d. CA certificates shall include cRLSign and keyCertSign bits;

e. Certificates to be used for authentication shall set the digitalSignature bit only;

f. Certificates to be used for CSS Key Use key usage extensions signing OCSP responses shall set the digitalSignature, and nonrepudiation bits; and

g. Certificates to be used at the FS‐PKI‐PIV‐I‐contSign assurance level shall include an extended key usage of id‐fpki‐pivi‐content‐signing.

Public keys that are bound into certificates shall be certified for use in signing or encrypting, but not both. This restriction is not intended to prohibit use of protocols (like the Secure Sockets Layer) that provide authenticated connections using Key Management certificates and require setting both digitalSignature and keyEncipherment bits to be set. However, in no case may dual‐use certificates assert the non‐repudiation key usage bit, and shall not be used to authenticate data that will be verified on the basis of the dual‐use certificate on any future date.

If a certificate is used for authentication of ephemeral keys, the Key Usage bit in the certificate must assert the digitalsignature and/or nonrepudiation bits, and may or may not assert the Key Encryption and Key Agreement depending on the public key in the certificate.

For Subscriber certificates the Extended Key Usage extension shall always be present and shall not contain anyExtendedKeyUsage {2.5.29.37.0}. The extended key usage shall meet the requirements stated in Table 10‐14. Extended Key Usage OIDs shall be consistent with key usage bits asserted.

6.2 PrivateKeyProtectionandCryptographicModuleEngineeringControls

6.2.1 Cryptographic Module Standards and Controls The relevant standard for cryptographic modules is FIPS PUB 140‐2, Security Requirements for Cryptographic Modules. The FSPMA may determine that other comparable validation, certification, or verification standards are sufficient. These standards shall be published by the FSPMA. Cryptographic modules shall be validated to the FIPS 140‐2 level identified in section 6.1, or validated, certified, or verified to requirements published by the FSPMA.

The table in section 6.1.1 summarizes the minimum requirements for cryptographic modules; higher levels may be used. Private keys shall not exist in plaintext form outside of the cryptographic module.

PIV‐I Cards are PKI tokens that have private keys associated with certificates asserting policies mapped to PIV‐I hardware or PIV‐I‐cardAuth. See Section 12 for PIV‐I requirements.


of 105

6.2.2 Private Key Multi-Person Control Use of a CA private signing key, a CSA private signing key or a FS‐PKI‐PIV‐I‐contSign private key shall require action by at least two persons.

6.2.3 Private Key Escrow Under no circumstances shall any private signature key be escrowed. No CA key used to sign certificates or CRLs shall be escrowed.

Subscriber private keys used solely for decryption shall be escrowed prior to the generation of the corresponding certificates.

If a device has a separate key management key certificate, the key management private key shall be escrowed except where the encrypted data will not need to be recovered. Escrow when required shall be completed prior to certificate issuance.

6.2.4 Private Key Backup

6.2.4.1 Backup of CA Private Signature Key The CA private signature keys shall be backed up under the same multi‐person control as the operational signature key. A single backup copy of the signature key shall be stored at or near the CA location.

A second backup copy shall be kept at the CA backup location.

Procedures for CA private signature key backup shall be included in the Fortior Solutions PKI CPS and shall meet the multiparty control requirement of section 5.2.2.

All copies of the CA private signature key shall be accounted for and protected in the same manner as the original.

6.2.4.2 Backup of Subscriber Private Signature Key Subscriber private signature keys based on FS‐PKI‐MediumSw or FS‐PKI‐MediumCBPSw may be backed up or copied, but must be held under the Subscriber’s direct control.

Subscriber private signature keys based on FS‐PKI‐MediumHw, FS‐PKI‐MediumCBPHw, or FS‐PKI‐PIV‐I assurance levels may not be backed up or copied.

6.2.4.3 Backup of Subscriber Key Management Private Keys Backed up subscriber private key management keys shall not be stored in plain text form outside the cryptographic module. Storage must ensure security controls consistent with the protection provided by the subscriber’s cryptographic module.

6.2.4.4 CSA Private Key Backup If backed up, the CSA private signature keys shall be backed up under the same multi‐person control as the signature key is invoked, and shall be accounted for and protected in the same manner as the original. A single backup copy of the signature key may be stored at or near the CSA location. A second backup copy may be kept at the CSA backup location. Procedures for CSA private signature key backup shall be included in the Fortior Solutions PKI CPS.

6.2.4.5 Content Signing Key Backup The FS‐PKI‐PIV‐I‐contSign private keys shall be backed up under the same multi‐person control as the operational Content Signing key. A single backup copy of the key shall be stored at or near the Content Signing system location. All copies of the FS‐PKI‐PIV‐I‐contSign private signature key shall be accounted for and protected in the same manner as the original.

A second backup copy shall be kept at the CA or CMS backup location.


of 105

Procedures for FS‐PKI‐PIV‐I‐contSign private key backup shall be included in the Fortior Solutions PKI CPS and shall meet the multiparty control requirement of section 5.2.2.

6.2.4.6 Backup of Device Private Keys Device keys must be held under the control of the device’s human sponsor or other authorized individual. Device keys may be backed up or copied, but shall not be stored in plaintext outside of the cryptographic module. Whatever storage is used must ensure security controls consistent with the protection provided by the devices cryptographic module.

6.2.4.7 Custodial Subscriber Key Stores

Custodial Subscriber Key Stores hold keys for a number of Subscriber certificates in one location. When a collection of private keys for Subscriber certificates are held in a single location, there is a higher risk associated with compromise of that cryptographic modulethan that of a single Subscriber. Cryptographic modules for Custodial Subscriber Key Stores at the Rudimentary Assurance Level shall be no less than FIPS 140 Level 1 (Hardware or Software). For all other levels, the cryptographic module shall be no less than FIPS 140 Level 2 Hardware. In addition, authentication to the Cryptographic Device in order to activate the private key associated with a given certificate shall require authentication commensurate with the assurance level of the certificate. Fortior Solutions does not allow the use of custodial subscriber key stores.

6.2.5 Private Key Archival Private signature keys shall not be archived.

6.2.6 Private Key Transfer Into or From a Cryptographic Module CA, CMS, and CSA private keys shall be generated by and remain in a FIPS 140‐2 approved cryptographic module. The CA, CMS, and CSA private keys may be backed up in accordance with the appropriate sub‐part of section 6.2.4.

Private or symmetric keys used to encrypt other private keys for transport must be protected from disclosure. In the event that a private key is to be transported from one location to another the key shall never exist in plaintext and shall be encrypted throughout transport.

6.2.7 Private Key Storage on Cryptographic Module The cryptographic module may store private keys in any form as long as the keys are not accessible without the use of an authentication mechanism that is in compliance with the FIPS 140‐2 rating of the cryptographic module. The cryptographic module storing the key shall be at least as strong as that required in section 6.1.1.

6.2.8 Method of Activating Private Key CA signing key activation requires multiparty control as specified in Section 5.2.2. In addition, FS‐PKI‐PIV‐I‐contSign key activation requires the same multiparty control established for the Fortior Solutions PKI CAs (see Section 5.2.2). The user of a cryptographic module must be authenticated to the cryptographic module before the activation of any private key(s). Acceptable means of authentication include but are not limited to pass‐phrases, PINs or biometrics. Entry of activation data shall be protected from disclosure (i.e., the data should not be displayed while it is entered).

For FS‐PKI‐PIV‐I‐cardAuth certificates, user activation of the private key is not required.

6.2.9 Method of Deactivating Private Key The cryptographic modules that have been activated shall not be left unattended or otherwise available to unauthorized access. After use, the cryptographic module shall be deactivated, i.e., via a manual logout procedure, or automatically after a period of inactivity as defined in the Fortior Solutions PKI CPS. Hardware cryptographic modules shall be removed and stored in a secure container when not in use.

6.2.10 Method of Destroying Private Key


of 105

Trusted roles shall destroy private signature keys when they are no longer needed, or when the certificates to which they correspond expire or are revoked. For software cryptographic modules, this can be done by overwriting the data. For hardware cryptographic modules, this will likely be done by executing an ‘initialize’ command. Physical destruction of hardware should not be required.

6.2.11 Cryptographic Module Rating See section 6.2.1.

6.3 OtherAspectsofKeyPairManagement

6.3.1 Public Key Archival The public key is archived as part of the certificate archival.

6.3.2 Certificate Operational Periods and Key Pair Usage Periods FS‐PKI‐PIV‐I‐hw and FS‐PKI‐PIV‐I‐cardAuth certificate expiration shall not be later than the expiration date of the hardware token on which the certificates reside. In no case may a CA issue any certificate whose expiration extends beyond the expiration of the CA certificate.

The validity period of Subscriber certificates shall not exceed beyond the initial identity‐proofing requirements specified in section 3.3.1.

CAs that distribute their self‐signed certificates for use as trust anchors shall limit the lifetime of the private keys to 20 years. For all other CAs, the CA shall limit the use of its private keys to a maximum of three years for subscriber certificates and three years for CRL signing and OCSP responder certificates.

The following table provides the maximum life times for all private keys and certificates issued under this policy.

Key 2048 Bit Keys Private Key Certificate

Root CAs 20 years 20 years Signing CAs 5 years 10 years Cross‐Certificate 10 years 10 years Subscriber Identity or Signature 3 years 3 years Subscriber Encryption 3 years 3 years FS‐PKI‐PIV‐I Content Signer 3 Years 8 Years OCSP Responder 3 years 31 days Server 3 years 3 years Device 3 years 3 years

6.4 ActivationData

6.4.1 Activation Data Generation and Installation The activation data used to unlock private keys, in conjunction with any other access control, shall have an appropriate level of strength for the keys or data to be protected and shall meet the Fortior Solutions PKI security policy requirements (section 6.2.1) of the crypto module used to store the keys. Subscriber activation data may be user selected. For CAs, it shall either entail the use of biometric data or satisfy the policy‐enforced at/by the cryptographic module. If the activation data must be transmitted, it shall be via an appropriately protected


of 105

channel, and distinct in time and place from the associated cryptographic module. If passwords are used to activate a CA signing key, the password shall be changed at least as often as when the CA is re‐keyed.

6.4.2 Activation Data Protection Data used to unlock private keys shall be protected from disclosure by a combination of cryptographic and physical access control mechanisms. Activation data should either be biometric in nature or memorized, not written down. If written down, it shall be secured at the level of the data that the associated cryptographic module is used to protect, and shall not be stored with the cryptographic module. The protection mechanism shall include a facility to temporarily lock the account, or terminate the application, after a predetermined number of failed login attempts as set forth in the Fortior Solutions PKI CPS.

6.4.3 Other Aspects of Activation Data Fortior Solutions PKI CAs, CSAs, and RAs shall change the activation data whenever the token is re‐keyed or returned from maintenance.

For Fortior Solutions PKI PIV‐I assurance, the activation data may be reset upon a successful biometric one‐to‐one match of the applicant by an RA or a Trusted Agent against the biometrics collected during the identity proofing process described in section 3.2.3.

6.5 ComputerSecurityControls

6.5.1 Specific Computer Security Technical Requirements The following computer security functions may be provided by the operating system, or through a combination of operating system, software, and physical safeguards (in a VME, these functions are applicable to both the VM and hypervisor). The Fortior Solutions PKI CA, CMS, CSA and RA shall include the following functionality:

a. Require authenticated logins;

b. Provide Discretionary Access Control, including managing privileges of users to limit users to their assigned roles;

c. Require identification and authentication of PKI roles and associated identities

d. Provide a security audit capability (see section 5.4);

e. Prohibit object re‐use;

f. Require use of cryptography for session communication and database security;

g. Require a trusted path for identification and authentication;

h. Provide domain isolation for processes;

i. Provide self‐protection for the operating system;

j. Require self‐test of security‐related CA services (i.e., check the integrity of the audit logs); and,

k. Support recovery from key or system failure.

When Fortior Solutions PKI CA equipment is hosted on evaluated platforms in support of computer security assurance requirements then the system (hardware, software, operating system) shall, when possible, operate in an evaluated configuration. At a minimum, such platforms shall use the same version of the computer operating system as that which received the evaluation rating.

The CA‐computer system shall be configured with the minimum of the required accounts, network services, and shall not permit remote login.

The Fortior Solutions PKI Root CA shall be offline when not in use.


of 105

6.5.2 Computer Security Rating No stipulation.

6.6 Life‐CycleTechnicalControls

6.6.1 System Development Controls The system development controls for the Fortior Solutions PKI CA, CMS, and CSA are as follows:

a. Use software that has been designed and developed under a formal, documented development methodology;

b. Where open source software has been utilized, the Fortior Solutions PKI shall demonstrate that security requirements were achieved through software verification and validation, and structured development/lifecycle management;

c. Procured hardware and software shall be purchased in a fashion to reduce the likelihood that any particular component was tampered with (i.e., by ensuring the equipment was randomly selected at time of purchase);

d. Specially developed hardware and software shall be developed in a controlled environment, and the development process shall be defined and documented. This requirement does not apply to commercial off‐the‐shelf hardware or software;

e. All hardware must be shipped or delivered via controlled methods that provide a continuous chain of accountability, from the purchase location to the operations location;

f. The hardware and software, including the VME hypervisor, shall be dedicated to performing the PKI activities. There shall be no other applications, hardware devices, network connections, or component software installed which are not parts of the PKI operation. In a VME, a single hypervisor may support multiple CAs and their supporting systems, provided all systems have comparable security controls and are dedicated to the support of the CA;

g. In a VME, all VM systems must operate in the same security zone as the CA;

h. Proper care shall be taken to prevent malicious software from being loaded onto the equipment. Applications required to perform the PKI operations shall be obtained from sources authorized by local policy. CA, CMS, CSA, and RA hardware and software shall be scanned for malicious code on first use and periodically thereafter; and

i. Hardware and software updates shall be purchased or developed in the same manner as original equipment, and be installed by trusted and trained personnel in a defined manner.

6.6.2 Security Management Controls The configuration of the Fortior Solutions PKI CA, CMS, and CSA system as well as any modifications and upgrades shall be documented and controlled.

There shall be a mechanism for detecting unauthorized modification to the CA, CMS, and CSA software or configuration.

A formal configuration management methodology shall be used for installation and ongoing maintenance of the CA and CMS system. The CA, CMS, and CSA software, when first loaded, shall be verified as being that supplied from the vendor, with no modifications, and be the version intended for use.

For RA workstations, only the software and devices necessary to support the Fortior Solutions mission shall be loaded onto the workstation and shall be obtained from sources authorized by local policy.

6.6.3 Life-Cycle Security Controls No stipulation.


of 105

6.7 NetworkSecurityControls

The Fortior Solutions PKI Root CA and its internal PKI repositories shall be operated off‐line with no Internet connections.

Fortior Solutions PKI CAs, CSAs, CMS, and RA equipment shall employ appropriate security measures to ensure they are guarded against denial of service and intrusion attacks. Such measures shall include the use of guards, firewalls and filtering routers. Unused network ports and services shall be turned off. Any network software present shall be necessary to the functioning of the pertinent equipment. CA and CMS network security controls shall be equal in assurance and security.

Any boundary control devices used to protect the network on which PKI equipment is hosted shall deny all but the necessary services to the PKI equipment even if those services are enabled for other devices on the network.

6.8 Time‐Stamping

All CA, CSA, and CMS components shall regularly synchronize with a time service such as the National Institute of Standards and Technology (NIST) Atomic Clock or the NIST Network Time Protocol (NTP) Service. Time derived from the time service shall be used for establishing the time:

a. Initial validity time of a Subscriber‘s certificate;

b. Revocation of a Subscriber‘s certificate;

c. Audit log timestamps;

d. Publishing of CRL updates; and

e. OCSP or other CSA responses.

Asserted times shall be accurate to within three (3) minutes. Electronic or manual procedures may be used to maintain system time. Clock adjustments are auditable events as listed in section 5.4.1.


of 105

7 PKI INTEROPERABILITY PROFILES FOR REPOSITORY, CERTIFICATE, CRL, ANDOCSP

This section provides an overview of the Fortior Solutions PKI interoperability profiles associated with the Repository. The following topics are discussed, followed by specific repository, certificate, CRL and OCSP profiles:

Protocol

Authentication

Naming

Object Class

Attributes

Each of these items is described below.

7.1RepositoryProfile

7.1.1 Protocol Fortior Solutions shall implement a PKI Repository that provides HTTP protocol access to certificates and CRLs.

7.1.2 Authentication The PKI Repository shall permit “none” authentication to read certificate and CRL information.

Any write, update, add entry, delete entry, add attribute, delete attribute, change schema etc., shall require password over SSL or a stronger authentication mechanism.

7.1.3 Naming This CP has defined the naming convention.

When a LDAP repository is used:

1. Certificates shall be stored in the LDAP Repository in the entry that appears in the certificate subject name;

2. The issuedByThisCA element of crossCertificatePair shall contain the certificate(s) issued by a CA whose name the entry represents; and

3. CRLs shall be stored in the LDAP Repository in the entry that appears in the CRL issuer name.

7.1.4 Object Class When a LDAP repository is used:

1. Entries that describe CAs shall be defined by the organizationUnit structural object class. These entries shall also be a member of pkiCA cpCPS auxiliary object classes; and

2. Entries that describe individuals (human entities) shall be defined by the inetOrgPerson class, which inherits from other classes: person, and organizational Person. These entries shall also be a member of pkiUser auxiliary object class.

7.1.5 Attributes When a LDAP repository is used:

1. CA entries shall be populated with the caCertificate, crossCertificatePair, certificateRevocationList, cPCPS attributes, as applicable; and


of 105

2. User entries shall be populated with userCertificate attribute containing the encryption certificate. Signature certificate need not be published to the LDAP Repository.

7.2 CertificateProfile

7.2.1 Version Numbers The Fortior Solutions PKI CAs shall issue X.509 v3 certificates (populate version field with integer "2").

7.2.2 Certificate Extensions Critical private extensions in certificates shall be interoperable in their intended community of use. However, CA certificates shall not include critical private extensions. Interoperability testing shall be completed by testing a representative set of end user applications for successful certificate usage.

Issuer CA and Subscriber certificates may include any extensions as specified by RFC 5280 in a certificate, but must include those extensions required by this CP. Any optional or additional extensions shall be non‐critical and shall not conflict with the certificate and CRL profiles defined in this CP. Section 10 contains the certificate formats.

All FS‐PKI‐PIV‐I‐hw and FS‐PKI‐PIV‐I‐cardAuth certificates shall comply with the Federal PKI Policy Authority’s ‘X.509 Certificate and Certificate Revocation List (CRL) Extensions Profile for Personal Identity Verification Interoperable (PIV‐I) Cards’.

7.2.3 Algorithm Object Identifiers Certificates issued under this CP shall use the following OIDs for signatures:

sha256WithRSAEncryption {iso(1) member‐body(2) us(840) rsadsi(113549) pkcs(1) pkcs‐1(1) 11}

ecdsa‐with‐Sha256 {iso(1) member‐body(2) us(840) ansi‐X9‐62(10045) signatures(4) specified(3) sha256(2)}

Certificates issued under this CP shall use the following OIDs for identifying the subject public key information:

rSAEncryption {iso(1) member‐body(2) us(840) rsadsi(113549) pkcs(1) pkcs‐1(1) 1}

id‐ecPublicKey {iso(1) member‐body(2) us(840) ansi‐X9‐62(10045) public‐key‐type(2) 1}

7.2.4 Name Forms The subject and issuer fields of the certificate shall be populated with a unique Distinguished Name in accordance with one or more of the X.500 series standards, with the attribute type as further constrained by RFC 5280. Subject and issuer fields shall include attributes as detailed in the tables below.

7.2.4.1 Issuer and Subject Name Form for Fortior Solutions PKI CAs

USAGE ATTRIBUTE REQUIRED COUNT

CONTENT

Recommended CN 0…1 Descriptive name for CA, i.e., ‘CN=Fortior Solutions PKI Root CA 2018’

Optional OU 0…N As needed

Recommended OU 0…1 ‘Certificate Authorities’ or similar text

Required O 1 Issuer name, i.e., ‘O=Fortior Solutions’

Required C 1 Country name, i.e., ‘C=US’


of 105

7.2.4.2 Subject Name Form for non-CAs

USAGE

ATTRIBUTE REQUIREDCOUNT

CONTENT

Required See right 1…N Additional naming attributes for uniquely identifying the subject including common

name, SerialNumber, email, etc.

Optional OU 0…N As needed, i.e., The name of the Affiliated organization or “Unaffiliated”

as per 3.1 Required O 1 Issuer name, i.e., ‘O=Fortior Solutions’

Required C 1 Country name, i.e., ‘C=US’ exactly as it appears in the CA certificate(s)

When multiple values exist for an attribute in a DN, the DN shall be encoded so that each attribute value is encoded in a separate relative distinguished name.

7.2.5 Name Constraints Fortior Solutions PKI CA(s) may assert critical or non‐critical name constraints beyond those specified in the certificate Formats in section 10 subject to the requirements above.

The issuing CA may establish a pseudonymous Subscriber Subject name to meet local privacy regulations as long as such name is unique and traceable to a corresponding Subscriber. Issuer names shall not be obscured.

7.2.6 Certificate Policy Object Identifier CA and Subscriber certificates issued under this Fortior Solutions PKI CP shall assert one or more of the certificate Policy OIDs listed in section 1.2. When a CA asserts a policy OID, it shall assert all lower assurance policy OIDs.

7.2.7 Usage of Policy Constraints Extension Principle CAs shall adhere to the policy constraints identified in the certificate formats described in section 10 in this Fortior Solutions PKI CP, since inhibiting policy mapping may limit interoperability.

7.2.8 Policy Qualifiers Syntax and Semantics Certificates issued under this Fortior Solutions PKI CP shall contain policy qualifiers as follows:

Policy name and CP pointers.

7.2.9 Processing Semantics for the Critical Certificate Policies Extension Processing semantics for the critical certificate policies extension shall conform to the RFC 5280 certification path processing rules.

7.3 CRLProfile

7.3.1 Version Numbers CAs shall issue X.509 version two (v2) CRLs (populate version field with integer "1").

7.3.2 CRL and CRL Entry Extensions Critical private extensions shall be interoperable in their intended community of use. Section 10 contains the CRL formats.


of 105

7.4 OCSPProfile

OCSP requests and responses shall be in accordance with RFC 6960. Section 10 contains the OCSP request and response formats.

7.4.1 Version Numbers The OCSP version number for request and responses shall be v1.

7.4.2 OCSP Extensions Responses shall support the nonce extension.


of 105

8 COMPLIANCEAUDITANDOTHERASSESSMENTS

The FSPMA shall have a compliance audit mechanism in place to ensure that the requirements of this CP, the associated CPS, all PKI components covered by this CP, and the provisions of the contracts (including agreement) with the TSCP Bridge, regardless of how or by whom the PKI components are managed and operated, and are being implemented and enforced.

8.1 FrequencyorCircumstancesofAssessments

All Fortior Solutions PKI CAs, CMSs, CSAs, and RAs shall be subject to a periodic compliance audit, which is not less frequent than once per year.

8.2 IdentityandQualificationsofAssessor

The compliance auditor shall demonstrate competence in the field of compliance audits, and shall be thoroughly familiar with the requirements of this CP. The compliance auditor must perform such compliance audits as a primary responsibility. The Fortior Solutions PKI CPS shall identify the compliance auditor and justify the compliance auditor's qualifications.

8.3 Assessor'sRelationshiptoAssessedEntity

The compliance auditor shall either represent a firm, which is independent from Fortior Solutions, or it shall be sufficiently organizationally separated from the company to provide an unbiased, independent evaluation. To further insure independence and objectivity, the compliance auditor may not have served Fortior Solutions in developing or maintaining the entity’s PKI Facility, associated IT and network systems, or certificate practices statement. The FSPMA shall determine whether a compliance auditor meets this requirement. In the event that Fortior Solutions chooses to engage compliance auditor services internal to Fortior Solutions, the Fortior Solutions PKI shall undergo an audit from an external third party auditor no less often than every third year.

8.4 TopicsCoveredbyAssessment

The purpose of a compliance audit shall be to verify that a component operates in accordance with this CP, CPS, and the MTFSA with TSCP. The compliance audit must include an assessment of the Fortior Solutions PKI CPS against this CP, to determine that the CPS adequately addresses and implements the requirements of this CP and the MTFSA.

8.5 ActionsTakenasaResultofDeficiency

The FSPMA may determine that a CA is not complying with its obligations as set forth in this CP or CPS. When such a determination is made, the FSPMA may suspend operation, may revoke the CA, or take other actions as appropriate. The Fortior Solutions PKI CPS shall provide the appropriate procedures. When the compliance auditor finds a discrepancy between how the CA is designed or is being operated or maintained, and the requirements of this CP the following actions shall be performed:

a. The compliance auditor shall note the discrepancy;

b. The compliance auditor shall notify the FSPMA of the discrepancy;

c. The FSPMA shall notify the TSCP Bridge PMA promptly and provide a remediation plan;

d. The Fortior Solutions PKI shall develop a remediation plan; and

e. The party responsible for correcting the discrepancy shall determine what further notifications or actions are necessary pursuant to the requirements of this CP and the respective contracts, and then proceed to make such notifications and take such actions without delay.

Depending upon the nature and severity of the discrepancy, and how quickly it can be corrected, the FSPMA may decide to temporarily halt operation of the CA, to revoke a certificate issued by the CA, or take other actions it deems appropriate. The FSPMA shall develop procedures for making and implementing such determinations.


of 105

8.6 CommunicationofResults

An Audit Compliance Report, including FSPMA assertions as to the audit status of the PKI along with identification of corrective measures taken or being taken shall be provided to the FSPMA by the Auditor as set forth in section 8.1. The report shall identify the versions of the CP and CPS used in the assessment. Additionally, where necessary, the results shall be communicated as set forth in 8.5 above. The compliance audit package shall be prepared in accordance with the Compliance Audit Requirements document and shall include an assertion from the FSPMA that all PKI components have been audited including any components that may be separately managed and operated. The FSPMA shall submit a compliance audit package to the TPMA, even if there are no audit findings or discrepancies.


of 105

9 OTHERBUSINESSANDLEGALMATTERS

9.1 Fees

9.1.1 Certificate Issuance or Renewal Fees Fortior Solutions in its sole discretion may charge end‐user Subscribers for the issuance, management, and renewal of Certificates provided by the Fortior Solutions PKI in accordance with the MTFSA with TSCP.

9.1.2 Certificate Access Fee Fortior Solutions does not charge for access to certificates or certificate information published in the Fortior Solutions PKI Repository.

9.1.3 Revocation or Status Information Access Fees Fortior Solutions in its sole discretion may charge fees related to enhanced revocation information or certificate status services. Fortior Solutions does not charge Relying Parties for access to basic certificate revocation or status information published in the Fortior Solutions PKI Repository.

9.1.4 Fees for Other Services Fortior Solutions in its sole discretion may charge fees for other PKI services.

9.1.5 Refund Policy Refunds are not provided.

9.2 FinancialResponsibility

9.2.1 Insurance Coverage Fortior Solutions maintains reasonable levels of insurance coverage for its foreseeable liabilities to participants in connection with the Fortior Solutions PKI services. RAs and other Fortior Solutions PKI participants that provide certification services to support performance of their operational PKI responsibilities are required to maintain reasonable levels of such insurance coverage to address all foreseeable liability obligations to Fortior Solutions and other Fortior Solutions PKI participants.

9.2.2 Other Assets Fortior Solutions maintains sufficient financial resources to reasonably maintain operations and fulfill duties in connection with the Fortior Solutions PKI services. RAs and other Fortior Solutions PKI participants that provide certification services to support performance of their operational PKI responsibilities are required to maintain sufficient financial resources to reasonably maintain operations, fulfill duties, and address commercially reasonable liability obligations to Fortior Solutions and other Fortior Solutions PKI participants.

9.2.3 Insurance or Warranty Coverage for End-Entities Fortior Solutions does not provide insurance or warranty protection to end entities except as may be expressly described in this CP.

9.3 ConfidentialityofBusinessInformation

Fortior Solutions shall maintain the confidentiality of confidential business information that is clearly marked or labelled as confidential or by its nature should reasonably be understood to be confidential, and shall treat such information with the same degree of care it would for its own most confidential information, provided that the treatment of confidential business information exchanged with external PKIs in the context of submitting an application for cross‐certification will be in accordance with the terms of such agreements as may be entered into between the applicable entity and Fortior Solutions.


of 105

9.4 PrivacyofPersonalInformation

For the purposes of the Fortior Solutions PKI ‐related services, the Fortior Solutions PKI collects, stores, processes, and may disclose personally identifiable information in accordance with applicable laws and regulations and the Fortior Solutions Privacy Policy, located at the URL cited on the cover page of this CP. RAs and other Fortior Solutions PKI participants that provide certification services to support performance of their operational PKI responsibilities shall be required to comply with applicable laws, regulations and privacy policies in connection with their storing, processing and disclosure of personally identifiable information.

When Fortior Solutions CAs issue certificates that contain the UUID in the subject alternative name extension, these certificates shall not be distributed over the Internet by either LDAP or HTTP.

9.5 IntellectualPropertyRights

Fortior Solutions owns and reserves all rights, title and interest in all intellectual property and other rights associated with all products and services in connection with the Fortior Solutions PKI services. Neither this CP, the Fortior Solutions PKI CA nor the OA knowingly violates intellectual property rights held by others.

9.5.1 Property Rights in Certificates and Revocation Information Fortior Solutions owns and reserves all rights, title and interest in all intellectual property and other rights in and to all Fortior Solutions PKI certificates and revocation information. For any certificates issued under the Fortior Solutions PKI, Fortior Solutions permits reproduction and distribution of certificates, provided that the certificates are reproduced in full and use of certificates is subject to a Memorandum of Agreement (or equivalent contractual agreement) with the relevant CA. Fortior Solutions permits Relying Parties to use revocation information to perform Relying Party functions, subject to Fortior Solutions’ applicable terms and conditions.

9.5.2 Property Rights in this CP and related CPSs Fortior Solutions owns and reserves all rights, title and interest in all intellectual property and other rights to this CP and related CPSs.

9.5.3 Property Rights in Names Fortior Solutions owns and reserves all rights, title and interest in all intellectual property and other rights in the Fortior Solutions PKI name and all associated names. As between Fortior Solutions and a certificate Applicant, the certificate Applicant retains all rights, if any, in any trademark, service mark, or trade name of the certificate Applicant contained in any Customer Application.

9.5.4 Property Rights in Keys Key pairs corresponding to certificates of cross‐certified CAs and Subscribers are the property of the cross‐certified CAs and Subscribers that are the respective subjects of these certificates, subject to the rights of Subscribers regardless of the physical medium within which the certificates are stored and protected. Such persons retain all intellectual property rights in and to these key pairs. Notwithstanding the foregoing, Root CA’s, root public keys, and the root certificates containing them, including all CA public keys and self‐signed certificates, are the sole and exclusive property of Fortior Solutions.

9.6 RepresentationsandWarranties

The Fortior Solutions PKI services are performed in conformance with applicable industry and government standards. Any express representations and warranties of the Fortior Solutions PKI and contractual partners shall be contained in such written contractual agreements as may be entered into by such parties.

9.6.1 The Fortior Solutions PKI CA Representations and Warranties The Fortior Solutions PKI CA shall represent and warrant in applicable contractual agreements that, to its knowledge and to the extent within its control:

a. Its signing private key is protected and no unauthorized person has had access to that private key and is being maintained in a manner consistent with this CP;


of 105

b. Its representations made in any applicable agreements are true and accurate;

c. Each Subscriber has been required to represent and warrant that all information supplied by the Subscriber in connection with, and/or contained in the certificate is true;

d. If applicable, Affiliated Organizations shall be required to contractually agree to conform to the provisions of this CP; and

e. The certificate is to be used exclusively for authorized and legal purposes, consistent with this and any other applicable CP or CPS.

f. The Fortior Solutions PKI repository, CRL, and Certificate Status Services (e.g. OCSP) are being maintained in a manner consistent with this CP

9.6.2 Subscribers A Subscriber shall be required to sign a document (i.e., a subscriber agreement) containing the requirements the Subscriber must meet respecting protection of the private key and use of the certificate before being issued the certificate.

In signing the document described above, each Subscriber shall be required to agree to the following:

a. Subscriber shall abide by all export control restrictions;

b. Subscriber shall accurately represent itself in all communications with the PKI authorities; and

c. Subscriber shall promptly notify the appropriate CA upon suspicion of loss or compromise of its private keys. Such notification shall be made directly or indirectly through mechanisms consistent with this CP.

In signing the document described above, each Subscriber shall be required to represent and warrant, at a minimum, that:

a. Any information contained within a certificate is not considered private;

b. A PKI Sponsor shall assume the Subscriber obligations for devices;

c. The data contained in any certificates issued to Subscriber is accurate;

d. The Subscriber lawfully holds the private key corresponding to public key identified in the Subscriber's certificate;

e. The Subscriber shall protect its private keys at all times, in accordance with this CP, as stipulated in its certificate acceptance agreements, and local procedures

f. The Subscriber shall abide by all the terms, conditions, and restrictions levied on the use of its private keys and certificates ; and

g. The Subcriber is the sole user of the key corresponding to the Subscriber’s certificate(s) exception key recovery scenarios.

9.6.3 Relying Parties Parties that rely upon the certificates issued under a policy defined in this document shall be required to agree, at a minimum, to:

a. Use the certificate solely for the purpose for which it was issued, as indicated in the certificate information (i.e., the key usage extension);

b. Check each certificate for validity, using procedures described in the X.509 standard [ISO 9594‐8] or successor standard, prior to reliance;


of 105

c. Check each certificate for validity, using procedures described in the X.509 standard [ISO 9594‐8] or successor standard, prior to reliance;

d. Establish trust in the CA who issued a certificate by verifying the certificate path in accordance with the guidelines set by the X.509 Version 3 Amendment or its successor; and

e. Preserve original signed data, the applications necessary to read and process that data, and the cryptographic applications needed to verify the Digital Signatures on that data for as long as necessary to verify the signature on that data.

9.6.4 Affiliated Organizations Affiliated Organizations shallbe required to authorize the affiliation of Subscribers with the organization, and shall be required to inform the Fortior Solutions PKI CA in writing of any severance of affiliation with any current Subscriber.

9.6.5 Other Participants No stipulation.

9.7 DisclaimersofWarranties

To the extent permitted by applicable law, Policy Mapping Agreements, cross‐certificate Agreements, Memoranda of Understanding, and any other related contractual agreements may contain disclaimers of all warranties (other than any express warranties contained in such agreements).

EXCEPT AS EXPRESSLY PROVIDED HEREIN OR IN A WRITTEN CONTRACTUAL AGREEMENT WITH FORTIOR SOLUTIONS,

(A) CERTIFICATES ISSUED BY FORTIOR SOLUTIONS AND THE FORTIOR SOLUTIONS PKI ARE PROVIDED "AS IS", AND FORTIOR SOLUTIONS, ITS EMPLOYEES, OFFICERS, DIRECTORS, AGENTS, CONTRACTORS, ASSIGNS, REPRESENTATIVES, AND AFFILIATES DISCLAIM ALL OTHER WARRANTIES, CONDITIONS AND OBLIGATIONS OF EVERY TYPE, EXPRESS OR IMPLIED (INCLUDING, WITHOUT LIMITATION, ANY WARRANTIES OF MERCHANTABILITY, NON‐INFRINGEMENT, TITLE, SECURITY, SATISFACTORY QUALITY, OR FITNESS FOR A PARTICULAR PURPOSE, OR ACCURACY OF INFORMATION PROVIDED), AND FURTHER DISCLAIM ANY AND ALL LIABILITY FOR NEGLIGENCE, FAILURE TO WARN, OR LACK OF REASONABLE CARE, AND

(B) THE ENTIRE RISK OF THE USE OF ANY FORTIOR SOLUTIONS PKI CERTIFICATES, ANY FORTIOR SOLUTIONS PKI SERVICES, OR THE VALIDATION OF ANY DIGITAL SIGNATURES LIES WITH THE APPLICABLE END‐USER SUBSCRIBER, CROSS‐CERTIFIED CA, RELYING PARTY, AFFILIATED ORGANIZATION OR OTHER PARTICIPANT.

9.8 LimitationsofLiabilities

TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, IN NO EVENT SHALL FORTIOR SOLUTIONS, INC. OR THE FORTIOR SOLUTIONS PKI CA BE LIABLE FOR ANY INDIRECT DAMAGES OF ANY KIND, INCLUDING CONSEQUENTIAL, INCIDENTAL, SPECIAL, PUNITIVE, ANY COSTS, EXPENSES, OR LOSS OF PROFITS, OR OTHER DAMAGES WHATSOEVER ARISING OUT OF OR RELATED TO THIS CP OR THE FORTIOR SOLUTIONS PKI SERVICES, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. IN NO EVENT SHALL FORTIOR SOLUTIONS INC. OR THE FORTIOR SOLUTIONS PKI CA BE LIABLE FOR ANY USAGE OF CERTIFICATE THAT FAILS TO CONFORM TO THE LIMITATIONS OF USAGE STATED UNDER THIS CP OR THAT IS NOT IN COMPLIANCE WITH THIS CP AND ASSOCIATED CPS. NEITHER FORTIOR SOLUTIONS, INC. NOR THE FORTIOR SOLUTIONS PKI CA SHALL BE LIABLE FOR ANY DAMAGE ARISING FROM THE COMPROMISE OF A SUBSCRIBER‘S PRIVATE KEY OR ANY LOSS OF DATA. SUBJECT TO THE FOREGOING, THE TOTAL, AGGREGATE LIABILITY OF THE FORTIOR SOLUTIONS PKI CA IS LIABILITY ARISING OUT OF OR RELATED TO IMPROPER ACTIONS BY THE FORTIOR SOLUTIONS PKI CA AND SHALL BE LIMITED TO ONE THOUSAND DOLLARS ($1,000 USD) PER TRANSACTION AND ONE MILLION DOLLARS ($1 MILLION USD) PER INCIDENT.

FOR PURPOSES OF THIS SECTION 9.8, (A) “IMPROPER ACTIONS” MEANS A DELIBERATE FAILURE TO COMPLY WITH A MATERIAL TERM OF THIS CP, (B) “TRANSACTION” MEANS WHEN A RELYING PARTY RELIES UPON A CERTIFICATE ISSUED WITHIN A SINGLE CREDENTIAL BY THE FORTIOR SOLUTIONS PKI CA AND TAKES OR ALLOWS AN ACTION OR


of 105

SERIES OF ACTIONS AS A CONSEQUENCE OF SUCH RELIANCE, AND (C) “INCIDENT” MEANS THE AGGREGATE OF ALL TRANSACTIONS PERTAINING TO A SINGLE CREDENTIAL.

9.9 Indemnities

9.9.1 Indemnification by Entity CA

To the extent permitted by applicable law, Entity CAs agree to indemnify and hold TSCP, Inc. harmless from any acts or omissions resulting in liability, any loss or damage, and any suits and expenses of any kind including reasonable attorney’s fees that TSCP, Inc. may incur as a result of:

Falsehood or misrepresentation of fact by the other Entity CA in the applicable contractual agreements.

Failure by the Entity CA to disclose a material fact in any applicable contractual agreement, if the misrepresentation or omission was made negligently or with intent to deceive any party,

Entity CA’s failure to protect their CA Private Key, to use a Trustworthy System, or to otherwise take the precautions necessary to prevent the compromise, loss, disclosure, modification, or unauthorized use of the Entity CA Private Key, or

The Entity CA’s use of a name (including without limitation within a common name, domain name, or e‐mail address) that infringes upon the Intellectual Property Rights of a third party.

Any applicable agreement may include additional indemnity obligations.

9.9.2 Indemnification by Relying Parties and Subscribers To the extent permitted by applicable law, each Relying Party and Subscriber shall be required to defend, indemnify and hold harmless Fortior Solutions and its employees, officers, directors, contractors, agents, assigns, representatives and affiliates from and against any third party claims, liabilities, damages, costs, fines, penalties and expenses (including reasonable attorney‘s fees), relating to or arising out of use of or reliance by Relying Party or Subscriber of any certificates issued by Fortior Solutions, including, without limitation, for:

a. The Relying Party‘s or Subscriber’s improper, illegal, or unauthorized use of a certificate (including use of any expired, revoked, or non‐validated certificate);

b. The Relying Party‘s or Subscriber’s unreasonable reliance on a certificate; or

c. The Relying Party‘s failure to check the status of a certificate on which it relies to determine if the certificate is expired or revoked.

Any applicable contractual agreement with Fortior Solutions may include additional indemnity obligations.

9.10 TermandTermination

9.10.1 Term This CP is effective upon its approval by the FSPMA and publication in the appropriate location. Amendments to this CP are effective upon approval by the FSPMA and publication in the appropriate location.

There is no specified term for this CP. This CP remains in force until terminated by Fortior Solutions. Fortior Solutions may amend this CP from time to time in its sole discretion. For purposes of clarification, termination of any written contractual agreement entered into in connection with this CP does not operate as a termination of this CP.

9.10.2 Termination Fortior Solutions may terminate this CP at any time. Fortior Solutions will provide reasonable notice of termination prior to the effective date of such termination.


of 105

9.10.3 Effect of Termination and Survival Upon termination of this CP, CAs cross‐certified with or subordinate to the Fortior Solutions PKI CA remain bound by the terms of this CP for all certificates issued thereunder for the remainder of the validity periods of such certificates. The following sections of this CP survive any termination or expiration of this CP: section 2.1, section 2.2, section 5.4, section 5.5, section 6.2‐6.4, section 6.8, section 9.2‐ 9.4, section 9.7‐9.10, section 9.13‐9.16.

9.11 IndividualNoticesandCommunicationswithParticipants

Unless otherwise specified by written contractual agreement between the parties, the Fortior Solutions PKI uses commercially reasonable methods to communicate with participants, taking into account the criticality and subject matter of the communication.

The TPMA shall be notified at least two weeks and one day prior to the implementation of any planned infrastructure change that has the potential to affect the TPMA operational environment. The notice period begins upon written acknowledgement of the TPMA. All new artifacts (CA certificates, CRL DP, AIA and/or SIA URLs, etc.) resulting from the change shall be provided to the TPMA within 24 hours following implementation.

9.12 Amendments

9.12.1 Procedure for Amendment The FSPMA reviews this CP and the respective CPSs at least annually. Additional reviews may be performed at any time in the sole discretion of the FSPMA.

If the FSPMA wishes to amend the CP or CPS, it circulates such amendments for review to appropriate parties identified by the FSPMA. Comments from such parties are collected and considered by the FSPMA.

Following approval by the FSPMA, the amended CP will be posted to the URL cited on the cover page of this CP.

Notwithstanding the foregoing, if the FSPMA believes that amendments to the CP are necessary immediately to stop or prevent a breach of the security of Fortior Solutions, the FSPMA in its sole discretion may make such amendments, which amendments become effective immediately upon publication in the Repository.

9.12.2 Notification Mechanism and Period Errata, amendments (including a description of such amendments) and the most up‐to‐date copy of the CP are published online at the URL cited on the cover page of this CP.

In addition, notice of material changes to the CP, CPSs is provided to affected entities via a designated point of contact.

This CP and any subsequent changes are made publicly available within seven (7) days of approval by the FSPMA.

9.12.3 Circumstances Under Which OIDs Are Subject to Change

Certificate Policy OIDs are subject to change if the FSPMA determines that a change in the CP materially reduces the level of assurance provided.

9.13 DisputeResolutionProvisions

9.13.1 Disputes between Fortior Solutions and Third Parties Provisions for resolving disputes with Fortior Solutions in connection with this CP or the Fortior Solutions PKI services shall be set forth in the applicable written contractual agreements between the parties.

9.13.2 Alternate Dispute Resolution Provisions Except as otherwise agreed (i.e., under a written contractual agreement under section 9.13.1 above), any dispute under this CP or in connection with the Fortior Solutions PKI services shall be resolved by binding arbitration in accordance with the commercial rules (or international rules, if the other party to the dispute is a non‐US entity) of the American Arbitration Association then in effect. The arbitration panel shall consist of one (1) neutral


of 105

arbitrator if the amount in controversy is less than $500,000, otherwise the panel shall consist of three (3) neutral arbitrators, each an attorney with five (5) or more years of relevant experience The arbitrator(s) shall have never been employed or engaged (either as an employee or as an independent consultant) by either of the parties, or any parent, subsidiary or other affiliate thereof. The parties shall have the right to take discovery of the other party by any or all methods provided in the Federal Rules of Civil Procedure. The arbitrator(s) may upon request exclude from being used in the arbitration proceeding any evidence not made available to the other Party pursuant to a proper discovery request. The arbitrator(s) shall apply the federal law of the United States and/or the laws of the State of Oregon, as applicable, and the arbitration proceeding shall be held in Multnomah County or Washington County, Oregon, USA or in such other location as is mutually agreed upon by the parties. The cost of the arbitration shall be borne equally by the parties. Notwithstanding the choice of law provision in this CP, the Federal Arbitration Act, except as otherwise provided herein, shall govern the interpretation and enforcement of this provision. All arbitration proceedings shall be conducted in English. A party’s claim, dispute and controversy shall be arbitrated on an individual basis and not aggregated with the claims of any other party. Class action arbitration is prohibited. The arbitrator(s) shall have no discretion to award punitive damages. Notwithstanding the foregoing dispute resolution procedures, either party may apply to any court having jurisdiction to:

a. Enforce this arbitration provision; or

b. Seek provisional injunctive relief so as to maintain the status quo until the arbitration award is rendered or the dispute in otherwise resolved, or to otherwise prevent irreparable harm.

9.14GoverningLaw

Subject to any limits appearing in applicable law, and subject to any written contractual agreements with Fortior Solutions expressly to the contrary, the federal laws of the United States and/or the laws of the State of Oregon, USA, shall govern the enforceability, construction, interpretation, and validity of this CP, irrespective of contract or other choice of law provisions and without the requirement to establish a commercial nexus in the State of Oregon.

9.15 CompliancewithApplicableLaw

This CP is subject to applicable national, state, local and foreign laws, rules, regulations, ordinances, decrees, and orders including, but not limited to, restrictions, if any, on exporting or importing software, hardware, or technical information.

9.16 MiscellaneousProvisions

9.16.1 Entire Agreement No stipulation.

9.16.2 Assignment Except as may be otherwise agreed by Fortior Solutions under written contractual agreements entered into under this CP or in connection with the Fortior Solutions PKI services, no party except Fortior Solutions may assign or delegate this CP, or any of its rights or duties under written contractual agreements entered into under this CP or in connection with the Fortior Solutions PKI services, without the prior written consent of TSCP, which consent will not be unreasonably withheld.

9.16.3 Severability If this CP is incorporated by reference into a written contractual agreement with Fortior Solutions, and if any provision of this CP is held to be invalid or unenforceable by a court of competent jurisdiction, then the CP shall be enforced to the maximum extent permissible and the legality and enforceability of the provisions of this CP shall not be affected.

9.16.4 Waiver of Rights In any written contractual agreements entered into with Fortior Solutions under this CP or in connection with the Fortior Solutions PKI services, the parties to such agreement may agree that no waiver of any breach or default or


of 105

any failure to exercise any right under such agreement shall be construed as a waiver of any subsequent breach or default or relinquishment of any future right to exercise such right.

The headings in this CP are for convenience only and cannot be used in interpreting this CP.

9.16.5 Force Majeure Fortior Solutions is not liable for any failure or delay in its performance under this CP or in connection with the Fortior Solutions PKI services due to causes that are beyond its reasonable control, including, but not limited to, an act of God, act of civil or military authority, natural disasters, fire, epidemic, flood, earthquake, riot, war, failure of equipment, failure of telecommunications lines, lack of Internet access, sabotage, changes in the law, and governmental action or any unforeseeable events or situations.

FORTIOR SOLUTIONS HAS NO LIABILITY FOR ANY DELAYS, NON‐DELIVERIES, NON‐PAYMENTS, MIS‐DELIVERIES OR SERVICE INTERRUPTIONS CAUSED BY ANY THIRD PARTY ACTS OR THE INTERNET INFRASTRUCTURE OR ANY NETWORK EXTERNAL TO FORTIOR SOLUTIONS.

9.17 OtherProvisions

No further provisions are set forth in this Section 9 of the CP.


of 105

10 CERTIFICATE,CRL,ANDOCSPFORMATS

This Section contains the formats for the various Fortior Solutions PKI objects such as certificates, CRLs, and OCSP requests and responses. The Section contains only certificate profiles based on RSA. For algorithm identifiers, parameter encoding, public key encoding, and signature encoding for ECDSA and ECDH, RFC 3279 shall be used. Where CRLSign is listed as a key usage, this includes Offline CRL Signing.

10.1 PKIRootCACertificate(TrustAnchor)

Field Value

Version V3 (2)

Serial Number Must be unique

Issuer Signature Algorithm per section 6.1.5

Issuer Distinguished Name C=US, O=Fortior Solutions, OU=Certificate Authorities, CN=Fortior Solutions PKI Root CA 2018

Validity Period Expressed in UTCTime until 2049

Subject Distinguished Name C=US, O=Fortior Solutions, OU=Certificate Authorities, CN=Fortior Solutions PKI Root CA 2018

Subject Public Key Information 2048 bit modulus, rsaEncryption {1 2 840 113549 1 1 1}

Issuer’s Signature per section 6.1.5

Extension Criticality Value

Subject Key Identifier No Octet String

Key Usage Yes keyCertSign, cRLSign

Basic Constraints Yes cA=True; path length constraint absent

10.2 PKIIntermediateCACertificate

Field Value

Version V3 (2)



Issuer Distinguished Name C=US, O=Fortior Solutions, OU=Certificate Authorities, CN=Fortior Solutions PKI Root CA 2018

Validity Period Expressed in UTCTime until 2049

Subject Distinguished Name C=US, O=Fortior Solutions, OU=Certificate Authorities, CN=Fortior Solutions Intermediate CA 2018




Authority Key Identifier No Octet String (same as subject key identifier in Root CA Certificate)

Subject Key Identifier No Octet String (same as in PKCS#10 request from the Signing CA)


Certificate Policies No Applicable policies as per section 7.2.6


of 105

Name Constraints Yes optional, permitted subtrees for DN, RFC 822, and DNS name

Basic Constraints Yes cA=True; pathLength= 0

Authority Information Access No id-ad-caIssuers access method entry contains HTTP URL for .p7c file containing Certificates issued to Issuing CA

CRL Distribution Points No Per section 10

10.3 PKISigningCACertificate

Field Value

Version V3 (2)



Issuer Distinguished Name C=US, O=Fortior Solutions, OU=Certificate Authorities, CN=Fortior Solutions Intermediate CA 20 8Validity Period Expressed in UTCTime until 2049

Subject Distinguished Name C=US, O=Fortior Solutions, Inc., OU=Certificate Authorities, CN=<descriptive name for CA, i.e. “CN=FS TSCP CA 2018C”>




Authority Key Identifier No Octet String (same as subject key identifier in Intermediate CA Certificate)

Subject Key Identifier No Octet String (same as in PKCS#10 request from the Signing CA)


Certificate Policies No Applicable policies as per section 7.2.6

Name Constraints Yes optional, permitted subtrees for DN, RFC 822, and DNS name

Basic Constraints Yes cA=True; pathLength= 0

Authority Information Access No id-ad-caIssuers access method entry contains HTTP URL for .p7c file containing Certificates issued to Issuing CA


10.4 PKIPrincipleCAtoTSCPBridgeCACertificate

Field Value

Version V3 (2)



Issuer Distinguished Name C=US, O=Fortior Solutions, OU=Certificate Authorities, CN=Fortior Solutions Intermediate CA 2018Validity Period Expressed in UTCTime until 2049

Subject Distinguished Name C=US, O=TSCP Inc., OU=CAs, CN=TSCP SHA256 Bridge CA




Authority Key Identifier No Octet String (same as in PCA PKCS#10 request to the Fortiorl )


of 105

Subject Key Identifier No Octet String (same as in PKCS#10 request from the TBCA)


Certificate Policies No Applicable Certificate Policies as per section 7.2.6

Policy Mapping No Applicable policy mappings as described in the MoU

Basic Constraints Yes cA=True; path length constraint absent

Name Constraints Yes optional; excluded subtrees: Name forms as determined by the FSPMA

Authority Information Access No id-ad-caIssuers access method entry containing HTTP URL for.p7c file containing certificates issued to the Fortior Solutions PKI


Inhibit anyPolicy No skipCerts = 0

10.5 SubscriberIdentityCertificate

Field Value

Version V3 (2)



Issuer Distinguished Name Unique X.500 Issuing CA DN as specified in section 7.2.4 of this CP

Validity Period No longer than 3 years from date of issue expressed in UTCTime until 2049

Subject Distinguished Name Unique X.500 subject DN as specified in section 7.2.4 of this CP




Authority Key Identifier No Octet String (same as subject key identifier in Issuing CA Certificate)

Subject Key Identifier No Octet String (same as in PKCS-10 request or calculated by the Issuing CA per RFC 5280 method 1 or other method)

Key Usage Yes digitalSignature

Extended Key Usage No Per section 10.18


Subject Alternative Name No URI (mandatory for FSPIV-I-hardware), otherName:principalName (if id-kp-smartcardLogon is included in EKU), RFC 822 email address of Subscriber if available, other name forms optional

Authority Information Access No 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


10.6 SubscriberSignatureCertificate

Field Value

Version V3 (2)




of 105









Key Usage Yes digitalSignature, nonRepudiation



Subject Alternative Name No Any name types may be present. *** If application (s) using certificates from this certificate profile use this extension, then this extension is required with the values specified below: (Mandatory) RFC822 email address (Optional) URI urn:uuid:<128 bit GUID> (Optional) others



10.7 SubscriberEncryptionCertificate

Field Value

Version V3 (2)







Issuer’s Signature Per section 6.1.5




Key Usage Yes keyEncipherment (required), dataEncipherment (optional)



of 105


Subject Alternative Name No RFC 822 email address (required), URI (optional), others optional



10.8 CardAuthenticationCertificate

Field Value

Version V3 (2)





Subject Distinguished Name C=US, O=Fortior Solutions, OU=CardAuth, OU=<AffiliatedOrg>, serialNumber=<GUID>









Subject Alternative Name No URI (mandatory)



10.9 RoleSignatureCertificate

Field Value

Version V3 (2)







of 105







Extended Key Usage Yes Per section 10.18


Subject Alternative Name No (Mandatory) DN of the person controlling the role signing privatekey (Optional) RFC822 email address (optional) others



10.10 RoleEncryptionCertificate

Field Value

Version V3 (2)











Key Usage Yes keyEncipherment (required), dataEncipherment (optional)



Subject Alternative Name No RFC 822 email address (required), URI (optional), others optional




of 105

10.11 ContentSignerCertificate

Field Value

Version V3 (2)




Validity Period 9 years from date of issue expressed in UTCTime until 2049

Subject Distinguished Name Unique X.500 Subject DN as specified in section 7.2.4 of this CP


Issuer Unique Identifier Not Present

Subject Unique Identifier Not Present








Subject Alternative Name No Optional

Authority Information Access No 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



of 105

10.12 Codesignercertificate

Field Value

Version V3 (2)


Issuer Signature Algorithm sha-1WithRSAEncryption {1 2 840 113549 1 1 5} or sha256 WithRSAEncryption {1 2 840 113549 1 1 11}

Issuer Distinguished Name Unique X.500 CA DN conforming to section 7.2.4 of this CP


Subject Distinguished Name Unique X.500 CA DN conforming to section 7.2.4 of this CP




Authority Key Identifier No Octet String (same as subject key identifier in issuing CA certificate)


Key Usage Yes (Mandatory) digitalSignature (Optional) nonRepudiation

Extended Key Usage Yes per Section 10.18


Subject Alternative Name No DN of the person controlling the code signer private key

Authority Information Access No 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


10.13 DeviceorServerCertificate

Field Value

Version V3 (2)





Subject Distinguished Name Unique X.500 subject DN as specified in section 7.2.4 of this CP cn={ Host URL | Host IP Address | Host Name }


Issuer Unique Identifier Not Present

Subject Unique Identifier Not Present



Authority Key Identifier No Octet String (same as subject key identifier in Issuing CA Certificate )


Key Usage Yes keyEncipherment, digitalSignature


of 105



Subject Alternative Name No always present, one or more Host URL | IP Address | Host Name

Authority Information Access No 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 when provided by Entity CA


10.14 OCSPResponderCertificate

The following is the OCSP Responder Certificate profile which must be used. This profile assumes that the OCSP Responder Certificate is issued by the same CA using the same key as that which is used to sign the Subscriber Certificate. For compatibility, no other trust model may be used.

Field Value

Version V3 (2)




Validity Period No longer than one month from date of issue expressed in UTCTime until 2049

Subject Distinguished Name Unique X.500 OCSP Responder (subject) DN as specified in section 7.2.4 of this CP




Authority Key Identifier No Octet String (same as subject key identifier in Issuing CA Certificate )

Subject Key Identifier No Octet String (same as in PKCS-10 request or calculated by the Issuing CA per RFC5280 method 1 or other method)

Key Usage Yes nonRepudiation, digitalSignature

Extended key usage Yes id-kp-OCSPSigning {1 3 6 1 5 5 7 3 9}

Certificate Policies No Applicable Certificate Policies as per the values listed in the Fortior Solutions PKI CA Certificate.

Subject Alternative Name No HTTP URL for the OCSP Responder

No Check No id-pkix-ocsp-nocheck;{1 3 6 1 5 5 7 48 1 5}

Authority Information Access No id-ad-caIssuers access method entry contains HTTP URL for .p7c file containing Certificates issued to issuing CA

10.15 CRLFormat

10.15.1 Full and Complete CRL Field Value

Version V2 (1)




of 105

thisUpdate expressed in UTCTime until 2049

nextUpdate expressed in UTCTime until 2049 (>= thisUpdate + CRL issuance frequency)

Revoked Certificates list 0 or more 2-tuple of Certificate serial number and revocation date (expressed in UTCTime until 2049)


CRL Extension Criticality Value

CRL Number No monotonically increasing integer (never repeated)

Authority Key Identifier No Octet String (same as in Authority Key Identifier field in Certificates issued by the CA)

CRL Entry Extension Criticality Value

Reason Code No optional, must be included when reason code = key compromise or CA compromise

Hold Instruction No Id-holdinstruction-reject may be present only if reason code is certificateHold

10.15.2 Distribution Point Based Partitioned CRL Partitioned CRLs shall not be used.


of 105

10.16 OCSPRequestFormat

Field Value

Version V1 (0)

Requester Name DN of the requestor (required)

Request List List of Certificates as specified in RFC 2560

Request Extension Value

None None

Request Entry Extension Value

None None

10.17 OCSPResponseFormat

Field Value

Response Status As specified in RFC 2560

Response Type id-pkix-ocsp-basic {1.3.6.1.5.5.7.48.1.1}

Version V1 (0)

Responder ID Octet String (same as subject key identifier in Responder Certificate)

Produced At Generalized Time

List of Responses Each response will contain Certificate id; Certificate status (including revocation time and reason from CRL entry and CRL entry extension, if the Certificate is revoked), thisUpdate (from current CA CRL), nextUpdate (from current CA CRL).

Responder Signature per section 6.1.5

Request List Applicable Certificates issued to the OCSP Responder

Response Extension Criticality Value

Nonce No Value in the nonce field of request (required, if present in request)

Response Entry Extension Value

None None


of 105

10.18ExtendedKeyUsage

Certificate Type Required EKU Optional EKU Prohibited EKU

CA6 None None All

Code Signing id‐kp‐codesigning {1 3 6 1 5 5 7 3 3}

Life‐time Signing {1.3.6.1.4.1.311.10.3.13}7

All Others

Domain Controller id‐kp‐serverAuth {1 3 6 1 5 5 7 3 1};

id‐kp‐clientAuth {1.3.6.1.5.5.7.3.2};

id‐pkinit‐KPKdc {1 3 6 1 5 2 3 5};

smartCardLogon {1.3.6.1.4.1.311.20.2.2}

None All Others

Trusted Role Authentication and Signature Certificate

id‐kp‐clientAuth {1.3.6.1.5.5.7.3.2};

smartCardLogon {1.3.6.1.4.1.311.20.2.2};

id‐pkinit‐KPClientAuth {1 3 6 1 5 2 3 4}8;

id‐kp‐emailProtection {1.3.6.1.5.5.7.3.4}

Any EKU that is consistent with Key Usage

Any EKU that is not consistent with Key

Usage

anyExtendedKeyUsage {2.5.29.37.0}

Trusted Role Encryption Certificate

See Subscriber Group, Role, Encryption Certificate

See Subscriber Group, Role, Encryption Certificate

See Subscriber Group, Role, Encryption

Certificate

OCSP Responder id‐kp‐OCSPSigning {1 3 6 1 5 5 7 3 9}

None All Others

PIV‐I, Card Authentication Certificate

id‐fpki‐PIV‐I‐cardAuth {2.16.840.1.101.3.6.8}

None All Others

PIV‐I Content Signing Certificate

id‐fpki‐pivi‐content‐signing {2.16.840.1.101.3.8.7}

None All Others

6 CA certificate includes self-signed Root, cross certificates, subordinate CA certificates, and self-issued key rollover certificates. 7 It is recommended that this EKU be included so that MSFT platforms will not verify signed code using an expired certificate. 8 The last two only if the private key is in hardware.


of 105


Subscriber, Group, Role, PIV‐I Authentication Certificate

id‐kp‐clientAuth {1.3.6.1.5.5.7.3.2};

smartCardLogon {1.3.6.1.4.1.311.20.2.2};

id‐pkinit‐KPClientAuth {1 3 6 1 5 2 3 4}9



Usage


Subscriber, Group, Role, Encryption Certificate10

id‐kp‐emailProtection

{1.3.6.1.5.5.7.3.4};


None All others

Subscriber, Group, Role, Signature Certificate

id‐kp‐emailProtection {1.3.6.1.5.5.7.3.4};

MSFT Document Signing {1.3.6.1.4.1.311.10.3.12};

Adobe Certified Document Signing

{1.2.840.113583.1.1.5}



Usage


Subscriber, Group, Role Authentication and Signature Certificate (Two Certificate Solution)

id‐kp‐clientAuth {1.3.6.1.5.5.7.3.2};

smartCardLogon {1.3.6.1.4.1.311.20.2.2};

id‐pkinit‐KPClientAuth {1 3 6 1 5 2 3 4}11;

id‐kp‐emailProtection {1.3.6.1.5.5.7.3.4};

MSFT Document Signing {1.3.6.1.4.1.311.10.3.12};

Adobe Certified Document Signing

{1.2.840.113583.1.1.5}



Usage


Time Stamp Authority id‐kp‐timestamping {1 3 6 1 5 5 7 3 8}

None All Others

Device Authentication id‐kp‐serverAuth {1 3 6 1 5 5 7 3 1}

id‐kp‐clientAuth {1.3.6.1.5.5.7.3.2}

None All Others

9 The last two only if the private key is in hardware. 10 This certificate is defined as the one that has only the key encipherment or key agreement bit set and optionally data encipherment bit set. 11 The last two only if the private key is in hardware.


of 105


Device Signing and Encryption

None None All

VPN Client id‐kp‐clientAuth {1.3.6.1.5.5.7.3.2};

iKEIntermediate {1.3.6.1.5.5.8.2.2};

id‐kp‐ipsecIKE {1 3 6 1 5 5 7 3 17}

None All Others

VPN Server id‐kp‐serverAuth {1 3 6 1 5 5 7 3 1};

id‐kp‐clientAuth {1.3.6.1.5.5.7417.3.2};


id‐kp‐ipsecIKE {1 3 6 1 5 5 7 3 17}

None All Others

Web Client id‐kp‐clientAuth {1.3.6.1.5.5.7.3.2}

None All Others

Web Server id‐kp‐serverAuth {1 3 6 1 5 5 7 3 1}

id‐kp‐clientAuth {1.3.6.1.5.5.7.3.2}

None All Others

Workstation id‐kp‐clientAuth {1.3.6.1.5.5.7.3.2};


id‐kp‐ipsecIKE {1 3 6 1 5 5 7 3 17}

None All Others

11BIBLIOGRAPHY

The following documents were used to develop this CP to ensure conformity to the appropriate Standards:

CHARTER Fortior Solutions PMA Charter

CP Fortior Solutions Certificate Policy

FBCA CP Federal Bridge Certificate Policy v2.27, December 2013 http://www.idmanagement.gov/fpkipa/documents/FBCA_CP_RFC 3647.pdf

FIPS 140‐2 Security Requirements for Cryptographic Modules, 1994‐01 http://csrc.nist.gov/cryptval/

FIPS 186‐3 Digital Signature Standard, 2000‐01‐27 http://csrc.nist.gov/publications/fips/fips186‐3/fips_186‐3.pdf


of 105

FIPS 201

Personal Identity Verification (PIV) of Federal Employees and Contractors, March 2006 http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.201‐2.pdf

RFC 3647

Certificate Policy and Certificate Practices Framework, Chokhani, Ford, Sabett, Merrill, and Wu. November 2003. http://www.ietf.org/rfc/rfc3647.txt

RFC 5280

Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, Cooper et. al., May 2008 http://www.ietf.org/rfc/rfc5280.txt

PIV‐I Personal Identity Verification Interoperability For Non‐Federal Issuers, May 2009 http://www.idmanagement.gov/documents/PIV_IO_NonFed_Issuers_May2009.pdf

M‐05‐24

Implementation of HSPD‐12 http://www.whitehouse.gov/sites/default/files/omb/memoranda/fy2005/m05‐24.pdf


of 105

12ACRONYMS

AES Advanced Encryption Standard

ANSI American National Standards Institute

C Country

CA Certification Authority

CHUID Cardholder Unique Identifier

CN Common Name

CP Certificate Policy

CPS Certification Practice Statement

CRL Certificate Revocation List

CSA Certificate Status Authority

DC Domain Component

DN Distinguished Name

DNS Domain Name Service

ECDH Elliptic Curve Diffie Hellman

ECDSA Elliptic Curve Digital Signature Algorithm

EE End Entity

FASC‐N Federal Agency Smart Credential Number

FIPS (US) Federal Information Processing Standard

FIPS PUB (US) Federal Information Processing Standard Publication

GUID Globally Unique Identifier

HR Human Resources

HTTP Hypertext Transfer Protocol

ID Identifier

IETF Internet Engineering Task Force

ISO International Organization for Standardization

KRP Key Recovery Policy

KRPS Key Recovery Practices Statement

LDAP Lightweight Directory Access Protocol

MOU

Memorandum of Understanding (as used in the context of this CP, between an Entity and Fortior Solutions allowing interoperation between the Fortior Solutions PKI CA and the Entity’s PIV‐I CA or Bridge CA). Fortior Solutions will take guidance from the FSPMA, through the FSPMA Chairman, as to the acceptability and suitability of the MOU.

NIST National Institute of Standards and Technology

NTP Network Time Protocol

O Organization

OA Operational Authority

OCSP Online Certificate Status Protocol


of 105

OID Object Identifier

OU Organizational Unit

PCA Principal Certification Authority

PIN Personal Identification Number

PIV Personal Identity Verification

PIV‐I PKCS Personal Identity Verification ‐ Interoperable

Public Key Certificate Standard

PKI Public Key Infrastructure

PKIX Public Key Infrastructure X.509

PMA Policy Management Authority

RA Registration Authority

RFC Request For Comments

RSA Rivest‐Shamir‐Adleman (encryption algorithm)

SCVP Simple Certificate Validation Protocol

SHA‐1 Secure Hash Algorithm, Version 1

SSL Secure Sockets Layer

TBCA Transglobal Secure Collaboration Program Bridge Certification Authority

TDES Triple Data Encryption Standard

TLS Transport Layer Security

TSCP Transglobal Secure Collaboration Program

UPN User Principal Name

UPS Uninterrupted Power Supply

URI Uniform Resource Identifier

URL Uniform Resource Locator

UUID Universally Unique Identifier


of 105

13GLOSSARY

Access Ability to make use of any information system (IS) resource.

Access Control Process of granting access to information system resources only to authorized users, programs, processes, or other systems.

Accreditation Formal declaration by a Designated Approving Authority that an Information System is approved to operate in a particular security mode using a prescribed set of safeguards at an acceptable level of risk.

Activation Data Private data, other than keys, that are required to access cryptographic modules (i.e., unlock private keys for signing or decryption events).

Affiliated Organization

Organizations that authorize affiliation with Subscribers of FS‐PKI‐PIV‐I certificates

Applicant The subscriber is sometimes also called an "applicant" after applying to a certification authority for a certificate, but before the certificate issuance procedure is completed.

Archive Long‐term, physically separate storage.

Audit

Independent review and examination of records and activities to assess the adequacy of system controls, to ensure compliance with established policies and operational procedures, and to recommend necessary changes in controls, policies, or procedures.

Audit Data Chronological record of system activities to enable the reconstruction and examination of the sequence of events and changes in an event.

Authenticate To confirm the identity of an entity when that identity is presented

Authentication Security measure designed to establish the validity of a transmission, message, or originator, or a means of verifying an individual's authorization to receive specific categories of information.

Backup Copy of files and programs made to facilitate recovery if necessary.

Binding Process of associating two related elements of information.

Biometric A physical or behavioral characteristic of a human being.

CA Facility The collection of equipment, personnel, procedures and structures that are used by a Certification Authority to perform certificate issuance and revocation.

Certificate

A digital representation of information which at least (1) identifies the certification authority issuing it, (2) names or identifies its subscriber, (3) contains the subscriber's public key, (4) identifies its operational period, and (5) is digitally signed by the certification authority issuing it. As used in this CP, the term ―Cer ficate’ refers to cer ficates that expressly reference an OID of this CP in the ―Cer ficate Policies’ field of an X.509 v.3 certificate.


of 105

Certificate Management

Authority (CMA) A Certification Authority or a Registration Authority.

Certificate Policy (CP)

A Certificate Policy is a specialized form of administrative policy tuned to electronic transactions performed during certificate management. A Certificate Policy addresses all aspects associated with the generation, production, distribution, accounting, compromise recovery and administration of digital certificates. Indirectly, a certificate policy can also govern the transactions conducted using a communications system protected by a certificate‐based security system. By controlling critical certificate extensions, such policies and associated enforcement technology can support provision of the security services required by particular applications.

Certificate Revocation List (CRL)

A list maintained by a Certification Authority of the certificates which it has issued that is revoked prior to their stated expiration date.

Certificate Status Authority

A trusted entity that provides on‐line verification to a Relying Party of a subject certificate's trustworthiness, and may also provide additional attribute information for the subject certificate.

Certificate‐Related Information

Information, such as a subscriber's postal address, that is not included in a certificate. May be used by a CA managing certificates.

Certification Authority (CA)

An authority trusted by one or more users to issue and manage X.509 Public Key Certificates and CRLs.

Certification Authority Software

Key Management and cryptographic software used to manage certificates issued to subscribers.

Certification Practice Statement

(CPS)

A statement of the practices that a CA employs in issuing, suspending, revoking and renewing certificates and providing access to them, in accordance with specific requirements (i.e., requirements specified in this CP, or requirements specified in a contract for services).

Client (application) A system entity, usually a computer process acting on behalf of a human user that makes use of a service provided by a server.

Common Criteria A set of internationally accepted semantic tools and constructs for describing the security needs of customers and the security attributes of products.

Compromise

Disclosure of information to unauthorized persons, or a violation of the security policy of a system in which unauthorized intentional or unintentional disclosure, modification, destruction, or loss of an object may have occurred.

Computer Security Objects Registry

(CSOR) Computer Security Objects Registry operated by NIST.


of 105

Confidentiality Assurance that information is not disclosed to unauthorized entities or processes.

Cross‐Certificate A certificate used to establish a trust relationship between two Certification Authorities.

Cryptographic Module

The set of hardware, software, firmware, or some combination thereof that implements cryptographic logic or processes, including cryptographic algorithms, and is contained within the cryptographic boundary of the module. [FIPS 140‐2]

Cryptoperiod Time span during which each key setting remains in effect.

Customer Any commercial organization that is a paying Subscriber or Subscriber‘s

Employer of Fortior Solutions’ PKI.

Data Integrity Assurance that the data are unchanged from creation to reception.

Digital Signature

The result of a transformation of a message by means of a cryptographic system using keys such that a Relying Party can determine: (1) whether the transformation was created using the private key that corresponds to the public key in the signer‘s digital certificate; and (2) whether the message has been altered since the transformation was made.

Dual Use Certificate

A certificate that is intended for use with both digital signature and data encryption services.

Duration A field within a certificate which is composed of two subfields; ―date

of issue’ and ―date of next issue’.

E‐commerce The use of network technology (especially the internet) to buy or sell

goods and services.

Employee Any person employed by an Entity as defined above.

Encryption Certificate

A certificate containing a public key that is used to encrypt electronic messages, files, documents, or data transmissions, or to establish or exchange a session key for these same purposes.

End Entity Relying Parties and Subscribers.

Entity An organization with operational control of a CA that will interoperate

with a Fortior Solutions PKI CA.

Entity CA A CA that acts on behalf of an Entity, and is under the operational

control of an Entity

Firewall Gateway that limits access between networks in accordance with local security policy.

Inside threat An entity with authorized access that has the potential to harm an information system through destruction, disclosure, modification of data, and/or denial of service.


of 105

Integrity

Protection against unauthorized modification or destruction of information. A state in which information has remained unaltered from the point it was produced by a source, during transmission, storage, and eventual receipt by the destination.

Intellectual Property Useful artistic, technical, and/or industrial information, knowledge or ideas that convey ownership and control of tangible or virtual usage and/or representation.

Intermediate CA A CA that is subordinate to another CA, and has a CA subordinate to itself.

Key Escrow

A deposit of the private key of a subscriber and other pertinent information pursuant to an escrow agreement or similar contract binding upon the subscriber, the terms of which require one or more agents to hold the subscriber's private key for the benefit of the subscriber, an employer, or other party, upon provisions set forth in the agreement.

Key Exchange The process of exchanging public keys in order to establish secure communications.

Key Generation Material

Random numbers, pseudo‐random numbers, and cryptographic parameters used in generating cryptographic keys.

Key Pair

Two mathematically related keys having the properties that (1) one key can be used to encrypt a message that can only be decrypted using the other key, and (ii) even knowing one key, it is computationally infeasible to discover the other key.

Local Registration Authority (LRA)

A Registration Authority with responsibility for a local community.

Memorandum of Understanding

(MoU)

Understanding reached between the FSPMA and an Entity allowing interoperability between the Entity CA or Bridge CA and the Fortior Solutions PKI CA.

Mission Support Information

Information that is important to the support of deployed and contingency forces.

Mutual Authentication

Occurs when parties at both ends of a communication activity authenticate each other (see authentication).

Naming Authority An organizational entity responsible for assigning distinguished names (DNs) and for assuring that each DN is meaningful and unique within its domain.


of 105

Non‐Repudiation

Assurance that the sender is provided with proof of delivery and that the recipient is provided with proof of the sender's identity so that neither can later deny having processed the data. Technical non‐repudiation refers to the assurance a Relying Party has that if a public key is used to validate a digital signature, that signature had to have been made by the corresponding private signature key. Legal non‐ repudiation refers to how well possession or control of the private signature key can be established.

Object Identifier (OID)

A specialized formatted number that is registered with an internationally recognized standards organization. The unique alphanumeric/numeric identifier registered under the ISO registration standard to reference a specific object or object class.

Out‐of‐Band

Communication between parties utilizing a means or method that differs from the current method of communication (i.e., one party uses U.S. Postal Service mail to communicate with the party where current communication is occurring online).

Outside Threat An unauthorized entity from outside the domain perimeter that has the potential to harm an Information System through destruction, disclosure, modification of data, and/or denial of service.

Physically Isolated Network

A network that is not connected to entities or systems outside a physically controlled space.

PKI Repository See Repository

PKI Sponsor Fills the role of a Subscriber for non‐human system components that

are named as public key certificate subjects, and is responsible for meeting the obligations of Subscribers as defined throughout this CP.

Policy Management

Authority (PMA)

Body established to oversee the creation and update of Certificate Policies, review Certification Practice Statements, review the results of CA audits for policy compliance, evaluate non‐domain policies for acceptance within the domain, and generally oversee and manage the PKI certificate policies.

Principal CA The Principal CA is a CA designated by an Entity to interoperate with

the Fortior Solutions Principal CA. An Entity may designate multiple Principal CAs to interoperate with the Fortior Solutions Principal CA.

Privacy Restricting access to subscriber or Relying Party information in

accordance with Federal law and Entity policy.

Private Key

(1) The key of a signature key pair used to create a digital signature.

(2) The key of an encryption key pair that is used to decrypt confidential information. In both cases, this key must be kept secret.


of 105

Public Key

(1) The key of a signature key pair used to validate a digital signature.

(2) The key of an encryption key pair that is used to encrypt confidential information. In both cases, this key is made publicly available normally in the form of a digital certificate.

Public Key Infrastructure (PKI)

A set of policies, processes, server platforms, software and workstations used for the purpose of administering certificates and public‐private key pairs, including the ability to issue, maintain, and revoke public key certificates.

Fortior Solutions PKI

A term used throughout this CP to generally denote the entire Fortior Solutions PKI including the CA(s), CSA and CMS.

Re‐key (a certificate)

To change the value of a cryptographic key that is being used in a cryptographic system application; this normally entails issuing a new certificate on the new public key.

Registration Authority (RA)

An entity that is responsible for identification and authentication of certificate subjects, but that does not sign or issue certificates (i.e., a Registration Authority is delegated certain tasks on behalf of an authorized CA).

Relying Party A person or Entity who has received information that includes a certificate and a digital signature verifiable with reference to a public key listed in the certificate, and is in a position to rely on them.

Renew (a certificate)

The act or process of extending the validity of the data binding asserted by a public key certificate by issuing a new certificate.

Repository A database containing information and data relating to certificates as specified in this CP; may also be referred to as a directory. In this CP, Repository refers to PKI Repository.

Responsible Individual

A trustworthy person designated by a sponsoring organization to authenticate individual applicants seeking certificates on the basis of their affiliation with the sponsor.

Revoke a Certificate

To prematurely end the operational period of a certificate effective at a specific date and time.

Risk An expectation of loss expressed as the probability that a particular threat will exploit a particular vulnerability with a particular harmful result.

Risk Tolerance The level of risk an entity is willing to assume in order to achieve a potential desired result.

Root CA In a hierarchical PKI, the CA whose public key serves as the most trusted datum (i.e., the beginning of trust paths) for a security domain.


of 105

Server A system entity that provides a service in response to requests from clients.

Signature Certificate

A public key certificate that contains a public key intended for verifying digital signatures rather than encrypting data or performing any other cryptographic functions.

Subordinate CA In a hierarchical PKI, a CA whose certificate signature key is certified by another CA, and whose activities are constrained by that other CA. (See superior CA).

Subject

An entity that (1) is named or identified in a certificate issued to that entity, (2) holds a private key that corresponds to the public key listed in the certificate, and (3) does not itself issue certificates to another party.

Subscriber An entity subscribing with a Certification Authority on behalf of one or more subjects [TS102042].

Superior CA In a hierarchical PKI, a CA who has certified the certificate signature

key of another CA, and who constrains the activities of that CA. (See subordinate CA).

System Equipment Configuration

A comprehensive accounting of all system hardware and software types and settings.

TBCA The PKI Bridge for Transglobal Secure Collaboration Program

Technical non‐ repudiation

The contribution public key mechanisms to the provision of technical evidence supporting a non‐repudiation security service.

Threat Any circumstance or event with the potential to cause harm to an

information system in the form of destruction, disclosure, adverse modification of data, and/or denial of service.

Trust List Collection of trusted certificates used by Relying Parties to

authenticate other certificates.

Trusted Agent

Entity authorized to act as a representative of an Entity in confirming Subscriber identification during the registration process. Trusted Agents do not have automated interfaces with Certification Authorities.

Trusted Certificate

A certificate that is trusted by the Relying Party on the basis of secure and authenticated delivery. The public keys included in trusted certificates are used to start certification paths. Also known as a "trust anchor".

Trusted Timestamp

A digitally signed assertion by a trusted authority that a specific digital object existed at a particular time.

Trustworthy System

Computer hardware, software and procedures that: (1) are reasonably secure from intrusion and misuse; (2) provide a reasonable level of availability, reliability, and correct operation; (3) are reasonably suited to performing their intended functions; and (4) adhere to generally accepted security procedures.


of 105

TSCP A Trust Framework and PKI Bridge primarily supporting the Defense Industrial Base

Two‐Person Control

Continuous surveillance and control of positive control material at all times by a minimum of two authorized individuals, each capable of detecting incorrect and/or unauthorized procedures with respect to the task being performed, and each familiar with established security and safety requirements.

Update (a certificate)

The act or process by which data items bound in an existing public key certificate, especially authorizations granted to the subject, are changed by issuing a new certificate.

Update (in reference to

significant change)

Alterations to Licensed Software, including code and/or error corrections and minor code enhancements or modifications, that may be developed and generally released from time to time by the Software Vendor and made available to the customer (licensee). Software Updates do not include: (i) Software Upgrades of the Licensed Software that may be developed and generally released from time to time by the software vendor

Upgrade (in reference to

significant change)

Enhancements to the Licensed Software providing a new program feature or function that may be developed and generally released from time to time by the software vendor and made available to customer (licensee). Software Upgrades do not include: (i) Software Updates of the Licensed Software that may be developed and generally released from time to time by the software updates

Initialize A method of erasing electronically stored data by altering the contents of the data storage so as to prevent the recovery of the data. [FIPS 140‐2]


of 105

APPENDIXA–PIV‐INTEROPERABLESMARTCARDDEFINITION

The Fortior Solutions PKI enables the issuance of smart cards that are technically interoperable with Federal Personal Identity Verification (PIV) Card readers and applications as well as PIV‐ Interoperable (PIV‐I) card readers and applications. Fortior Solutions PKI fully maps to PIV‐I specification as defined by the U.S. Federal Government. This section defines the specific requirements of a Fortior Solutions PKI Card. It relies heavily on relevant specifications from the National Institute of Standards and Technology (NIST).

1. Smart card platform shall be from the GSA‘s FIPS 201 Evaluation Program Approved Product List (APL) and shall use the PIV application identifier (AID);

2. Smart card issued under FS‐PKI‐PIV‐I policies and all data objects on it shall be in accordance with SP 800‐73 as specified for PIV‐Interoperable;

3. Smart card shall contain the mandatory private key and associated Authentication certificate asserting a FS‐PKI‐PIV‐I‐hw Policy OID mapped to the US Federal PKI Hardware policy OID;

4. Smart card shall contain a private key and associated Card Authentication certificate asserting the FS‐PKI‐PIV‐I‐cardAuth ‐mapped certificate Policy OID;

5. Smart card may contain private key and associated Digital Signature certificate asserting either a FS‐PKI‐PIV‐I‐hw or a FS‐PKI‐mediumhw‐‐mapped certificate Policy OID;

6. Smart card may contain private key and associated Encryption certificate asserting either a FS‐PKI‐PIV‐I‐hw or a FS‐PKI‐mediumhw‐‐mapped certificate Policy OID;

7. The digital signature certificate that is used to sign objects on the PIV‐I Card (e.g., CHUID, Security Object) shall contain a policy OID that has been mapped to the FS‐PKI‐PVI‐I‐contSign policy OID.

8. The Authentication, Signature, Key Management, Card Authentication, and Content Signer Certificates shall conform to the applicable profiles in Section 10.

9. Smart card shall contain an electronic representation (as specified in SP 800‐73 and SP 800‐76) of the Cardholder Facial Image printed on the card;

10. Smart card issued under FS‐PKI‐PIV‐I policies and all data objects on it shall be in accordance with SP 800‐73 as specified for PIV‐I;

11. Biometrics on the smart card shall also comply with section 4.4 of FIPS 201‐1 and SP 800‐76;

12. Cardholder Unique Identifier (CHUID) shall also comply with section 4.2 of FIPS 201‐1. The Federal Agency Smart Credential Number (FASC‐N) shall be modified as define in section 3.3 of SP800‐73‐3. FASC‐N shall be constructed using Agency Code equal to 9999, System Code equal to 9999, and Credential Number equal to 999999. CHUID shall contain a 16 byte Global Unique Identifier (GUID);

13. The CMS‐Signed objects such as fingerprint and photograph shall contain GUID as entry UUID attribute in place of FASC‐N as pivFASC‐N attribute;

14. Smart cards shall be visually distinct from the US Federal PIV Card. At a minimum, images or logos on an FS‐PKI‐PIV‐I Card shall not be placed entirely within Zone 11, Agency Seal, as defined by FIPS 201;

15. The smart card physical topography shall include, at a minimum, the following items on the front of the card:

i. Cardholder facial image;

ii. Cardholder full name;

iii. Organizational Affiliation, if it exists; otherwise the issuer of the card; and


of 105

iv. Card expiration date.

16. Smart card shall have an expiration date not to exceed 6 years of issuance;

17. Smart card expiration shall not be later than the expiration of the FS‐PKI‐PIV‐I Content Signing certificate on the card, which shall conform to the Content Signing certificate profile specified in section 10.8;

18. The FS‐PKI‐PIV‐I Content Signing certificate and corresponding private key shall be managed within a trusted CMS in accordance with the requirements specified in this document;

19. At issuance, the RA shall activate and release the smart card to the Subscriber only after a successful one‐to‐one biometric match of the Applicant against the biometrics collected during initial identity‐proofing (See section 3.2.3);

20. Smart card may support card activation by the CMS to support card personalization and post‐issuance card update. To activate the card for personalization or update, the CMS shall perform a challenge response protocol using cryptographic keys stored on the card in accordance with SP 800‐73. When cards are personalized, card management keys shall be set to be specific to each smart card. That is, each smart card shall contain a unique card management key. Card management keys shall meet the algorithm and key size requirements stated in SP 800‐78.

21. Each year, for each PCI configuration used, one populated, representative sample PIV‐I card shall be submitted to the FIPS 201 evaluation Program for testing.


of 105

APPENDIXB‐CARDMANAGEMENTSYSTEMREQUIREMENTS

PIV‐I Cards are issued and managed through information systems called Card Management Systems (CMSs). The complexity and use of these trusted systems may vary. Nevertheless, Entity CAs have a responsibility to ensure a certain level of security from the CMSs that manage the token on which their certificates reside, and to which they issue certificates for the purpose of signing PIV‐I Cards. This appendix provides additional requirements to those found above that apply to CMSs that are trusted under this Certificate Policy.

The Card Management Master Key shall be maintained in a FIPS 140‐2 Level 2 Cryptographic Module and conform to [NIST SP 800‐78] requirements. Diversification operations shall also occur on the Hardware Security Module (HSM). Use of these keys requires PIV‐I Hardware or commensurate. Activation of the Card Management Master Key shall require strong authentication of Trusted Roles. Card management shall be configured such that only the authorized CMS can manage issued cards.

The PIV‐I identity proofing, registration and issuance process shall adhere to the principle of separation of duties to ensure that no single individual has the capability to issue a PIV‐I credential without the cooperation of another authorized person.

Individual personnel shall be specifically designated to the four Trusted Roles defined in Section 5.2.1. Trusted Role eligibility and Rules for separation of duties follow the requirements for Medium assurance in Section 5.

All personnel who perform duties with respect to the operation of the CMS shall receive comprehensive training. Any significant change to CMS operations shall have a training (awareness) plan, and the execution of such plan shall be documented.

Audit log files shall be generated for all events relating to the security of the CMS and shall be treated the same as those generated by the CA (see Sections 5.4 and 5.5).

A formal configuration management methodology shall be used for installation and ongoing maintenance of the CMS. Any modifications and upgrades to the CMS shall be documented and controlled. There shall be a mechanism for detecting unauthorized modification to the CMS.

The CMS shall have document incident handling procedures that are approved by the head of the organization responsible for operating the CMS. If the CMS is compromised, all certificates issued to the CMS shall be revoked, if applicable. The damage caused by the CMS compromise shall be assessed and all Subscriber certificates that may have been compromised shall be revoked, and Subscribers shall be notified of such revocation. The CMS shall be re‐established.

All Trusted Roles who operate a CMS shall be allowed access only when authenticated using a method commensurate with PIV‐I Hardware.

The computer security functions listed below are required for the CMS:

Authenticate the identity of users before permitting access to the system or applications;

Manage privileges of users to limit users to their assigned roles;

Generate and archive audit records for all transactions; (see Section 5.4)

Enforce domain integrity boundaries for security critical processes; and

Support recovery from key or system failure.

fortior solutions tscp pki credential service certificate ... · tscp pki credential service...

Documents