verizon federal ssp cps v3 · 2018. 9. 7. · verizon ssp . certification practice statement for ....

Verizon SSP Certification Practice Statement for

The U.S. Federal PKI Common Policy Framework

Version 3.1 July 30th, 2018

Prepared by:

Verizon Silver Spring, Maryland

Page i

Verizon SSP

Certification Practice Statement For the U.S. Federal PKI

Common Policy Framework

Table of Contents 1. INTRODUCTION ............................................................................................................................... 1

1.1 OVERVIEW ..................................................................................................................................... 2 1.1.1 Certificate Policy .................................................................................................................. 2 1.1.2 Relationship between CP and the CPS ................................................................................. 2 1.1.3 Scope .................................................................................................................................... 2 1.1.4 Interoperation with CAs Issuing under Different Policies ................................................... 2

1.2 DOCUMENT NAME AND IDENTIFICATION ....................................................................................... 2 1.3 PKI PARTICIPANTS ........................................................................................................................ 3

1.3.1 PKI Authorities .................................................................................................................... 3 1.3.1.1 Federal Chief Information Officers (CIO) Council ......................................................................... 3 1.3.1.2 Federal PKI Policy Authority (FPKIPA) ........................................................................................ 4 1.3.1.3 FPKI Management Authority (MA) ................................................................................................ 4 1.3.1.4 FPKI Management Authority Program Manager ............................................................................ 4 1.3.1.5 Policy Management Authority ........................................................................................................ 4 1.3.1.6 Certification Authority .................................................................................................................... 5 1.3.1.7 Managed Validation Service (MVS) (also known as Certificate Status Servers) ............................ 5

1.3.2 Registration Authorities ....................................................................................................... 5 1.3.3 Trusted Agents ..................................................................................................................... 6 1.3.4 Subscribers ........................................................................................................................... 6 1.3.5 Relying Parties ..................................................................................................................... 6 1.3.6 Other Participants ................................................................................................................. 6

1.3.6.1 Compliance Auditors ...................................................................................................................... 6 1.4 CERTIFICATE USAGE ...................................................................................................................... 7

1.4.1 Appropriate Certificate Uses ................................................................................................ 7 1.4.2 Prohibited Certificate Uses ................................................................................................... 7

1.5 POLICY ADMINISTRATION.............................................................................................................. 8 1.5.1 Organization Administering the Document .......................................................................... 8 1.5.2 Contact Person ..................................................................................................................... 8 1.5.3 Person Determining CPS Suitability for the Common Policy .............................................. 8 1.5.4 CPS Approval Procedures .................................................................................................... 8

1.6 DEFINITIONS AND ACRONYMS ....................................................................................................... 9

2. PUBLICATION AND REPOSITORY RESPONSIBILITIES ........................................................ 9 2.1 REPOSITORIES ................................................................................................................................ 9 2.2 PUBLICATION OF CERTIFICATION INFORMATION ........................................................................... 9

2.2.1 Publication of Certificates and Certificate Status ................................................................. 9 2.2.2 Publication of CA Information ............................................................................................10 2.2.3 Interoperatiblity ...................................................................................................................10

2.3 TIME OR FREQUENCY OF PUBLICATION ........................................................................................10 2.4 ACCESS CONTROLS ON REPOSITORIES ..........................................................................................10

3. IDENTIFICATION AND AUTHENTICATION ............................................................................11 3.1 NAMING ........................................................................................................................................11

Page ii

3.1.1 Types of Names ...................................................................................................................11 3.1.2 Need for Names to be Meaningful ......................................................................................15 3.1.3 Anonymity or Pseudonymity of Subscribers .......................................................................15 3.1.4 Rules for Interpreting Various Name Forms .......................................................................15 3.1.5 Uniqueness of Names ..........................................................................................................16 3.1.6 Recognition, Authentication and Role of Trademarks ........................................................17

3.2 INITIAL IDENTITY VALIDATION ....................................................................................................17 3.2.1 Method to Prove Possession of Private Key ........................................................................17 3.2.2 Authentication of Organization Identity ..............................................................................18 3.2.3 Authentication of Individual Identity ..................................................................................18

3.2.3.1 Authentication of Human Subscribers........................................................................................... 19 3.2.3.2 Authentication of Devices ............................................................................................................. 22 3.2.3.3 Authentication for Derived PIV Credentials ................................................................................. 23

3.2.4 Non-verified Subscriber Information ..................................................................................23 3.2.5 Validation of Authority .......................................................................................................23 3.2.6 Criteria for Interoperation ...................................................................................................24

3.3 IDENTIFICATION AND AUTHENTICATION FOR RE-KEY REQUESTS ................................................24 3.3.1 Identification and Authentication for Routine Re-Key .......................................................24 3.3.2 Identification and Authentication for Re-Key after Revocation ..........................................25

3.4 IDENTIFICATION AND AUTHENTICATION FOR REVOCATION REQUEST ..........................................25

4. CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS .........................................25 4.1 CERTIFICATE APPLICATION ..........................................................................................................25

4.1.1 Who Can Submit a Certificate Application .........................................................................26 4.1.1.1 CA Certificates .............................................................................................................................. 26 4.1.1.2 User Certificates ............................................................................................................................ 26 4.1.1.3 Device Certificates ........................................................................................................................ 26 4.1.1.4 Code Signing Certificates ............................................................................................................. 26

4.1.2 Enrollment Process and Responsibilities .............................................................................26 4.2 CERTIFICATE APPLICATION PROCESSING ......................................................................................27

4.2.1 Performing Identification and Authentication Functions ....................................................27 4.2.2 Approval or Rejection of Certificate Applications ..............................................................28 4.2.3 Time to Process Certificate Applications ............................................................................28

4.3 CERTIFICATE ISSUANCE ................................................................................................................28 4.3.1 CA Actions During Certificate Issuance .............................................................................28 4.3.2 Notification to Subscriber by the CA of Issuance of Certificate .........................................28

4.4 CERTIFICATE ACCEPTANCE ..........................................................................................................29 4.4.1 Conduct Constituting Certificate Acceptance .....................................................................29 4.4.2 Publication of the Certificate by the CA .............................................................................29 4.4.3 Notification of Certificate Issuance by the CA to Other Entities ........................................29

4.5 KEY PAIR AND CERTIFICATE USAGE.............................................................................................29 4.5.1 Subscriber Private Key and Certificate Usage ....................................................................29 4.5.2 Relying Party Public Key and Certificate Usage .................................................................30

4.6 CERTIFICATE RENEWAL ................................................................................................................31 4.6.1 Circumstance for Certificate Renewal.................................................................................31 4.6.2 Who May Request Renewal ................................................................................................31 4.6.3 Processing Certificate Renewal Requests ...........................................................................31 4.6.4 Notification of New Certificate Issuance to Subscriber ......................................................31 4.6.5 Conduct Constituting Acceptance of a Renewal Certificate ...............................................31 4.6.6 Publication of the Renewal Certificate by the CA ..............................................................31 4.6.7 Notification of Certificate Issuance by the CA to Other Entities ........................................31

4.7 CERTIFICATE RE-KEY ...................................................................................................................31 4.7.1 Circumstance for Certificate Re-Key ..................................................................................31 4.7.2 Who May Request Certification of a New Public Key........................................................32 4.7.3 Processing Certificate Re-Keying Requests ........................................................................32 4.7.4 Notification of New Certificate Issuance to Subscriber ......................................................32 4.7.5 Conduct Constituting Acceptance of a Re-Keyed Certificate .............................................32

Page iii

4.7.6 Publication of Re-Keyed Certificate by the CA ..................................................................32 4.7.7 Notification of Certificate Issuance by the CA to Other Entities ........................................32

4.8 CERTIFICATE MODIFICATION ........................................................................................................32 4.8.1 Circumstance for Certificate Modification ..........................................................................33 4.8.2 Who May Request Certificate Modification .......................................................................33 4.8.3 Processing Certificate Modification Requests .....................................................................33 4.8.4 Notification of New Certificate Issuance to Subscriber ......................................................33 4.8.5 Conduct Constituting Acceptance of Modified Certificate .................................................33 4.8.6 Publication of Modified Certificate by the CA ...................................................................34 4.8.7 Notification of Certificate Issuance by the CA to Other Entities ........................................34

4.9 CERTIFICATE REVOCATION AND SUSPENSION ..............................................................................34 4.9.1 Circumstances for Revocation .............................................................................................34 4.9.2 Who Can Request a Revocation ..........................................................................................35 4.9.3 Procedure for Revocation Request ......................................................................................35 4.9.4 Revocation Request Grace Period .......................................................................................35 4.9.5 Time within which CA must Process the Revocation Request ...........................................36 4.9.6 Revocation Checking Requirements for Relying Parties ....................................................36 4.9.7 CRL Issuance Frequency.....................................................................................................36 4.9.8 Maximum Latency for CRLs ..............................................................................................37 4.9.9 Online Revocation/Status Checking Availability ................................................................37 4.9.10 On-line Revocation Checking Requirements ......................................................................38 4.9.11 Other Forms of Revocation Advertisements Available .......................................................38 4.9.12 Special Requirements Related to Key Compromise ............................................................38 4.9.13 Circumstances for Suspension .............................................................................................38 4.9.14 Who Can Request Suspension .............................................................................................38 4.9.15 Procedure for Suspension Request ......................................................................................38 4.9.16 Limits on Suspension Period ...............................................................................................39

4.10 CERTIFICATE STATUS SERVICES ...................................................................................................39 4.10.1 Operational Characteristics .................................................................................................39 4.10.2 Service Availability .............................................................................................................39 4.10.3 Optional Features ................................................................................................................39

4.11 END OF SUBSCRIPTION ..................................................................................................................39 4.12 KEY ESCROW AND RECOVERY ......................................................................................................39

4.12.1 Key Escrow and Recovery Policies and Practices ...............................................................39 4.12.2 Session Key Encapsulation and Recovery Policy and Practices .........................................40

5. FACILITY, MANAGEMENT, AND OPERATIONAL CONTROLS ..........................................40 5.1 PHYSICAL CONTROLS ...................................................................................................................40

5.1.1 Site Location and Construction ...........................................................................................40 5.1.2 Physical Access ...................................................................................................................40

5.1.2.1 Physical Access for CA Equipment .............................................................................................. 40 5.1.2.2 Physical Access for RA Equipment .............................................................................................. 42 5.1.2.3 Physical Access for Certificate Status Servers (CSS) Equipment ................................................. 43

5.1.3 Power and Air Conditioning................................................................................................43 5.1.4 Water Exposures .................................................................................................................43 5.1.5 Fire Prevention and Protection ............................................................................................43 5.1.6 Media Storage .....................................................................................................................44 5.1.7 Waste Disposal ....................................................................................................................44 5.1.8 Offsite Backup ....................................................................................................................44

5.2 PROCEDURAL CONTROLS ..............................................................................................................44 5.2.1 Trusted Roles ......................................................................................................................44 5.2.2 Number of Persons Required per Task ................................................................................45 5.2.3 Identification and Authentication For Each Role ................................................................46 5.2.4 Roles Requiring Separation of Duties .................................................................................46

5.3 PERSONNEL CONTROLS ................................................................................................................46 5.3.1 Qualifications, Experience, and Clearance Requirements ...................................................46

Page iv

5.3.2 Background Check Procedures ...........................................................................................47 5.3.3 Training Requirements ........................................................................................................47 5.3.4 Retraining Frequency and Requirements ............................................................................47 5.3.5 Job Rotation Frequency and Sequence ................................................................................48 5.3.6 Sanctions For Unauthorized Actions ...................................................................................48 5.3.7 Independent Contractor Requirements ................................................................................48 5.3.8 Documentation Supplied to Personnel ................................................................................48

5.4 AUDIT LOGGING PROCEDURES .....................................................................................................48 5.4.1 Types of Events Recorded ...................................................................................................49 5.4.2 Frequency of Processing Data .............................................................................................55 5.4.3 Retention Period for Security Audit Data ...........................................................................55 5.4.4 Protection of Audit Log .......................................................................................................56 5.4.5 Audit Log Backup Procedures ............................................................................................56 5.4.6 Audit Collection System (Internal vs. External) .................................................................56 5.4.7 Notification to Event-Causing Subject ................................................................................56 5.4.8 Vulnerability Assessments ..................................................................................................57

5.5 RECORDS ARCHIVAL ....................................................................................................................57 5.5.1 Types of Events Archived ...................................................................................................57 5.5.2 Retention Period for Archive ..............................................................................................58 5.5.3 Protection of Archive ..........................................................................................................58 5.5.4 Archive Backup Procedures ................................................................................................59 5.5.5 Requirements for Time-Stamping of Records .....................................................................59 5.5.6 Archive Collection System (Internal or External) ...............................................................59 5.5.7 Procedures to Obtain and Verify Archive Information .......................................................59

5.6 KEY CHANGEOVER .......................................................................................................................59 5.7 COMPROMISE AND DISASTER RECOVERY .....................................................................................60

5.7.1 Incident and Compromise Handling Procedures .................................................................60 5.7.2 Computing Resources, Software, and/or Data are Corrupted ..............................................61 5.7.3 CA Private Key Compromise Procedures ...........................................................................61 5.7.4 Business Continuity Capabilities after a Disaster ................................................................62

5.8 CA OR RA TERMINATION .............................................................................................................62

6. TECHNICAL SECURITY CONTROLS .........................................................................................63 6.1 KEY PAIR GENERATION AND INSTALLATION ................................................................................63

6.1.1 Key Pair Generation ............................................................................................................63 6.1.1.1 CA Key Pair Generation ............................................................................................................... 63 6.1.1.2 Subscriber Key Pair Generation .................................................................................................... 64 6.1.1.3 CSS Key Pair Generation .............................................................................................................. 64 6.1.1.4 PIV Content Signing Key Pair Generation .................................................................................... 64

6.1.2 Private Key Delivery to Subscriber .....................................................................................65 6.1.3 Public Key Delivery to Certificate Issuer ............................................................................65 6.1.4 CA Public Key Delivery to Relying Parties ........................................................................65 6.1.5 Key Sizes .............................................................................................................................66 6.1.6 Public Key Parameters Generation and Quality Checking ..................................................67 6.1.7 Key Usage Purposes (as per X.509 v3 Key Usage Field) ...................................................67

6.2 PRIVATE KEY PROTECTION AND CRYPTOGRAPHIC MODULE ENGINEERING CONTROLS ...............68 6.2.1 Cryptographic Module Standards and Controls ..................................................................68 6.2.2 Private Key (n out of m) Multi-person Control ...................................................................69 6.2.3 Private Key Escrow .............................................................................................................70 6.2.4 Private Key Backup .............................................................................................................70

6.2.4.1 Backup of CA Private Signature Key ............................................................................................ 70 6.2.4.2 Backup of Subscriber Private Keys ............................................................................................... 70 6.2.4.3 Backup of Subscriber Private Key Management Key ................................................................... 71 6.2.4.4 Backup of MVS Private Key ......................................................................................................... 71 6.2.4.5 Backup of Device Private Keys .................................................................................................... 71 6.2.4.6 Backup of Common PIV Content Signing Key ............................................................................. 71

6.2.5 Private Key Archival ...........................................................................................................71

Page v

6.2.6 Private Key Entry Into or from a Cryptographic Module ....................................................72 6.2.7 Private Key Storage on Cryptographic Module ..................................................................72 6.2.8 Method of Activating Private Keys .....................................................................................72 6.2.9 Methods of Deactivating Private Keys ................................................................................73 6.2.10 Method of Destroying Private Keys ....................................................................................73 6.2.11 Cryptographic Module Rating .............................................................................................73

6.3 OTHER ASPECTS OF KEY-PAIR MANAGEMENT .............................................................................73 6.3.1 6.3.1 Public Key Archival ...................................................................................................73 6.3.2 Usage Periods for the Public and Private Keys ...................................................................73

6.4 ACTIVATION DATA .......................................................................................................................74 6.4.1 Activation Data Generation and Installation .......................................................................74 6.4.2 Activation Data Protection ..................................................................................................74 6.4.3 Other Aspects of Activation Data........................................................................................74

6.5 COMPUTER SECURITY CONTROLS .................................................................................................75 6.5.1 Specific Computer Security Technical Requirements .........................................................75 6.5.2 Computer Security Rating ...................................................................................................76

6.6 LIFE-CYCLE TECHNICAL CONTROLS .............................................................................................77 6.6.1 System Development Controls ............................................................................................77 6.6.2 Security Management Controls ...........................................................................................77 6.6.3 Life-Cycle Security Ratings ................................................................................................78

6.7 NETWORK SECURITY CONTROLS ..................................................................................................78 6.8 TIME-STAMPING ...........................................................................................................................79

7 CERTIFICATE, CRL AND OCSP PROFILES ..............................................................................79 7.1 CERTIFICATE PROFILE ..................................................................................................................79

7.1.1 Version Numbers.................................................................................................................79 7.1.2 Certificate Extensions .........................................................................................................79 7.1.3 Algorithm Object Identifiers ...............................................................................................79 7.1.4 Name Forms ........................................................................................................................80 7.1.5 Name Constraints ................................................................................................................81 7.1.6 Certificate Policies Extension .............................................................................................81 7.1.7 Usage of Policy Constraints Extension ...............................................................................81 7.1.8 Policy Qualifiers Syntax and Semantics ..............................................................................81 7.1.9 Processing Semantics for the Critical Certificate Policy Extension ....................................81

7.2 CRL PROFILE................................................................................................................................82 7.2.1 Version Numbers.................................................................................................................82 7.2.2 CRL and CRL Entry Extensions .........................................................................................82

7.3 OCSP PROFILE .............................................................................................................................82 7.3.1 Version Number(s) ..............................................................................................................82 7.3.2 OCSP Extensions ................................................................................................................82

8. COMPLIANCE AUDIT AND OTHER ASSESSMENTS ..............................................................82 8.1 FREQUENCY OR CIRCUMSTANCES OF ASSESSMENT ......................................................................82 8.2 IDENTITY/QUALIFICATIONS OF COMPLIANCE AUDITOR ................................................................83 8.3 ASSESSOR’S RELATIONSHIP TO ASSESSED ENTITY .......................................................................83 8.4 TOPICS COVERED BY ASSESSMENT ...............................................................................................83 8.5 ACTIONS TAKEN AS A RESULT OF DEFICIENCY ..............................................................................84 8.6 COMMUNICATION OF RESULTS .....................................................................................................84

9. OTHER BUSINESS AND LEGAL MATTERS ..............................................................................84 9.1 FEES .............................................................................................................................................84

9.1.1 Certificate Issuance or Renewal Fees ..................................................................................84 9.1.2 Certificate Access Fees .......................................................................................................85 9.1.3 Revocation or Status Information Access Fees ...................................................................85 9.1.4 Fees for Other Services .......................................................................................................85 9.1.5 Refund Policy ......................................................................................................................85

Page vi

9.2 FINANCIAL RESPONSIBILITY .........................................................................................................85 9.2.1 Insurance Coverage .............................................................................................................85 9.2.2 Other Assets ........................................................................................................................85 9.2.3 Insurance or Warranty Coverage for End-Entities ..............................................................85

9.3 CONFIDENTIALITY OF BUSINESS INFORMATION ............................................................................85 9.3.1 Scope of Confidential Information ......................................................................................86 9.3.2 Information not within the Scope of Confidential Information ...........................................86 9.3.3 Responsibility to Protect Confidential Information .............................................................86

9.4 PRIVACY OF PERSONAL INFORMATION .........................................................................................86 9.4.1 Privacy Plan ........................................................................................................................86 9.4.2 Information Treated as Private ............................................................................................86 9.4.3 Information not Deemed Private .........................................................................................87 9.4.4 Responsibility to Protect Private Information .....................................................................88 9.4.5 Notice and Consent to Use Private Information ..................................................................88 9.4.6 Disclosure Pursuant to Judicial or Administrative Process .................................................88 9.4.7 Other Information Disclosure Circumstances .....................................................................88

9.4.7.1 Release as Part of Civil Discovery ................................................................................................ 88 9.4.7.2 Disclosure upon Owner’s Request ................................................................................................ 88 9.4.7.3 Disclosure of Certificate Revocation Information ......................................................................... 88

9.5 INTELLECTUAL PROPERTY RIGHTS ...............................................................................................89 9.6 REPRESENTATIONS AND WARRANTIES .........................................................................................89

9.6.1 CA Representations and Warranties ....................................................................................89 9.6.2 RA Representations and Warranties ....................................................................................90 9.6.3 Subscriber Obligations ........................................................................................................90 9.6.4 Relying Party Obligations ...................................................................................................91 9.6.5 Representations and Warranties of Other Participants ........................................................91

9.7 DISCLAIMERS OF WARRANTIES ....................................................................................................91 9.8 LIMITATIONS ON LIABILITY ..........................................................................................................91

9.8.1 Verizon Liability .................................................................................................................91 9.8.1.1 Warranties and Limitations on Warranties .................................................................................... 92 9.8.1.2 Damages Covered and Disclaimers ............................................................................................... 92 9.8.1.3 Excluded liability .......................................................................................................................... 92 9.8.1.4 Loss Limitations ............................................................................................................................ 92 9.8.1.5 Other Exclusions ........................................................................................................................... 92

9.9 INDEMNITIES .................................................................................................................................92 9.9.1 Indemnification by Relying Parties .....................................................................................92

9.10 TERM AND TERMINATION .............................................................................................................92 9.10.1 Term ....................................................................................................................................92 9.10.2 Termination .........................................................................................................................93 9.10.3 Effect of the Termination and Survival ...............................................................................93

9.11 INDIVIDUAL NOTICES AND COMMUNICATIONS WITH PARTICIPANTS ............................................93 9.12 AMENDMENTS ..............................................................................................................................93

9.12.1 Procedure for Amendment ..................................................................................................93 9.12.2 Notification Mechanism and Period ....................................................................................93 9.12.3 Circumstances under which OID must be Changed ............................................................94

9.13 DISPUTE RESOLUTION PROCEDURES .............................................................................................94 9.14 GOVERNING LAW .........................................................................................................................94 9.15 COMPLIANCE WITH APPLICABLE LAW ..........................................................................................94 9.16 MISCELLANEOUS PROVISIONS ......................................................................................................94

9.16.1 Entire Agreement ................................................................................................................94 9.16.2 Assignment ..........................................................................................................................95 9.16.3 Severability .........................................................................................................................95 9.16.4 Enforcement (Attorney’s Fees and Waiver of Rights) ........................................................95 9.16.5 Force Majeure .....................................................................................................................95

9.17 OTHER PROVISIONS ......................................................................................................................95 9.17.1 Fiduciary Relationships .......................................................................................................95 9.17.2 Survival ...............................................................................................................................96

Page vii

9.17.3 Merger .................................................................................................................................96 9.17.4 Waiver .................................................................................................................................96

10. BIBLIOGRAPHY ..........................................................................................................................96 11. ACRONYMS AND ABBREVIATIONS ......................................................................................97

12. GLOSSARY ....................................................................................................................................99

APPENDIX A – VERIZON (CERTIFICATE, CRL, AND OCSP PROFILES) .................................106 AGENCY SUBORDINATE SSP CA .......................................................................................................109 PIV AUTHENTICATION CERTIFICATE PROFILE .......................................................................................111 PIV CARD AUTHENTICATION CERTIFICATE PROFILE ............................................................................115 PIV SIGNING CERTIFICATE PROFILE ......................................................................................................117 PIV KEY MANAGEMENT (ENCRYPTION) CERTIFICATE PROFILE ...........................................................119 DEVICE CERTIFICATE PROFILE ..............................................................................................................121 CONTENT SIGNING CERTIFICATE PROFILE ............................................................................................122 SSP OCSP RESPONDER CERTIFICATE ................................................................................................124 SSP CRL FORMAT AS FULL AND COMPLETE CRLS ............................................................................126 PKI ENTITY CERTIFICATE PROFILE E.G. RAO, RRO, AND KRO .........................................................126

Page viii

Document Control

Author(s):Verizon Inc.

Working Group Ownership: Verizon Inc.

Approver(s): Verizon IAM Policy Management Authority

Issue Date: March 17, 2017

Version: 3.0

Security: Verizon Sensitive

Distribution: The information contained in this document is intended for personnel charged with the management and operations of the Verizon SSP CA.

Revision History

Revision Date Revised By Summary of Changes/Comments 1.3 August, 2004 Russ Weiser and Tom

Greco Initial Version of Betrusted SSP CPS. Approved by the Federal PKI Policy Authority

1.3 February, 2005 Tom Greco Revised Section 4.4.3.1 regarding CRL publishing frequency. Change approved by vote of the Federal PKI Policy Authority on March 8, 2005.

1.4 October, 2006 Russ Weiser and Tom Greco

Change Betrusted references to Verizon. Update CPS to include changes to U.S. Federal PKI Common Policy Framework through version 2.4 dated February 2006. Add Appendix A with Certificate Profile information.

1.5 August, 2007 Debb Blanchard, Russel Weiser, and Tom Greco

Updated to RFC3647 format

Made corrections per memo sent by FICC 1.6 October 2008 Germaine Roux Made corrections per auditor comments and

updates from the System Security Plan and Risk Assessment.

Page ix

Revision Date Revised By Summary of Changes/Comments 2.0 September

2015 Mel Holden, Andy Gerhard, Andre Varacka

CP Change 2007-03 - Accommodating legacy PKIs for PIV Authentication – CPS sections: 2.4, 5.7.3, 6.2.1, 6.2.4.4, 6.7

2.0 September 2015

Mel Holden, Andy Gerhard, Andre Varacka

CP Change 2008-01 or 2008-03 - Assessor’s Relationship to Assessed Entity [correct revision #?, title matches but change document lists as 2008-03, not 2008-01] – CPS section 8.3

2.0 September 2015


CP Change 2009-01 - nextUpdate in Certificate Revocation Lists (CRL) published by legacy Federal PKIs – CPS section: 4.9.7

2.0 September 2015


CP Change 2009-02 - Allow the use of the PIV Authentication certificate as proof of identity and employment – CPS section: 3.2.3.1

2.0 September 2015

Mel Holden, Germaine Roux, Andy Gerhard

CP Change 2010-01 - Align key length requirements w/ SP 800-57 – CPS section: 6.1.5

2.0 September 2015


CP Change 2010-02 - Remote administration of Certificate Authorities – CPS sections: 2.1.1, 2.4, 5.1, 5.1.1, 5.1.2.1.5/4/4, 6.5.1, 6.7

2.0 September 2015


CP Change 2010-03 - Allowing inclusion of UUIDs in Card Authentication Certificates – CPS sections: 3.1.1, 10, 11 Added section 10 Bibliography and renumbered the subsequent sections.

2.0 September 2015


CP Change 2010-04 – CPS sections: 8.1, 8.4

2.0 September 2015


CP Change 2010-05 - Clarify the archive definition and how its records are intended to be used – CPS sections: 5.4, 5.5.1

2.0 September 2015


CP Change 2010-06 - Allow Federal Legacy PKIs to directly cross certify with Common Policy CA – CPS sections:

2.0 September 2015


CP Change 2010-07 - Legacy use of SHA-1 during transition period Jan 1, 2011 to Dec 31, 2013 – CPS sections: 1, 1.2, 1.3.1.3, 1.4.1, 6.1.5, 7.1.6, 7.2

2.0 September 2015


CP Change N/A - Clarify requirement to support CA Key Rollover – CPS sections: 3.1.5, 4.7, 5.6 (Tailored the wording in section 5.6 for Verizon)

2.0 September 2015


CP Change 2011-01 - CA to assert policy OIDs in OCSP responder certificates for which the OCSP responder is authoritative – CPS sections: Section 1.3.1.7 didn't exist in the CPS so it was added.

Page x



CP Change 2011-02 - Clarify requirements for device subscribers and certificates – CPS sections: 1, 1.2, 3.1.1, 3.2.3.2, 3.3.1, 4.9.2, 6.1.5, 6.2.1, 6.2.1, 6.2.3, 6.2.4.5, 6.2.8, 7.1.4, 7.1.6, 12 (CPS has no Foreward section so didn't add new text for that section.)

2.0 September 2015


CP Change 2011-03 - Remove requirements for Lightweight Directory Access Protocol (LDAP) references in certificates – CPS sections: 2.1, 2.2.1, 5.1.3, 6.1.4, 6.7, Certificate Profiles

2.0 September 2015


CP Change 2012-01 - Clarify RA audit requirements – CPS sections: 1.3.1.5, 8.0, 8.1, 8.4, 8.5, 8.6 and the Glossary

2.0 September 2015


CP Change 2012-02 - Add new section 4.1.1.4, Code Signing Certificates, to address change proposal requiring organizations receiving a code signing certificate to have access to a Time Stamp Authority – CPS sections: 4.1.1.4

2.0 September 2015


CP Change 2012-03 - Add new language to sections 3.2.3.2 and 9.6.3 to address change proposal to allow a human device sponsor, who is not physically located near the sponsored device, and/or who does not have sufficient administrative privileges on the sponsored device to fulfill these responsibilities, to delegate them to an authorized administrator of the device. – CPS sections: 3.2.3.2, 9.6.3

2.0 September 2015


CP Change 2012-04 - Revise section 4.9.7 to address change proposal to detail and clarify Common Policy CA's CRL issuance policies to ensure Offline Root CA operations are permitted. – CPS sections: 4.9.7

2.0 September 2015


CP Change 2012-05 - Revise sections 1.2, 1.4.1, 3.1.1, 6.2.8, 6.3.2, 7.1.4, 7.1.6, and add new sections 6.1.1.4 and 6.2.4.6 to address change proposal to create a new Common PIV Conent Signing Policy OID. – CPS sections: 1.2, 1.4.1, 3.1.1, 6.1.1.4, 6.2.4.6, 6.2.8, 6.3.2, 7.1.4, 7.1.6

2.0 September 2015


CP Change 2013-01 - Clarify places in the Common Policy which were flagged during the FPKIMA Annual Audit as either contradictory with the FBCA CP or contradictory to current best practices. Clarify division of responsibilities between trusted roles (Section 5.2.1): clarify meaning of "all Securtiy Audit logs"(Section 5.4.1), and allow audit logs to be removed from production site once reviewed (Section 5.4.3). – CPS sections: 5.2.1, 5.4.3

Page xi



CP Change 2013-02 - Remove SHA-1 policies from Common Policy. – CPS sections: 1, 1.2, 1.3.1.3, 1.4.1, 7.1.6, 7.2

2.0 September 2015


CP Change 2013-03 - Require PIV cards to be on the GSA APL prior to issuance and require annual PIV card testing – CPS sections: 6.2.1, 10, 11

2.0 September 2015


CP Change 2015-01 - Create two new Common Derived PIV Authentication Certificate Policy OIDs in the Common Policy, and change/add text in appropriate sections throughout the CP. – CPS sections: 1, 1.2, 1.4.1, 3.1.1, 3.2.3.3, 3.3.1, 4.9.9, 6.1.1.2, 6.1.1.4, 6.1.5, 6.1.7, 6.2.1, 6.2.4.2, 6.2.8, 6.3.2, 7.1.4, 7.1.6, 10, Added worksheet 11 to Appendix A

2.1 October 2015 Andre Varacka General wording and grammar changes throughout the document. Added support for Common Derived credentials in CPS sections: 1.2, 1.4.1, 3.1.1, 3.2.3.3, 3.3.1, 4.5.1, 6.1.1.2, 6.1.7, 6.2.1, 6.2.4.2, 6.2.8, 6.3.2, 7.1.3, 7.1.4, 7.1.6, Appendix A, added the Derived PIV Authentication Certificate Profile table.

2.2 February 2016 Mel Holden 8.2 removed requirement that the Auditor must be associated with a public accounting firm.

2.3 June 20, 2016 Mel Holden Updated section 5.4.1 to replace bulleted list with table that specifies the specific location for each item.

2.4 November 17, 2016

Mel Holden Updated the following sections in response to GSA comments:

1.2, 3.1.1, 3.2.3.2, 3.2.5 4.2.1 5.2.1, 5.2.2, 5.3.2, 5.4.5, 5.5.7, 5.7.1, 5.7.2, 5.7.3, 5.7.4, 5.8 6.1.5, 6.2.4.6, 6.2.9, 6.4.1 7.1.3, 7.1.4 8.6

Page xii

3.0 March 2017 Mel Holden Updated the following sections in response to auditor comments during SSP Audit 2016:

1.0, 1.1.2, 1.1.4 1.2 1.3.1.5, 1.3.1.7, 1.3.4 1.4.1, 1.4.2 1.5.3, 1.5.4 2.1 2.2.1, 2.2.2 2.4 3.1.1, 3.1.2, 3.1.3, 3.1.6 3.2.3, 3.2.5 3.3.1 3.4 4.1.1.1, 4.1.2 4.2.1 4.3.2 4.4.3 4.5.2 4.7.3 4.9, 4.9.5, 4.9.7, 4.9.8, 4.9.9, 4.9.11, 4.9.12 5.1, 5.1.1, 5.1.2.1, 5.1.3, 5.1.4, 5.1.7, 5.1.8 5.2.2, 5.2.4 5.3.2, 5.3.4 5.4.4, 5.4.6 5.5.1, 5.5.2, 5.5.3, 5.5.5 5.6 5.7.1, 5.7.2, 5.7.3, 5.7.4 5.8 6.1.1.1, 6.1.1.2, 6.1.1.3 6.1.2, 6.1.4, 6.1.5, 6.1.7 6.2.1, 6.2.2, 6.2.4.1, 6.2.4.4, 6.2.5, 6.2.6, 6.2.9, 6.2.10 6.3.2 6.4.1, 6.4.2 6.5.1 6.6.1, 6.6.2 6.7 7.1.1.1, 7.1.3, 7.1.4, 7.1.6 7.2, 7.2.1 7.3, 7.3.1 8 8.1 8.2 8.3 8.4 8.5 9.4.1, 9.4.2 9.6, 9.6.1, 9.6.2

Page xiii

Revision Date Revised By Summary of Changes/Comments 9.13

9.13 (continued from previous cell) 3.1 July 2018 Abdul Nur Updated the following sections

1.2. 1.3.1.7 1.4.2 3.2.3.3 4.1.1.2 4.2.1 4.7.2 4.9.9 5.2.3 5.4.1, 5.4.4 5.6 6.1.3 6.2.1, 6.2.4.1, 6.2.4.4, 6.2.4.6, 6.2.6, 6.2.10 6.7 6.8 8.2 8.5

Document Approval – Verizon Policy Management Authority Organization Approver Approval Evidence Security Officer, Audit & Compliance

Abdul Nur

Manager, IAM Advanced Engineering

Dave Desrochers

Manager, Product Russ Weiser

1. INTRODUCTION

The Certification Practice Statement (CPS) establishes the practices for the issuance, acceptance, maintenance, use, reliance upon and revocation of digital certificates issued by Verizon U.S., Inc., (Verizon) under the X.509 Certificate Policy for the U.S. Federal PKI Common Policy Framework (Common Policy). In particular, this CPS and related documents establish the rules governing:

• Verizon acting as the Certification Authority (CA) issuing Certificates under the Common Policy;

• The Subscribers, Registration Authorities, and any other individuals or organizations that participate in the Public Key Infrastructure (PKI) defined by the Common Policy and this CPS and includes provisions relating to the liabilities and obligations of each; and

• The categories of electronic communication specified as being unsuitable applications for Certificates issued in accordance with the Common Policy and this CPS.

This CPS applies to CA activities undertaken by Verizon itself and in relation to Certificates issued by Verizon under this CPS. Verizon operates this PKI in conjunction with and on the behalf of Federal Government Agencies who have contracted for services through the General Services Administration and the Shared Service Provider (SSP) Program. Agency registration activities are conducted pursuant to the terms of a Registration Practice Statement (RPS) and underlying agreement with Verizon. Verizon takes no responsibility for the Registration Authority (RA) activities of any such Agency, and will not be liable for the consequences of the Agency’s actions or omissions. Verizon makes its CPS, related RPSs and Key Recovery Practice Statement (KRPS) available to relying parties so that users have sufficient information to make their own evaluations before applying for or using any Certificate issued under this CPS. It is the responsibility of all parties applying for or using a Certificate issued under this CPS in any capacity to read this CPS and any other documents and contracts. It is the responsibility of all parties under this CPS to understand the practices established for the lifecycle management of Certificates issued by Verizon before entering into any such transaction. Any application for or use of a Certificate signifies understanding and acceptance of this CPS and related policy documents. In particular all parties are hereby given notice that Verizon does not undertake any identification or authentication of end-entities. The end-entity identification and authentication function will be performed by the RA acting for, and on behalf of, a Contracting Federal Agency. The RA is solely responsible for all aspects of that process. The RA may establish additional requirements to those established in this CPS. Such requirements shall be specified in a separate RPS and shall be made available by the Federal Contracting Agency on request to any Subscriber or Relying Party. Any applicable RPS shall be incorporated by reference in this CPS as if fully set forth in this CPS. All references to this CPS shall be deemed to include any applicable RPS. Any capitalized words contained in the CPS will be defined in the glossary located in Section 9 of this document. As the CA under this policy Verizon provides the following security management services:

• Key generation/storage.

• Certificate generation, update, renewal, rekey and distribution.

• Certificate revocation list (CRL) generation and distribution.

• Directory management of certificate related items.

• Certificate token initialization/programming/management.

• Encryption key archiving and recovery.

• System management functions (e.g., security audit, configuration management, archive.)

• Issuance and Management of Smart Card based Certificates.

Verizon Identity and Access Management (IAM) CAs which operate under this CPS will not operate under any other CP unless such CP conforms with the same FPKI CP requirements. This CPS is consistent with the Internet Engineering Task Force (IETF) Public Key Infrastructure X.509 (IETF PKIX) request for comments (RFC) 2527, CP and Certification Practice Statement Framework.

1.1 Overview

1.1.1 Certificate Policy

Certificates issued under this policy contain a registered certificate policy object identifier (OID), which may be used by a relying party to decide whether a certificate is trusted for a particular purpose. This CPS applies to CAs owned by or operated on behalf of the Federal government that issue certificates according to this policy.

1.1.2 Relationship between CP and the CPS This CPS is governed by the Common Policy and may have dependent RPS and related documents which describe the Contracting Agency’s RA requirements, encryption key recovery and use of certificates.

Assurance that certificates issued by CAs operating under this CPS comply with the CP is ensured by implementing secure certificate practices defined in the CPS and RPS, policy mappings embedded in the certificates, and independent assessments of the practices.

1.1.3 Scope

This CPS applies to certificates issued to RAs, Key Recovery Agents (KRA), devices, and Federal employees, contractors and other affiliated personnel. This CPS does not apply to certificates issued to groups of people.

1.1.4 Interoperation with CAs Issuing under Different Policies

Verizon IAM CAs operating under this CPS are directly subordinated under the Federal Common Policy Root CA. Interoperation with CAs issued under different policies is achieved through policy mapping and cross-certification of the GSA owned Federal Bridge Certification Authority, and through cross certification directory interoperability between domains.

Note that interoperability may also be achieved through other means, such as trust lists, to meet local requirements.

1.2 Document Name and Identification

This CPS provides assurance concerning identity of certificate subjects. Issuing CAs operating under this CPS assert in the certificate policy extension of all certificate templates used by RAs to issue end entity certificates, at least one of the following OIDs which are associated with the Federal Common Policy Root CA: Table 1: id-fpki-common Policy OIDs

id-fpki-common-policy ::={2 16 840 1 101 3 2 1 3 6} id-fpki-common-hardware ::={2 16 840 1 101 3 2 1 3 7} id-fpki-common-devices ::={2 16 840 1 101 3 2 1 3 8} id-fpki-common-authentication ::={2 16 840 1 101 3 2 1 3 13} id-fpki-common-cardAuth ::={ 2 16 840 1 101 3 2 1 3 17} id-fpki-common-piv-contentSigning ::={ 2 16 840 1 101 3 2 1 3 39} id-fpki-common-derived-pivAuth ::= {2 16 840 1 101 3 2 1 3 40} id-fpki-common-derived-pivAuth-hardware ::= {2 16 840 1 101 3 2 1 3 41}

This CPS covers the issuance of subordinate issuing CA certificates, subscriber end user certificates, and subscriber device certificates.

• Certificates issued by Verizon to Subordinate Issuing CAs will contain any or all of the OIDs listed in Table 1, based on customer specific needs.

• Certificates issued to users, other than devices, to support digitally signed documents or key management may contain either id-fpki-common-policy or id-fpki-common-hardware.

• Subscriber certificates issued to devices under this CPS shall include OID id-fpki-common-devices.

Verizon Federal SSP CPS currently does not support ID-FPKI-COMMON-PUBLIC-TRUSTED-SERVERAUTH CERTIFICATES This CPS also supports 5 policies specific to FIPS 201 Personal Identity Verification (PIV) of Federal Employees and Contractors.

• Verizon CAs operating under this CPS assert id-fpki-common-authentication OID in user certificates supporting authentication but not digital signature, where the corresponding private key is stored on a PIV Card.

• CAs also assert id-fpki-common-cardAuth OID in user certificates where the private key is stored on a PIV Card, which supports authentication and can be used without user authentication.

• CAs also assert OIDs id-fpki-common-derived-pivAuth-hardware or id-fpki-common-derived-pivAuth as appropriate in user certificates issued in accordance with NIST SP 800-157, which support authentication, but not digital signature, and their corresponding private key is not stored on a PIV Card.

CAs only assert the id-fpki-common-piv-contentSigning policy in certificates issued to devices that sign PIV data objects in accordance with [FIPS 201] or [SP 800-157].

1.3 PKI Participants

The following are roles relevant to the administration and operation of CAs under the Common Policy.

1.3.1 PKI Authorities

1.3.1.1 Federal Chief Information Officers (CIO) Council

The Federal CIO Council comprises the Chief Information Officers of all cabinet level departments and other independent agencies. The Federal CIO Council has established the framework for the interoperable Federal PKI (FPKI) and oversees the operation of the organizations responsible for governing and promoting its use. In particular, this CPS operates under the Common Policy, which was established under the authority of and with the approval of the Federal CIO Council. Verizon received Authorization to Operate (ATO) as a Shared Service Provider (SSP) Public Key Infrastructure (PKI) Information System on June 15, 2015. This ATO is valid for three (3) years from that date. The ATO letter can be found on the IAM SharePoint site at the following URL:

https://teamsites.vzbi.com/sites/mss/iam/IAM%20Audit%20%20Compliance/ATO/Signed%20ATO_IAM%206%2015%202015.pdf

1.3.1.2 Federal PKI Policy Authority (FPKIPA)

The Federal PKI Policy Authority (FPKIPA) is a group of U.S. Federal Government Agencies (including cabinet-level Departments) established by the Federal CIO Council. The FPKIPA is responsible for maintaining the Common Policy, approving this CPS, approving Verizon’s compliance audit report for its CA services under the Common Policy, and ensuring Verizon’s continued conformance under the Common Policy with applicable requirements as a condition for allowing continued participation as a SSP.

1.3.1.3 FPKI Management Authority (MA)

The FPKI Management Authority is the organization that operates and maintains the Common Policy Root on behalf of the U.S. Government, subject to the direction of the FPKIPA.

1.3.1.4 FPKI Management Authority Program Manager

The Program Manager is the individual within the FPKIMA who has principal responsibility for overseeing the proper operation of the Common Policy Root CA including the Common Policy Root CA repository, and selecting the FPKIMA staff. The Program Manager is selected by the FPKIMA and reports to the FPKIPA. The FPKIMA Program Manager must hold a Top Secret security clearance.

1.3.1.5 Policy Management Authority

Verizon’s Shared Service Provider (SSP) CPS is maintained by the Identity and Access Management (IAM) Advanced Engineering department. The IAM Advanced Engineering department works in conjunction with the Audit and Compliance team, as well as the Operations teams to insure that Verizon’s SSP PKI components are operated in compliance with the CPS and with Common Policy CP. Agencies that contract for the services of Verizon under the Common Policy and this CPS, shall establish a management body to manage any agency-operated components (e.g., RAs or repositories) and resolve name space collisions. (see Section 3.1.6). This body shall be referred to as an Agency Policy Management Authority, or Agency PMA. Verizon maintains a list of all subscribing Agency PMA contacts on its IAM SharePoint site at: https://teamsites.vzbi.com/sites/mss/iam/Federal%20SSP%20Audits/IAM%20SSP%20Subscribing%20Agency%20PMA%20Contacts.docx An Agency PMA serves as the liaison for that agency to the Verizon SSP PMA and to FPKIPA. The Agency PMA is also responsible for ensuring that all Agency operated PKI components are operated in compliance with this CPS and the Common Policy CP. The agency side PKI components include Registration Authority (RA) functions, Card Management Systems (CMS), and on site validation and OCSP components. PKIs operating under this CPS assume that CAs are always operated under Verizon Identity and Access Managed service. Verizon also offers optional Certificate Status Services which



https://teamsites.vzbi.com/sites/mss/iam/Federal%20SSP%20Audits/IAM%20SSP%20Subscribing%20Agency%20PMA%20Contacts.docx


complement the issuing CAs. Verizon is capable of hosting the Card Management Systems, however the RA roles are always filled by the Agency. A list of active Agency PMAs and the PKI components they use are listed in the client contracts. Verizon also maintains a list of subscribing Agency PMA contacts. The client contacts and Agency PMA contacts are located on the IAM SharePoint site at: https://teamsites.vzbi.com/sites/mss/iam/Federal%20SSP%20Audits/IAM%20SSP%20Subscribing%20Agency%20PMA%20Contacts.docx

1.3.1.6 Certification Authority

The Verizon SSP CAs are made up of a collection of hardware, software and operating personnel that create, sign, and issue public key certificates to subscribers. The Verizon SSP CAs are responsible for the issuance and management of certificates including:

• The certificate manufacturing process;

• Publication of certificates;

• Revocation of certificates;

• Generation and destruction of CA signing keys

• Encryption key archival and recovery services and;

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

1.3.1.7 Managed Validation Service (MVS) (also known as Certificate Status Servers)

Verizon PKI SSP service does include optional Managed Validation Service (MVS). The Online Certificate Status Protocol (OCSP) based Certificate Status Service (CSS) is part of Verizon’s MVS .The CSS provides status information about certificates on behalf of a CA through on-line OCSP transactions. Verizon’s Federal SSP CSS is configured to natively validate any end entity certificate issued by any CA compliant with this CPS and any CA known to the CSS.

Verizon’s CSS includes OCSP authority and OCSP responders. Where the CSS URI is identified in the authority information access (AIA) extension of a certificate issued by a Verizon CA as an authoritative source for revocation information, the operation of that CSS authority is considered within the scope of this CPS. OCSP authority servers that are locally trusted, as described in RFC 6960, are not covered by this CPS.

1.3.2 Registration Authorities

The registration authority (RA) is the entity that collects and verifies each subscriber’s identity and the information that is to be entered into the subscriber’s public key certificate. The RA performs its function in accordance with this CPS and the Agency RPS approved by the FPKIPA and Verizon. The RA is bound by the terms of this CPS and all other relevant contracts and is responsible for:

• Control over the registration process including the activities of any Local Registration Authority (LRA)

• The identification and authentication process



Unless otherwise specified in the Agreement with the Contracting Agency, Verizon will not be acting as an RA.

1.3.3 Trusted Agents

The trusted agent is a person who satisfies all the trustworthiness requirements for an RA and who performs identity proofing as a proxy for the RA. The trusted agent records information from and verifies biometrics (e.g., photographs) on presented credentials for applicants who cannot appear in person at an RA. As a general rule, the Contracting Agency acts as the RA where employees and or contractors perform appropriate registration functions under the guidance of the Agency RA. The parties fulfilling the role of the trusted agent and the methods used to establish their trustworthiness are specified in the Contracting Agency’s RPS.

1.3.4 Subscribers

A subscriber is the entity whose name appears as the subject in a certificate. In general, the subscriber asserts that he or she uses the key and certificate in accordance with the certificate policy asserted in the certificate, and does not issue certificates. Under the Common Policy and this CPS, subscribers are limited to Federal employees, contractors and affiliated personnel and devices operated by or on behalf of Federal agencies. Note that the term “subscriber”, as used in this CPS, refers only to those who request certificates for uses other than signing and issuing certificates or certificate status information.

Devices named as certificate subjects will have a human sponsor and will be authenticated as provided for in Section 3.2.3.2.

1.3.5 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 or 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 digitally signed message, to identify the creator of a message, to establish confidential communications with the holder of the certificate or to authenticate the holder to networks and services. 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.

Under the terms of the Common Policy and this CPS, the relying party may be any entity that wishes to validate the binding of a public key to the name of a federal employee, contractor, or other affiliated personnel.

1.3.6 Other Participants The RAs and Trusted Agents operating under the Common Policy and this CPS may require the services of other security, community, and application authorities, such as compliance auditors and attribute authorities. The parties responsible for providing such services and the mechanisms used to support these services are identified in the following sections.

1.3.6.1 Compliance Auditors

Verizon utilizes the services of an independent third party compliance auditor to determine its adherence to the requirements of the Common Policy and other applicable Federal Government statutes, regulations and standards.

1.3.6.2 Key Recovery Agent

The Key Recovery Agent (KRA) is the entity that facilitates the recovery of a subscriber’s private encryption key. The policy and procedures governing this role are described in Section 4.12.1 and any applicable Verizon or Contracting Agency’s KRPS.

1.3.6.3 Key Recovery Officer

The Key Recovery Officer (KRO) is the entity responsible for verifying the identity and authority of a person requesting the recovery of a private encryption key. The policies and procedures governing this role are described in Section 4.12.1 and any applicable Verizon or Contracting Agency’s KRPS.

1.4 Certificate Usage

1.4.1 Appropriate Certificate Uses

This CPS is intended to support the use of validated public keys to access Federal systems that have not been designated national security systems. While a validated public key is not generally sufficient to grant access, the key may be sufficient when supplemented by appropriate authorization mechanisms. Credentials issued by Verizon under this CPS may also be used for key establishment. The Common Policy is intended to support applications involving unclassified information, which can include sensitive unclassified data protected pursuant to federal statutes and regulations.

Credentials issued under the id-fpki-common-policy and id-fpki-common-derived-pivAuth policies are intended to meet the requirements for Level 3 authentication, as defined by the OMB E-Authentication Guidance. [E-Auth] Credentials issued under the id-fpki-common-hardware, the id-fpki-common-authentication, and id-fpki-common-derived-pivAuth-hardware policy, meet the requirements for Level 4 authentication, as defined by the OMB E-Authentication Guidance. [E-Auth]

Credentials issued under the id-fpki-common-piv-contentSigning policy are intended to meet the requirements in FIPS 201 and SP 800-157 as the digital signatory of the PIV Card Holder Unique IDentifier (CHUID) and associated PIV data objects.

In addition, certificates issued under the Common Policy and this CPS may support signature and confidentiality requirements for Federal government processes.

1.4.2 Prohibited Certificate Uses

Certificates issued under this CPS are not authorized for use in any circumstances or in any application which could lead to death, personal injury or damage to property, or in conjunction with on-line control equipment in hazardous environments requiring fail-safe performance such as in the operation of nuclear facilities, aircraft navigation or communications systems, air traffic

control or direct life support machines, and Verizon shall not be liable for any claims arising from such use.

Certificates that assert id-fpki-common-card Auth shall only be used to authenticate the hardware token containing the associated private key and shall not be interpreted as authenticating the presenter or holder of the token.

Verizon Federal SSP CPS currently does not support id-fpki-common-public-trusted-serverauth certificates

1.5 Policy Administration

1.5.1 Organization Administering the Document

This CPS is administered by the Verizon IAM organization and is based on policies established by Verizon corporate policies and the Federal PKI Common Policy Framework.. The Verizon IAM Policy Management Authority (PMA) is responsible for approval and administration of this CPS.

1.5.2 Contact Person

Questions regarding this CPS shall be directed to:

IAM Support: 1-800-284-4130 US Email: [email protected]. Any formal notices required by this CPS shall be sent in accordance with the notification procedures specified in Section 9.11 of this CPS.

1.5.3 Person Determining CPS Suitability for the Common Policy

The approval of Verizon’s CPS is performed by the FPKIPA under the terms of Section 1.5.4 of the Common Policy (CPS Approval Procedures), and related policies and procedures specified by the FPKIPA.

1.5.4 CPS Approval Procedures Verizon’s CPS is subject to review and approval of the FPKIPA. The FPKIPA will make the determination that this CPS and any revisions comply with the Common Policy. Verizon and the Contracting Agency RAs must meet all requirements of an approved CPS before commencing operations. In some cases, the FPKIPA may require the additional approval of an authorized agency. The FPKIPA will make this determination based on the nature of the system function, the type of communications, or the operating environment. The FPKIPA does not issue waivers.

In each case, the determination of suitability shall be based on an independent compliance auditor’s results and recommendations. See Section 8 for further details.

mailto:[email protected]

1.6 Definitions and Acronyms

See sections 11 and 12.

2. Publication and Repository Responsibilities

2.1 Repositories

As stipulated in Section 2.2, Verizon posts all CA certificates issued by or to a CA and CRLs issued by Verizon SSP CAs in a repository that is publicly accessible through all Uniform Resource Identifier (URI) references asserted in valid certificates issued by Verizon.

All Verizon issued SSP CA certificates contain HTTP based repository references in AIA, SIA, and CDP extensions. All subscriber certificates contain AIA and CDP extensions. All Verizon SSP CA certificates and CRls are available at public domain:

ssp-strong-id.net.

Examples of the URLs are provided in section 2.2.1 of this CPS. Verizon repositories comply with the service requirements found in the Shared Service Provider Repository Service Requirements [SSP-REP] document. Verizon may post subscriber certificates to this repository in accordance with the policies of the Contracting Agency except as noted in Section 9.4.3. Verizon has instituted access controls, including strong authentication of authorized persons, to promote consistent access to certificates and CRL’s and to prevent unauthorized modification or deletion of information.

2.2 Publication of Certification Information

2.2.1 Publication of Certificates and Certificate Status

Verizon’s publicly accessible SSP repository is designed and implemented so as to provide 99% availability overall and limit scheduled down-time to 0.5% annually. Verizon’s CSS is also designed and implemented so as to provide 99% availability overall and limit scheduled down-time to 0.5% annually. Availability of the validation public repositories is monitored 24/7. Outages, if any, are reported in Root Cause Analysis (RCA) reports. RCA reports are published in Verizon IAM SharePoint site at:

HTTPS://TEAMSITES.VZBI.COM/SITES/MSS/IAM/OPERATIONAL%20REPORTS/FORMS/REPORT%20TYPE.ASPX#

https://teamsites.vzbi.com/sites/mss/iam/Operational%20Reports/Forms/Report%20Type.aspx

https://teamsites.vzbi.com/sites/mss/iam/Operational%20Reports/Forms/Report%20Type.aspx

Verizon publishes CA Certificates and CRLs to specific locations encoded in the certificates within the appropriate Certificates extension fields of Authority Information Access (AIA) and CRLs Distribution Point (CDP) in accordance with Section 2.1.

CA URIs examples:

http://aia1.ssp-strong-id.net/CA/SSP-CA-A1.p7c

http://aia1.ssp-strong-id.net/CA/<AGENCY-ACRONYM>-SSP-CA-Bx.p7c

CRL URIs examples:

http://cdp1.ssp-strong-id.net/CDP/SSP-CA-A1.crl http://cdp1.ssp-strong-id.net/CDP/<AGENCY-ACRONYM>-SSP-CA-Bx.crl

2.2.2 Publication of CA Information

The Verizon Federal SSP CPS isl not publicly available. Practice Note: There is no requirement for the publication of the Verizon CPS under the Federal Common Policy.

2.2.3 Interoperatiblity

Where certificates and CRLs are published by Verizon in optional LDAP directories, standards-based schemas for directory objects and attributes shall be used as specified in the Shared Service Provider Repository Service Requirements [SSP-REP]. In particular, Verizon complies with standard LDAP interface, Distinguished Name, objectclass and attribute requirements mentioned in SSP-REP Tables I, II, and IV.

2.3 Time or Frequency of Publication

This CPS and any subsequent changes shall be made publicly available within thirty days of approval. If agency contracts specify publication of subscriber certificates to a repository the subscriber certificates are published by Verizon in the specified directory following subscriber acceptance as specified in Section 4.4 and proof of possession of private key as specified in Section 3.2.1. The CRL is published as specified in Section 4.9.7 and 4.9.12. All information to be published in the repository is published promptly after such information becomes available to Verizon. 2.4 Access Controls on Repositories

Verizon protects information that is not intended for public dissemination or modification through the use of strong authentication, access controls and an overall Information Security Management System that prevents unauthorized access to information.


http://aia1.ssp-strong-id.net/CA/%3cAGENCY-ACRONYM%3e-SSP-CA-Bx.p7c

http://cdp1.ssp-strong-id.net/CDP/SSP-CA-A1.crl

By default, CA certificates and CRLs are stored in public repositories and accessible over the HTTP protocol, or optional LDAP protocol. Verizon does not store private information in public repositories.

If an agency has a need for the CA to publish subscriber public certificates in a repository, Verizon will make those available by default in a public repository.

Optionally, Verizon can store additional information of non-public nature in custom or private repositories. Such information is subject to Verizon’s agreement with the Contracting Agency as well as an Agency’s authorizing and controlling statutes. Private repositories are protected either with SSL encryption, username and password, or a VPN, or a combination of those mechanisms.

3. IDENTIFICATION AND AUTHENTICATION

3.1 Naming

3.1.1 Types of Names

For certificates issued under id-fpki-common-policy, id-fpki-common-hardware, and id-fpki-common-devices, Verizon, or the Contracting Agency operating under its approved RPS, will assign X.501 distinguished names to all Subscribers. These distinguished names may be in either of two forms: a geo-political name; or an Internet domain component name. The formats for the distinquished names are listed below. All geo-political distinguished names assigned to federal employees will be in one of the following directory information trees:

C=US, o=U.S. Government, [ou=department], [ou=agency] , [ou=structural_container]

The organizational units department and agency appear when applicable and are used to specify the federal entity that employs the subscriber. At least one organizational unit will appear in the DN. The additional organizational unit structural_container is permitted to support local directory requirements, such as differentiation between human subscribers and devices. This organizational unit may not be employed to further differentiate between subcomponents within an agency.

The distinguished name of the federal employee subscriber will take one of the following forms: • C=US, o=U.S. Government, [ou=department], [ou=agency], [ou=structural container],

cn=nickname lastname • C=US, o=U.S. Government, [ou=department], [ou=agency], [ou=structural container],

cn=firstname initial. lastname • C=US, o=U.S. Government, [ou=department], [ou=agency], [ou=structural container],

cn=firstname middlename lastname In the first name form, nickname may be the subscriber’s first name, a form of the first name, middle name, or pseudonym (e.g., Buck) by which the subscriber is generally known. A generational qualifier, such as “Sr.” or “III”, may be appended to any of the common name forms specified above.

Distinguished names assigned to federal contractors and other affiliated persons will be within the same directory information tree. The distinguished name of the federal contractor subscribers and affiliate subscribers will take one of the following forms: • C=US, o=U.S. Government, [ou=department], [ou=agency], [ou=structural container],

cn=nickname lastname (affiliate) • C=US, o=U.S. Government, [ou=department], [ou=agency], [ou=structural container],

cn=firstname initial. lastname (affiliate) • C=US, o=U.S. Government, [ou=department], [ou=agency], [ou=structural container],

cn=firstname middlename lastname (affiliate) For names assigned to federal contractors and other affiliated persons, generational qualifiers may be inserted between lastname and “(affiliate)”.

Legacy implementations which predate this policy may use the directory tree: C=US, [o=department], [ou=agency], [ou=structural container]

Common name fields will be populated as specified above. Distinguished names based on Internet domain component names will be in the following directory information trees:

dc=gov, dc=org0, [dc=org1],…[ dc=orgN], [o=structural container],[ou=structural container]

dc=mil, dc=org0, [dc=org1],…[ dc=orgN], [ou=structural container]

The default Internet domain name for the agency, [orgN.]…[org0].gov or [orgN.]…[org0].mil will be used to determine DNs. The first domain component of the DN will either be dc=gov or dc=mil. At a minimum, the org0 domain component will appear in the DN. The org1 to orgN domain components appear, in order, when applicable and are used to specify the federal entity that employs the subscriber. The distinguished name of the federal employee subscriber may take one of the following forms when their agency’s Internet domain name ends in .gov: • dc=gov, dc=org0, [dc=org1], …[dc=orgN], [ou=structural container], cn=nickname lastname • dc=gov, dc=org0, [dc=org1],…[dc=orgN], [ou=structural container], cn=firstname initial.

lastname • dc=gov, dc=org0, [dc=org1],…[dc=orgN], [ou=structural container], cn=firstname middlename

lastname The distinguished name of the federal contractors and affiliated subscribers may take one of the following forms when the agency’s Internet domain name ends in .gov: • dc=gov, dc=org0, [dc=org1],…[dc=orgN], [ou=structural container], cn=nickname lastname

(affiliate) • dc=gov, dc=org0, [dc=org1],…[dc=orgN], [ou=structural container], cn=firstname initial.

lastname (affiliate) • dc=gov, dc=org0, [dc=org1],…[dc=orgN], [ou=structural container], cn=firstname middlename

lastname (affiliate) The distinguished name of the federal employee subscriber may take one of the following forms when their agency’s Internet domain name ends in .mil:

• dc=mil, dc=org0, [dc=org1], …[dc=orgN], [ou=structural container], cn=nickname lastname • dc=mil, dc=org0, [dc=org1],…[dc=orgN], [ou=structural container], cn=firstname initial.

lastname • dc=mil, dc=org0, [dc=org1],…[dc=orgN], [ou=structural container], cn=firstname middlename

lastname The distinguished name of the federal contractors and affiliated subscribers may take one of the following forms when the agency’s Internet domain name ends in .mil: • dc=mil, dc=org0, [dc=org1],…[dc=orgN], [ou=structural container], cn=nickname lastname

(affiliate) • dc=mil, dc=org0, [dc=org1],…[dc=orgN], [ou=structural container], cn=firstname initial.

lastname (affiliate) • dc=mil, dc=org0, [dc=org1],…[dc=orgN], [ou=structural container], cn=firstname middlename

lastname (affiliate) Verizon’s SSP does not support issuance of role based certificates. Verizon anticipates that each certificate distinguished name uniquely identifies a person by name or a unique ID.

Verizon may supplement any of the name forms for users specified in this section by including a dnQualifier, serial number, or user id attribute. If Verizon includes any of these attributes, they may appear as part of a multi-valued relative distinguished name (RDN) with the common name or as a distinct RDN that follows the RDN containing the common name attribute. Generational qualifiers may optionally be included in common name attributes in distinguished names based on Internet domain names. For names assigned to employees, generational qualifiers may be appended to the common name. For names assigned to federal contractors and other affiliated persons, generational qualifiers may be inserted between lastname and “(affiliate)”. Signature certificates issued under id-fpki-common-hardware OID can have a common name that specifies an organizational role such as the head of an agency, as long as that role clearly identifies a single person and includes the agency name. For instance: • C=US, o=U.S. Government, [ou=department], [ou=agency], [ou=structural_container], cn=role [, department/agency] • dc=gov, dc=…, [ou=structural_container], cn=role [, department/agency] As stated in the CP, where the [department/agency] is implicit in the role (e.g., Secretary of Commerce), it should be omitted. Where the role alone is ambiguous (e.g., Chief Information Officer) the department/agency must be present in the common name. The organizational information in the common name must match that in the organizational unit attributes. This CPS currently does not support role based certificate issuance under the id-fpki-common-High OID Verizon may assign devices that are the subject of certificates issued under this CPS either a geo-political name or an Internet domain component name. Device names may take the following forms: • C=US, o=U.S. Government, [ou=department], [ou=agency], [ou=structural container],

cn=device name • dc=gov, dc=org0, [dc=org1], …[dc=orgN], [ou=structural container], [cn=device name] • dc=mil, dc=org0, [dc=org1], …[dc=orgN], [ou=structural container], [cn=device name] where device name is a descriptive name for the device. Where a device is fully described by the Internet domain name, the common name attribute is optional.

Verizon CAs that issue certificates under this CPS must have distinguished names. Verizon CA and MVS distinguished names may be either a geo-political name or an Internet domain component name. Authorized CA DN structures are further discussed in section 3.1.5.

CA and CSS geo-political and internet domain distinguished names are further discussed in section 3.1.5. The structure of all subscriber certificates’ DN is enforced in a certificate template. Certificate templates are constructed during the initial bootstrap of the SSP CAs, the templates disallow any certificate DN changes aside from subscriber’s Common Name, Serial number, or email address. Certificates templates are discussed in the Appendices of the CPS. Certificates issued under id-fpki-common-derived-pivAuth-hardware and id-fpki-common-derived-pivAuth shall include a non-empty subject DN and shall also include a subject alternative name extension that includes a UUID, which shall be encoded as a URI as specified in Section 3 of [RFC 4122]. A unique UUID shall be created for each certificate issued under one of these policies. For certificates issued under this CPS, subject distinguished names shall follow either the rules specified above for id-fpki-common-hardware or the rules specified below for including a non-NULL subject DN with a UUID in id-fpki-common-cardAuth. For certificates issued under id-fpki-common-authentication, assignment of X.500 distinguished names is mandatory. For certificates issued under this policy, distinguished names shall follow the rules specified above for id-fpki-common-hardware. Certificates issued under id-fpki-common-authentication shall include a subject alternative name. At a minimum, the subject alternative name extension shall include the pivFASC-N name type [FIPS 201-1]. The value for this name shall be the FASC-N [PACS] of the subject’s PIV card. Certificates issued under id-fpki-common-cardAuth shall include a subject alternative name extension that includes the pivFASC-N name type. The value for this name shall be the FASC-N of the subject’s PIV card. Certificates issued under id-fpki-common-cardAuth may also include a UUID [RFC 4122] in the subject alternative name extension, if the UUID is included as specified in Section 3.3 of [SP 800-73-3(1)]. Certificates issued under id-fpki-common-cardAuth shall not include any other name in the subject alternative name extension but may include a non-NULL name in the subject field. If included, the subject distinguished name shall take one of the following forms:

• C=US, o=U.S. Government, [ou=department], [ou=agency], [ou=structural container], serialNumber=FASC-N

• dc=gov, dc=org0, [dc=org1], …, [dc=orgN], [ou=structural container], serialNumber=FASC-N

• dc=mil, dc=org0, [dc=org1], …, [dc=orgN], [ou=structural container], serialNumber=FASC-N

• C=US, o=U.S. Government, [ou=department], [ou=agency], [ou=structural_container], serialNumber=UUID

• - dc=gov, dc=org0, [dc=org1], …, [dc=orgN], [ou=structural_container], serialNumber=UUID

• - dc=mil, dc=org0, [dc=org1], …, [dc=orgN], [ou=structural_container], serialNumber=UUID

The Common PIV Content Signing certificate’s subject DN shall indicate the organization administering the PIV card issuance system or device according to types of names for devices.

3.1.2 Need for Names to be Meaningful

The subscriber certificates issued pursuant to this CPS are meaningful only if the names that appear in the certificates can be understood and used by relying parties. Names used in the certificates will identify in a meaningful way the subscriber to which they are assigned.

The common name in the DN will represent the subscriber in a way that is easily understandable for humans. When the Subscriber is a person, this will typically be a legal name, so the preferred common name form to be utilized by Verizon is

CN=firstname initial lastname

While the issuer name in CA certificates is not generally interpreted by relying parties, this CPS requires use of meaningful names by CAs issuing under this CPS. Where Verizon is the CA, the common name will describe the issuer, such as:

CN=Cybertrust SSP CA A11.

In the event that a Contracting Agency intends to set up a CA under this CPS, Verizon will implement the naming convention requested by the Agency so long as it is consistent with the requirements of the Common Policy.

The subject name in CA certificates will match the issuer name in certificates issued by the subject, as required by RFC 5280.

3.1.3 Anonymity or Pseudonymity of Subscribers

While the certificate template defined at the CA ensures specific DN structure, Agency RAs who approve the certificate requests ensure that each request has a legitimate Common Name, or serial number defined. Each CA certificate name, operated by Verizon SSP program, is reviewed by the SSP PMA and/or by GSA representative prior to the issuance of such CA for its conformance with the CP/CPS. CA certificate with anonymous or pseudonyms identities are rejected by the PMA/GSA.

3.1.4 Rules for Interpreting Various Name Forms

Rules for interpreting distinguished name forms are specified in X.501. Rules for interpreting e-mail addresses are specified in [RFC 2822]. Rules for interpreting the pivFASC-N name type are specified in [PACS].

The Contracting Agency (and its appointed Registration Authority) is responsible for interpreting and approving distinguished names. The Applicant/Subscriber is responsible for presenting a distinguished name for approval on the Certificate application.

1 This is an example. The actual name of the CA may be identified by the Organization’s previous legal name (e.g., Betrusted) that will be revised when the CA certificate is reissued at a later date.

3.1.5 Uniqueness of Names

Name uniqueness for Certificates issued by Verizon will be enforced. Verizon and its associated Agency RAs will enforce name uniqueness within the X.500 name space. The X.500 distinguished name shall be considered the "name" by which the Subscriber is identified. The distinguished name will be unique within the Directory in which it is located. If other name forms are used, they will be allocated in a manner that ensures name uniqueness for certificates issued by Verizon. Unique device certificate names will be enforced through the use of fully qualified domain names or IP address. Name uniqueness is not violated when multiple certificates are issued to the same entity. Verizon’s directory information trees for the assignment of subject names are as follows:

Base tree for Verizon SSP CAs:

C=US, O=Verizon, OU=SSP, CN=<CA name> Legacy base tree for Verizon SSP CA:

C=US, O=Betrusted US Inc, OU=SSP, OU=<CA name>, CN=<CA name> The common name of the Verizon SSP CA is further discussed in section 3.1.2. Optional Base tree for Agency Specific Issuing CAs:

C=US, O=Verizon, OU=Services, OU=PKI, CN=<CA name>

or

C=US, O=U.S. Government, OU= <Department Acronym>, OU=<structural component>,CN=<CA Name>

or

DC=gov, DC=<department acronym>, c=US, O=U.S. Government, OU=<department name>, CN=<CA name>

or

dc=gov, dc=<department acronym>, ou=Services, ou=PKI, cn=<CA name>

or

dc=gov, dc=<department acronym>, dc=ssp, ou=Services, ou=PKI, cn=<CA name>

The common name of the Agency Issuing CA consists of CN= <Department Acronym>-SSP-CA-Bx, and the “x” refers to the number of the CAs generated within the Verizon SSP Hierarchy. Legacy CA common names can consist of an agency acronym and purpose of the CA.

Base tree for end entity Certificates:

C=US, O=U.S. Government, ou=<department name>, <ou=optional agency>, <ou=structural container>,

or

DC=gov, DC= <department acronyms>,DC=<optional component>,<ou=optional

structural container>, <ou=optional structural container>, In the event Verizon establishes a PKI where multiple CAs share a single directory information tree, Verizon will submit its procedures for name space control to the FPKIPA for review and approval.

Practice Note: For distinguished names, name uniqueness is enforced for the entire name rather than any particular attribute value (e.g., the common name).

3.1.6 Recognition, Authentication and Role of Trademarks

Verizon operating under the Federal Common Policy shall not knowingly issue a certificate that infringes on the trademark of another. The FPKIPA shall resolve disputes involving names and trademarks.

The Contracting Agency PMAs will resolve name collisions within the Agency’s own name space. Verizon neither acts as an arbitrator nor provides dispute resolution between Subscribers and third party complainants in respect to disputes in relation to the registration or use of a Subject name in a Certificate. This CPS does not bestow any procedural or substantive rights on any third party complainant in respect to the Subject name in a Certificate. Verizon shall in no way be precluded from seeking legal or equitable relief (including injunctive relief) in respect to any dispute between a Subscriber and third party complainant or in respect to any dispute between a Subscriber and Verizon arising out of the Subject name in a Certificate. Verizon shall have the right to revoke a Certificate upon receipt of a properly authenticated order from the FPKIPA, the Contracting Agency RA, an arbitrator or court of competent jurisdiction requiring the revocation of the Certificate or Certificates containing a Subject name in dispute.

3.2 Initial Identity Validation

3.2.1 Method to Prove Possession of Private Key

Verizon, the Contracting Agency and RAs will deploy and operate a system which ensures that public keys are delivered in a way that binds the applicant’s verified identification to the public key. The certificate requestor will follow the application process specified in the Contracting Agency’s Certificate Request Form. The process includes the use of a Certificate request form that contains a transaction identifier and requires submittal of the transaction identifier during the Certificate retrieval process. For software based Certificates, a signed certificate request pursuant to PKCS#10 and PKCS#7 is generated from the requestor’s browser and sent over an

SSL encrypted session to Verizon at which time a subscriber chosen pass phrase will be used to provide binding back to the original registration and certificate request.

For hardware based certificates, requests are managed from the RA workstation (including the hardware token provisioning system) located at the Contracting Agency. A signed certificate request pursuant to PKCS#10 and PKCS#7 is generated by the RA workstation and sent to the Verizon CA and then returned to the agency RA workstation and injected onto the Subscriber’s smart card which is handed to the Subscriber along with card pin information.

Verizon does not generate signature key pairs for subscribers. Where Certificates are created for encryption purposes Verizon maintains an archive of private keys to be used for data recovery purposes. In all other cases private keys are generated by either the requestor’s browser or through the RA workstation or CMS directly on the hardware token. Key management keys generated by Verizon in support of Archival services are securely generated on a FIPS 140-2 level 2 HSM, signed by the CA and archived. These keys and associated certificate are then supplied to the subscriber, RA or hardware token provisioning system as a password protected PKCS #12.

The Subscriber’s private key is generated within the boundary of a cryptographic module, as described in Section 6.1.1.2. Where the owner of the cryptographic token generates the key, there is no need for Verizon to deliver the private key. Verizon, the Contracting Agency or the RA will maintain accountability for the location and state of the cryptographic token until the Subscriber accepts possession of the token and will only generate private keys on hardware tokens in the presence of the Subscriber. In no event will Verizon or anyone else who generates a private signing key for the Subscriber retain any copy of the key. Cryptographic tokens containing CA private signature keys will be backed up in accordance with security audit requirements defined Section 8.

End Entities generate their digital signature key pair at the registrant’s location or in the presence of the RA or under the control of the agency CMS. The key generation will be performed in a FIPS 140-1 level 1 (or higher) compliant module. The certification and initialization process will be handled in accordance with PKCS #10, RFC 2511 "Internet X.509 Certificate Request Message Format” and PKCS #7, RFC 2510 "Internet X.509 Public Key Infrastructure Certificate Management Protocols." Verizon verifies the Certificate Applicant’s possession of a private key through the use of a digitally signed certificate request pursuant to PKCS #10. Verizon will not issue Certificates under this CPS that contain a public key whose associated private key is intended to be shared. The Agreements with both the RA and Subscribers contain clauses specifically prohibiting the sharing of private keys.

3.2.2 Authentication of Organization Identity

When Verizon requests a CA certificate, it will include in the request the CA name, address, and documentation of the existence of the CA. The issuing CA will be expected to verify the information, the authenticity of the requesting representative, and the representative’s authorization to act in the name of Verizon. Additionally, if Verizon is the issuing CA, Verizon personnel will verify the information, the authenticity of the requesting representative and the representative’s authorization to act in the name of the requesting CA.

3.2.3 Authentication of Individual Identity

This CPS allows a certificate to be issued only to a single entity. Verizon does not allow the issuance of certificates that contain a public key in which the associated private key is shared. Each human subscriber certificate private key is assigned to a specific person who owns it and is instructed by the RA not to share it. Each TLS or a device certificate has a human sponsor who ensures that multiple devices don’t share the same private key.

3.2.3.1 Authentication of Human Subscribers

Verizon does not perform any authentication of an Applicant for Certificates other than the initial Agency RA Officer. Verizon will perform initial vetting of a Contracting Agency RA through an in-person proofing process that follows the requirements of this Section 3.2.3.1 and includes a review of the identity credentials presented by the RA, employment verification, and verification of the RA’s authorization to act on behalf of the agency. In the event that Verizon is issuing an SSP Certificate to the RA, Verizon will also ensure that the RA’s manager has authorized the RA to receive the SSP certificate. The Contracting Agency (acting through its appointed RA) will authenticate the identity of any Applicant using authentication techniques appropriate to the intended use of the certificate. It is expected that such processes will be specified in detail in the Agency’s RPS. Verizon plays no part in the identification and authentication of the Applicant or Subscriber, which function is solely performed by the Contracting Agency (acting through its appointed RA), and, therefore, neither warrants nor represents to any party that this information is correct or complete. Procedures used by Agencies to issue identification to their own personnel, affiliates and devices may be more stringent than those set forth below. When this is the case, the agency procedures for authentication of personnel shall apply in addition to the terms contained in this section.

The RA will ensure that the Applicant’s identity information is verified. Identity will be verified no more than thirty (30) days before initial certificate issuance. RAs may accept notarized authentication of an Applicant’s identity to support identity proofing of remote applicants, assuming agency identity badging requirements are otherwise satisfied. Authentication by a trusted agent does not relieve the RA of its responsibility to perform steps 1), 2), the verification of identifying information (e.g., by checking official records) in step 3), and the maintenance of biometrics in step 4) below. Minimal procedures for RA authentication and notarized authentication of employees and affiliated personnel are described below, but additional policies and procedures may be contained in the agency’s RPS.

At a minimum, the authentication procedures for agency employees will include the following steps:

1) Verification that a request for certificate issuance to the Applicant was submitted by agency management;

2) Verification of the Applicant’s employment through use of official agency records.

3) Establishment of the Applicant’s identity through in-person proofing before the Registration Authority, based on either:

a) Process #1:

i) The Applicant presenting a government-issued form of identification (e.g., an Agency ID badge, a passport, or driver’s license) as proof of identity, and

ii) The RA examining the presented credential for biometric data that can be linked to the Applicant (e.g. a photograph on the credential itself or a securely linked photograph of Applicant), and

iii) The RA verifying the credential presented in step (3) (a) (i) above for currency and legitimacy (e.g., the agency ID is verified as valid). The Agency’s RPS will specify the process the RA uses to make this verification (e.g., by querying a database maintained by the organization that issued the credential or equivalent method).

or

b) Process #2:

i) The Applicant presenting a government-issued form of identification (e.g., an Agency ID badge, a passport, or driver’s license) as proof of identity, and

ii) The RA examining the presented credential for biometric data that can be linked to the Applicant (e.g., a photograph on the credential itself or a photograph of Applicant securely stored and linked to the credential), and

iii) The Applicant presenting current corroborating information (e.g., current credit card bill or recent utility bill) to the RA. The RA verifies the identifying information (e.g., name and address) on the credential presented in step (3) (b) (i) above for currency and legitimacy (e.g., the agency ID is verified as valid). The Agency’s RPS will specify the process used to make this verification but, for example, it may be accomplished by querying a database maintained by the organization that issued the financial instrument or statements provided to the RA by the Applicant as current corroborating information.

4) A biometric of the applicant (e.g., a photograph or fingerprint) will be recorded and maintained by either Verizon, the Contracting Agency or the RA to establish an audit trail for purposes of dispute resolution. Note that handwritten signatures and other behavioral characteristics are not accepted as biometrics for the purposes of this CPS.

When the Contracting Agency and its RA are authenticating the identity of contractors and other affiliated personnel, the authentication procedures will include the following steps:

1) Verification that a request for certificate issuance to the Applicant was submitted by an authorized Sponsoring Agency employee (e.g., contracting officer or contracting officer’s technical representative);

2) Verification of the Sponsoring Agency employee’s identity and employment through one of the following methods:

a) The Sponsoring Agency employee may prove both employment and identity by providing a digitally signed certificate issuance request, verified by a currently valid employee signature certificate issued by the employee’s Sponsoring Agency.

b) The Sponsoring Agency employee may prove both employment and identity by authenticating with a valid employee PIV-authentication certificate issued by the employee’s Sponsoring Agency.

c) The Sponsoring Agency employee’s identity may be established through in-person proofing before the Sponsoring Agency’s RA as in employee authentication above. The

Sponsoring Agency employee’s employment may be validated through use of official agency records.

3) Applicant’s identity shall be established by in-person proofing before the RA, based on either of the following processes:

a) Process #1:

i) The Applicant presents a government-issued form of identification (e.g., an Agency ID badge, a passport, or driver’s license) as proof of identity, and

ii) The RA examines the presented credential for biometric data that can be linked to the Applicant (e.g. a photograph on the credential itself or a securely linked photograph of applicant), and

iii) The credential presented in step (3)(a)(i) above is verified by the RA for currency and legitimacy (e.g., the agency ID is verified as valid). The Agency’s RPS will specify the process the RA uses to make this verification (e.g., by querying a database maintained by the organization that issued the credential or equivalent method).

or

b) Process #2:

i) The Applicant presents a government-issued form of identification (e.g., an Agency ID badge, a passport, or driver’s license) as proof of identity, and

ii) The RA examines the presented credential for biometric data that can be linked to the Applicant (e.g. a photograph on the credential itself or a securely linked photograph of the Applicant), and

iii) The Applicant presents current corroborating information (e.g., current credit card bill or recent utility bill) to the RA. The RA verifies the information (e.g., name and address) on the credential presented in step (3) (b) (i) above for currency and legitimacy (e.g., the Agency ID is verified as valid). The Agency’s RPS will specify the process used to make this verification but, for example, it may be accomplished by querying a database maintained by the organization that issued the financial instrument or statements provided to the RA by the Applicant as current corroborating information.

4) A biometric of the Applicant (e.g., a photograph or fingerprint) will be recorded and maintained by either Verizon, the Contracting Agency or the RA to establish an audit trail for purposes of dispute resolution. Note that handwritten signatures and other behavioral characteristics are not accepted as biometrics for the purposes of this CPS.

The RA will record the process that was followed for issuance of each certificate. The process documentation and authentication requirements include all of the following elements:

• The identity of the person performing the identification;

• A signed declaration by the person performing the identification that he or she verified the identity of the Applicant as required by the CPS using the format set forth at 28 U.S.C. 1746 (declaration under penalty of perjury);

• Unique identifying number(s) from the ID(s) of the applicant, or a facsimile of the ID(s);

• The biometric of the applicant;

• The date and time of the verification; and

• A declaration of identity signed by the applicant using a handwritten signature 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).

FIPS 201 imposes a strict requirement for in-person registration. For the issuance of non-FIPS 201 credentials and for those certificate policies where it is not possible for applicants to appear in person before the RA, a trusted agent will serve as a proxy for the RA. The trusted agent forwards the information collected from the Applicant directly to the RA in a secure manner. The requirement for recording a biometric of the Applicant is satisfied by providing passport-style photographs to the trusted agent. The trusted agent will verify the photographs against the appearance of the applicant and the biometrics on the presented credentials and securely incorporate the biometric as a component in a notarized package. The trusted agent will send this package to the RA via express or postal mail or by private courier. The package will be sealed in a manner that will show evidence of tampering if the container is opened by someone other than the intended recipient. The process employed by the RA to appoint a trusted agent and the methods used to securely transmit an applicant’s information from the trusted agent to the RA will be specified in the Contracting Agency’s RPS.

Where the RA uses a trusted agent as part of the identity proofing process, the RA will continue to perform steps (1), (2), the verification of identifying information (e.g., by checking official records) in step 3), and the maintenance of biometrics in step 4), above.

3.2.3.2 Authentication of Devices When computing and communication devices (routers, firewalls, servers, etc.) and software applications are named as certificate subjects the device will have a human sponsor. The Contracting Agency (acting through its appointed RA) will authenticate the identity of the human sponsor applying for the device Certificate. The sponsor is responsible for providing the RA with the following registration information:

• Equipment identification (e.g., serial number) or service name (e.g., DNS name) or unique software application name

• Equipment or software application public keys • Equipment authorizations and attributes (if such information is to be included in the

certificate) • Contact information to enable the RA to communicate with the sponsor when required

These certificates shall be issued only to authorized devices under RA’s control. 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. The RA will authenticate the identity of the sponsor by:

• Verification of digitally signed messages sent from the sponsor using a certificate issued under this policy; or

• Performing in-person registration of the sponsor, with the identity of the sponsor confirmed in accordance with the requirements of Section 3.2.3.1 and the Contracting Agency’s RPS.

The Contracting Agency’s RPS may include additional requirements including proof that the human sponsor applying for the device certificate is authorized to apply for a device certificate for that particular device. The Contracting Agency, acting through its appointed Registration Authority, is responsible for identification and authentication of the System Administrator. The contracting agency will perform audits at least annually to confirm that it is performing these functions in compliance with this CPS and the Federal Common Policy.

3.2.3.3 Authentication for Derived PIV Credentials For certificates issued under id-fpki-common-derived-pivAuth-hardware and id-fpki-common-derived-pivAuth, the Contracting Agency RA shall verify identity of the subscriber in accordance with the requirements specified for issuing derived credentials in [SP 800-157]. The RA or CA shall:

1) Verify that the request for certificate issuance to the applicant was submitted by an authorized agency employee.

2) Use the PKI-AUTH authentication mechanism from Section 6 of FIPS 201 to verify that the PIV Authentication certificate on the applicant’s PIV Card is valid and that the applicant is in possession of the corresponding private key.

3) Maintain a copy of the applicant’s PIV Authentication certificate.

Seven days after issuing the Derived credential, the issuer should recheck the revocation status of the PIV Authentication certificate. This step can detect use of a compromised PIV Card to obtain a derived credential. For certificates issued under id-fpki-common-derived-pivAuth-hardware, the applicant shall appear at the RA in person to present the PIV Card and perform the PKI-AUTH authentication mechanism. The verification is done programmatically within the enrollment portal by verifying the piv credential is in valid and in good standing, also verifying the card holder knows the PIN to activate the card. The RA shall perform a one-to-one comparison of the applicant against biometric data stored on the PIV Card, in accordance with [SP 800-76], and shall record and maintain the biometric sample used to validate the applicant. In cases where a 1:1 biometric match against the biometrics available on the PIV Card or in the chain-of-trust, as defined in [FIPS201] is not possible:

1) The applicant shall present a government-issued form of identification (e.g., a passport or driver’s license) in addition to the PIV Card, and

2) The RA shall examine the presented credentials for biometric data that can be linked to the applicant (e.g., a photograph on the credential itself or a securely linked photograph of the applicant), and

3) The process documentation for the issuance of the certificate shall include the identity of the person performing the verification of the second (non-PIV) form of identification, a signed declaration by that person that he or she verified the identity of the applicant as required by the CPS using the format set forth at 28 U.S.C. 1746 (declaration under penalty of perjury), a unique identifying number from the second form of identification or a facsimile of the ID, a biometric of the applicant, and the date and time of the verification.

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

3.2.5 Validation of Authority

Before issuing CA certificates or signature certificates that assert organizational authority, e.g., code signing certificates and/or FIPS 201 id-PIV-content-signing certificates, Verizon or the Contracting Agency will validate the authority of the individual to act in the name of the organization. Verizon, and this CPS, does not support issuance of pseudonymous certificates at this time. Prior to CA certificate issuance, the OA verifies that the SSP PMA has authorized the CA certificate request. A Contracting Agency authorizes a minimal number of RAs to have access to the content-signing or the code-signing certificate request registration forms.

3.2.6 Criteria for Interoperation The FPKIPA will determine interoperability criteria for CAs operating under the Federal Common Policy.

3.3 Identification and Authentication for Re-Key Requests

3.3.1 Identification and Authentication for Routine Re-Key Certificate holders are required to obtain new key pairs at least once every three years. (The usage periods for CA and Subscriber private keys are described in Section 6.3.2.) During the re-keying process, Verizon will create a new certificate with the same characteristics as the old certificate but with a new and different key pair and serial number. This new certificate may be given a new validity period or use the validity period that appeared in the old certificate.

For all id-fpki policies (other than id-fpki-common-High) where it has been less than nine (9) years since the time the Subscriber was identified by the RA as provided for in Section 3.2 of this CPS and the relevant provisions of the Contracting Agency’s RPS, Verizon will authenticate an electronic request for a new certificate using the currently valid signature certificate issued to the Subscriber. Verizon will: (i) review the RPS of the Contracting Agency to ensure compliance with this CPS; (ii) after approval, Verizon or the Contracting Agency will specify a web interface where the Subscriber will authenticate by utilizing their current signature certificate via Client authentication. Once the Subscriber has been authenticated (their certificate is still valid) a new PKCS #10 will be submitted to the Verizon CA. Note that the RA of the Contracting Agency must re-establish Subscriber identity through an in-person registration process at least once every nine (9) years from the time of the initial registration. For device certificates, identity may be established through the use of the device’s current signature key or the signature key of the device’s human sponsor, except that identity shall be established through the initial registration process at least once every nine years from the time of initial registration. For re-key of subscriber certificates issued under id-fpki-common-derived-pivAuth and id-fpki-common-derived-pivAuth-hardware, the department or agency shall verify that the Subscriber is eligible to have a PIV Card (i.e., PIV Card is not terminated). In addition, for re-key of subscriber certificates issued under id-fpki-common-derived-pivAuth-hardware, identity shall be established via mutual authentication between the issuer and the cryptographic module containing the current key, if the new key will be stored in the same cryptographic module as the current key. Identity shall be established through the initial registration process if the new key will be stored in a different cryptographic module than the current key. In those situations where it has been longer than nine (9) years from the time that the Subscriber’s identity has been authenticated as provided for in Section 3.2 and the Contracting Agency’s RPS, then the Subscriber certificate re-key will follow the same procedures as the initial certificate issuance process. CA certificate re-key will follow the same procedures as initial certificate issuance.

3.3.2 Identification and Authentication for Re-Key after Revocation In the event of certificate revocation, Verizon and the Contracting Agency will require that the Subscriber go through the initial registration process before a new certificate is issued. That process will follow the requirements specified in Section 3.2 above and the Contracting Agency’s RPS.

3.4 Identification and Authentication for Revocation Request

Verizon will authenticate all certificate revocation requests. Verizon will process electronic revocation requests that have been authenticated by using that certificate’s associated public key regardless of whether or not the associated private key has been compromised. Verizon may process other forms of certificate revocation requests that contain identification information regarding the Certificate to be revoked, the reason for the revocation, time and date of the revocation and the identity of the requestor of the revocation.

The primary method of certificate revocation will be through the Contracting Agency RA and any revocation will be made in accordance with the terms of Section 4.9 and the Contracting Agency’s RPS. The Verizon SSP CA only accepts revocation requests signed by a valid credential issued from that CA. During revocation, the CA verifies that the request is submitted either by the subscriber of the certificate or by a member of an authorized registration authority group. Revocation authentication settings are configured in the certificate template settings.

4. Certificate Life-Cycle Operational Requirements

4.1 Certificate Application

The Contracting Agency, through its RA, will perform the following steps when an Applicant applies for a certificate:

• Establish the applicant’s authorization (by the employing or sponsoring Agency) to obtain a certificate. (per Section 3.2.3)

• Establish and record identity of the applicant (per Section 3.2.3)

• Obtain the applicant’s public key and verify the applicant’s possession of the private key for each certificate required (per Section 3.2.1)

• Transmit to Verizon confirmation that the Applicant has met the authentication requirements, the information which is to appear in the Certificate, and a copy of the Applicant’s Public Key

Verizon will not include information regarding an applicant’s role or authorization in certificates issued under this CPS. The SSP expects that the agency instructs its Registration Authorities not to include role information in the certificate distinguished name. If certificates are issued with a role in the DN, such certs are a subject of revocation. Verizon will perform the following steps when it receives the confirmation and certificate information from the RA:

• Verify that the transmission is from the Contracting Agency (acting through its RA)

• Generate the Certificate relating to that Applicant

• Transmits the Certificate to the Applicant

Verizon and the related PKI Authorities will complete these steps before a certificate is issued.

4.1.1 Who Can Submit a Certificate Application

4.1.1.1 CA Certificates An application for a CA certificate will be submitted by an authorized representative of the applicant CA or under the direction of Contracting Agency. CA certificate applications are reviewed and authorized by the SSP PMA. SSP PMA informs the PA of each approved CA application. Records of CA application are stored at SSP document repository at: https://teamsites.vzbi.com/sites/mss/iam/Federal%20SSP%20Audits/Forms/Federal%20SSP%20Documents%20by%20Type.aspx#

4.1.1.2 User Certificates An application for a user (subscriber) certificate shall be submitted by either the applicant or a Trusted Agent. Only valid and authorized members of the agency domain can be granted privilege to self-enroll software certificates. The proof of such enrollment authorization can be found in the agency’s active directory. All other requests are authorized by RA, the proof of credential issuance via RA can be obtained from the Verizon CA/RA database.

4.1.1.3 Device Certificates

An application for a device certificate will be submitted by the human sponsor of the device.

4.1.1.4 Code Signing Certificates

Not Applicable

4.1.2 Enrollment Process and Responsibilities

Communication between the various PKI Authorities involved in the certificate application and issuance process are authenticated and protected from modification. Verizon SSP enrollment portals currently protect an HTTPS session using TLS 1.1 or TLS 1.2 protocols along with AES 128 and AES 256 cipher suites. All certificate requests have to be digitally signed by a valid RA key. Escrowed keys are encrypted by the CA’s PKI component public key. Where shared secrets are transmitted electronically, these transmissions are conducted over encrypted channels using cryptographic mechanisms that are commensurate with the strength of the public/private key pair being used. Digital certificates used in the communication process have been issued with RSA SHA256 algorithm with 2048 size key. When out-of-band communication is used to protect client-server communication, a dedicated VPN with source IP is established to protect such communication. VPNs can be protected with a combination of username, password, and 2-factor authentication where required. Subscribers are responsible for providing accurate information on their certificate applications.

https://teamsites.vzbi.com/sites/mss/iam/Federal%20SSP%20Audits/Forms/Federal%20SSP%20Documents%20by%20Type.aspx

https://teamsites.vzbi.com/sites/mss/iam/Federal%20SSP%20Audits/Forms/Federal%20SSP%20Documents%20by%20Type.aspx

4.2 Certificate Application Processing

Information in certificate applications must be verified as accurate before certificates are issued. When the Contracting Agency and its RA receive a request for a certificate, the RA will:

• Verify the identity of the requestor;

• Verify the authority of the requestor and the integrity of the information in the certificate request and;

• Submit the certificate request to Verizon.

Verizon will sign a certificate if all certificate requirements have been met, and make the certificate available to the subscriber.

The certificate request may already contain a certificate built by either the RA or the Subscriber. Verizon will not sign the certificate until all verifications and modifications, if any, have been completed to Verizon’s satisfaction.

All authorization and other attribute information received from an Applicant is verified before inclusion in the certificate. The Contracting Agency and its RA are responsible for verifying the data to be included in the Certificate. The Agency’s RPS describes the process used to verify this data. At a minimum the RA will follow the steps described in Section 3.2.3.

4.2.1 Performing Identification and Authentication Functions

The identification and authentication of the subscriber must meet the requirements specified for Subscriber authentication as specified in Sections 3.2 and .3.3 of this CPS. Agency RAs authenticate human subscriber’s identity following the requirements specified in sections 3.2 and 3.3. Agency RAs are also responsible for authenticating identity of the sponsor of a device certificate. Identity of the initial RA certificate holders and CA certificates is authenticated by the SSP PMA and Agency PMA respectively. Each subscriber is authenticated by verifying more than one aspect of subscriber’s identity by the agency’s issuing RA, as described in agency’s RPS. For PIV subscribers, such verification should include validation of the subscriber’s two forms of identification, background check, validity of the sponsorship, and other items specified in 3.2 and 3.3 of this CPS. Trusted-server-auth certs are currently not supported by this CPS The following table summarizes responsibility for the key identification and authentication functions:

Section Validation Component CA RA 3.2.1 Possession of Private Key X 3.2.2 Authentication of Organization identity X

3.2.3.1 Authentication of Human Subscribers X 3.2.3.2 Authentication of Devices X 3.2.3.3 Authentication for Derived PIV Credential X 3.2.4 Non-verified Subscribeer Information X 3.2.5 Validation of Authority X 3.3.1 Identification and Authentication for Routine Re-Key X 3.3.2 Identification and Authentication for Re-key after Revocation X

4.2.2 Approval or Rejection of Certificate Applications

For the Common Policy Root CA, the FPKIPA may approve or reject a certificate application. For this CPS in which Verizon applies for its top level CA, approval or rejection of the CA certificate application is at the discretion of the Common Policy authority. For this CPS where Agency based CA’s are to be subordinated under the Verizon top level CA, approval or rejections is the mutual agreement between Verizon and the contracting agency as well as notification to the FPKIPA. For this CPS in which Verizon is operating as a CA under the Common Policy, approval or rejection of Subscriber certificate applications is at the discretion of the Agency PMA or its designee.

4.2.3 Time to Process Certificate Applications

Certificate applications must be processed and a certificate issued within 30 days of identity verification. The Contracting Agency is responsible for ensuring that certificate applications are processed and a certificate is issued within 30 days of identity verification.

4.3 Certificate Issuance 4.3.1 CA Actions During Certificate Issuance

When the Contracting Agency and its RA receive a request for a certificate, the RA will:

• Verify the identity of the requestor;

• Verify the authority of the requestor and the integrity of the information in the certificate request and;

• Submit the certificate request to Verizon.

Verizon will sign a certificate if all certificate requirements have been met, and make the certificate available to the subscriber.

The certificate request may already contain a certificate built by either the RA or the Subscriber. Verizon will not sign the certificate until all verifications and modifications, if any, have been completed to Verizon’s satisfaction.

All authorizations and other attribute information received from an Applicant is verified before inclusion in the certificate. The Contracting Agency and its RA are responsible for verifying the data to be included in the Certificate. The Agency’s RPS describes the process used to verify this data. At a minimum the RA will follow the steps described in Section 3.2.3.

4.3.2 Notification to Subscriber by the CA of Issuance of Certificate Verizon, operating under the Common Policy and in this CPS, will ensure that the Contracting Agency’s RA will inform the Subscriber (or other certificate subject) of the creation of a certificate and make the certificate available to the Subscriber. For device certificates, the Agency’s RA will inform the human sponsor. The notification and delivery to the subscriber or the device sponsor will be facilitated through the Contracting Agency where practical. Details of this process are covered in the Contracting Agency’s RPS.

4.4 Certificate Acceptance

Prior to a Subscriber being able to use their Certificate, Verizon ensures that the registration process deployed by the Contracting Agency provides the Subscriber with appropriate disclosure and acknowledgement of the Subscriber’s responsibilities as defined in Section 1.3.4 and Section 9.6.3 and notifies the Subscriber of the creation and contents of the Certificate. Per the requirements of Section 4.9.7, Subscribers will also be informed of how to obtain certificate revocation information and the consequences of using dated revocation information. This disclosure and notification process may take place in electronic or paper form and the mechanisms used are dependent upon a variety of factors including how the private key is generated and how the certificate is delivered to the Subscriber.

Details of this process are covered in the Contracting Agency’s RPS and certificate request forms.

4.4.1 Conduct Constituting Certificate Acceptance

For the Common Policy Root CA, failure to object to the certificate or its contents shall constitute acceptance of the certificate. For all other CAs operating under this CPS, no stipulation. 4.4.2 Publication of the Certificate by the CA

Verizon may use several methods to deliver Trusted Certificates to users. These include, but are not limited to:

• Loading certificates from web sites secured with a currently valid certificate of equal or greater assurance level than the certificate being downloaded.

• During Subscriber Certificate issuance Verizon will distribute Trusted Certificates via PKCS #7 certificate chains.

• Delivered by courier or hand delivery to the designated personnel.

At a minimum Verizon will, as indicated in the first bullet above, post the Trusted SSP CA root certificate at a publicly available URL such as:

https://cdp1.ssp-strong-id.net/CA/SSP-CA-A1.p7c

This CPS makes no stipulation regarding publication of subscriber certificates except as noted in section 9.4.3. 4.4.3 Notification of Certificate Issuance by the CA to Other Entities

The Verizon SSP PMA will notify the FPKIPA whenever Verizon issues a CA certificate operating under the Common Policy CP and CPS. 4.5 Key Pair and Certificate Usage 4.5.1 Subscriber Private Key and Certificate Usage

The intended scope of usage for a private key is specified through certificate extensions, including the key usage and extended key usage extensions, in the associated certificates.

https://cdp1.ssp-strong-id.net/CA/SSP-CA-A1.p7c

The use of a specific Verizon certificate is constrained by the key usage extension in the X.509 certificate.

Public keys that are bound to human subscriber certificates will be used only for signing or encrypting, but not both. Subscriber certificates that assert id-fpki-common-authentication, id-fpki-common-derived-pivAuth, Id-fpki-common-derived-pivAuth-hardware, or id-fpki-common-cardAuth shall only assert the digitalSignature bit. Other human subscriber certificates that are to be used for digital signatures will assert the digitalSignature and nonRepudiation bits. Subscriber certificates containing RSA public keys that are to be used for key transport will assert the keyEncipherment bit. Subscriber certificates containing Elliptical Curve public keys that are to be used for key transport will assert keyAgreement bit.

Public keys that are bound into Verizon’s CA certificates will be used only for signing certificates and status information (e.g., CRLs). CA certificates whose subject public key is to be used to verify other certificates will assert the keyCertSign bit. CA certificates whose subject public key is to be used to verify CRLs will assert the cRLSign bit. CA certificates whose subject public key is to be used to verify Online Certificate Status Protocol (OCSP) responses will assert the digitalSignature and/or nonRepudiation bits.

Public keys that are bound into Verizon device certificates may be used for signing, encrypting or both. Device certificates to be used for digital signatures (including authentication) will assert the digitalSignature bit. Device certificates that contain RSA public keys that are to be used for key transport will assert the keyEncipherment bit. Device certificates containing Elliptical Curve public keys that are to be used for key transport will assert keyAgreement bit. Device certificates will not assert the nonRepudiation bit.

The dataEncipherment, encipherOnly, and decipherOnly bits will not be asserted in certificates issued under this CPS. Extended Key Usage within certificates is not defined unless necessary for application interoperability. In cases where extended key usage is needed for application interoperability, the Verizon certificate will also include anyExtendedKeyUsage (OIDxxx) as a sub-attribute of extended key usage. when the certificate is not restricted to only selected extended key usages. 4.5.2 Relying Party Public Key and Certificate Usage

Common Policy-issued certificates specify restrictions on use through critical certificate extensions, including the basic constraints and key usage extensions. Verizon, operating under the Common Policy, will issue CRLs specifying the current status of all unexpired certificates. OCSP responder certificates that include the id-pkix-ocsp-nocheck extension are the only certificates for which the status cannot be obtained from the CRL. OCSP certificates have short validity span and they are never revoked. It is recommended that relying parties process and comply with this information whenever using Common Policy certificates in a transaction. A Relying Party shall check the CRL maintained in the public repositories to determine whether the Certificate that the Relying Party wishes to rely on has been revoked. In no event shall Verizon or any of Verizon’s partners, principals, subcontractors, distributors, agents, suppliers, employees or directors of any of the foregoing be liable for any damages whatsoever due to: (i) the failure of a Relying Party to check for revocation or expiration of a Certificate, or (ii) any reliance by a Relying Party on a Certificate that has been revoked or that has expired. Additional Relying Party obligations are set forth in Section 1.3.5 and Section 9.6.4 of this CPS. Verizon may also enter into specific agreements with Relying Parties which will further define the parties’ obligations.

4.6 Certificate Renewal

The Common Policy defines certificate renewal as the process by which a new certificate is issued with the same subject name, private key and other information as the old certificate but with a new, extended, validity period and a new serial number. The old certificate may or may not be revoked, but must not be further re-keyed, renewed, or modified.

4.6.1 Circumstance for Certificate Renewal

Verizon will not renew subscriber certificates issued under this CPS except in connection with recovery from a CA key compromise (see 5.7.3). In such cases, the renewed certificate will expire as specified in the original subscriber certificate. CA certificates and OCSP responder certificates may be renewed so long as the aggregated lifetime of the public key does not exceed the certificate lifetime specified in section 6.3.2. Verizon may automatically renew certificates during recovery from key compromise. 4.6.2 Who May Request Renewal

For all CAs and OCSP responders operating under this policy, the corresponding operating authority may request renewal of its own certificate. 4.6.3 Processing Certificate Renewal Requests

Processing of the CA certificate renewal request is overseen and approved by FPKIPA. 4.6.4 Notification of New Certificate Issuance to Subscriber

Verizon will notify the Subscriber of the renewal of his or her certificate and the contents of the certificate, in case a subscriber certificate is renewed due to CA key compromise. The notification and delivery to the subscriber or the device sponsor will be facilitated through the Contracting Agency where practical. Details of this process are covered in the Contracting Agency’s RPS. 4.6.5 Conduct Constituting Acceptance of a Renewal Certificate No stipulation 4.6.6 Publication of the Renewal Certificate by the CA Verizon CA certificates will be published in repositories as specified in Section 2.1. Additionally publication of Subscriber certificates will adhere to the requirements as specified in Section 9.4.3. 4.6.7 Notification of Certificate Issuance by the CA to Other Entities No stipulation. 4.7 Certificate Re-Key The Common Policy defines certificate re-key as the process of creating new certificates with a different public key (and serial number) while retaining the remaining contents of the old certificate that describe the subject. The new certificate may be assigned a different validity period, key identifiers, specify a different CRL distribution point, and/or be signed with a different key. Re-key of a certificate does not require a change to the subjectName and does not violate the requirement for name uniqueness. The old certificate may or may not be revoked, but must not be further re-keyed, renewed, or modified.

4.7.1 Circumstance for Certificate Re-Key

Certificate holders are required to obtain new key pairs at least once every three years. (The usage periods for CA and Subscriber private keys are described in Section 6.3.2.) During the re-keying process, Verizon will create a new certificate with the same characteristics as the old certificate but with a new and different key pair and serial number. This new certificate may be given a new validity period or use the validity period that appeared in the old certificate.

Examples of circumstances requiring certificate re-key include: pending expiration, loss or compromise, issuance of a new hardware token, and hardware token failure.

4.7.2 Who May Request Certification of a New Public Key

Subscribers with a currently valid certificate may request certification of a new public key. Verizon, the Contracting Agency or the RA may request certification of a new public key on behalf of a Subscriber. For device certificates, the human sponsor of the device may request certification of a new public key. Refer to section 4.2 4.7.3 Processing Certificate Re-Keying Requests

Verizon CA treats all subscriber re-key requests as initial requests. This is enforced via a configuration feature in the certificate template. Verizon CA authenticates each electronic request for a new certificate using either the current valid certificate of the subscriber, or using the certificate of the Contracting Agency RA who requests new certificates on behalf of subscribers. If the re-key request is submitted by a Contracting agency RA agent, it is the responsibility of the RA agent to authenticate the digital signature of a subscriber before electronic re-key requests are submitted to the CA for processing. This process should be documented in the Agency’s RPS. With respect to key management keys for hardware certificates, the subscriber will be required to present themselves to the RA so that the key management key may be properly generated and archived for the subscriber. In those situations where it has been longer than nine (9) years, the Subscriber certificate re-key will follow the same procedures as the initial certificate issuance process. 4.7.4 Notification of New Certificate Issuance to Subscriber

No stipulation 4.7.5 Conduct Constituting Acceptance of a Re-Keyed Certificate

No Stipulation. 4.7.6 Publication of Re-Keyed Certificate by the CA

As specified in Section 2.1, Verizon CA certificates will be published in repositories as specified in Section 2.1. Additionally publication of Subscriber certificates will adhere to the requirements as specified in Section 9.4.3. 4.7.7 Notification of Certificate Issuance by the CA to Other Entities

No stipulation. 4.8 Certificate Modification

The Common Policy defines certificate modification as the process of creating a new certificate that may have the same key as the old certificate but has a different serial number and one or

more different fields. Under this CPS, Subscribers requesting a modification of their certificates will have their old certificates revoked, and will be required to repeat the initial registration process, and be issued new certificates with new keys.

4.8.1 Circumstance for Certificate Modification Where an individual’s name changes (e.g., due to marriage) then that individual must follow the process specified in the Contracting Agency’s RPS in order for a certificate with the new name to be issued. At a minimum, the agreement between the certificate holder and Verizon imposes an obligation upon the certificate holder to immediately inform the Contracting Agency and Verizon of changes to registration information including a change of legal name. The individual must appear in-person before either the Agency RA or other Trusted Agent and provide the RA or its agent with proof of the name change using the forms and processes followed by the Contracting Agency when issuing the certificate holder’s current certificate.

Verizon may modify its CA or OCSP responder certificate in which the characteristics may have changed (e.g., assert new policy OID). The new certificate may have the same or different subject public key. When Verizon updates its private signing key and generates the new public key it will notify all CAs, RAs and Subscribers who rely on its CA certificate that it has been changed. When Verizon updates its CA certificates, it will also generate key rollover certificates, where the new public key is signed by the old private key, and vice versa. 4.8.2 Who May Request Certificate Modification

Subscribers with a currently valid certificate may request certificate modification. Verizon, the Contracting Agency, or the RA may request certificate modification of a new public key on behalf of a Subscriber. For device certificates, the human sponsor of the device may request certificate modification. 4.8.3 Processing Certificate Modification Requests

Where an individual’s name changes (e.g., due to marriage) then that individual must follow the process specified in the Contracting Agency’s RPS in order to provide proof of the name change and for a certificate with the new name to be issued. Proof of all subject information changes must be provided to the Agency RA or other designated agent and verified before the modified certificate is issued. At a minimum, the agreement between the certificate holder and Verizon imposes an obligation upon the certificate holder to immediately inform the Contracting Agency and Verizon of changes to registration information including a change of legal name. The individual must appear in-person before either the Agency RA or other Trusted Agent and provide the RA or its agent with proof of the name change using the forms and processes followed by the Contracting Agency when the certificate holder’s current certificate was issued. If the Subscriber’s authorizations or privileges change, the Agency RA will verify those authorizations. If authorizations have been reduced, the old certificate must be revoked.

4.8.4 Notification of New Certificate Issuance to Subscriber

No stipulation 4.8.5 Conduct Constituting Acceptance of Modified Certificate No Stipulation.

4.8.6 Publication of Modified Certificate by the CA

Verizon CA certificates will be published in repositories as specified in Section 2.1. Additionally, publication Subscriber certificates will adhere to the requirements as specified in Section 9.4.3. 4.8.7 Notification of Certificate Issuance by the CA to Other Entities No Stipulation 4.9 Certificate Revocation and Suspension

Verizon will issue CRLs covering all unexpired certificates issued under this CPS except for OCSP responder certificates that include the id-pkix-ocsp-nocheck extension.

Verizon is committed to abide by the Federal Common Policy CP requirements and issue all CA and agency subscriber public keys with embedded publicly (local URLs are optional) accessible validation URLs in their AIA and CDP extensions. Agency RAs inform their subscribers (via screen banner, email, verbal or signed document) during the certificate issuance process about the importance of the up-to-date validation information and the consequences of using dated revocation information. The certificate status information is readily available via CRLs and OCSP to all Subscribers and relying parties who handle public keys issued under this CPS. Verizon SSP CA will only process authenticated revocation requests. Depending on the type of the certificate and the configuration settings defined in the certificate template, requests to revoke a certificate may be authenticated using that certificate's associated private key, regardless of whether or not the private key has been compromised. Revocation requests can also be submitted by RA agents on behalf of the subscribers.

Certificate suspension for CA certificates is not allowed by this CPS. However, the use of certificate suspension for end entity certificates which are issued under card management system on behalf of contracting agencies is allowed and is described within the Contracting Agency’s RPS. Verizon does not allow the suspension of software based certificates or device certificates.

4.9.1 Circumstances for Revocation Verizon will revoke a certificate when the Contracting Agency, its RA or the Subscriber requests revocation for any reason. Verizon will revoke a certificate when it becomes aware or is notified that the binding between the subject and the subject’s public key defined within the certificate is no longer considered valid. Circumstances that invalidate the binding are:

• Identifying information or affiliation components of any names in the certificate becomes invalid.

• Privilege attributes asserted in the subscriber’s certificate are reduced.

• The subscriber can be shown to have violated the stipulations of its subscriber agreement.

• There is reason to believe the private key has been compromised.

• Any information in the certificate would make the certificate misleading or inaccurate.

• The subscriber or other authorized party (as defined in this CPS or the Contracting Agency’s RPS) asks for his/her certificate to be revoked.

Whenever any of the above circumstances occur, the associated certificate will be revoked and placed on the CRL. Revoked certificates will be included on all new publications of the certificate status information until the certificates expire.

4.9.2 Who Can Request a Revocation Verizon may summarily revoke certificates within its domain. Circumstances where Verizon may revoke a certificate include a determination by Verizon or the Contracting Agency Registration Authority that the Subscriber’s certificate has been, or may become, compromised. Only persons serving in Trusted Roles (see Section 5.2.1) may request revocation. When Verizon revokes a certificate under this section, it will send an email to the subscriber or the requesting authorized agent notifying them of the revocation of the certificate as well as providing a brief explanation of the reason for revocation. The RA can request the revocation of a subscriber’s certificate on behalf of any authorized party as specified in the Contracting Agency’s RPS. A subscriber may request that their own certificate be revoked. The human sponsor of a device can request the revocation of the device’s certificate. In addition, the RPS may provide that specified Agency officials (e.g., the Inspector General or Chief Information Security Officer) may request revocation. 4.9.3 Procedure for Revocation Request A request to revoke a certificate will identify the certificate to be revoked, explain the reason for revocation, and enable the request to be authenticated. The Verizon CA will process certificate revocation requests through the Contracting Agency’s RA through use of a proprietary protocol that authenticates the identity of the authorizing RA. Such requests are digitally signed. Per the requirements of Section 3.4, Verizon will also process certificate revocation requests made by the certificate holder through use of a validated pass phrase or through the validation of a signed revocation request made with the private key of the certificate to be revoked. The procedures for authenticating a revocation request shall be specified in the Contracting Agency’s RPS. The Contracting Agency (acting through its RA) shall authenticate any revocation requests and shall notify the Verizon CA of any Certificates that are to be revoked. On successful revocation, Verizon will add the Certificate to the CRL during the next scheduled CRL update and publish an updated version of the CRL in the Directory in accordance with Section 2.3 of this CPS. Where Subscribers use hardware tokens, revocation is optional if all 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 or Agency RA;

• the token was zeroized or destroyed promptly upon surrender;

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

In all other cases, revocation of the certificates is mandatory. Even where all the above conditions have been met, revocation of the associated certificates is recommended.

4.9.4 Revocation Request Grace Period

No grace period exists for revocation. 4.9.5 Time within which CA must Process the Revocation Request

Verizon will revoke Certificates as quickly as practical upon receipt of a proper revocation request. Verizon CAs’ CRL publication settings are configured during the initial setup to issue CRLs every 12 hours, unless otherwise requested by a contracting agency, even where no certificates have been revoked. Revocation requests received within two (2) hours of CRL issuance will be processed before the following CRL is published. Optionally a CA can be configured to issue CRLs automatically upon certificate revocation. Revocation requests can be electronically submitted via the same enrollment portal, which is used by RA agents to issue certificates to the subscribers. All electronically submitted and properly authenticated revocation requests are processed by the CA immediately upon arrival, or in less than 2 hours. Revocation requests submitted manually via email request through the support center are processed within 1 day, unless otherwise requested by the Contracting Agency.

4.9.6 Revocation Checking Requirements for Relying Parties

The Relying Party will decide, pursuant to its own policies, what steps it will need to take to rely on a certificate issued under this CPS. Verizon will provide the tools for the relying party to perform the trust path creation and certificate validation that the relying party may wish to employ in making its determination to rely on these certificates. In the event the Relying Party decides to rely on certificates issued under this CPS, the relying party shall, at a minimum:

(i) read and agree to all terms and conditions of this CPS; (ii) validate all Certificates through the use of the Certificate Revocation List (CRL); (iii) trust and make use of a Certificate only if the Certificate has not expired or been revoked and if a proper chain of trust can be established to the trusted root; and (iv) make its own judgment and rely on a Certificate only if such reliance is reasonable in the circumstances, including determining whether such reliance is reasonable given the nature of the security and trust provided by the Certificate and the value of any transaction that may involve the use of a Certificate. The Relying Party shall comply with all laws and regulations applicable to a Relying Party's right to use Certificates and/or related information. A Relying Party shall check the CRL maintained in the repository to determine whether the Certificate that the Relying Party wishes to rely on has been revoked. In no event shall Verizon or any of Verizon’s partners, principals, subcontractors, distributors, agents, suppliers, employees or directors of any of the foregoing be liable for any damages whatsoever due to: (i) the failure of a Relying Party to check for revocation or expiration of a Certificate, or (ii) any reliance by a Relying Party on a Certificate that has been revoked or that has expired. Additional Relying Party obligations are set forth in Section 1.3.5 and Section 9.6.4 of this CPS. Verizon may also enter into specific agreements with Relying Parties which will further define the parties’ obligations.

4.9.7 CRL Issuance Frequency Authorized RA agents can request certificate revocation via UniCERT UPI API calls providing the credential’s serial number and the revocation reason and submitting the UPI RevocationRequestForm. Alternatively, revocation requests can be submitted via UniCERT webportal by clicking the revocation tab, providing the credential serial number and a reason for the revocation.

Change in certificate status information is posted to a CRL no later than the next scheduled CRL update time. Verizon does not operate offline SSP CAs. Both Verizon Subscriber Issuing CAs and CAs which only issue certificates to other CAs operate in online mode and will generate new CRLs every twelve hours, unless otherwise requested by contracting agencies, but not less frequently than at least every 18 hours. Total validity of a CRL by default will be 24 hours, not to exceed 48 hours, even if there are no changes, to ensure timeliness of information. In the event one of Verizon’s SSP CA certificates is revoked because of a compromise, or suspected compromise of a private key, Verizon will issue a CRL within six (6) hours of notification.

4.9.8 Maximum Latency for CRLs

Verizon will publish CRLs within four (4) hours of generation. Furthermore, Verizon will publish CRLs no later than the next scheduled update period. Relying parties and other interested participants in the PKI may obtain copies of the most current CRL from the Verizon SSP validation Web portals. CRL locations are specified in the certificate’s “CRL distribution point” extension as HTTP URIs. 4.9.9 Online Revocation/Status Checking Availability

Verizon shall support on-line status checking via OCSP [RFC 2560] for Contracting Agencies and Relying Parties for end entity certificates issued under id-fpki-common-authentication, id-fpki-common-cardAuth, id-fpki-common-derived-pivAuth-hardware, and id-fpki-common-derived-pivAuth. Status information maintained by the OCSP server is updated on a regular basis. Where a certificate is revoked for key compromise, the status information is updated and available to relying parties within 6 hours. Where a certificate is revoked for a reason other than key compromise, the status information is updated and available to relying parties within 18 hours. OCSP does not exceed 31 days validity. Current OCSP version does not support reporting “unknown” for unknown serial numbers. Corestreet v7 does have that option (Verizon IAM will upgrade to this version in year 2018). OCSP Validation Authority queries the CRL on hourly basis for any certificate serial number status change. CA updates the CRL every 12 hours, which makes certificate status information within OCSP response no less than 13 hours accurate Verizon IAM Validation system monitoring agents are configured to detect CRL and OCSP slow responses and warn the 24/7 monitoring team when the responses to validation requests take longer than 10 seconds. Public trust auth cert is not supported by this CPS. Verizon OCSP signing certificates do contain id-pkix-ocsp-nocheck extension, as stated in the CPS Apendix A OCSP profile The URL for this will be specified within the certificate extension “Authority Information Access (AIA)” for OCSP access method. Where a relying party application utilizes OCSP, CRL retrieval and checking requirements are automatically satisfied. Note that since some relying parties cannot accommodate on-line communications, Verizon will publish CRLs as noted in Sections 4.9.7 and 4.9.8. Further information about the identity OCSP validation service is described in the document Managed_Validation_Service_Details in the library at the following link:

https://teamsites.vzbi.com/sites/mss/iam/AE/Service%20Overview/Forms/AllItems.aspx# and/or from the OCSP product vendor site: https://www.hidglobal.com/products/software/corestreet-validation-suite 4.9.10 On-line Revocation Checking Requirements

Relying party client software may optionally support on-line status checking. Client software using on-line status checking need not obtain or process CRLs. 4.9.11 Other Forms of Revocation Advertisements Available

Verizon does not offer alternative methods to publicize certificate revocation status other than the methods described in sections 4.9.7 through 4.9.10.

4.9.12 Special Requirements Related to Key Compromise

Verizon maintains policies and procedures in its SharePoint Federal SSP Documents library for dealing with the possibility of compromise of its CA private key. Details for key compromise can be found in the document at:

https://teamsites.vzbi.com/sites/mss/iam/Federal%20SSP%20Audits/Cybertrust%20Offline%20and%20Online%20Customer%20Key%20Management%20Plan%20for%20nCipher%20security%20world%20v5%200-20070927final.doc

In the event of a CA private key compromise, Verizon will generate an appropriate new CA certificate to be signed by the Federal Root CA as required and, as provided in Section 4.6, Verizon may also choose to renew current end entity certificates under the new signing key.

When a CA certificate is revoked because of compromise or suspected compromise of a private key, Verizon will issue a CRL within 18 hours of notification following the CRL publication procedures described in section 4.9.7.

4.9.13 Circumstances for Suspension

For CA certificates, suspension is not permitted. For Subscriber certificates, suspension is allowed when utilized by the Contracting Agency’s card management environment and is described within the Contracting Agency RPS. Verizon does not allow the suspension of software based certificates or devices certificates. 4.9.14 Who Can Request Suspension

See Contracting Agencies RPS. No stipulation for end entity certificates.. 4.9.15 Procedure for Suspension Request

See Contracting Agencies RPS.No stipulation for end entity certificates.

https://teamsites.vzbi.com/sites/mss/iam/AE/Service%20Overview/Forms/AllItems.aspx




4.9.16 Limits on Suspension Period

See Contracting Agencies RPS. No stipulation for end entity certificates. 4.10 Certificate Status Services

No stipulation 4.10.1 Operational Characteristics

No stipulation 4.10.2 Service Availability No stipulation 4.10.3 Optional Features

No stipulation 4.11 End of Subscription

No stipulation 4.12 Key Escrow and Recovery 4.12.1 Key Escrow and Recovery Policies and Practices

CA private keys are never escrowed.

Subscriber key management keys may be archived to provide key recovery. Further details of the method for archiving and recovering keys are described in a Contracting Agency’s Key Recovery Practices Statement (KRPS). A Customer-KRPS-Template can be found at the IAM SharePoint site:

https://teamsites.vzbi.com/sites/mss/iam/Federal%20SSP%20Audits/Forms/AllItems.aspx#

In general, Verizon will archive private encryption keys to enable the Subscriber or other authorized person to recover encrypted data in the event the Subscriber loses its encryption certificate.

During certificate key pair generation, a copy of the Subscriber’s private encryption key is made and placed in a secure repository. A Key Recovery Officer (KRO) (generally located local to the RA functions at the Contracting Agency) will receive requests to recover archived keys. The KRO will ensure that the request for key recovery comes from an authorized party. The KRO verifies the requestor’s identity and authorization to make the recovery request and transmits that information to a KRA who will perform the recovery. Key recovery requests may be made by the Subscriber or a third party. The Contracting Agency will specify in a KRPS the parties, in addition to the Subscriber, who may request recovery of the Subscriber’s private encryption key. Delivery of keys will be in a method consistent with Section 6.1.2 of this policy. Subscriber encryption keys issued under id-fpki-common-policy will be recovered in compliance with FIPS 140-2 level 1

https://teamsites.vzbi.com/sites/mss/iam/Federal%20SSP%20Audits/Forms/AllItems.aspx

requirements, while encryption keys issued under id-fpki-common-hardware will be recovered to a cryptographic module meeting or exceeding FIPS 140-2 level 2 requirements.

Under no circumstances will a subscriber’s signature key be held or archived by Verizon or other related or third party.

4.12.2 Session Key Encapsulation and Recovery Policy and Practices Verizon CA's subscriber key recovery and encapsulation process is documented in UniCERT Key Archive Server Administrator guide. This document is included with the UniCert product and can be requested if needed.

5. Facility, Management, and Operational CONTROLS

5.1 Physical Controls

Verizon’s CA equipment is protected from unauthorized access while the cryptographic module is installed and activated. The CA equipment is housed at a secure datacenter at all times, accessible only to authorized engineers who are members of the trusted CA Administration group. The datacenter is controlled by security guards, bio-metric readers, badge readers and PIN numbers. Additionally, cameras record all access to the facility and datacenter areas. Verizon has also implemented physical access controls to reduce the risk of equipment tampering when the cryptographic module is not installed and activated. Verizon’s cryptographic tokens are protected against theft, loss, and unauthorized use at all times. Verizon’s security policies and procedures are detailed in Verizon’s System Security Plan which is located on the IAM SharePoint stie at:


5.1.1 Site Location and Construction

The primary site for Verizon SSP CA equipment is the Network Access Point (NAP) of the Capitol Region located in Culpeper, VA. The backup site is located in Irving, TX. Both facilities are classified as a Tier-IV data centers, the highest standard established for data centers. As described in Section 5.1.2, Verizon has implemented these standards in a manner which provides robust protection, including guards, biometric access readers and access controls to protect against unauthorized access to the CA equipment and records.

5.1.2 Physical Access

5.1.2.1 Physical Access for CA Equipment Verizon has implemented policies and procedures (as described in detail in Verizon’s Security Procedures and Standard Operating Procedures) to ensure that the physical environment in which Verizon’s SSP systems are installed maintain a high level of security:

(i) Verizon’s SSP system is installed in a secure facility that is isolated from outside networks, with all access controlled;


(ii) the entrances and exits from the secure areas are under constant video surveillance and all systems that provide authentication, as well as those that record entry, exit and network activity, are in secured areas; and (iii) the software components are installed in an environment designed to minimize security risks. The security techniques employed are designed to resist a large number and combination of different forms of attack. The mechanisms Verizon uses include: • Proximity card readers • Perimeter alarms • Closed circuit television • Biometric identification systems • Mantraps (individual and multi-person) • Human guards

In addition, Verizon has implemented policies and procedures to ensure that: (i) physical access to Verizon systems is controlled; (ii) only operative personnel and essential personnel with a valid business reason (e.g., resources to conduct statutory independent audits) are provided such access; (iii) the access control system is always functional and requires unique login credentials; (iv) those admitted physical access are only granted access to business and proprietary information based on their "need to know" and; (v) facility access is logged and such logs are reviewed by Verizon’s Chief Security Officer or designee. To prevent tampering, cryptographic hardware is stored in a secure site, with access limited to authorized personnel, having the following characteristics:

• inventory control processes and procedures to manage the origination, arrival, condition, departure and destination of each device;

• access control processes and procedures to limit physical access to authorized personnel;

• all successful or failed physical access attempts are recorded in an event journal;

• incident processes and procedures to handle abnormal events, security breaches, and investigation and reports;

• audit processes and procedures to verify the effectiveness of the controls;

• prior to installation, the handling of cryptographic hardware is performed in the presence of no less than two individuals in Trusted Roles; and

• cryptographic hardware is stored in tamper resistant and tamper evident packages.

Verizon’s Security Procedures and Standard Operating Procedures provide for physical access controls to ensure that:

• All removable media and paper containing sensitive plain-text information is stored in secure containers.

• An access log is maintained and inspected periodically.

• Only authorized individuals are granted access as indicated above

• Activation data is either memorized or recorded and stored in a manner commensurate with the security afforded the cryptographic module, and is not stored with the cryptographic module.

• Two-person control is required to physically access and administer the cryptographic module appliances.

The installation of cryptographic hardware is performed in the presence of no less than two individuals in Trusted Roles. The removal of cryptographic hardware from production and the process of disassembling such hardware shall be performed in the presence of no less than two individuals in Trusted Roles. When not in use, the removable CA cryptographic materials (tokens, smartcards, physical keys) are removed from the Hardware Security Modules and stored in GSA approved dual access fire proof safe containers. The safe containers are located either near the HSM devices at the secure datacenter, or in a separate highly secure offline backup site under constant surveillance. If the HSM device is being permanently removed from service, then any key contained within the device that has been used for any cryptographic purpose is erased from the device by initializing the device. The HSM activation data (PINs, passwords) is either memorized or recorded and stored in fire proof and dual access safe containers along with the removable crypto materials, unless being actively used for the CA key activation or the activation of the cryptographic modules. Verizon uses human guards to continually monitor the perimeter of the facility housing the CA equipment on a 24 hour, 365 day basis. The contracted guards perform daily roves every 2 hours. All roves are reported in the Security Reporting system. The Security Reporting System is maintained by the Premium Data Center Security department. With approval, this can be shown (via WebEx or other secure method), but no access shall be given due to the For Official Use Only (FOUO) information contained in this reporting system. In addition to the guards who monitor the building, Verizon also uses CCTV and Intrusion Detection System (IDS) to monitor the Verizon suite. The CA and Remote Operator suite contain sign in/out sheets. All authorized personnel and visitors must sign in/out. Although the facility is continuously attended the last personnel to sign out performs the basic checks listed below:

• Security containers are properly secured

• Physical security systems (door locks, vent covers etc) are functioning properly

• The area is secured against unauthorized access

• The equipment is in a state appropriate to the current mode of operation (for the CA all equipment other than the repository is shut down).

5.1.2.2 Physical Access for RA Equipment Verizon, its Contracting Agency (or the Agency’s appointed RA) will implement appropriate physical and procedural access controls for all hardware and software sub-systems used in the registration and revocation of Subscribers, and the creation and signing of Certificates. Verizon and the Contracting Agency will limit access to functions critical to registration and certificate issuance to personnel in Trusted Roles (see Section 5.2.1 of this CPS).

5.1.2.3 Physical Access for Certificate Status Servers (CSS) Equipment

Physical access control requirements for CSS equipment will meet the physical access requirements specified in section 5.1.2.1 of this CPS.

5.1.3 Power and Air Conditioning

The datacenter, the Network Access Point (NAP) of the Capitol Region, is a secure SSAE16/SAS 70 Type II audited facility. Verizon uses 2 backup generators and sufficient UPS capability to lock out input, finish any pending actions, and record the state of the equipment automatically before lack of power or air conditioning causes a shutdown. The repositories (containing CA-issued certificates and CRLs) are provided with uninterrupted power sufficient for a minimum of 6 hours operation in the absence of commercial power. Additionally, the generator will be on line and available at 100% capacity within 50 seconds, to maintain availability of services. Should the UPS fail to transfer power to the 2 backup generators, team members will contact the agencies and initiate the transfer of systems to the DR site as designated in the SLAs.

5.1.4 Water Exposures

Each HVAC unit has water leak detectors under the raised floor that sends a signal to a control panel at the guards’ station. CA equipment is installed in computer racks which are not in danger of exposure to water (e.g. on tables or elevated floors). Additional floor water sensors are also located at each air handler location.

Characteristics of the water shutoff valves are:

• Every building contains at least one shutoff valve • Each is easily identified and located • Easily visible to all personnel

Fire suppression systems use:

oDry-pipe over critical information systems oWet pipe over non-critical infrastructure

Leak detection is located on and under each:

• Heating unit • Ventilation unit • Air condition unit • Chiller unit

Rope leak detection is located under the data center floor and TC water resistant cable is used for cabling within the same space. All servers and equipment are held on a 36 inch raised floor.

5.1.5 Fire Prevention and Protection

Verizon follows best industry standard practices for fire prevention and protection. The facility is protected by HALON Notifier 5000 fire suppression systems. Our DR facility uses pre-action dry pipe sprinkler system with pressurized leak detection. Heat and smoke detection above and below the floor is also in use.

5.1.6 Media Storage

Media storage under the control of Verizon is subject to multiple-layer security storage requirements as described in Verizon’s Security Procedures and Standard Operating Procedures. Removable media necessary for operation of the environment is stored at either one or both secure datacenters. The primary datacenter is located in Culpeper, VA. The DR/backup site is in Irving, TX. Media at both locations is stored in government rated fireproof dual access safes, so as to protect them from accidental damage (e.g., water, fire, or electromagnetic). Media may also be stored at alternative and secure non-datacenter sites like the offline room in Silver Spring, MD, or Iron Mountain storage facility in PA.

5.1.7 Waste Disposal

Verizon’s Security Procedures provide that sensitive media and documentation that are no longer needed for operations are destroyed in the disposal process. For example, sensitive paper documentation is shredded, burned, or other wise rendered unrecoverable. Procedures are documented in the Verizon-Cybertrust Security Procedures Manual and stored in the IAM SharePoint repository at:


5.1.8 Offsite Backup

Verizon makes full system backups once a day. Backups are automatically transferred to the DR site at Irving, TX, on a daily basis to enable either local recovery from a system failure at the primary site or a full site recovery at the DR location.

5.2 Procedural Controls

5.2.1 Trusted Roles

A trusted role is one whose incumbent performs functions that can introduce security problems if not carried out properly, whether accidentally or maliciously. Verizon’s Business Organization Plan supports the company’s information security management system and details roles and responsibilities of personnel, including the skills to perform the specific job functions. Specific trusted roles description for the IAM SSP organization are described in the following document:

https://teamsites.vzbi.com/sites/mss/iam/Federal%20SSP%20Audits/SSP%20Trusted%20Roles%20v4%200.doc

The people selected by Verizon and its Contracting Agency to fill these roles will be extraordinarily responsible. The functions performed in these roles form the basis of trust for the entire PKI. 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.

The requirements of this policy are defined in terms of four roles. (Note: the information derives from the Certificate Issuing and Management Components (CIMC) Protection Profile.). The primary trusted roles defined in this CPS are Administrator, Officer, Auditor, and Operator. These roles are derived from roles identified in the CIMC Protection Profile developed by NIST and will be employed at both Verizon and the Contracting Agency’s RA locations as appropriate. The roles required for each level of assurance are identified in Section 5.2.4. These four roles are




employed at the CA, RA, and CSS locations as appropriate. Separation of duties shall comply with 5.2.4, and requirements for two person control with 5.2.2, regardless of the titles and numbers of Trusted Roles. The four roles are defined as follows:

1. Administrator – this role is performed by a Verizon SSP employee who is a US citizen. The administrator is responsible for:

• Installation, configuration, and maintenance of the CA hardware and software • Establishing and maintaining CA and MVS system accounts • Configuring certificate profiles or templates and audit parameters • Configuring CSS response profiles; and • Generating and backing up CA and MVS keys • Archive audit logs. • Administrators do not issue certificates to subscribers.

2. Officer – The Verizon SSP program supports two main officer roles: the Key Recovery Officer (KRO) and the Registration Authority Officer (RAO). The Officer’s responsibility is to insure the following functions occur according to the stipulations this CPS, including:

• Registering new subscribers and requesting issuance of certificates • Verifying the identity of subscribers and the accuracy of information included in

certificates • Approving and executing the issuance of certificates • Requesting, approving and executing the revocation of certificates

3. Auditor –The Auditor is responsible for:

• Reviewing, maintaining and archiving audit logs

• Performing or overseeing internal compliance audits to insure that the CA and associated RAs and CSS, where applicable, are operating in accordance with this CPS and their RPS.

4. Operator – The operator role is also performed by Verizon SSP employees. The Operator performs routine operational duties on the CA equipment and CA environment such as basic hardware maintenance, system backups and recovery, daily monitoring and system level troubleshooting.

5.2.2 Number of Persons Required per Task

All CA key processes (generation, activation, backup, rollover, decommission) are performed by two trusted CA administrators. SSP maintains a list of trusted CA administrators authorized to act in this role. The trusted CA Administrator role is discussed in more detail in section 5.2.1.1. Key generation, key rollover, or key decommission ceremonies are witnessed by a trusted CA auditor.

Two or more persons assigned to trusted roles are required for the following tasks:

• CA key generation

• CA signing key activation

• CA private key backup.

At least one of the participants will be an Administrator as defined in Section 5.2.1.1 of this CPS. Also, the Auditor trusted role as defined in Section 5.2.1.4 of this CPS will not perform any of the tasks that require two (2) or more persons.

5.2.3 Identification and Authentication For Each Role

Identification of Verizon trusted employees authorized Verizon uses UserID and Password and SecureID authentication for Operator roles and certificate based identification and authentication for Officer roles. The Contracting Agency’s RPS will provide further details on these roles and the identification and authentication procedures used.

5.2.4 Roles Requiring Separation of Duties Individual Verizon CA personnel and Contracting Agency RA personnel are specifically designated to the minimum of four roles defined in Section 5.2.1 above and described in Verizon’s Trusted Roles document. Individuals may only assume one of the Officer, Administrator, and Auditor roles, but any individual may assume the Operator role. Verizon’s CA software and hardware will identify and authenticate its users. The authentication methods and the role separation practices used to validate the identity of the Verizon CA administrators are described in CPS section 6.5.1. The Contracting Agency’s RA software and hardware authentication practices are described in RPS section 5.2. Verizon restricts assignement of the CA administrator trusted roles to a minimum number of internal employees who are recommended by the OA and approved by the Verizon PMA. Verizon Administrator, Operator, and Auditor role assignment and separation practices are defined in the Verizon IAM Federal SSP Trusted Roles document, as well as in the Key Management Plan document. Both documents are available in the IAM SharePoint/Federal SSP Documents/ folder which can be found at: https://teamsites.vzbi.com/sites/mss/iam/Federal%20SSP%20Audits/Forms/AllItems.aspx# The RA officer role is exclusively filled by the contracting agency trusted employees.

5.3 Personnel Controls

5.3.1 Qualifications, Experience, and Clearance Requirements

All persons filling trusted roles are selected on the basis of skills, loyalty, trustworthiness, and integrity, and are U.S. citizens. Verizon’s Human Resources Department follows internal policies and procedures to ensure that appropriate job descriptions are maintained for personnel who operate manage, oversee and audit the CA. Among other processes, Verizon reviews resumes and conducts interviews to determine that the personnel selected to fill these roles have the skills necessary to perform the required functions. Supervisors and Managers regularly review personnel performance and provide oversight to those engaged in trusted roles. Verizon’s Human Resources Department maintains the Personnel Security related procedures for the organization. Human Resources works closely with the Security Manager to ensure that these Personnel Security procedures meet the objectives of the Verizon Security Procedures and this CPS. Verizon, the Contracting Agency (or its appointed Registration Authority), whichever is the employer of the particular individual, shall carry out verification checks on any individual who is seeking to be employed in a Trusted Role within their respective organizations.


The scope of such checks include pre-employment screening with a background investigation. Applicants are informed in writing that permanent employment is contingent upon successful completion of the background investigation process. The depth and extent of the background investigation varies depending on the level of information access required or the responsibilities associated with the role to be performed. Verizon, the Contracting Agency (or its appointed Registration Authority) shall each carry out periodic reviews in respect of any individuals they employ in Trusted Roles to verify the continued trustworthiness of such individuals.

5.3.2 Background Check Procedures

All Verizon CA personnel undergo a background investigation conducted by a third party. The investigations look at the past 7 years in the areas of employment, education, place of residence, law enforcement, and references. All personnel also undergo a drug screening test. In addition, personnel who have direct access to the computer systems, network and data bases within Verizon’s defined federal CA boundary undergo a Federal Minimum Background Investigation (MBI).

Where permitted by law, the criminal history check shall consist of a Federal and state check for felony and misdemeanor criminal convictions (or the equivalent thereof under relevant law) in all locations where the assigned employee has resided, has been employed, or has attended school in the immediately preceding seven (7) years, and a check of U.S. Government Specially Designated National (OFAC) and export denial lists. This criminal history check shall include, to the extent available and permitted by law, a check for outstanding warrants and a check for pending felony charges in all such locations. Statewide county searches shall be performed in all states where such search mechanism is available without requiring specialized data (such as fingerprints or DNA), and the National Criminal File database shall also be searched. For more information please refer to Verizon Partner Program Background Check Policy. Verizon’s advanced level background investigation process in combination with the MBI is consistent with the guidelines of Executive Order 12968 which can be found at:

https://www.federalregister.gov/documents/1995/08/07/95-19654/access-to-classified-information

5.3.3 Training Requirements

As specified in its Standard Operating Procedures, Verizon or its Contracting Agency (as appropriate) will provide proper training to all personnel performing duties with respect to the operation of the CA and RA. Training is conducted in the following areas:

• CA (or RA) security principles and mechanisms • All PKI software versions in use on the CA (or RA) system • All PKI duties that the personnel are expected to perform • Disaster recovery and business continuity procedures • The stipulations contained in the Common Policy, this CPS and the RPS.

5.3.4 Retraining Frequency and Requirements

All individuals responsible for PKI roles are made aware of changes in the CA operation via the Change Control process which is documented in the IAM Change Management Process document located at the IAM SharePoint site:

https://teamsites.vzbi.com/sites/mss/iam/Processes/Forms/IAM%20SOP.aspx#

Any significant change to operations such as a CA software or hardware upgrade, changes in automated security systems, and relocation of equipment require a change ticket which describes the change in detail, is peer reviewed and approved by a third individual (not the ticket originator or the peer reviewer). Change tickets are reviewed daily during the Integrated Global Operations - Daily Review Meeting which is attended by all Operations, Advanced Engineering and assigned Project Management personnel. Changes performed over the past 24-hours are reviewed as well as open tickets that are scheduled to be completed.

5.3.5 Job Rotation Frequency and Sequence

No stipulation.

5.3.6 Sanctions For Unauthorized Actions

Verizon, the Contracting Agency or its RA will take appropriate administrative and disciplinary actions against personnel who have performed actions involving the CA or it’s RAs that are not authorized in this CP, CPS, RPS or other published procedures.

5.3.7 Independent Contractor Requirements

When Verizon or the Contracting Agency uses a subcontractor to perform services, the subcontractor shall complete appropriate access agreements for individuals requiring access to organizational information and information systems before being granted access. Furthermore, explicitly stated objectives and supervision is in place to ensure that any subcontractors perform in accordance with the Common Policy, the CPS and the RPS as well as the requirements stipulated in Section 5.3.1.

5.3.8 Documentation Supplied to Personnel

Verizon or the Contracting Agency provides, to the personnel filling a Trusted Role, the necessary documentation sufficient to define duties and procedures for that role.

5.4 Audit Logging Procedures

Verizon will implement and maintain Trustworthy Systems to preserve an audit trail for Material Events and for key life cycle management, including key generation, backup, storage, recovery, destruction and management of cryptographic devices. Detailed audit procedures are contained in Verizon’s Standard Operating Procedures. The Contracting Agency (and its appointed RAs) shall implement and maintain Trustworthy Systems to preserve an audit trail for all Material Events conducted by the RAs. Verizon may employ certified public accountants or other information security specialists with demonstrated expertise in security or accredited security professionals to audit the operations of the Contracting Agency (or its appointed RAs) as Verizon in its sole discretion determines, to evaluate the compliance of the Contracting Agency (or its appointed RAs) with this CPS, the Contracting Agency’s RPS, and other applicable agreements, guidelines, procedures and standards. Where the Contracting Agency (or its appointed RAs) employs a third party auditor to evaluate their compliance with this CPS or any other applicable agreements, guidelines, procedures or standards, the Contracting Agency (or its appointed RAs) shall provide to Verizon copies of the audit reports prepared by the third party auditor to enable Verizon to review the compliance of the

https://teamsites.vzbi.com/sites/mss/iam/Processes/Forms/IAM%20SOP.aspx

Contracting Agency (or its appointed RAs). Receipt by Verizon of such audit reports provided by such third party auditor constitutes neither an endorsement nor approval on the part of Verizon of the content, findings, or recommendations of such reports. As Verizon is not the author of such audit reports and is therefore not responsible for their content, Verizon does not express any opinion on such audit reports and shall not be held responsible for any damages to anyone resulting from Verizon’s reliance on such audit reports. A third party audit report shall not, in any way, limit a Contracting Agency (or its appointed RAs) from being audited by Verizon. Verizon generates audit log files for all events relating to the security of the CA. When possible, the security audit logs are automatically collected. When this is not possible, a logbook, paper form, or other physical mechanism is used. All security audit logs, both electronic and non-electronic, are retained and made available for review during compliance audits.

5.4.1 Types of Events Recorded

Verizon enables all security auditing capabilities of its CA operating system and PKI CA applications during installation. At a minimum, each audit record includes the following (either recorded automatically or manually for each auditable event):

• The type of event

• The date and time the event occurred

• A success or failure indicator when executing the CA’s signing process

• A success or failure indicator when performing certificate revocation and

• The identity of the entity and/or operator that caused the event. CA receives messages only via UniCERT product proprietary authorized protocols, like UPI API and WebRAO. These messages include the identity of the requesting party, and this information is stored in the PKI CA-RA component database. The logged message includes message date and time, the requestor of the action, as well as the contents of the request.

Verizon or the Contracting Agency’s RA (as appropriate) will record each of the events identified in the list below. To the extent a particular event is being recorded by the RA, the Contracting Agency’s RPS will reflect that fact. When these events cannot be electronically logged, the CA and Contracting Agency RA shall supplement electronic audit logs with physical logs as necessary. Manual and/or Automated logging processes are identified below.

Auditable Event Recording Mechanism SECURITY AUDIT Ex. file location, application log file name, folder, hard copy,

Ticket system, network monitoring, physical monitoring etc. Any changes to the Audit parameters, e.g., audit frequency, type of event audited

At least one of the following logs should contain the information: CCB: https://opnet.idm.cybertrust.com/ccb Windows OS: Event Logs: Security Linux OS: /var/log/audit/audit.log Linux OS: /var/log/messages Linux OS: /var/log/secure Linux OS: /var/log/bash

Any attempt to delete or modify the Audit logs At least one of the following logs should contain the information: Windows OS: Event Logs: Security Linux OS: /var/log/audit/audit.log Linux OS: /var/log/messages Linux OS: /var/log/secure Linux OS: /var/log/bash Oracle logs: SYS.AUD$ table or ALERT.LOG file

https://opnet.idm.cybertrust.com/ccb

Auditable Event Recording Mechanism Obtaining a third-party time-stamp At least one of the following logs should contain the

information: Windows OS: Event Logs: Security Linux OS: /var/log/audit/audit.log Linux OS: /var/log/messages Linux OS: /var/log/secure Linux OS: /var/log/bash

IDENTIFICATION AND AUTHENTICATION Successful and unsuccessful attempts to assume a role At least one of the following logs should contain the

information: Windows OS: Event Logs: Security Linux OS: /var/log/audit/audit.log Linux OS: /var/log/messages Linux OS: /var/log/secure Linux OS: /var/log/bash Unicert: audit logs Agency CMS logs

The value of maximum authentication attempts is changed At least one of the following logs should contain the information: CCB: https://opnet.idm.cybertrust.com/ccb Windows OS: Event Logs: Security Linux OS: /var/log/audit/audit.log Linux OS: /var/log/messages Linux OS: /var/log/secure Linux OS: /var/log/bash

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

At least one of the following logs should contain the information: Windows OS: Event Logs: Security Linux OS: /var/log/audit/audit.log Linux OS: /var/log/messages Linux OS: /var/log/secure Linux OS: /var/log/bash

An Administrator unlocks an account that has been locked as a result of unsuccessful authentication attempts

At least one of the following logs should contain the information: Windows OS: Event Logs: Security Linux OS: /var/log/audit/audit.log Linux OS: /var/log/messages Linux OS: /var/log/secure Linux OS: /var/log/bash CCB: https://opnet.idm.cybertrust.com/ccb

An Administrator changes the type of authenticator, e.g., from passphrase to biometrics

At least one of the following logs should contain the information: Windows OS: Event Logs: Security Linux OS: /var/log/audit/audit.log Linux OS: /var/log/messages Linux OS: /var/log/secure Linux OS: /var/log/bash CCB: https://opnet.idm.cybertrust.com/ccb

LOCAL DATA ENTRY All security-relevant data that is entered in the system Needs clarification. Depending on the type of data and nature

of the request, this information can be found in one of these sources: CCB: https://opnet.idm.cybertrust.com/ccb ETMS: https://etms.verizon.com/ticketing/ Windows OS: Event Logs: Security Linux OS: /var/log/audit/audit.log Linux OS: /var/log/messages Linux OS: /var/log/secure Linux OS: /var/log/bash

REMOTE DATA ENTRY





https://etms.verizon.com/ticketing/

Auditable Event Recording Mechanism All security-relevant messages that are received by the system Needs clarification. Depending on the type of data and nature

of the request, this information can be found in one of these sources: Windows OS: Event Logs: Security Linux OS: /var/log/audit/audit.log Linux OS: /var/log/messages Linux OS: /var/log/secure Linux OS: /var/log/bash Unicert: PKI component audit logs Corestreet: audit logs

DATA EXPORT AND OUTPUT All successful and unsuccessful requests for confidential and security-relevant information

Depending on the type of data and nature of the request, this information can be found in one of these sources: CCB: https://opnet.idm.cybertrust.com/ccb ETMS: https://etms.verizon.com/ticketing/ Windows OS: Event Logs: Security Linux OS: /var/log/audit/audit.log Linux OS: /var/log/messages Linux OS: /var/log/secure Linux OS: /var/log/bash

KEY GENERATION Whenever the CA generates a key (Not mandatory for single session or one-time use symmetric keys)

Unicert: CA audit logs in CAO

PRIVATE KEY LOAD AND STORAGE The loading of Component private keys CCB: https://opnet.idm.cybertrust.com/ccb

Unicert: PKI component audit logs (CAO, KAO, RAEventViewer)

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

Unicert: PKI component audit logs (KAO and RAEventViewer)

TRUSTED PUBLIC KEY ENTRY, DELETION AND STORAGE All changes to the trusted public keys, including additions and deletions

Clarify if this is validation or issuance related. Either way, such changes are normally recorded in CCB. CCB: https://opnet.idm.cybertrust.com/ccb

SECRET KEY STORAGE The manual entry of secret keys used for authentication Clarify.

Retrieval of physical token to start a PKI component is recorded in manual safe container logs, and could be also in CCB: https://opnet.idm.cybertrust.com/ccb ETMS: https://etms.verizon.com/ticketing/

PRIVATE AND SECRET KEY EXPORT The export of private and secret keys (keys used for a single session or message are excluded)

Pki component keys stored in HSM are not exportable; Archived EE keys recovered from the system are tracked in Unicert KAO audit logs

CERTIFICATE REGISTRATION All certificate requests Unicert: RA audit logs in RAEventViewer

Federal Agency CMS: CMS logs CERTIFICATE REVOCATION All certificate revocation requests Unicert: CA audit logs in CAO and/or RAEventViewer CERTIFICATE STATUS CHANGE APPROVAL The approval or rejection of a certificate status change request Unicert: PKI component audit logs in CAO and

RAEventViewer Agency: CMS/enrollment portal logs

CA CONFIGURATION Any security-relevant changes to the configuration of the CA CA changes are recorded in CCB, but could be referred to in

CA audit logs as well: CCB: https://opnet.idm.cybertrust.com/ccb Unicert: CA audit log in CAO

ACCOUNT ADMINISTRATION






Auditable Event Recording Mechanism Roles and Subscribers are added or deleted Depending on the type of role and subscriber, this information

can be found in one of these sources: Unicert: CA audit log in CAO CCB: https://opnet.idm.cybertrust.com/ccb ETMS: https://etms.verizon.com/ticketing/ Windows OS: Event Logs: Security Linux OS: /var/log/audit/audit.log Linux OS: /var/log/messages Linux OS: /var/log/secure Linux OS: /var/log/bash Federal Agency CMS and Enrollment Portal logs

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

Depending on the type of role and subscriber, this information can be found in one of these sources: ETMS: https://etms.verizon.com/ticketing/ CCB: https://opnet.idm.cybertrust.com/ccb Unicert: CA audit log in CAO Windows OS: Event Logs: Security Linux OS: /var/log/audit/audit.log Linux OS: /var/log/messages Linux OS: /var/log/secure Linux OS: /var/log/bash Federal Agency CMS and Enrollment Portal logs

CERTIFICATE PROFILE MANAGEMENT All changes to the certificate profile Depending on the nature of the change, this information can

be found in one of these sources: Unicert: CA audit log in CAO CCB: https://opnet.idm.cybertrust.com/ccb ETMS: https://etms.verizon.com/ticketing/

REVOCATION PROFILE MANAGEMENT All changes to the revocation profile Clarification needed, because Unicert per say does not use a

revocation profile. Depending on the nature of the change, relevant information can be found in one of these sources: Unicert: CA audit log in CAO CCB: https://opnet.idm.cybertrust.com/ccb ETMS: https://etms.verizon.com/ticketing/

CERTIFICATE REVOCATION LIST PROFILE MANAGEMENT All changes to the certificate revocation list profile Depending on the nature of the change, this information can

be found in one of these sources: CCB: https://opnet.idm.cybertrust.com/ccb ETMS: https://etms.verizon.com/ticketing/ Unicert: CA audit log in CAO

MISCELLANEOUS Appointment of an individual to a Trusted Role One or more of the following sources record CA trusted role

appointment information: CCB: https://opnet.idm.cybertrust.com/ccb ETMS: https://etms.verizon.com/ticketing/ Sharepoint: https://teamsites.vzbi.com/sites/mss/iam/default.aspx

Designation of personnel for multiparty control One or more of the following sources record designation information: CCB: https://opnet.idm.cybertrust.com/ccb ETMS: https://etms.verizon.com/ticketing/ Windows OS: Event Logs: Security Linux OS: /var/log/audit/audit.log Linux OS: /var/log/messages Linux OS: /var/log/secure Linux OS: /var/log/bash Federal Agency Sharepoint: https://teamsites.vzbi.com/sites/mss/iam/default.aspx













https://teamsites.vzbi.com/sites/mss/iam/default.aspx




Auditable Event Recording Mechanism Installation of the Operating System One or more of the following sources record installation

information: CCB: https://opnet.idm.cybertrust.com/ccb ETMS: https://etms.verizon.com/ticketing/

Installation of the CA One or more of the following sources record installation information: CCB: https://opnet.idm.cybertrust.com/ccb ETMS: https://etms.verizon.com/ticketing/

Installing hardware cryptographic modules One or more of the following sources record installation information: CCB: https://opnet.idm.cybertrust.com/ccb ETMS: https://etms.verizon.com/ticketing/

Removing hardware cryptographic modules CCB: https://opnet.idm.cybertrust.com/ccb Destruction of cryptographic modules CCB: https://opnet.idm.cybertrust.com/ccb System Startup CCB: https://opnet.idm.cybertrust.com/ccb Logon Attempts to CA Applications One or more of the following sources record this information:

Windows OS: Event Logs: Security Linux OS: /var/log/audit/audit.log Linux OS: /var/log/messages Linux OS: /var/log/secure Linux OS: /var/log/bash Federal Agency Unicert: PKI component audit logs (CAO, RAEventViewer, KAO)

Receipt of Hardware/Software Sharepoint: https://teamsites.vzbi.com/sites/mss/iam/default.aspx

Attempts to set passphrases One or more of the following sources record this information: Windows OS: Event Logs: Security Linux OS: /var/log/audit/audit.log Linux OS: /var/log/messages Linux OS: /var/log/secure Linux OS: /var/log/bash Federal Agency

Attempts to modify passphrases One or more of the following sources records this information: Windows OS: Event Logs: Security Linux OS: /var/log/audit/audit.log Linux OS: /var/log/messages Linux OS: /var/log/secure Linux OS: /var/log/bash

Backing up CA internal database Oracle logs: SYS.AUD$ table or ALERT.LOG file Restoring CA internal database Oracle logs: SYS.AUD$ table or ALERT.LOG file File manipulation (e.g., creation, renaming, moving) One or more of the following sources record this information:

Windows OS: Event Logs: Security Linux OS: /var/log/audit/audit.log Linux OS: /var/log/messages Linux OS: /var/log/secure Linux OS: /var/log/bash

Posting of any material to a repository Need clarification which repository. CA publishes CRL to local directory on the CA server. This is recorded in Unicert CA audit logs. Validation data posting is also referred to in CCB: https://opnet.idm.cybertrust.com/ccb

Access to CA internal database One or more of the following sources record this information: Linux OS: /var/log/audit/audit.log Linux OS: /var/log/messages Linux OS: /var/log/secure Linux OS: /var/log/bash Oracle logs: SYS.AUD$ table or ALERT.LOG file

All certificate compromise notification requests ETMS: https://etms.verizon.com/ticketing/













Auditable Event Recording Mechanism Loading tokens with certificates Clarification is needed if this relates to subscriber tokens or

CA HSM tokens. Loading a token into HSM, which protects PKI key, is recorded in one or more of the following: safe container manual log CCB: https://opnet.idm.cybertrust.com/ccb ETMS: https://etms.verizon.com/ticketing/

Shipment of Tokens This is most likely referring to Subscriber tokens. VZ HSM tokens would be in sharepoint. Purchasing document stored at sharepoint https://teamsites.vzbi.com/sites/mss/iam/default.aspx

Zeroizing tokens CCB: https://opnet.idm.cybertrust.com/ccb Re-key of the CA CCB: https://opnet.idm.cybertrust.com/ccb

Unicert CA audit log via CAO Configuration changes to the CA server involving: CCB: https://opnet.idm.cybertrust.com/ccb - Hardware CCB: https://opnet.idm.cybertrust.com/ccb - Software CCB: https://opnet.idm.cybertrust.com/ccb - Operating System CCB: https://opnet.idm.cybertrust.com/ccb - Patches CCB: https://opnet.idm.cybertrust.com/ccb - Security Profiles CCB: https://opnet.idm.cybertrust.com/ccb PHYSICAL ACCESS/SITE SECURITY Personnel Access to room housing CA Datacenter cage access log available upon request from the

datacenter security team Access to the CA server Datacenter cage access log available upon request from the

datacenter security team Known or suspected violations of physical security One or more of the following sources contain this information:

Culpeper/Irving guard desk logs Datacenter cage access log Incident report posted at sharepoint: https://teamsites.vzbi.com/sites/mss/iam/default.aspx

ANOMALIES Software Error conditions One or more of the following sources contains this

information: Unicert PKI component audit or service logs Windows OS: Event Logs: Security Linux OS: /var/log/audit/audit.log Linux OS: /var/log/messages Linux OS: /var/log/secure Linux OS: /var/log/bash

Software check integrity failures One or more of the following sources contain this information: Unicert PKI component audit or service logs Windows OS: Event Logs: Security Linux OS: /var/log/audit/audit.log Linux OS: /var/log/messages Linux OS: /var/log/secure Linux OS: /var/log/bash

Receipt of improper messages Clarify what qualifies as improper message. One or more of the following sources could contain this information: Unicert PKI component audit or service logs Windows OS: Event Logs: Security Linux OS: /var/log/audit/audit.log Linux OS: /var/log/messages Linux OS: /var/log/secure Linux OS: /var/log/bash

Misrouted messages One or more of the following sources contain this information: Unicert PKI component audit or service logs Windows OS: Event Logs Linux OS: /var/log/audit/audit.log Linux OS: /var/log/messages Linux OS: /var/log/secure Linux OS: /var/log/bash













Auditable Event Recording Mechanism Network attacks (suspected or confirmed) One or more of the following sources contain this information:

ETMS: https://etms.verizon.com/ticketing/ Firewall logs

Equipment failure One or more of the following sources contain this information: ETMS: https://etms.verizon.com/ticketing/ Logs: Windows Event Logs: System Logs: Linux /var/log/messages

Electrical power outages Normally a datacenter provides seamless power failover. If all backup power should fail, following sources will record the event: ETMS: https://etms.verizon.com/ticketing/ Incident report posted at sharepoint: https://teamsites.vzbi.com/sites/mss/iam/default.aspx

Uninterruptible Power Supply (UPS) failure Normally a datacenter provides seamless power failover. If all backup power should fail, following sources will record the event: ETMS: https://etms.verizon.com/ticketing/ Incident report posted at sharepoint: https://teamsites.vzbi.com/sites/mss/iam/default.aspx

Obvious and significant network service or access failures ETMS: https://etms.verizon.com/ticketing/ Violations of Certificate Policy posted at sharepoint:

https://teamsites.vzbi.com/sites/mss/iam/default.aspx Violations of Certification Practice Statement posted at sharepoint:

https://teamsites.vzbi.com/sites/mss/iam/default.aspx Resetting Operating System clock One or more of the following sources contain this information:

CCB: https://opnet.idm.cybertrust.com/ccb Windows OS: Event Logs Linux OS: /var/log/audit/audit.log Linux OS: /var/log/messages Linux OS: /var/log/secure Linux OS: /var/log/bash

5.4.2 Frequency of Processing Data

Verizon’s Security Officer (or the Contracting Agency’s RAs) or a person nominated by the security officer will review the audit log on a regular basis, but no less frequently than once every two months. Such reviews involve verifying that the log has not been tampered with and briefly inspecting all log entries. Verizon (or the Contracting Agency’s RA) will conduct a more thorough investigation of any alerts or irregularities in the logs. In addition, a statistically significant portion (approximately 5%) of the security audit data generated by the CA (or RA) since the last review shall be examined.

All significant events will be explained in an audit log summary and any actions taken as a result of these reviews will be documented.

5.4.3 Retention Period for Security Audit Data

Verizon and the Contracting Agency RAs will retain audit logs onsite until reviewed, in addition to being retained in the manner described below. The individual who removes audit logs from the CA system is an official different from the individuals who, in combination, command the CA signature key. These tasks and separation of duties are described in Verizon’s Standard Operating Procedures and the SSP Trusted Roles Document.











5.4.4 Protection of Audit Log

The operating procedures and configuration of Verizon’s CA system ensures that security audit data will not be open for reading or modification by any human, or by any automated process, other than those that perform security audit processing. Only authorized people archive or delete security audit data. Security audit data may be made available for review by appropriate individuals as provided in the disclosure of confidential information provisions contained in Section 9.4 Operating procedures have been developed and implemented to protect archived data from deletion or destruction before the end of the security audit data retention period (note that deletion requires modification access). Verizon IAM uses a combination of labelling archived materials along with proper personnel training procedures, to properly label designated materials or archives to NOT be destroyed prior to the end of the retention period. Security audit data is moved to a safe, secure storage location separate from the the location where the data was generated. Security data is not removed from the operational environment, rather it is retained at the primary and or DR sites. CA audit data accumulates in the CA database and is retained at that location until the CA is decommissioned. Other OS and application logs are also retained at the primary and DR operation sites.

5.4.5 Audit Log Backup Procedures

Verizon’s audit logs are backed-up in a secure manner in accordance with the Verizon Standard Operating Procedures. Audit logs and audit summaries are backed up at least monthly. A copy of the audit logs is sent offsite on a monthly basis.

5.4.6 Audit Collection System (Internal vs. External)

Automated log collection is managed outside the SSP CA systems. When the CA system is powered up, the automated log collection is activated and collects the logs periodically. Splunk tool is used for automated log collection. Upon Startup the splunkd service sends a signal to the input to begin collecting the data. Similarly, when Splunk is shut down cleanly, the service sends a different signal to the inputs to tell them to stop collecting data, clean up and exit. The configuration file that ensures this automated process is ‘inputs.conf’ located at:

%splunk_home%\etc\system\local

Verizon CAs audit logs are stored in a database (clp-fed-iamdb-01) with autoextend capabilities to prevent log overflow. CA logs are cumulative and backed up on daily basis.

If it becomes apparent that the audit system has failed, and the integrity of the system or confidentiality of the information protected by the system is at risk, VZ SSP Auditor will launch an investigation to confirm whether a failure has occurred, and to what extent any system or data has been impacted. Severity of the incident is then brought to the attention of the Verizon PMA, which will determine if the operations have to be suspended until the problem has been remedied. The Verizon PMA will also determine at which point FPKIPA is to be notified after the incident and the next steps Verizon intends to undertake to resume operations.

5.4.7 Notification to Event-Causing Subject

No stipulation.

5.4.8 Vulnerability Assessments

Verizon performs routine self-assessments of security controls consistent with the Verizon Internal Audit Procedures and Risk Management Procedures.

5.5 Records Archival

5.5.1 Types of Events Archived

Verizon’s records archival process is stipulated in the Verizon Standard Operating Procedures. This section of the CPS describes Verizon’s, the Contracting Agency’s and the RA’s process. To the extent the Contracting Agency is maintaining archive information, the details surrounding the types of information retained and the policies and procedures followed will be specified in the Contracting Agency’s RPS. The archive records are sufficiently detailed to determine the proper operation of Verizon’s SSP CA(s) and the validity of any certificate (including those revoked or expired) issued by the CA(s). At a minimum, the following data is recorded for archive:

• Verizon CA accreditation • The Federal Common Policy (Current and Revised) • The Certification Practice Statement (Current and Revised) • Contractual obligations with Contracting Agency • Contracting Agency’s Registration Practice Statement (If Applicable) • Key Recovery Practice Statement (If Applicable) • Other agreements concerning operation of the Verizon CAs • System and equipment configuration • Modifications and updates to system or configuration • Certificate requests • All certificates issued and/or published • Record of Re-key • Revocation requests • Subscriber identity Authentication data as per Section 3.1.9 • Subscriber agreements • Documentation of receipt of tokens • All CARLs and CRLs issued and/or published • Other data or applications to verify archive contents • Compliance Auditor reports • Changes made to the Audit parameters, e.g., audit frequency, type of event audited • Attempts to delete or modify the Audit logs • CA key generation activity (not mandatory for single-session or one-time use symmetric

keys) • Access to certificate subject private keys retained within the CA for key recovery

purposes • Changes to the trusted public keys, including additions and deletions. • Export of private and secret keys (excluding keys used for a single session or message) • Approval or rejection of a certificate status change request • Appointment of an individual to a Trusted Role • Destruction of cryptographic modules • Certificate compromise notifications • Remedial action taken as a result of violations of physical security • Violations of Certificate Policy • Violations of Certificate Practice Statement

In addition, Verizon will archive subscriber private encryption keys for business continuity purposes. Verizon supports key archive services on behalf of Contracting Agencies at either Verizon’s secure facilities or at a location specified by the Contracting Agency. In general, Verizon will archive encipherment keys based upon the configuration of the Subscriber’s registration profile. Verizon uses PKIX and CRMF (RFC 2511) to perform key archiving. When a PKIXCertificateRequest message arrives at the CA that has a key encrypted using the [CRMF] archive option, the CA issues the certificate, and sends the request to be handled by the ArchiveAgent which writes the request to the database. The agent will decrypt each key, and re-encrypt it and send the Archive Request Message to the Archive Server. The Archive Server decrypts the private keys from the [PKIX] request message, and matches them with their issued certificates, and then archives them to the database. Once completed, the Archive Server sends a PKIX confirmation message to the CA that the archiving was completed. Key Recovery Officers (KROs) request key recovery on behalf of Subscribers and other authorized persons. The KRO verifies that the person requesting recovery of the Subscriber’s key is authorized to receive that key. The KRO is also responsible for securely returning the requested key to the Subscriber or other authorized person. When the Contracting Agency manages archived keys at its facilities, these procedures will be described in the agency’s KRPS.

5.5.2 Retention Period for Archive

Verizon will keep the archive records for a minimum of 10 years and 6 months without any loss of data. Such records will be transferred to a record keeping system and retained as either retrievable computer based messages or paper-based documents. Contracting Agency’s and their RAs will impose similar archiving requirements for those records (such as subscriber related information) maintained at the RA site.

Note: Verizon CAs currently do not support the stricter data retention requirements only relevant for certificates issued under id-fpki-common-High policy.

5.5.3 Protection of Archive

All archive collection locations are only accessible to CA Administrators or CA Auditors, whose names are kept up to date in “Verizon IAM Federal SSP Trusted Roles document located in the IAM SharePoint site at:

https://teamsites.vzbi.com/sites/mss/iam/Federal%20SSP%20Audits/Forms/AllItems.aspx# Permission to wite, modify and delete are granted by the Verizon SSP PMA only after Verizon SSP PMA has interviewed and determined the ‘need to know’ is there. Logs are maintained to provide an audit trail of who has accessed the archive, the purpose of the access and when the access occurred. Verizon’s archived records may be moved to another medium (e.g., paper documents may be converted to scanned digital images). The contents of the archive will not be released except (1) in accordance with the Contracting Agency’s policy, or (2) as required by law. Records of individual transactions may be released upon request of any Subscriber involved in the transaction or their legally recognized agents. Archive media is stored in a safe, secure storage facility separate from Verizon’s CA operations as specified in Verizon’s Security Procedures and Standard Operating Procedures. Verizon archives audit data to prevent data loss due to corruption over a longer period of time. All data is kept on the primary site and is replicated to the DR site for backup. The replicated data is


tested at least once a year during the annual Disaster Recover Test and documented in the Contigency.

Verizon will keep the archive records for a minimum of 7 years without loss of any data. US Federal customers will have the retention period lengthened to support National Archive and Records Administration data rention of 10 years and 6 months.

5.5.4 Archive Backup Procedures

Verizon follows industry best practices to back-up the archive as specified in the Security Procedures and Standard Operating Procedures.

5.5.5 Requirements for Time-Stamping of Records

Timestamping of the CA signing records are enforced by the CA application itself. Timestamping of the OS events utilize internal Network Time Protocol (NTP) based NIST time services and the Spectracom Netclock 9289 GPS Synchronization. Network Time Protocol (NTP) is used for each device’s internal system clock and is synchronized to Spectracom Netclock 9289 GPS at least hourly to ensure that all audit record time stamps are within milliseconds of each other

5.5.6 Archive Collection System (Internal or External)

Verizon collects both paper-based and electronic Archive data and this material is maintained at a site local to Verizon or to the Contracting Agency’s RAs. Archive data is collected in the manner most expedient for Verizon. (See Section 5.5.7)

5.5.7 Procedures to Obtain and Verify Archive Information

Verizon’s ’(SOP Sec 27) Archiving and Auditing’ standard operating procedure details how the archive information is created, verified, packaged, transmitted and stored. These policies and procedures are updated and augmented to reflect the legal and best practice requirements for managing and protecting electronic records. Records management personnel and practices are employed to produce and maintain records retention policies and schedules, and to oversee and monitor the preservation of the information for the full life cycle of the data. Verizon has implemented transmission and access security controls for meeting the requirements of preserving integrity, protecting confidentiality, and establishing ongoing authenticity of the records. Verizon creates audit trails for each access or other event or action that could potentially result in modification, loss, misuse or destruction of an electronic record. Quality control and assurance steps are an integral part of Verizon’s data acquisition and capture processes, including image scanning as well as electronic receipt and creation, to ensure that accurate and complete records are being stored.

5.6 Key Changeover

When Verizon SSP CAs keys are rolled-over, Verizon deprecates the use of the old key for all key signing procedures and commences using the new key to sign certificate requests and audit records from the moment the new key is generated. All instances of CA keys, whether they are old or new, deprecated or archived, remain protected by a FIPS certified HSM device at all times, until the archive retention period is over. After retention period is exceed the CA keys are destroyed using HSM OEM suggested procedures. Verizon’s CA signing key will have the validity period described in Section 6.3.2. Verizon protects all CA keys regardless of their status

including the physical security controls specified in Section 5.1.2 and the multi-person control provisions specified in Section 6.2.2. Once the private signing key is changed, only the new key will be used for certificate signing purposes. When Verizon updates its private signature key and thus generates a new public key, such event is managed as a project with a dedicate Verizon Project Manager. As part of this key update project management, Verizon SSP notifies the FPKIPA and the PMA of the Agency whose subscribers might be impacted by the CA key replacement process. Verizon maintains communication with the third parties via conference calls, through emails, and written memos, and requires third party acknowledgement and agreement at every stage of the key changeover process. If the Common Policy Root CA key rollover process generates cross certificates between the old and the new keys, Verizon will rely on such certificates to establish trust between the old and the new keys. Alternatively, the SSP will request a new cross certificate for its CAs and update their chain validation with the new Root CA certificate.

5.7 Compromise and Disaster Recovery

5.7.1 Incident and Compromise Handling Procedures

• Verizon SSP PMA will notify the FPKIPA via email and/or phone if any CAs operating under this policy experience the following:suspected or detected compromise of the CA systems;

• suspected or detected compromise of a certificate status server (CSS) if (1) the CSS certificate has a lifetime of more than 72 hours and (2) the CSS certificate cannot be revoked (e.g., an OCSP responder certificate with the id-pkix-ocsp-nocheck extension);

• physical or electronic penetration of CA systems;

• successful denial of service attacks on CA components; or

• any incident preventing the CA from issuing a CRL within 48 hours of the issuance of the previous CRL.

The Federal PKI Policy Authority will take appropriate steps to protect the integrity of the Federal PKI and Verizon will work closely with them to coordinate and execute recommended actions. Verizon will notify affected customers.

Verizon shall reestablish operational capabilities as quickly as possible following these procedures:

• Confirm that the FPKIPA has given approval for Verizon to reestablish operational capability.

• Start the databases

• Insert the appropriate Remote Operator cards into the HSMs

• Start all CA services

• Publish new CRLs and validate that CDPs have been updated

• Test WebRAO and Autoenroll functions

• Remove Remote Operator cards from the HSMs

• Notify FPKIPA and all affected customers that services are operational.

Up to date FPKIPA contact information can be obtained from:

https://www.idmanagement.gov/

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

When Verizon computing resources, software, and/or data are corrupted, Verizon CAs operating under the federal Common Policy shall respond as follows:

• In the event of hardware, software or data corruption, Verizon will reestablish CA operations as quickly as possible. The OA first makes an attempt to determine which part of the PKI system suffered corruption. OA will then replace the corrupted hardware or reinstall the corrupted software at the primary site or provide CA services from a backup location located in Irving, TX, while adhering to CPS and contract requirements. Built in PKI integrity checks performed during startup of every CA service help to establish whether the CA data or CA keys were corrupted. The OA inspects the CA audit logs, CA service logs, CA certificate reports, to confirm if any data or key corruption has occurred. The OA also generates a new CRL and verifies that it contains historical revocation data. Before returning to operation, Verizon will ensure that the system’s integrity has been fully restored and validated.

• If the CA signature keys are not destroyed, Verizon’s CA operation shall be reestablished. The priority will be to reestablish CA operation so it can generate updated certificate status information within the CRL issuance schedule specified in section 4.9.7. Verizon will notify the FPKIPA in the event of such an occurrence.

• If the CA signature keys are destroyed, CA operation shall be reestablished as quickly as possible, giving priority to the generation of a new CA key pair. The CA operation will be reestablished at the primary site or at the backup site following the procedures specified in Business Continuity Plan. If all CA keys are destroyed, the OA will establish a new CA.

5.7.3 CA Private Key Compromise Procedures

In the event that Verizon’s CA key is compromised, the Operational Authority (OA) will take the following steps:

• Immediately inform the following entities:

o the FPKIPA o any superior or cross-certified CAs o any entities known to be distributing the compromised CA certificate o any subscribers issued from or chained to the compromised CA. The client

contact list is maintained by the IAM-Support Desk which can be reached at: [email protected] or phone: 1-800-284-4130

mailto:[email protected]

• Generate new CA keys for the existing compromised CA in accordance with Section 6.1.1.1, and submit a request to be signed by the Federal Root CA.

As stated in section 6.1.4, Verizon will make the newly signed intermediary CA public key available publicly at:

http://aia1.ssp-strong-id.net/CA/<name-of-the-CA> (e.g., VZ-SSP-CA-A2.p7c)

Verizon, as a managed service provider, does not distribute CA private keys.

In the event that the OA or the relying party finds it necessary to distribute a public key securely, it can be done in one of the following ways: Secure SSL session to a well-known Verizon SSP web page; Through all Verizon Contracting Agency RAs; Through email with direct validation of the certificate through an online web page with the

CA’s fingerprint or thumbprint validation; or Through direct hand delivery to the designated personnel of the Contracting Agency. Verizon will either automatically renew Subscriber certificates under the new key pair, or Verizon will require Subscribers to repeat the initial certificate application process.

5.7.4 Business Continuity Capabilities after a Disaster

Verizon does not host the Common Policy Root CA, therefore, the requirement to reconstitute the CA within 6 hours does not apply.

At a minimum, other CAs which Verizon does operate will have recovery procedures in place to reconstitute the CA within 72 hours in the event of a failure. Any failure of such contingency planning and disaster recovery capabilities to achieve this aim shall be treated as Force Majeure, unless the failure results from a breach by Verizon of its obligation under this Section to implement procedures which are consistent with reasonable industry practices. Verizon’s primary and backup/DR sites operate in hot/hot manner for the CRL and OCSP services. Certificate lifecycle services are available on standby mode at the backup/DR site.

In the case of a disaster whereby Verizon’s CA installation is physically damaged and all copies of the CA signature key are destroyed as a result, Verizon will follow the policies and procedures specified in its Business Continuity Plan to mitigate the consequences of such events. In particular, Verizon will notify the FPKIPA at the earliest feasible time, and the FPKIPA will take whatever action it deems appropriate. The continuity plan is available as “Verizon SSP Contingency Plan” at Verizon IAM sharepoint site.


Relying parties shall use their own judgment on whether to continue to use certificates signed with the destroyed private key pending reestablishment of CA operation with new certificates. Destruction of Verizon’s private key will not be construed as relieving Relying Parties of their obligations under Section 1.35 and Section 9.6.4.

5.8 CA or RA Termination

If Verizon terminates CA operations before all certificates have expired, Verizon SSP will advise the relying parties, who obtained credentials from the terminated CA, of the termination activity., and will offer to surrender the CA signing keys to the FPKIPA. Notice will be provided through e-mail, first class mail or any other commercially reasonable method. If the FPKIPA does not take

http://aia1.ssp-strong-id.net/CA/%3cname-of-the-CA


possession of the CA materials, Verizon will provide archived date to an archive facility as described in its standard operating procedure, Archiving and Auditing (SOP 27 stored in the IAM SharePoint, SOP Documents library) located at:

https://teamsites.vzbi.com/sites/mss/iam/Processes/(SOP%20Sec%2027)%20Archiving%20and%20Auditing.doc

Verizon will collect the CA data and key backups and send them to the offsite archive location for the amount of time required by the Common Policy, which is 10.5 years for medium assurance CAs.

6. TECHNICAL SECURITY CONTROLS

6.1 Key Pair Generation and Installation

6.1.1 Key Pair Generation

6.1.1.1 CA Key Pair Generation

Key pair generation for Verizon CA keys is performed in accordance with Verizon’s CA key generation procedures as described in Verizon’s Standard Operating Procedures. Key Pairs for CAs are generated and stored in Thales nShield hardware modules throughout their entire life time. The Thales modules are configured by the manufacturer and the OA to meet FIPS 140-2 level 3 requirements.

Note: Verizon does not issue certificates under id-fpki-common-High. The process followed by the OA for CA key pair generation creates a verifiable audit trail to establish that the security requirements for procedures were followed. The audit trail also identifies and documents any failures or anomalies in the key generation process, and any corrective actions taken. Each key ceremony follows key protection guidelines specified these documents available in the Verizon SharePoint site: https://teamsites.vzbi.com/sites/mss/iam/Federal%20SSP%20Audits/Forms/AllItems.aspx# • Verizon IAM Key Management Plan document (Verizon_IAM_KMP). The KMP identifies multiperson controls in place over the HSM smartcards, or PINs. • Verizon IAM Federal SSP Trusted Roles document, which identifies the names of OA engineers assigned to particular Admin, Audit, or Operator roles.

• This CPS - Each CA key ceremony is physically or virtually witnessed either by company internal auditor/security officer, who is organizationally separate from the OA, or if contractually required, by an independent third party auditor. Signed key ceremony documents are also available for further audit review. The Verizon IAM Federal SSP Trusted Roles document has up to date list of internal auditors and can be found in the SharePoint site listed above.




6.1.1.2 Subscriber Key Pair Generation

Subscriber’s key pairs are generated: For Certificates issued under the id-fpki-common-policy (Software certificates):

• at the Subscriber's computer and or Web Browser for signature keys; and • at the RA/CA with an approved HSM for key management keys.

For Certificates issued under the id-fpki-common-hardware, id-fpki-common-authentication, id-fpki-common-cardauth, and id-fpki-common-derived-pivAuth-hardware (Hardware certificates):

• at the RA administrator workstation or card management system with an approved FIPS-140 Level 2 HSM for key management keys, and

• directly on a smart card for Signature keys. Subscriber key pair generation may be performed by the Subscriber when software certificates are being issued or by Verizon, or the Contracting Agency’s RA when hardware based certificates are issued. No matter which party performs the key generation, a FIPS approved method is used. In the case of key management certificates, either Verizon or the Contracting Agency RA will generate key pairs and archive the key and certificate in compliance to the requirements for key pair delivery specified in Section 6.1.2. For software certificates, Verizon ensures that only FIPS 140-2 level 1 or greater validated cryptographic modules are used to generate software subscriber key pairs, as well as pseudo-random numbers and parameters used in key pair generation. Any pseudo-random numbers used for key generation material are generated on the HSM device using methods embedded on the device by the HSM manufacturer. Verizon ensures that only FIPS 140-2 level 2 or greater validated cryptographic modules are used to generate hardware subscriber key pairs, as well as pseudo-random numbers and parameters used in key pair generation. Symmetric keys will be generated by means of either software or hardware mechanisms.

Verizon, in conjunction with a Contracting Agency and through the Agency’s RPS, will restrict accepted Cryptographic Service Providers within the browsers to the set defined within the RPS. 6.1.1.3 CSS Key Pair Generation

Verizon MVS keys are protected by Hardware Security Modules which meet the FIPS 140-2 Level 3 requirements. MVS currently uses HSMs manufactured by Thales. The FIPS rating of each HSM version can be verified at:

http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/1401val2016.htm

For the MVS that does not provide status under id-fpki-common-High, the module(s) shall meet or exceed FIPS 140 Level 2.

6.1.1.4 PIV Content Signing Key Pair Generation Cryptographic keying material used by PIV issuing systems or devices for Common PIV Content Signing shall be generated in FIPS 140 validated cryptographic modules. For PIV issuing systems or devices, the module(s) shall meet or exceed FIPS 140 Level 2. Key generation procedures shall be documented.

6.1.2 Private Key Delivery to Subscriber

As stated in Section 6.1.1.2, Verizon does not generate private keys for the Subscriber. The private key is either generated by the Subscriber in their browser (software certificates) or at the RA workstation in the presence of the Subscriber (hardware certificates). In either situation the private key is delivered securely to the Subscriber. Private keys may be delivered electronically using industry standard based PKCS messages over secure protocols which provide equivalent or higher encryption strength than the key being transported or may be delivered on a hardware cryptographic module. In all cases, the following requirements are met:

• Anyone who generates a private signing key for a Subscriber does not retain any copy of the key after delivery of the private key to the Subscriber.

• The private key is protected from activation, compromise, or modification during the delivery process.

• The Subscriber acknowledges receipt of the private key(s). • Delivery is accomplished in a way that ensures that the correct tokens and activation data

are provided to the correct Subscribers.

o For hardware modules, accountability by Verizon or the Contracting Agency’s RA for the location and state of the module is maintained until the Subscriber accepts possession of it.

o For electronic delivery of private keys, the key material is encrypted using a cryptographic algorithm and key size at least as strong as the private key. Activation data is delivered using a separate secure channel.

Verizon or the Contracting Agency’s RA maintains a record of the subscriber’s acknowledgement of receipt of the token. 6.1.3 Public Key Delivery to Certificate Issuer

Where key pairs are generated by the Subscriber or RA, the public key and the Subscriber’s identity are delivered securely to the CA for certificate issuance. The specific nature of this delivery process will depend on the registration process employed by the Contracting Agency and the technology it uses. The Contracting Agency’s RPS will specifically describe the process or processes used. The delivery mechanism used will bind the Subscriber’s verified identity to the public key. Where a cryptographic process is used to achieve this binding, it will be at least as strong as the CA keys used to sign the certificate. Delivery of every signed public key to the subscriber by Verizon SSP CA is protected via TLS 1.2 transport protocol encrypted with the same TLS key strength as the CA key itself, which currently is sha256, key size 2048, AES256

6.1.4 CA Public Key Delivery to Relying Parties

Verizon does not distribute self-signed CA certificates. Verizon distributes its CA cross-certificates, intermediary CA certificates, or issuing CA certificates through publication in online HTTP repositories: http://aia1.ssp-strong-id.net/CA/<Agency_or_Provider_Acronym>-SSP-CA-<CA_Version>.p7c For instance, Verizon SSP top level crosscertificate is available at http://aia1.ssp-strong-id.net/CA/VZ-SSP-CA-A2.p7c

http://aia1.ssp-strong-id.net/CA/%3cAgency_or_Provider_Acronym%3e-SSP-CA-%3cCA_Version%3e.p7c

6.1.5 Key Sizes

Certificates issued under this CPS use RSA PKCS#1, RSASSA-PSS, or ECDSA signatures. Certificates also meet additional restrictions on key sizes and hash algorithms as detailed below. Certificates issued under this policy contain RSA public keys or elliptic curve public keys.

Verizon’s SSP trusted certificates which expire before January 1, 2031 have a key size of 2048 or 3072 bits for RSA or 256 or 384 bits for elliptic curve and are signed with the corresponding private key. Trusted certificates expiring after January 1, 2031 will have key size 3072 bits for RSA or 256 or 384 bits for elliptic curve and be signed with the corresponding private key.

The CAs Verizon uses to generate certificates and CRLs under this policy use signature keys of 2048 or 3072 bits for RSA and 256 or 384 bits for elliptic curve algorithms. Certificates that expire after December 31, 2030 shall be generated with 3072 bit keys for RSA and 256 or 384 bit keys for elliptic curve algorithms.

Verizon CAs that generate certificates and CRLs under this policy shall use the , SHA-256, or SHA-384 hash algorithm when generating digital signatures. RSA signatures on certificates and CRLs that are issued after December 31, 2010 shall be generated using SHA-256; ECDSA signatures on certificates and CRLs shall be generated using, SHA-256, or SHA-384, as appropriate for the key length.

Where implemented, the MVS system signs OCSP responses using the same signature algorithm, key size, and hash algorithm which is used to sign CRLs, as described in previous CA key size and key algorithm section. End entity certificates issued under id-fpki-common-devices that expire before December 31, 2030 shall contain RSA public keys that are 2048 and 3072 bits or elliptic curve keys that are 256 or 384 bits. End entity certificates issued under id-fpki-common-devices that expire after December 31, 2030 shall contain RSA public keys that are 3072 bits or elliptic curve keys that are 256 or 384 bits.

All Verizon SSP CAs are configured to enforce the following key sizes and key algorithms in end entity certificates:

• id-fpki-common-device certificates that expire on or after December 31, 2010 contain RSA public keys with key size 2048 or 3072 bits, and or elliptic curve keys that have a key size 256 or 384 bits. Certificates that expire after December 31, 2030 shall contain RSA public keys that have key size 3072 bits or elliptic curve keys with key size 256 or 384 bits.

• id-fpki-common-authentication certificates contain RSA public keys that are at least 2048 bits in length or elliptic curve keys that are 256 bits in key size.

• id-fpki-common-derived-pivAuth-hardware certificates RSA public keys that are at least 2048 bits in length or elliptic curve keys that are 256 bits in key size.

• id-fpki-common-derived-pivAuth contain RSA public keys that are at least 2048 bits in length or elliptic curve keys that are 256 bits in key size.

• id-fpki-common-cardAuth certificates contain RSA public keys that are at least 2048 bits in length or elliptic curve keys that are 256 bits.

• id-fpki-common-policy certificates shall contain RSA public keys that are 2048 or 3072 bits or elliptic curve keys that are at least 256 or 384 bits.

• id-fpki-common-hardware shall contain RSA public keys that are 2048 or 3072 bits or elliptic curve keys that are at least 256 or 384 bits.

Where certificates are issued to satisfy FIPS 201 requirements, implementations are limited to SHA-256 and SHA-384 for ECDSA.

Whenever Verizon or the Contracting Agency (and its RAs) use TLS or Verizon Betrusted RAO Server Protocol ( BRSP) to accomplish any of the requirements of the Common Policy, this CPS or the RPS, then the symmetric key will be at least 2048 or 3072 bit RSA or 256 or 384 bits elliptical curve keys for the asymmetric keys with expiration prior to December 31, 2030. TLS certificates expiring after December 31, 2030 will only support 3072 bit RSA or 256 or 384 bits elliptical curve keys. Appendix A of this CPS contains certificate profiles for all commonly issued certificate types governed by this policy. Certificate profiles mentioned in the appendix A are based on the “Common Policy Certificate and CRL profile <date-n-version>.pdf”, which is available at www.idmanagement.gov site. Verizon CAs that generate certificates and CRLs under this policy shall use the SHA-256, or SHA-384 hash algorithm when generating digital signatures. RSA signatures on certificates and CRLs that are issued after December 31, 2010 shall be generated using SHA-256; ECDSA signatures on certificates and CRLs shall be generated using, SHA-256, or SHA-384, as appropriate for the key length. As of January 2011, Verizon CAs governed by this CPS no longer generate certificates using SHA1 algorithm.

6.1.6 Public Key Parameters Generation and Quality Checking

Public key parameters will always be generated and checked in accordance with the standard that defines the cryptographic algorithm in which the parameters are to be used. If standard key parameters are used they will be in accordance with public key parameters prescribed in the Digital Signature Standard (DSS) and are generated in accordance with FIPS 186-2. Elliptic Curve public key parameters will always be selected from the set specified in Section 7.1.3.

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

The use of a specific Verizon certificate is constrained by the key usage extension in the X.509 certificate. All certificates will include a critical key usage extension.

Public keys, which are associated with certificates issued to human subscribers, are to be used only for either digital signing or encrypting, but not both.

SSP CAs operated under this CPS enforce the following key usage rules in the subscriber certificates:

• Only the digitalSignature bit is asserted for certificates with id-fpki-common-authentication, id-fpki-common-derived-pivAuth-hardware, id-fpki-common-derived-pivAuth, or id-fpki-common-cardAuth OIDs.

• both the digitalSignature and nonRepudiation bits are asserted in all other human subscriber certificates that are to be used for digital signing

• keyEncipherment bit is asserted in subscriber certificates containing RSA public keys that are to be used for key transport.

• keyAgreement bit is asserted in subscriber certificates that contain elliptic curve public keys and that are to be used for key agreement.

Subscriber certificate profiles are available in Appendix A of this CPS. Verizon SSP CA’s public keys key usage attribute is configured as follows:

• All CA certificates which verify other certificates assert “Certificate Signing” and “CRL Signing”

• All CA certificates which sign and verify CRL assert “CRL Signing” bit

• CA certificates which verify Online Certificate Status Protocol (OCSP) responses assert the digitalSignature and nonRepudiation bits.

CA certificate profiles are available in Appendix A of this CPS. Device certificate public keys issued by Verizon SSP CAs follow these key usage guidelines: • Certificates may be used for signing, authentication), key management or both • certificates used for digital signatures (including authentication) assert the digitalSignature bit. • certificates that contain RSA public keys that are used for key transport, assert the keyEncipherment bit. • certificates that contain elliptic curve public keys that are to be used for key agreement assert the keyAgreement bit. • certificates used for both digital signatures and key management assert the digitalSignature bit and either the keyEncipherment (for RSA) or keyAgreement (for elliptic curve) bit. • certificates do not assert the nonRepudiation bit. CA certificate profiles are available in Appendix A of this CPS.

CA or subscriber certificates issued under this CPS do not assert dataEncipherment, encipherOnly, and decipherOnly bits in key usage attribute. Content signing certificates with id-fpki-common-piv-contentSigning OID include extended key usage of id-PIV-content-signing (see [CCP-PROF]).

6.2 Private Key Protection and Cryptographic Module Engineering Controls

6.2.1 Cryptographic Module Standards and Controls

The cryptographic modules used by Verizon, the Contracting Agency, RAs and Subscribers shall be validated to a FIPS 140 level identified in this section, or validated, certified, or verified to requirements published by the FPKIPA.

In accordance with FIPS 201, the relevant NIST Guidelines for PIV Card Issuers (PCI) and Derived PIV Credential Issuers are NIST SP 800-79, Guidelines for the Accreditation of PCIs and

Derived PIV Credential Issuers (DPCI), which utilizes various aspects of NIST SP 800-37 and applies them to accrediting the reliability of PCIs and DPCIs.

Verizon performs certificate issuance and does not issue PIV cards. The agency acts as the PIV Card Issuer (PCI) and the Derived PIV Credential Issuer (DPCI) and describes in RPS the credential lifecycle processes following NIST SP 800-79 and NIST SP 800-37 guidelines, as indicated in the CP. The Contracting Agency shall only use PIV Card stock that has been tested and approved by the FIPS 201 Evaluation Program and listed on the GSA Approved Products List (APL). A PIV Card sample shall be submitted to the FIPS 201 Evaluation Program for testing on annual basis by the agency. Verizon SSP CAs do not issue certificates under id-fpki-common-High, and use a FIPS 140 Level 2 or higher validated hardware cryptographic module. Contracting Agency RAs will use a FIPS 140 Level 2 or higher validated hardware cryptographic module as well. Subscribers issued software certificates will use a FIPS 140 Level 1 or higher validated cryptographic module for all cryptographic operations. Subscribers issued certificates under the hardware users’ policy (id-fpki-common-hardware), or one of the hardware authentication policies (id-fpki-common-authentication, id-fpki-common-derived-pivAuth-hardware, or id-fpki-common-cardAuth) will use a FIPS 140 Level 2 or higher validated hardware cryptographic module for all private key operations, e.g. FIPS 201 approved smart cards. Verizon offers MVS which does not provide status information for certificates issued under id-fpki-common-High. Further information on the HSM can be found in section 6.1.1.3.

Public-trusted-serverAuth certs are not supported by this CPS at this time. 6.2.2 Private Key (n out of m) Multi-person Control

The control of Verizon’s SSP CA private key is under dual control. A single person is not permitted to invoke the complete CA signature process or access any cryptomodule containing the complete CA private signing key. The 2 person access control of the online HSM tokens/smartcards and split PINs is described in section 8 of the VZ_Key_Management_Plan available at SharePoint in “Federal SSP Documents” folder: https://teamsites.vzbi.com/sites/mss/iam/Federal%20SSP%20Audits/Forms/AllItems.aspx# Verizon SSP CA’s private keys remain under 2-person control while backed up, because the key is always encrypted by the HSM security world, and it can only be accessed/decrypted when restored from backup into a functioning HSM environment. The same approach applies to keys, which are usually dormant at a DR/backup site until activated during a DR event. Access to CA signing keys is backed up for disaster recovery and is under at least two-person control. The names of the persons assigned to trusted roles and persons participating in the dual control of the CA key are discussed in “Verizon IAM Federal Trusted Roles”, which is also available on SharePoint in the “Federal SSP Documents” folder. This document is made available for inspection during compliance audits. https://teamsites.vzbi.com/sites/mss/iam/Federal%20SSP%20Audits/Forms/AllItems.aspx#

http://www.idmanagement.gov/approved-products-list-apl

http://www.idmanagement.gov/approved-products-list-apl



6.2.3 Private Key Escrow

CA private keys are never escrowed.

Subscriber key management keys may be archived to provide key recovery. If a device has a separate key management key certificate, the key management private key may be escrowed. Further details of Verizon’s method for archiving keys may be described in a Key Recovery Practices Statement (KRPS). In general, Verizon will archive private key management keys to enable the Subscriber or other authorized person to recover encrypted data in the event the Subscriber loses its key management certificate.

During certificate key pair generation, a copy of the Subscriber’s private key management key is made and placed in a secure repository. A Key Recovery Officer (KRO) (generally located local to the RA functions at the Contracting Agency) will receive requests to recover archived keys. The KRO will ensure that the request for key recovery comes from an authorized party. The KRO verifies the requestor’s identity and authorization to make the recovery request and transmits that information to a KRA who will perform the recovery. Key recovery requests may be made by the Subscriber or a third party. The Contracting Agency will specify in a KRPS the parties, in addition to the Subscriber, who may request recovery of the Subscriber’s private encryption key. Delivery of keys will be in a method consistent with Section 6.1.2 of this policy.

Under no circumstances will a subscriber’s signature key be held or archived by Verizon or other related party.

6.2.4 Private Key Backup

6.2.4.1 Backup of CA Private Signature Key

Verizon’s CA private signature keys are backed up under the same multiperson control as the original signature key. These controls and practices are described in section 6.2.2 and in the VZ_IAM_Key_Management_Plan located at the SharePoint site:


CA private keys including signature keys are backed up in the DR location, which is currently located in Irving, TX. Encrypted CA private keys are backed up daily at the primary site in Culpeper, VA, by taking daily backup of the CA virtual server. A backup of the CA keys can be also found on the DR backup CA server at the DR site in Irving Texas. An encrypted copy of the CA key pair is transferred to the backup DR site in Irving, TX shortly after the primary key pair is generated. This process is documented in the CA key ceremony documentation and in change control documentation. All CA PKI keys are accounted for and listed in the CA key inventory document published on SharePoint. A signed copy of the key ceremony document can be obtained from SharePoint. Change control documentation is internally available at: https://opnet.idm.cybertrust.com/ccb

6.2.4.2 Backup of Subscriber Private Keys


Subscriber private signature keys whose corresponding public key is contained in a certificate asserting the id-fpki-common-authentication, id-fpki-common-derived-pivAuth-hardware, or id-fpki-common-cardAuth policy may not be backed up or copied.

All other Subscriber private signature keys may be backed up or copied only when they are held in the subscriber’s control. Backed up subscriber private keys will be encrypted using a symmetric algorithm of consistent strength or stored in a cryptographic module validated at FIPS 140 Level 2. 6.2.4.3 Backup of Subscriber Private Key Management Key

Backed up Subscriber private key management keys will not be stored in plaintext 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 Backup of MVS Private Key

MVS private keys are backed up at Irving, TX DR facility. Inventory of the MVS keys are stored on SharePoint document repository. 6.2.4.5 Backup of Device Private Keys

Agencies may back up or copy device private keys, but they must be held under the control of the device’s human sponsor or other authorized administrator. Backed up device private keys shall not be stored in plaintext form outside the cryptographic module. Storage must ensure security controls consistent with the protection provided by the device’s cryptographic module. 6.2.4.6 Backup of Common PIV Content Signing Key

Verizon requires that the Common PIV Content Signing private signature keys shall be backed up, and the backup copies shall be handled in the same way as the primary keys. At least one one copy of each private signature key is stored in a secondary location. All key instances are required to remain under multi-person control and under the protection of a cryptographic module, using the cryptographic module manufacturer's standard backup procedures. All copies of the Common PIV Content Signing private signature key are generated at the Agency’s Card Management System and are inventoried and accounted for by the RA representatives at the Agency. Backed up private signature keys shall not be exported or stored in plaintext form outside the cryptographic module. Backup procedures are documented as part of the detailed key ceremony and stored in the Verizon SharePoint site in the Key Ceremony Documents library: https://teamsites.vzbi.com/sites/mss/iam/AE/Key%20Ceremony%20Documents/Forms/AllItems.aspx# Each agency RPS shall address the requirements of this section as appropriate. 6.2.5 Private Key Archival

Verizon’s CA private signature keys and the subscriber’s private signatures keys are not archived. This practice is enforced by the built in restriction of the MCS UniCERT PKI product.

https://teamsites.vzbi.com/sites/mss/iam/AE/Key%20Ceremony%20Documents/Forms/AllItems.aspx

https://teamsites.vzbi.com/sites/mss/iam/AE/Key%20Ceremony%20Documents/Forms/AllItems.aspx

MCS UniCERT only allows archival of the encryption certificates, and this feature has to be manually set for each certificate type in the certificate registration template defined in the CA. Subscriber key management keys may be archived to provide key recovery.

6.2.6 Private Key Entry Into or from a Cryptographic Module

CA private keys may be exported from the cryptographic module only to perform CA key backup procedures as described in Section 6.2.4.1. Verizon SSP CA private keys are always protected by the Thales HSM security environment configured to function at FIPS-2 level 3, which prevents export of such key in clear. Subscriber encryption keys, which the agency or relying party chooses to escrow and archive at the Verizon SSP CA site, or recover from the CA Key Archive Server (KAS), are encrypted during transit between the RA site and the Key Archive Server PKI component. Further information can be obtained from the MCS UniCERT product documentation. Protection of symmetric keys used in transport of other private keys is integrated in the Card Management System and PKI CA product code 6.2.7 Private Key Storage on Cryptographic Module

No stipulation beyond that specified in FIPS 140 . 6.2.8 Method of Activating Private Keys

For certificates issued under id-fpki-common-authentication, id-fpki-common-derived-pivAuth-hardware, id-fpki-common-derived-pivAuth, id-fpki-common-policy and id-fpki-common-hardware, the subscriber will be authenticated to the cryptographic token before the activation of the associated private key(s). The methods employed by Verizon and the Contracting Agency for authentication to the token may include, but are not limited to, pass-phrases, PINs or biometrics. Entry of activation data is protected from disclosure (i.e., the data is not displayed while it is entered).

For certificates issued under id-fpki-common-cardAuth, subscriber authentication is not required to use the associated private key. For certificates issued under id-fpki-common-devices, these certificates are stored in software and are expected to self-activate. Where appropriate, a password protection of the software key activation process may be implemented and controlled by a human sponsor.

For certificates issued under id-fpki-common-piv-contentSigning, the PIV card management system will provide a secure activation process using a cryptographic module. PIV CMS systems support key activation with or without requiring a human sponsor or authorized administrator to authenticate to the cryptographic token, provided the activation access controls are conformant with PIV issuance requirements (see [FIPS 201]). Contracting Agencies’ RPS shall describe the method for activating private keys.

6.2.9 Methods of Deactivating Private Keys

The HSMs which protect CA and PKI private keys are operated inside the Federal SSP boundary in secure datacenters as discussed in other sections of the CPS. Only CA administrators are allowed to access the HSM devices logically or physically. The access controls for the HSMs are described in the Verizon CYBSSPS (SSPS) Security Plan document.After use, the private keys activated in cryptographic modules are manually deactivated and active CA sessions on the cryptographic module are cleared using the CA software or HSM software provided methods. The process of deactivation is further discussed in section 5. CA cryptographic modules are handled in the manner described in section 5.1.2 and placed in secure containers by no less than two individuals serving in Trusted Roles.

6.2.10 Method of Destroying Private Keys

Private signature keys are destroyed when they are no longer needed or when the certificates to which they correspond expire or are revoked. Verizon or the Contracting Agency may accomplish this destruction through a “zeroize” command. This zeroize feature is built into the CMS product and used when PIV cards are erased or repurposed. Agency’s CMS documentation can be consulted for further information. The zeroize feature is also built into the Thales HSM product suite, and further discussed in the Key Management Plan or in Thales documentation. Each hardware decommission procedure is described in detail in change control documentation.

Subscriber hardware tokens will not be destroyed unless deemed necessary to remove biometric information stored on the token. Further information regarding destruction of subscriber tokens may be found in the Contracting Agency’s RPS.

Trusted role holders shall collect all primary and backup instances of the CA, RA, and CSS (e.g., OCSP server) private keys and destroy them using the procedures discussed in previous paragraph, when such keys are no longer needed. Subscribers shall either surrender their cryptographic module to CA/RA personnel for destruction or destroy their private signature keys, when they are no longer needed or when the certificates to which they correspond expire or are revoked. Physical destruction of hardware is not required. To ensure access to encrypted data, subscriber private key management keys are secured according to Archive retention requirements as define in section 5.5.2.

6.2.11 Cryptographic Module Rating

See Section 6.2.1. 6.3 Other Aspects of Key-Pair Management

6.3.1 6.3.1 Public Key Archival

Verizon archives certificates as part of its archive procedures which are included as part of the CA and Repository management procedures documented in Verizon’s Standard Operating Procedures.

6.3.2 Usage Periods for the Public and Private Keys

The usage period for Verizon’s CA key pair is a maximum of ten (10) years. The CA private key will be used to generate certificates for at most four (4) years, but may be used to sign CRLS and OCSP responder certificates for the entire usage period.

Part of ongoing internal audit is to verify that a subscriber CA has not been used for more than 4 years for end entity certificate signing, and if the 4 years is approaching, the auditor notifies the PMA board to take action and roll over the key or stand up a new CA. Subscriber or Device public keys in certificates that assert the id-PIV-content-signing OID in the extended key usage extension have a maximum usage period of nine (9) years. The private keys corresponding to the public keys in these certificates have a maximum usage period of three (3) years. Expiration of the id-fpki-common-piv-contentSigning certificate shall be later than the expiration of the id-fpki-common-authentication or id-fpki-common-derived-pivAuth-hardware, or id-fpki-common-derived-pivAuth certificates.

OCSP Responders operating under this CPS and Subscriber public keys have a maximum usage period of three (3) years. Subscriber signature private keys have the same usage period as their corresponding public key. The usage period for subscriber key management private keys is not restricted.

Validity of certificates is defined in the certificate registration template/policy. Certificates templates are defined in the Appendix A of the CPS, and implementation of the registration policies in the CA environment is recorded in the change control system. Settings embedded in the registration policies can be verified during audit.

6.4 Activation Data

6.4.1 Activation Data Generation and Installation

Verizon’s CA activation data may be user-selected (by each of the multiple parties holding that activation data) and the process is detailed in the VZ_IAM_Key_Management_Plan to which the SharePoint link is provided below. If the activation data is transmitted, it will be via an appropriately protected channel, and distinct in time and place from the associated cryptographic module.

RA and Subscriber activation data may be user-selected. The strength of the activation data shall meet or exceed the requirements for authentication mechanisms stipulated for Level 2 in FIPS 140-2. If the activation data is transmitted, it will be via an appropriately protected channel, and distinct in time and place from the associated cryptographic module. Verizon transmits such information through encrypted channels. The VZ_IAM_Key_Management_Plan is located in the IAM Sharepoint site at:


6.4.2 Activation Data Protection

As discussed in section 5.1.6 and in the KMP, data materials used to unlock private CA, MVS, or KAS keys is protected from disclosure by a combination of cryptographic and physical access control mechanisms. Smartcards or tokens, unless in use, are always locked in government rated fireproof safes at secure locations. Activation data like the smartcard PINs can be memorized, and written down copies are physically stored in the safes along with the physical tokens. PINs that are used for day-to-day OA activities can be also stored in online encrypted file system, as indicated in the VZ-IAM-KMP. PINs used to unlock subscriber keys on the PIV cards are memorized. 6.4.3 Other Aspects of Activation Data

No stipulation.


6.5 Computer Security Controls

6.5.1 Specific Computer Security Technical Requirements Verizon and the Contracting Agency (or its RAs) have implemented the following computer security functions in the operating system, or through a combination of operating system, software, and physical safeguards:

• Authenticated logins - Implemented by Operating systems, Databases, PKI application software and LDAP directory software.

• Discretionary Access Control - Implemented by Operating System and Applications

• A security audit capability - Implemented by Operating systems, PKI applications and physical security

• Restricted access control to CA services and PKI roles - Implemented by Physical security, Operating system, Databases and PKI applications

• Enforced separation of duties for PKI roles - Implemented by Physical security, Operating system, and PKI application software

• Identification and authentication of PKI roles and associated identities - Implemented by Operating System, Databases, and PKI Applications

• Prohibited object reuse or require separation for CA random access memory - Implemented by the Operating system

• Use of cryptography for session communication and database security - Implemented by Operating System and “Configurable” at the PKI application

• Archive CA history and audit data - Implemented by Operating System, and PKI application software

• Self-test of security-related CA services - Implemented by Crypto devices

• A trusted path for identification of PKI roles and associated identities - Implemented by PKI application software

• A recovery mechanism for keys and the CA system - Implemented by Physical security

• Domain integrity boundaries enforced for security-critical processes. - Implemented by Physical safeguards and Applications software

In the event Verizon’s CA equipment is hosted on evaluated platforms in support of computer security assurance requirements, the system (hardware, software, operating system) will, when possible, operate in an evaluated configuration. At a minimum, such platforms will use the same version of the computer operating system as that which received the evaluation rating.

For CSS systems operating under this CPS, the following computer security functions are in place:

• CSS server operates within the Federal SSP security boundary, access is only granted to authorized CA Admins. Up to date CA Admins list is maintained in the Trusted Roles document available on the IAM SharePoint site:


CA Administrators must successfully authenticate with their personal credentials before access is granted.



• As described in the ATO documentation, CSS system resides inside of a network boundary secured by firewalls and access list.

• Daily system backups ensure recoverability of the CSS system. To ensure 99.9 SLA, CSS services are offered from 2 sites operated in a hot-hot configuration.

All communications between any PKI trusted role and the CA shall be authenticated and protected from modification. The PKI components of the CA service are all operated on virtual servers, hosted at a secure datacenter.

Access to the virtual PKI servers is granted via a secure virtual management workstation over an encrypted VPN. Identity of a trusted engineer is first verified at the VPN level using 2-factor authentication. The engineer’s identity is also verified at the secure management workstation via Identity, Policy, Audit (IPA) personal credential authentication system. The same IPA system controls access to the individual CA virtual servers within the secure boundary, based on CA Administrators access list. The secure boundary of the SSP systems is enforced by logical firewall port controls, dedicated VLANs that the CA systems operate on, IPA access lists, encrypted file system access lists, as well as physical access controls at the secure datacenter location.

Only trusted and authorized CA Aministrators are granted access to the CA systems within the federal secure boundary. As described in the Verizon IAM Federal SSP Trusted Roles document located on SharePoint at:


A minimum number of engineers are assigned to dual controlled trusted roles who can access the CA keys. The assigned dual control roles are enforced by practices described in the KMP.

Archive audit records of all access attempts are maintained at the secure management workstation, and also at the CA systems inside the boundary. The CA application itself maintains an audit log of all login events and transactions performed by the CA.

Every component of the virtual access system and the virtual CA system is backed up on daily basis to accommodate for sudden data loss or system corruption. Backups of all CA components inside the secure boundary are also available at the DR site. 6.5.2 Computer Security Rating No Stipulation.



6.6 Life-Cycle Technical Controls

6.6.1 System Development Controls

The System Development Controls for the CA and RA are as follows:

• Verizon SSP utilizes Verizon’s off-the-shelf MCS UniCERT software to operate their CA services. All major releases of the software are shipped shrinkwrapped from the development center. Software development is performed outside the SSP OA group. Hardware and software procured to operate Verizon’s CA is purchased in a fashion to reduce the likelihood that any particular component was tampered with (e.g., by ensuring the vendor cannot identify the PKI component that will be installed on a particular device). Verizon SSP OA only uses OEM hardware and software. HSM hardware is ordered through Verizon procurement directly from Thales HSM manufacturer. Major software releases are shipped directly from the OEM to the CA Admins who upload and install the updates on the CA servers. CA, CSS, and OS major software releases and patches are either shipped directly by the OEM to the CA administrators via Fedex, USP, or DHL, or CA Administrators download these software releases from the OEM secure site. A onetime hash can be used to compare the integrity of the software before and after the download.

• Verizon’s SSP CA hardware and software is dedicated to performing one task: the CA. No other applications, hardware devices, network connections, or component software that are not part of the CA operation will be installed. Where the CA operation requires multiple CAs or CA components, Verizon reserves the right to share the hardware platform for related CA usage.

• Verizon undertakes all reasonable precautions to prevent malicious software from being loaded onto the CA equipment. Only applications required to perform the operation of the CA are procured and only from sources authorized by local policy. The RA hardware and software is scanned for malicious code on first use and periodically thereafter. Installation of every software update or a tool on the CA systems goes through proper change control approval process. Regular internal audits verify that software installed on the servers has a purpose and comes from OEM by examining the change control request and implementation plan. CA servers are also monthly scanned for vulnerabilities as part of Verizon’s operational best practice and GSA requirement.

• Hardware and software updates are either directly shipped on shrink wrapped media by the OEM as part of ongoing support agreement to the CA admins, or CA Admins download the updates via OEM secure software distribution sites. Installation of every software/hardware update is scrutinized via change control approval prior to the software installation. Software installation changes are also subject of regular internal SSP audit process.

6.6.2 Security Management Controls

The configuration of the Verizon’s CA system, in addition to any modifications and upgrades, is documented and controlled by formal configuration and change management process. Either the initial configuration of the CA system or any subsequent change of the system is proposed and documented by one of the CA Admins. Before the change can be implemented, the CA admin working on the change submits the implementation documentation and change overview to the change control board (CCB) for review at Verizon internal change management site:


The CCB reviews the documentation and then discusses the overview and any concerns at the next change control board meeting. If the change is approved, it is marked approved and scheduled for implementation. The CA administrator who implements the change, updates the status of the change on the CCB website and the CCB closes the change as implemented. All change requests are also reviewed during regular internal audit process. The CA administrator compares the checksum value provided by the OEM with the checksum value generated on the CA system prior to the installation of the software. Verizon will periodically verify the integrity of the software as specified in this Section.

6.6.3 Life-Cycle Security Ratings

No stipulation.

6.7 Network Security Controls

Verizon uses a network design of multiple firewalls from multiple vendors to protect network access to Verizon’s CA, MVS. Network Intrusion detection systems are deployed and operated in a 24x7 operational environment. These technologies limit the services allowed to and from the CA equipment to those required to perform CA functions. Additionally, only the CA administrators who are properly authenticated and authorized to communicate with the CA interface over a secure channel are granted access. More details about the systems in use to protect the CA systems can be obtained from the Verizon CYBSSPS (SSPS) Security Plan document available at Verizon SharePoint site:

https://teamsites.vzbi.com/sites/mss/iam/Federal%20SSP%20Audits/Verizon%20CYBSSPS%20(SSPS)%20Security%20Plan%20v5.0.docx

Verizon’s network security controls are designed to protect CA equipment against known network attacks. All unused network ports and services are turned off. Any network software present on the CA equipment is necessary to the functioning of the CA application. More details about the systems in use to protect the CA systems can be obtained from the ATO documentation available at Verizon SharePoint site:

https://teamsites.vzbi.com/sites/mss/iam/IAM%20Audit%20%20Compliance/Forms/AllItems.aspx#Any boundary control devices used to protect the network on which PKI equipment is hosted will deny all but the necessary services to the PKI equipment as specified in our Security Procedures and Standard Operating Procedures. More details about the systems in use to protect the CA systems can be obtained from the ATO documentation available at Verizon SharePoint site.

https://teamsites.vzbi.com/sites/mss/iam/IAM%20Audit%20%20Compliance/Forms/AllItems.aspx#

Repositories, certificate status servers, and remote workstations used to administer the CAs follow the same access control rules and practices, which are discussed in more detail in Section 6.5.1. As also described in Section 6.5.1, access to CA service and PKI roles is restricted through the implementation of physical controls, the operating system, databases and PKI applications. The CA connection with a remote workstation used to administer the CA is granted only after successful authentication of the remote workstation at a level of assurance commensurate with that of the CA. Security controls which secure CA remote workstation connection are discussed in more detail in CPS sections 6.5.1 and 6.7.



https://teamsites.vzbi.com/sites/mss/iam/IAM%20Audit%20%20Compliance/Forms/AllItems.aspx




6.8 Time-Stamping

Verizon IAM ensures that system time is automatically maintained and adjusted through NTP service, not to exceed 3 minutes in time difference. Verizon CAs, MVSs, and other related systems utilize internal NTP services to distribute NIST time. Clock adjustments are auditable events (see section 5.4.1).

7 CERTIFICATE, CRL AND OCSP PROFILES

7.1 Certificate Profile

Certificates issued by Verizon under this CPS will conform to the X.509 Certificate and Certificate Revocation List (CRL) Extensions Profile for the Shared Service Providers (SSP) Program [CCP-PROF]. Verizon’s certificate profile information is found in Appendix A of this CPS. 7.1.1 Version Numbers

Verizon will issue X.509 v3 certificates (populate version field with integer “2”). The UniCERT CA product, which is used to administer the CA, only supports X.509 v3 certificate templates. The certificate structure is configured by a CA Administrator during the initial setup by selecting from the CA UniCERT predefined available certificate attributes and options, which are defined in a certificate registration policy. CA administrators choose specific options based on requirements defined in this CPS and in the client enrollment form. The CA restricts the CA administrators or RAs from further modifying the structure of the certificate registration policies once these have been configured and used.

7.1.2 Certificate Extensions

Rules for the inclusion, assignment of value, and processing of extensions are defined in Common CP Certificate Profile [CCP-PROF]. These profiles are written to prescribe an appropriate amount of control over an infrastructure yet be flexible enough to meet the needs of the various CAs and communities. Verizon will comply with RFC 3280 and the profiles mentioned above. Whenever private extensions are used, they shall be identified in this CPS or the Contracting Agency’s RPS. Critical private extensions will be interoperable in their intended community of use.

7.1.3 Algorithm Object Identifiers

Certificates issued under this CPS shall identify the signature algorithm using one of the following OIDs:

sha-1WithRSAEncryption

{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 5 }

sha256WithRSAEncryption

{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 11 }

RSA with PSS padding { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 10 }

ecdsa-with-SH256 { iso(1) member-body(2) us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2 (3) 2 }

ecdsa-with-SHA384 { iso(1) member-body(2) us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 3 }

Note: sha1WithRSAEncryption is no longer supported for issuance of new certificates. All of the above OIDs are supported by the CA UniCERT product and are selectable by the CA Administrator during the initial setup of the certificate registration policy. Where certificates are signed using RSA with PSS padding, the OID is independent of the hash algorithm; the hash algorithm is specified as a parameter. RSA signatures with PSS padding may be used with the hash algorithms and OIDs specified below:

SHA-256 { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistalgorithm(4) hashalgs(2) 1 }

Certificates issued under this CPS shall identify the cryptographic algorithm associated with the subject public key using one of the following OIDs:

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) id-publicKeyType(2) 1 }

Where the certificate contains an elliptic curve public key, the parameters shall be specified as one of the following named curves:

ansip256r1 { iso(1) member-body(2) us(840) 10045 curves(3) prime(1) 7 } ansip384r1 { iso(1) identified-organization(3) certicom(132) curve(0) 34 }

Where non-CA certificates issued on behalf of federal agencies contain an elliptic curve public key, the parameters shall be specified as one of the following named curves:

ansip256r1 { iso(1) member-body(2) us(840) 10045 curves(3) prime(1) 7 } ansip384r1 { iso(1) identified-organization(3) certicom(132) curve(0) 34 }

These requirements are embedded in the CA UniCERT product and can be selected during the initial setup of the client certificate registration policies. 7.1.4 Name Forms

The subject field in certificates issued under id-fpki-common-policy, id-fpki-common-hardware, id-fpki-common-authentication, id-fpki-common-derived-pivAuth-hardware, id-fpki-common-derived-pivAuth, id-fpki-common-piv-contentSigning and id-fpki-common-devices of the base certificate shall be populated with an X.500 distinguished name with the attribute type as specified in section 3.1.1.

The issuer field of certificates issued under the policies in this document will be populated with a non-empty X.500 distinguished name as specified in section 3.1.1.

The subject alternative name extension will be present and include the pivFASC-N name type in certificates issued under id-fpki-common-authentication and id-fpki-common-cardAuth.

The subject alternative name extension shall be present and include a UUID, encoded as a URI, in certificates issued under id-fpki-common-authentication, id-fpki-common-cardAuth and id-fpki-common-derived-pivAuth-hardware and id-fpki-common-derived-pivAuth. Subject alternative name settings are defined in UniCERT certificate registration policies. The certificate registration policies are also described in appendix A.

7.1.5 Name Constraints

When it deems necessary and appropriate, Verizon may assert name constraints in its CA certificates.

7.1.6 Certificate Policies Extension

Certificates issued under this CPS will assert at least one of the following OID in the certificate policies extension, as appropriate:

id-fpki-common-policy ::= {2 16 840 1 101 3 2 1 3 6} (denoting Browser or software based certificates) id-fpki-common-hardware ::= {2 16 840 1 101 3 2 1 3 7} id-fpki-common-devices ::= {2 16 840 1 101 3 2 1 3 8} id-fpki-common-authentication ::= {2 16 840 1 101 3 2 1 3 13} id-fpki-common-derived-pivAuth-hardware ::= {2 16 840 1 101 3 2 1 3 41} id-fpki-common-derived-pivAuth ::= {2 16 840 1 101 3 2 1 3 40} id-fpki-common-derived-pivAuth-hardware ::= {2 16 840 1 101 3 2 1 3 41} id-fpki-common-cardAuth ::= {2 16 840 1 101 3 2 1 3 17} id-fpki-common-piv-contentSigning ::= {2 16 840 1 101 3 2 1 3 39} Certificates that express the id-fpki-common-piv-contentSigning policy OID, shall not express any other policy OIDs. Subject alternative name settings are defined in UniCERT certificate registration policies. The certificate registration policies are also described in appendix A. 7.1.7 Usage of Policy Constraints Extension

When deemed necessary and appropriate, Verizon may assert policy constraints in its CA certificates.

7.1.8 Policy Qualifiers Syntax and Semantics

Certificates issued under this CPS will not contain policy qualifiers.

7.1.9 Processing Semantics for the Critical Certificate Policy Extension

Certificates issued under this CPS will not contain a critical certificate policy extension.

7.2 CRL Profile

CRLs issued by Verizon under this CPS will conform to the CRL Profile specified in [CCP-PROF]. During the initial setup of the CA, CRL properties and generation times are configured in CA properties by the CA administrators. 7.2.1 Version Numbers

Verizon will issue X.509 Version two (2) CRLs. Verizon SSP CA software UniCERT is preconfigured to issue v2 CRLs by default. CA Administrators configure the CRLs settings during the initial setup in CA properties.

7.2.2 CRL and CRL Entry Extensions

Verizon will generate CRL Entry Extensions in accordance with the detailed CRL profiles addressing the use of each extension as specified in [CCP-PROF].

7.3 OCSP Profile

The MVS operating under this CPS will sign responses using algorithms designated for CRL signing. Signature algorithm used by the MVS system is defined by a CA administrator in the Corestreet administration console during the initial setup. The MVS will be able to process SHA-1 hashes when included in the CertID field and the keyHash in the responderID field. 7.3.1 Version Number(s)

The MVS operating under this CPS will use OCSP version 1. The Corestreet software which Verizon SSP uses to provide OCSP certificate validation services is preconfigured to offer OCSP version 1. No further configuration is required. 7.3.2 OCSP Extensions

Critical OCSP extensions will not be used.

8. Compliance Audit and Other Assessments CAs operating under this CPS have a compliance audit mechanism in place to ensure that the requirements of this CPS are being implemented and enforced. A Verizon internal auditor initiates and performs a bi-monthly audit and discusses the results of the audit with the Verizon PMA. Verizon PMA ensures that an internal audit report is filed every other month and any outstanding findings from the internal audit are being addressed. SSP Internal audit reports are available at the SharePoint: https://teamsites.vzbi.com/sites/mss/iam/IAM%20Audit%20%20Compliance/Forms/AllItems.aspx#

8.1 Frequency or Circumstances of Assessment



Verizon and Contracting Agencies operating as RAs under the Common Policy and this CPS will conduct a compliance audit no less than once every year in accordance with the “FPKIPA Compliance Audit Requirements” document located at: http://www.idmanagement.gov/documents/fpki-compliance-audit-requirements Verizon may also initiate an audit to review its continuing compliance with its obligations under this CPS at any time following a significant change in this CPS or to the operations of Verizon. In addition, Verizon and its RAs, in accordance with the “Compliance Audit Requirements” document, are subject to periodic inspections conducted by the FPKIPA to validate that the CA/RA is operating in accordance with their CPS and RPS. Verizon may also conduct periodic inspections of the Contracting Agency’s RAs to ensure compliance with this CPS and the Agency’s RPS. Any audits carried out pursuant to this Section 8.1 will be performed by an external auditor appointed in accordance with Section 8.2. Every year the Verizon Compliance team submits a Purchase Order to a third party auditor to conduct an annual SSP audit of the Verizon SSP CAs managed services, as well as perform an RA audit of the Federal agencies which issue certificates from the Verizon operated CAs.

8.2 Identity/Qualifications of Compliance Auditor

Verizon shall appoint an external auditor who has demonstrated expertise in computer security or a computer security professional and the auditor must be a certified information system auditor (CISA). The auditor will also be familiar with the Federal Common Policy, this CPS, audit methodology, audit standards, Public Key Infrastructure and security issues. Verizon utilizes the services of an independent third party compliance auditor to determine its adherence to the requirements of the Common Policy and other applicable Federal Government statutes, regulations and standards. Verizon appoints the certified external compliance auditor to conduct a full audit of the SSP services on annual basis. Verizon engages qualified auditors that their primary business activity is auditing PKI infrastructures.

8.3 Assessor’s Relationship to Assessed Entity The auditor appointed pursuant to Section 8.2 will be independent of Verizon and its RAs. The auditor will not have any conflict of interest with Verizon, as defined by the Information System Audit and Control Association (ISACA) guidelines. Based on client contract stipulations, Verizon PMA works with the Contracting Agency’s PMA to identify and engage a qualified auditor to review agency operations that implement aspects of the Common Policy as reflected in the Contracting Agency’s RPS.

8.4 Topics Covered by Assessment

The compliance audit will test compliance of Verizon CAs and its RAs against the policies and procedures set out in the current versions of the Common Policy, this CPS and the Contracting Agency’s RPS. Components other than CAs may be audited fully or by using a representative

http://www.idmanagement.gov/documents/fpki-compliance-audit-requirements

sample. If the auditor uses statistical sampling, all PKI components, PKI component managers and operators shall be considered in the sample. The samples shall vary on an annual basis.

8.5 Actions taken as a result of deficiency The Verizon PMA will request that the auditor inform it of any discrepancies between the operations of Verizon and the requirements of the Common Policy and this CPS. The Verizon PMA will review any such discrepancies of which it is informed. For the significant discrepancies which are in direct violation of the CP or CPS, the Verizon PMA will suggest corrective actions and the expected time for implementation of such actions. For discrepancies which may result from miscommunication or misunderstanding of the current practice in place, the PMA will first try to clarify the misunderstanding and then come to a common resolution of such issue with the external auditor. Verizon will work with the FPKIPA and the RAs to resolve serious deficiencies. Depending upon the nature and severity of the discrepancy, and how quickly it can be corrected, Verizon SSP will comply with the FPKIPA if it decides to temporarily halt operation of the CA or RA, to revoke a certificate issued to the CA or RA, or take other actions it deems appropriate. Verizon will appoint a project manager and a compliance officer to track progress of the procedure development process and the implementation of the determinations resulting from the process. Verizon PMA will suggest period conference call meetings to keep everybody informed on the progress.

8.6 Communication of Results

On an annual basis, an Auditor Letter of Compliance prepared in accordance with the FPKI Complaiance Audit Requierments document, on behalf of an Agency PMA will be provided to the SSP. Also,on an annual basis, the SSP PMA shall submit an audit compliance package to the FPKIPA. This package shall be prepared in accordance with the “FPKIPA Compliance Audit Requirements” document and includes an assertion from the Verizon PMA that all PKI components have been audited - including any components that may be separately managed and operated. The report shall identify the versions of this CPS used in the assessment. Additionally, where necessary, the results shall be communicated as set forth in Section 8.5 above.

9. Other Business and Legal Matters

9.1 Fees

9.1.1 Certificate Issuance or Renewal Fees

Fees associated with Certificates issued and used under the Common Policy and this CPS will be specified in the Contracting Agency Agreement and any applicable schedules of the General Services Administration or similar Federal Government contracting vehicles.

9.1.2 Certificate Access Fees

Section 2 of the Common Policy requires that CA certificates be publicly available. Therefore, CAs operating under this CPS will not charge additional fees for access to this information.

9.1.3 Revocation or Status Information Access Fees

CAs operating under the Common Policy must not charge additional fees for access to CRLs and OCSP status information.

9.1.4 Fees for Other Services

No stipulation.

9.1.5 Refund Policy

No Stipulation

9.2 Financial Responsibility

The terms of the financial relationship between Verizon and the Contracting Agency shall be governed by the provisions of the agreement between Verizon and the relevant Contracting Agency. Each Contracting Agency shall be responsible for the financial consequences to the Contracting Agency itself, its appointed Registration Authorities, Subscribers, Relying Parties and to any other third parties for any transactions in which such Subscribers or Relying Parties participate and which use Certificates or any services provided by Verizon in relation to Certificates. Verizon makes no representations and gives no warranties regarding the financial efficacy of any transaction completed utilizing a Certificate or any services provided by Verizon in relation to Certificates and Verizon shall have no liability to any RAs, Subscribers, Relying Parties or third parties in respect to the use of, or inability to use, or reliance on a Certificate or any services provided by Verizon in relation to Certificates. Verizon’s liability to a Contracting Agency is set out in the relevant Contracting Agency Agreement.

9.2.1 Insurance Coverage

No Stipulation

9.2.2 Other Assets

No Stipulation

9.2.3 Insurance or Warranty Coverage for End-Entities

No Stipulation

9.3 Confidentiality of Business Information

This section establishes the obligations of confidentiality, which apply between Verizon and Subscribers. The Contracting Agency warrants and shall ensure that all Subscribers fulfill any obligations in this CPS (including without limitation this Section 9.3, the Agency’s RPS and any additional laws, regulations and policies as applicable. The Contracting Agency shall be responsible for the acts or omissions of any Subscriber, including without limitation any Subscriber's breach of any obligation, promise, warranty or similar requirement stated in this CPS (including without limitation this Section 9.3, the Agency’s RPS or an Agreement with the

Subscriber. Obligations of confidentiality between Verizon and the Contracting Agency are specified in the relevant sections of that agreement including specific details relating to the applicability of Privacy laws to the relationship between Verizon, the Contracting Agency and the Subscribers.

CA information not subject to protection under this Section 9.3 will be made publicly available as noted in Section 9.6.

9.3.1 Scope of Confidential Information

No stipulation

9.3.2 Information not within the Scope of Confidential Information

No Stipulation

9.3.3 Responsibility to Protect Confidential Information

No stipulation. 9.4 Privacy of Personal Information 9.4.1 Privacy Plan The sensitivity of the information processed or protected using certificates issued by Verizon under this CPS will vary significantly. Agency PMAs 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. The SSP PMA will discuss the need for the Contracting Agency to conduct a Privacy Impact Assessment (PIA) and provide a PIA report in compliance with the CP. SSP PMA will post the agency PIA internally on SharePoint at: https://teamsites.vzbi.com/sites/mss/iam/IAM%20Audit%20%20Compliance/Forms/AllItems.aspx# The Contracting Agency will have a Privacy Plan to protect personally identifying information from unauthorized disclosure. The Contracting Agency will implement privacy plans in accordance with the requirements of the Privacy Act of 1974, as amended. 9.4.2 Information Treated as Private

Federal entities acquiring services under the Common Policy and this CPS shall protect all subscriber personally identifying information from unauthorized disclosure. Records of individual transactions may be released upon request of any subscribers involved in the transaction or their legally recognized agents. The contents of the archives maintained by the Verizon CAs operating under this policy shall not be released except as required by law. For the purposes of this CPS, references to "Confidential Information" mean all information disclosed or made available by Applicant and/or Subscriber in connection with such party's application for and/or subscription for a Certificate and which information is not set forth in Section 9.4.2 herein. Confidential Information also includes, but is not limited to, any information disclosed by either Verizon, Contracting Agency, Applicant and/or Subscriber which may be reasonably regarded as confidential information of the disclosing party in whatever format



(whether written, electronic or otherwise). Confidential Information shall be disclosed and otherwise dealt with only in accordance with this CPS. Verizon and the Subscriber hereby undertake that: • Verizon shall keep the Confidential Information confidential by employing those precautions which it employs to protect its own Confidential Information and shall only use Confidential Information for the purposes for which it was so disclosed or came into its possession under this CPS; and • Verizon shall not disclose any Confidential Information to any third party (other than as specifically stated in this Section) without the prior written consent of the other party;

• Nothing in this section shall be deemed or construed to prevent Verizon from disclosing any Confidential Information to any partner, principal, employee, agent or sub-contractor engaged by Verizon who needs to know such Confidential Information in connection with this CPS, provided that Verizon shall first cause any such partner, principal, employee, agent or sub-contractor to sign a confidentiality agreement consisting of substantially the same terms as are contained in this Section 9.4. Verizon shall not have access to the Private Keys of any Subscriber to whom it issues Certificates except in the case of key management keys as provided in Section 4.12. Private Keys held by Verizon used to sign Certificates and Private Keys held by Customers to sign Certificate requests will be held in the strictest confidence in accordance with this Section 9.4.

Personally Identifiable Information which the SSP gathers from the certificate subscribers during the certificate enrollment process is protected as follows:

• Only Agency RAs who possess a valid RA certificate are authorized to fill certificate request forms and submit certificate requests

• PII contained within certificate requests is transmitted over encrypted HTTPS channel

• PII derived from the certificates is only retained in the CA database and accessible only to trusted CA Admins or CA auditors

9.4.3 Information not Deemed Private

Information included in certificates is not subject to protections outlined in section 9.4.2. However, certificates that contain the FASC-N in the subject alternative name extension, such as PIV Authentication Certificates, shall not be distributed via public repositories (e.g., via LDAP or HTTP). The provisions of this Section 9.4.3 shall not apply to any information which: • is or becomes public knowledge other than by breach of this Section 9.4; • is in the possession of the receiving party without restriction in relation to disclosure before the date of receipt from the disclosing party; • is received from a third party who lawfully acquired it and who is under no obligation restricting its disclosure; • is independently developed without access to the Confidential Information; • appears in Certificates issued by Verizon under this CPS; or • relates to the revocation of Certificates issued by Verizon under this CPS; and such information shall accordingly not be treated as Confidential Information.

This CPS and Certificates issued by Verizon under this CPS do not constitute Confidential Information of any party. 9.4.4 Responsibility to Protect Private Information

Sensitive information must be stored securely, and may be released only in accordance with other stipulations in section 9.4.

9.4.5 Notice and Consent to Use Private Information

The FPKI Operational Authority or Agency PMA is not required to provide any notice or obtain the consent of the subscriber or Authorized Agency Personnel in order to release private information in accordance with other stipulations of section 9.4.

9.4.6 Disclosure Pursuant to Judicial or Administrative Process

The FPKI Operational Authority or Agency PMA shall not disclose private information to any third party unless authorized by this policy, required by law, government rule or regulation, or order of a court of competent jurisdiction. Any request for release of information shall be processed according to 41 CFR 105-60.605. Verizon will not disclose Confidential Information to any law enforcement official or agency unless such disclosure is required by law, governmental rule or regulation, court order or other regulatory authority, provided that each disclosure permitted pursuant to this Section 9.4.6 shall be made only to the extent required. Request for release of information shall be directed to the persons identified in Section 9.11. 9.4.7 Other Information Disclosure Circumstances

No stipulation

9.4.7.1 Release as Part of Civil Discovery

Notwithstanding the other provisions of this Section 9.4, Confidential Information may be disclosed to third parties as required by the discovery process in civil court proceedings, provided that each disclosure permitted pursuant to this Section 9.4 shall be made only to the extent required. Request for release of information shall be directed to the persons identified in Section 9.11. 9.4.7.2 Disclosure upon Owner’s Request

Confidential Information may be released with the prior written consent of the party who is the subject of such Confidential Information or to whom the Confidential Information otherwise relates. Request for release of information shall be directed to the persons identified in Section 9.11. 9.4.7.3 Disclosure of Certificate Revocation Information

Verizon will obtain, hold and disclose information in accordance with the procedures set out in this CPS regarding the revocation of Certificates that Verizon has issued under this CPS. This information is made available to Subscribers and Relying Parties through a Certificate Revocation List. Revocation reason codes may be provided for selection by the Registration Authority administrator. Other than the information contained in the available revocation reason code, no other information concerning the revocation shall be disclosed by Verizon under this Section 9.4.7.3. 9.5 Intellectual Property Rights

Verizon shall own the Intellectual Property Rights and all other rights in relation to this CPS, Certificates and CRLs issued by Verizon and any other documents, specifications or guidelines created or issued by Verizon. Applicants and, upon issuance of a Certificate under this CPS, Subscribers and Customers provide the warranty and indemnity regarding Intellectual Property Rights set out in Section 3.1.6 of this CPS. 9.6 Representations and Warranties

The Common Policy requires that the Contracting Agency’s PMA:

• Review periodic compliance audits to ensure that RAs and other components operated by the agency are operating in compliance with this CPS; and

• Review name space control procedures to ensure that distinguished names are uniquely assigned within their agency.

Verizon reviews the compliance audits and reports of the Agency’s PMA to ensure the Agency is meeting its obligations under this CPS and the RPS. SSP PMA internal auditor requests from the Agency PMA the evidence of conducting periodic internal RA audits and distinguished name audits. These audit reports are posted on SharePoint at: https://teamsites.vzbi.com/sites/mss/iam/IAM%20Audit%20%20Compliance/Forms/AllItems.aspx# 9.6.1 CA Representations and Warranties

Verizon, as a CA operating under the terms of the Common Policy conforms with all the requirements of the Common Policy including:

• Providing the FPKIPA with this CPS for conformance assessment.

• Maintaining its operations in conformance to the stipulations of the approved CPS.

• Ensuring that registration information is accepted only from approved RAs operating under an approved CPS and RPS.

• Including only valid and appropriate information in certificates, and maintaining evidence that due diligence was exercised in validating the information contained in the certificates.

• Revoking the certificates of subscribers found to have acted in a manner counter to their obligations in accordance with Section 2.1.4.



• Operating or providing for the services of an online repository that satisfies the obligations under Section 2.1.6, and informing the repository service provider of their obligations (if applicable).

• Performing in-depth independent annual audit of the CA and RA conformance with the CP and CPS, in accordance with CP section 8

• Performing bi-monthly internal audit of the CA systems

• Working with the Agency PMA on bi-monthly basis to conduct RA internal audit and produce a report

9.6.2 RA Representations and Warranties

An RA who performs registration functions as described in the Common Policy shall comply with the stipulations of the Common Policy, and with a CPS or RPS that has been approved by the FPKIPA for use with that policy. An RA who is found to have acted in a manner inconsistent with these obligations is subject to revocation of RA responsibilities. An RA supporting the Common Policy will conform to the stipulations of that document, including:

• Maintaining its operations in conformance to the stipulations of the approved CPS or RPS.

• Including only valid and appropriate information in certificate requests, and maintaining evidence that due diligence was exercised in validating the information contained in the certificate.

• Ensuring that obligations are imposed on subscribers in accordance with Section 2.1.4, and that subscribers are informed of the consequences of not complying with those obligations.

• Performing in-depth independent annual audit of the CA and RA conformance with the CP and CPS, in accordance with CP Section 8

9.6.3 Subscriber Obligations

A subscriber (or human sponsor for device certificates) shall be required to sign a document containing the requirements the subscriber shall meet respecting protection of the private key and use of the certificate before being issued the certificate. Wherever possible, subscriber documents must be digitally signed. Subscribers will:

• Accurately represent themselves in all communications with the PKI authorities and other subscribers.

• Protect their private keys at all times, in accordance with this policy, as stipulated in their certificate acceptance agreements and any additional procedures imposed by the Contracting Agency including signing the Subscriber agreement of the Contracting Agency.

• Notify, in a timely manner, the CA that issued their certificates of suspicion that their private keys are compromised or lost. Such notification shall be made directly, or indirectly, through mechanisms consistent with Verizon’s CPS and the Contracting Agency’s RPS.

• Abide by all the terms, conditions, and restrictions imposed upon the use of their private keys and certificates as noted in the signed Subscriber agreement of the Contracting Agency.

If the human sponsor for a device is not physically located near the sponsored device, and/or does not have sufficient administrative privileges on the sponsored device to protect the device’s private key and ensure that the device’s certificate is only used for authorized purposes, the device sponsor may delegate these responsibilities to an authorized administrator for the device. The delegation shall be documented and signed by both the device sponsor and the authorized administrator for the device. Delegation does not relieve the device sponsor of his or her accountability for these responsibilities. The agency RPS shall fully define this process and the sponsor shall maintain the authorization document and be able to supply them upon request. A Subscriber’s failure to comply with this CPS may result, without limitation, in the immediate revocation of any Certificates issued to the Subscriber. 9.6.4 Relying Party Obligations

The Relying Party will decide, pursuant to its own policies, what steps it will need to take to rely on a certificate issued under this CPS. Verizon will provide the tools for the relying party to perform the trust path creation and certificate validation that the relying party may wish to employ in making its determination to rely on these certificates. In the event the Relying Party decides to rely on certificates issued under this CPS, the relying party shall, at a minimum: (i) read and agree to all terms and conditions of this CPS; (ii) validate all Certificates through the use of the Certificate Revocation List (CRL); (iii) trust and make use of a Certificate only if the Certificate has not expired or been revoked and if a proper chain of trust can be established to the trusted root; and (iv) make its own judgment and rely on a Certificate only if such reliance is reasonable in the circumstances, including determining whether such reliance is reasonable given the nature of the security and trust provided by the Certificate and the value of any transaction that may involve the use of a Certificate. The Relying Party shall comply with all laws and regulations applicable to a Relying Party's right to use Certificates and/or related information. 9.6.5 Representations and Warranties of Other Participants

No Stipulation. 9.7 Disclaimers of Warranties

CAs operating under the Common Policy and this CPS may not disclaim any responsibilities described in the Common Policy and this CPS. 9.8 Limitations on Liability

The terms and provisions of the Federal Common Policy are interpreted and governed by applicable Federal law. The U.S. Government will not be liable to any party, except as determined pursuant to the Federal Tort Claims Act (FTCA), 28 U.S.C. 2671-2680, or as determined through a valid express written contract between the Government and another party. In this section “Contracting Agency Agreement” means the agreement(s) between Verizon and the relevant Contracting Agency for provision of services under the SSP Program. 9.8.1 Verizon Liability

9.8.1.1 Warranties and Limitations on Warranties Refer to the relevant Contracting Agency Agreement. 9.8.1.2 Damages Covered and Disclaimers Refer to the relevant Contracting Agency Agreement. 9.8.1.3 Excluded liability Refer to the relevant Contracting Agency Agreement. 9.8.1.4 Loss Limitations Refer to the relevant Contracting Agency Agreement. 9.8.1.5 Other Exclusions Refer to the relevant Contracting Agency Agreement. 9.9 Indemnities 9.9.1 Indemnification by Relying Parties IN ADDITION TO ANY INDEMNIFICATIONS STATED HEREIN OR IN ANY RELYING PARTY AGREEMENT, EACH RELYING PARTY SHALL, TO THE EXTENT PERMITTED BY APPLICABLE LAW, INDEMNIFY AND HOLD VERIZON HARMLESS FROM AND AGAINST ANY AND ALL LIABILITIES, LOSSES, COSTS, EXPENSES, DAMAGES, CLAIMS AND SETTLEMENT AMOUNTS (INCLUDING REASONABLE ATTORNEYS' FEES, COURT COSTS AND EXPERTS' FEES) (“LOSSES”) ARISING OUT OF OR RELATING TO ANY USE OR RELIANCE BY A RELYING PARTY ON ANY CERTIFICATE(S) OR ANY SERVICE PROVIDED IN RESPECT TO CERTIFICATE(S) ISSUED UNDER THIS CPS, INCLUDING(i) LACK OF PROPER VALIDATION BY A RELYING PARTY, (ii) RELIANCE BY THE RELYING PARTY ON AN EXPIRED OR REVOKED CERTIFICATE, (iii) USE OF A CERTIFICATE OTHER THAN AS PERMITTED BY THIS CPS, THE RELYING PARTY AGREEMENT, THE COMMON POLICY AND/OR APPLICABLE LAW, (iv) FAILURE BY A RELYING PARTY TO EXERCISE REASONABLE JUDGMENT IN THE CIRCUMSTANCES IN RELYING ON A CERTIFICATE, (v) ANY CLAIM OR ALLEGATION THAT THE RELIANCE BY A RELYING PARTY ON A CERTIFICATE OR THE INFORMATION CONTAINED IN A CERTIFICATE INFRINGES, MISAPPROPRIATES, DILUTES, UNFAIRLY COMPETES WITH OR OTHERWISE VIOLATES THE RIGHTS INCLUDING INTELLECTUAL PROPERTY RIGHTS OR ANY OTHER RIGHTS OF ANYONE IN ANY JURISDICTION, OR (vi) IN THE EVENT THAT THE RELYING PARTY BREACHES, IN WHOLE OR IN PART, ITS OBLIGATIONS UNDER THIS CPS OR THE RELYING PARTY AGREEMENT. NOTWITHSTANDING THE FOREGOING, RELYING PARTIES SHALL NOT BE OBLIGATED TO PROVIDE ANY INDEMNIFICATION TO VERIZON IN TO ANY LOSSES TO THE EXTENT SUCH LOSSES ARISE OUT OF OR RELATE TO THE NEGLIGENCE OR WILLFUL MISCONDUCT OF VERIZON. 9.10 Term and Termination 9.10.1 Term

This CPS becomes effective when approved by the FPKIPA. This CPS has no specified term.

9.10.2 Termination

Termination of this CPS is at the discretion of the FPKIPA. 9.10.3 Effect of the Termination and Survival

The requirements of this CPS remain in effect through the end of the archive period for the last certificate issued. 9.11 Individual Notices and Communications with Participants

Any notice to be given to Verizon by a Subscriber, Applicant, Contracting Agency, Registration Authority (acting on behalf of the Customer) or Relying Party under this CPS or a Contracting Agency Agreement or Policy, shall be given in writing to the address specified below by prepaid receipted mail, facsimile (confirmed by prepaid receipted mail or overnight courier), or overnight courier, and shall be effective as follows: (i) in the case of facsimile or courier, on the next business day, and (ii) in the case of receipted mail, five business days following the date of deposit in the mail. Any notice to be given by Verizon under this CPS or any Contracting Agency Agreement or any Policy may be given by email or to the last known address for the recipient on file with Verizon. In the event of notice by email, the notice shall become effective on the next business day. In the event of notice to the last address on file with Verizon, notice shall become effective as specified in (i) or (ii), depending on the means of notice utilized. For the purposes of notices and other communications the address of shall be: Verizon Business Security Solutions by Verizon 22001 Loudoun County Parkway Ashburn, VA 20147 For the attention of: Assistant General Counsel, Federal, Verizon Business Security Solutions 9.12 Amendments 9.12.1 Procedure for Amendment

Subject to the approval of the FPKIPA, Verizon reserves the right to change this CPS from time to time. Any such change will be made prospectively; no retroactive amendments will be made to the CPS. Verizon will incorporate any such change into a new version of this CPS and, upon approval, publish the new version on the Verizon web site at: http://cp1.ssp-strong-id.net/CPS/ The new CPS will carry a new version number.

9.12.2 Notification Mechanism and Period

This CPS and any subsequent changes shall be made publicly available within 1 week of approval by the FPKIPA.

http://cp1.ssp-strong-id.net/CPS/

9.12.3 Circumstances under which OID must be Changed

OIDs will be changed if the FPKIPA determines that a change in the Common Policy and this CPS reduces the level of assurance provided. 9.13 Dispute Resolution Procedures

The FPKIPA shall facilitate the resolution between entities when conflicts arise as a result of the use of certificates issued under the Common Policy. When the dispute is between Federal agencies, and the FPKIPA is unable to facilitate resolution, dispute resolution may be escalated to OMB or U.S. Department of Justice, Office of Legal Counsel as necessary.

Verizon SSP is committed to serve the agencies at all time in compliance with the FPKI CP and with best intention to resolve any disputes that might arise between the Agency, the SSP, and the FPKIPA.

Verizon is committed to conducting itself at all times in accordance with the Shared Service Provider Roadmap by:

• Appointing a client advocate person who is regularly in contact with the agency PMA in order to discuss and address any known issues or program changes

• Undergoing an annual FPKI compliance audit of the CA systems and RA system, purpose of which is uncover and resolve any service compliance discrepancies

• Professionally and respectfully accepting any communication from the policy authority regarding any disputes or service deficiencies and working with the FPKIPA either informally or formally to address any agency complaints or basic conduct deficiencies

A copy of the FPKIPA Shared Service Provider Roadmap is retained on the IAM SharePoint site:


9.14 Governing Law

The terms and provisions of the Common Policy are interpreted under and governed by applicable Federal law. The enforceability, construction, interpretation, and validity of this CPS shall be governed by the laws of the State of New York in the United States of America, without regard to its conflict of laws provisions. The application of the United Nations Convention on Contracts for the International Sale of Goods and the United Nations Convention on the Limitation Period in the International Sale of Goods, as both are amended, to this CPS are expressly excluded. The agreements with Contracting Agencies will be governed by applicable Federal law. 9.15 Compliance with Applicable Law

Verizon operating under this CPS is required to comply with applicable law. 9.16 Miscellaneous Provisions 9.16.1 Entire Agreement

No Stipulation


9.16.2 Assignment

The Contracting Agency, Subscriber, Registration Authority, Applicant or any Relying Party may not assign, sell, transfer, or otherwise dispose of the rights granted under its Agreement or any Policy, including without limitation this CPS whether voluntarily, involuntarily, by operation of law, or otherwise, without the prior written consent of Verizon. Any attempted assignment or transfer without such consent shall be void and may, in Verizon’s sole discretion, terminate such party's rights under the Contracting Agency Agreement, this CPS or any Certificate Policy, as applicable. Except as otherwise provided in its agreement with the Contracting Agency, Verizon may freely assign, sell, transfer, or otherwise dispose of the Contracting Agency Agreement or any Policy, including without limitation this CPS to which it is a party, together with all or some of its rights and obligations, by way of example and not limitation:

(i) to any person or entity controlling, controlled by or under common control with such party (an "Affiliate"); or

(ii) as part of a sale, merger, or other transfer of all or substantially all the assets of the business of Verizon to which this CPS and Contracting Agency Agreement, or any Policy, relate.

Subject to the foregoing limits, this CPS shall be binding upon and shall inure to the benefit of permitted successors and assigns of Verizon, Applicants, Subscribers, Contracting Agencies (and its appointed Registration Authorities) and Relying Parties as the case may be. 9.16.3 Severability

If any provision of this CPS is found to be invalid, illegal or unenforceable for any reason by any court or regulatory body of competent jurisdiction, that provision shall be severed and the remainder of the provisions of this CPS shall continue in full force and effect as if this CPS had been executed with the invalid, illegal or unenforceable provision eliminated. The invalid, illegal or unenforceable term shall be replaced by a valid and enforceable term which is as close as possible to the economic effect of the original term. 9.16.4 Enforcement (Attorney’s Fees and Waiver of Rights)

No Stipulation 9.16.5 Force Majeure

Unless otherwise specifically provided in the agreement with the Contracting Agency, Verizon shall not be in default or liable for any losses, costs, expenses, liabilities, damages, claims, or settlement amounts arising out of or related to delays in performance or from failure to perform or comply with the terms of this CPS or the Common Policy or any other related agreement due to any causes beyond its reasonable control, which causes include, without limitation, acts of God or the public enemy, riots and insurrections, terrorist activities, war, accidents, fire, strikes and other labor difficulties (whether or not Verizon is in a position to concede to such demands), embargoes, judicial action, lack of or inability to obtain export permits or approvals, necessary labor, materials, energy, utilities, components or machinery, acts of civil or military authorities. 9.17 Other Provisions 9.17.1 Fiduciary Relationships

Nothing contained in this CPS, or in any Agreement with a Contracting Agency, shall be deemed to constitute either Verizon, or any of its subcontractors, agents, officials, suppliers, employees, partners, principals, or directors to be a partner, Affiliate, trustee, or legal representative of any

Contracting Agency, or any third party or to create any fiduciary relationship between Verizon and any Contracting Agency, or any third party, for any purpose whatsoever. Nothing in this CPS or any Agreement with a Contracting Agency shall confer on any Subscriber, Customer, Relying Party, Registration Authority, Applicant or any third party, any authority to act for, bind, or create or assume any obligation or responsibility, or make any representation on behalf of Verizon. 9.17.2 Survival

Sections 9.16, 9.17 and 11 of this CPS shall, in respect of any actions based upon a Certificate issued subject to this CPS, survive the termination or withdrawal from use of this CPS, irrespective of whenever and however that termination or withdrawal from use occurs. Any such termination or withdrawal from use of this CPS shall not prejudice or affect any right of action or remedy that may have accrued to any person up to and including the date of such termination or withdrawal. 9.17.3 Merger

The Common Policy, the Agreement with the Contracting Agency and this CPS (and related policy documents), state all of the rights and obligations of Verizon and any Contracting Agency, in respect to the subject matter hereof and thereof and such rights and obligations shall not be augmented or derogated by any prior agreements, communications or understandings of any nature whatsoever whether oral or written. The rights and obligations of Verizon may not be modified or waived orally and may be modified only in a writing signed or authenticated by a duly authorized representative of Verizon. 9.17.4 Waiver

The failure of Verizon to insist upon strict performance of any provision of this CPS, or the failure of Verizon to exercise any right or remedy to which it is entitled under this CPS, shall not constitute a waiver thereof and shall not cause a diminution of the obligations established by this CPS. A waiver of any breach of this CPS shall not constitute a waiver of any subsequent breach of this CPS. No waiver of any of the provisions of this CPS shall be effective unless it is expressly stated to be a waiver and communicated to the other relevant parties in writing. No right or remedy conferred upon any person by this CPS shall be exclusive of any other right or remedy howsoever arising and all such rights and remedies shall be cumulative.

10. Bibliography RFC 4122 A Universally Unique Identifier (UUID) URN Namespace, Paul

J. Leach, Michael Mealling, and Rich Salz, July 2005

SP 800-73-3(1) Interfaces for Personal Identity Verification – Part 1: End-Point PIV Card Application Namespace, Data Model and Representation, NIST Special Publication 800-73-3, Februrary 2010.

ABADSG Digital Signature Guidelines, 1996-08-01. http://www.abanet.org/scitech/ec/isc/dsgfree.html

APL Approved Products List (APL) http://www.idmanagement.gov/approved-products-list-apl

NIST Special Publication 800-79

http://csrc.nist.gov/publications/PubsSPs.html

http://www.abanet.org/scitech/ec/isc/dsgfree.html

FIPS 186

Digital Signature Standard (DSS), FIPS 186, July 2013. http://csrc.nist.gov/publications/fips/fips186-2/fips186-2-change1.pdf

SP 800-37

Guide for Applying the Risk Management Framework to Federal Information Systems: A Security Life Cycle Approach, NIST Special Publication 800-37 Revision 1, February 2010 http://csrc.nist.gov/publications/nistpubs/800-37-rev1/sp800-37-rev1-final.pdf

SP 800-63 Electronic Authentication Guideline, NIST Special Publication 800-63-2, August 2013. http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63-2.pdf

SP 800-76 Biometric Specifications for Personal Identity Verification, NIST Special Publication 800-76-2, July 2013. http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-76-2.pdf

SP 800-157 Guidelines for Derived Personal Identity Verification (PIV) Credentials,

NIST Special Publication 800-157. http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-157.pdf or http://csrc.nist.gov/publications/drafts/800-157/sp800_157_draft.pdf

11. ACRONYMS AND ABBREVIATIONS

AIA

BRSP

CA

Authority Information Access

Betrusted RAO Server Protocol

Certification Authority

CMS Card Management System

COMSEC Communications Security

CP Certificate Policy

CPS Certification Practice Statement

CRL Certificate Revocation List

CSOR Computer Security Object Registry

CSS Certificate Status Service

DN

DR

Distinguished Name

Disaster Recovery

DSS Digital Signature Standard

FAR Federal Acquisition Regulations

FBCA Federal Bridge Certification Authority

FASC-N Federal Agency smart Credential Number

FIPS (U.S.) Federal Information Processing Standard

FPKI Federal Public Key Infrastructure

FPKIPA Federal PKI Policy Authority

CCP-Prof X.509 Certificate and CRL Extensions Profile for the Common Policy

IETF

IPA

Internet Engineering Task Force

Identity, Policy, Audit

ISO International Organization for Standardization

ISSO Information Systems Security Officer

MOA Memorandum of Agreement (as used in the context of this CP, between an Agency and the FPKIPA allowing interoperation between two separate organizational CAs)

MVS Managed Validation Service supporting OCSP and SCVP

NIST National Institute of Standards and Technology

NSA National Security Agency

NSTISSI National Security Telecommunications and Information Systems Security Instruction

OID Object Identifier

OCSP Online Certificate Status Protocol

PACS Physical Access Control System; refers to the Technical Implementation Guidance: Smart Card Enabled Physical Access Control Systems, Version 2.2, The Government Smart Card Interagency Advisory Board’s Physical Security Interagency Interoperability Working Group, July 30, 2004

PCI PIV Card Issuer

PIN Personal Identification Number

PKCS Public Key Certificate Standard

PKI Public Key Infrastructure

PKIX Public Key Infrastructure X.509

RA Registration Authority

RFC Request For Comments

RSA Rivest-Shamir-Adleman (encryption algorithm)

SHA-1 Secure Hash Algorithm, Version 1

S/MIME Secure Multipurpose Internet Mail Extension

SSL

URI

URL

Secure Sockets Layer

Uniform Resource Identifier

Uniform Resource Locator

U.S.C. United States Code

UUID

WWW

Universal Unique Identifier

World Wide Web

12. GLOSSARY Access Ability to make use of any information system (IS) resource. [NS4009] Access Control Process of granting access to IS resources only to authorized users,

programs, processes, or other systems. [NS4009] Accreditation Formal declaration by a Designated Approving Authority that an IS is

approved to operate in a particular security mode using a prescribed set of safeguards at an acceptable level of risk. [NS4009]

Activation Data Private data, other than keys, that are required to access cryptographic

modules (i.e., unlock private keys for signing or decryption events). Agency Any department, subordinate element of a department, or independent

organizational entity that is statutorily or constitutionally recognized as being part of the Executive Branch of the Federal Government.

Applicant The subscriber is sometimes also called an “applicant” after applying to a

CA for a certificate, but before the certificate issuance procedure is completed. [ABADSG footnote 32]

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. [NS4009]

Audit Data Chronological record of system activities to enable the reconstruction and

examination of the sequence of events and changes in an event. [NS4009audit trail]

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. [NS4009]

Backup Copy of files and programs made to facilitate recovery if necessary.

[NS4009] Binding Process of associating two related elements of information. [NS4009] Biometric A physical characteristic of a human being, including a photograph for visual

identification. For the purposes of this document, biometrics do not include handwritten signatures.

Certificate A digital representation of information which at least (1) identifies the CA 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 CA issuing it. [ABADSG]. As used in this CP, the term “Certificate” refers to certificates that expressly reference the OID of this CP in the “Certificate Policies” field of an X.509 v.3 certificate.

Certification Authority (CA) An authority trusted by one or more users to issue and manage X.509

Public Key Certificates and CARLs or CRLs. Certification Authority Revocation List (CARL)

A signed, time-stamped list of serial numbers of CA public key certificates, including cross-certificates that have been revoked.

CA Facility The collection of equipment, personnel, procedures, and structures that are

used by a CA to perform certificate issuance and revocation. Certification Authority Software

Key Management and cryptographic software used to manage certificates issued to subscribers.

Certificate Policy (CP) A specialized form of administrative policy tuned to electronic transactions

performed during certificate management. A CP addresses all aspects associated with the generation, production, distribution, accounting, compromise recovery, and administration of digital certificates. Indirectly, a CP 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.

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).

Certificate-Related Information

Information, such as a subscriber’s postal address, that is not included in a certificate. A CA managing certificates may use this information.

Certificate Revocation List (CRL)

A list maintained by a CA of the certificates it has issued that are revoked prior to their stated expiration date.

Certificate Status Authority A trusted entity that provides online verification to a relying party of a subject

certificate’s trustworthiness and may also provide additional attribute information for the subject certificate.

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.

Component Private Key Private key associated with a function of the certificate-issuing equipment,

as opposed to being associated with an operator or administrator.

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. [NS4009]

Computer Security Objects Registry (CSOR)

Computer Security Objects Registry operated by NIST.

Confidentiality Assurance that information is not disclosed to unauthorized entities or

processes. [NS4009] Contracting Federal Agency Any Federal government entity that contracts for services from an approved

Shared Service Provider. Cross-Certificate A certificate used to establish a trust relationship between two CAs. 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 1401]

Cryptoperiod Time span during which each key setting remains in effect. [NS4009] 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.

Discretionary Access Control Means of restricting access to objects based on user identity. Duration A field within a certificate that 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 Agency as defined above. Encrypted Network A network that is protected from outside access by NSA-approved high-

grade (Type I) cryptography. Examples are Secure Internet Protocol Routing Network (SIPRNET) and TOP SECRET networks.

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. Federal Bridge Certification Authority (FBCA)

The FBCA consists of a collection of PKI components (Certificate Authorities, Directories, Certificate Policies, and Certificate Practice Statements) that are used to provide peer-to-peer interoperability among Federal Agency CAs.

Firewall Gateway that limits access between networks in accordance with local security policy. [NS4009]

Information System Security Officer (ISSO)

Person responsible to the Designated Approving Authority for ensuring the security of an IS throughout its life-cycle, from design through disposal. [NS4009]

Inside Threat An entity with authorized access that has the potential to harm an IS through

destruction, disclosure, modification of data, and/or denial of service. Integrity Protection against unauthorized modification or destruction of information.

[NS4009]. 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.

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. [Adapted from ABADSG, “Commercial key escrow service”].

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 (2) even knowing one key, it is computationally infeasible to discover the other key.

Local Registration Authority (LRA)

An RA with responsibility for a local community.

Memorandum of Agreement (MOA)

An agreement between an organization and the FPKIPA allowing interoperation between two separate organizational CAs.

Mission Support Information Information that is important to the support of deployed and contingency

forces. Mutual Authentication Authentication when parties at both ends of a communication activity

authenticate each other (see “Authentication”). Naming Authority An organizational entity responsible for assigning DNs and for assuring that

each DN is meaningful and unique within its domain.

National Security System Any telecommunications or information system operated by the U.S. Government, the function, operation, or use of which involves intelligence activities; involves cryptologic activities related to national security; involves command and control of military forces; involves equipment that is an integral part of a weapon or weapons system; or is critical to the direct fulfillment of military or intelligence missions, but does not include a system that is to be used for routine administrative and business applications (including payroll, finance, logistics, and personnel management applications). [ITMRA]

Nonrepudiation 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. [NS4009]. Technical nonrepudiation 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 nonrepudiation 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. In the federal government PKI OIDs are used to uniquely identify each of the policies and cryptographic algorithms supported.

Out-of-Band Communication between parties using a means or method that differs from

the current method of communication (e.g., one party uses U.S. Postal Service mail to communicate with another party where current communication is occurring online).

Outside Threat An unauthorized entity from outside the domain perimeter that has the

potential to harm an IS 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 Sponsor Fills the role of a subscriber for nonhuman 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 certificate 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. The individual or group that is responsible for maintaining the SSP CPS and for ensuring that all SSP PKI components (e.g., CAs, CSSs, CMSs, RAs) are operated in compliance with this CP and the SSP CPS.

Privacy Restricting access to subscriber or relying party information in accordance

with Federal law and Agency 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 used to decrypt confidential information. In both cases, this key must be kept secret.

Public Key (1) The key of a signature key pair used to validate a digital signature. (2) The key of an encryption key pair 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.

Registration Authority (RA) An entity that is responsible for identification and authentication of certificate

subjects but does not sign or issue certificates (i.e., an RA is delegated certain tasks on behalf of an authorized CA).

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.

Relying Party A person or Agency 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. 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. Secret Key A “shared secret” used in symmetric cryptography, wherein users are

authenticated based on a password, PIN, or other information shared between the user and the remote host or server. A single key is shared between two parties: the sender, to encrypt a transmission, and the recipient, to decrypt the transmission, with the shared key being generated with an algorithm agreed to beforehand by the transacting parties.

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.

Subscriber A subscriber is an entity that (1) is the subject 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. This includes, but is not limited to, an individual, an application or network device.

System Equipment Configuration

A comprehensive accounting of all system hardware and software types and settings.

System High The highest security level supported by an IS. [NS4009] Technical Nonrepudiation The contribution of public key mechanisms to the provision of technical

evidence supporting a nonrepudiation 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. [NS4009]

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 Agency in confirming

subscriber identification during the registration process. Trusted Agents do not have automated interfaces with CAs.

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.

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. [NS4009]

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.

Zeroize 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 1401]

Appendix A – Verizon (Certificate, CRL, and OCSP Profiles) The following certificate profile provides specifics about the Verizon Top level SSP CA used for issuing subordinate CA certificates to Federal Agencies. This CA is issued one-way cross-certificate from the Federal Common Policy CA under the requirements of the Federal Common Policy.

Betrusted Production SSP CA A1

Field Criticality Value Version Integer value “2” forVersion 3 cert. Serial Number Integer (assigned by CA) (01 9a) Signature AlgorithmIdentifier Must match Algorithm Identifier in signatureAlgorithm field. The parameters

field is only populated when the algorithm is RSA. 1.2.840.113549.1.1.11 Sha256WithRSAEncryption

Parameters NULL For all RSA algorithms except id-RSASSA-PSS

Issuer CN=Federal Common Policy CA,OU=FPKI,O=U.S. Government,C=US

Validity Period 10 Yrs. . Subject CN=Betrusted Production SSP CA A1,OU=Betrusted Production SSP

CA A1,OU=SSP,O=Betrusted US Inc,C=US Subject Public Key Information

RSA Encryption 2048 key size

1.2.840.113549.1.1.1 RSA Encryption Parameters Format and meaning dependent upon algorithm

NULL For RSA, parameters field is populated with NULL. subjectPublicKey RSA 2048 bits modulus Extensions Authority Key Identifier FALSE 160 bit SHA-1 Subject Key Identifier FALSE 160 bit SHA-1 Basic Constraints TRUE pathlength = None, cA = TRUE Key Usage TRUE digitalSignature, nonRepudiation, certificateSigning, off-lineCRL

Signing, cRLSigning Certificate Policies FALSE Id-fpki-common-policy Policy Identifier=2.16.840.1.101.3.2.1.3.6 Id-fpki-common-hardware

Policy Identifier=2.16.840.1.101.3.2.1.3.7

Id-fpki-common-device Policy Identifier=2.16.840.1.101.3.2.1.3.8 Id-fpki-common-authentication


Id-fpki-common-cardAuth


CRL Distribution Point FALSE http://http.fpki.gov/fcpca/fcpca.crl ldap://ldap.fpki.gov/cn=Federal Common Policy CA,ou=FPKI,o=U.S.

Government,c=US?certificateRevocationList (ldap://ldap.fpki.gov/cn%3dFederal%20Common%20Policy%20CA,ou%3dFPKI,o%3dU.S.%20Government,c%3dUS?certificateRevocationList)


FALSE

1.3.6.1.5.5.7.48.2 http://http.fpki.gov/fcpca/caCertsIssuedTofcpca.p7c

1.3.6.1.5.5.7.48.2 ldap://ldap.fpki.gov/cn=Federal Common Policy CA,ou=FPKI,o=U.S.

Government,c=US?cACertificate;binary,crossCertificatePair;binary (ldap://ldap.fpki.gov/cn=Federal%20Common%20Policy%20CA,ou=FPKI,o=U.S.%20Government,c=US?cACertificate;binary,crossCertificatePair;binary)

Subject Information Access

FALSE

1.3.6.1.5.5.7.48.5 http://sia1.ssp-strong-id.net/CA/SSP-CA-A1-SIA.p7c

1.3.6.1.5.5.7.48.5 ldap://dir1.ssp-strong-id.net/cn=Betrusted Production SSP CA A1,ou=Betrusted Production SSP CA A1,ou=SSP,o=Betrusted US Inc,c=US?cACertificate;binary,crossCertificatePair;binary (ldap://dir1.ssp-strong-id.net/cn=Betrusted%20Production%20SSP%20CA%20A1,ou=Betrusted%20Production%20SSP%20CA%20A1,ou=SSP,o=Betrusted%20US%20Inc,c=US?cACertificate;binary,crossCertificatePair;binary)

The following intermediary CA certificate profile provides specifics about the next generation Verizon Top level SSP CA used for issuing subordinate CA certificates to Federal Agencies. This CA is issued one way cross-certificate subordinated to the Federal Common Policy CA under the requirements of the Federal Common Policy.

Verizon SSP CA A2 Field Criticality Value Version Integer value “2” forVersion 3 cert. Serial Number Integer (assigned by CA) Signature AlgorithmIdentifier Must match Algorithm Identifier in signatureAlgorithm field. The parameters

field is only populated when the algorithm is RSA. 1.2.840.113549.1.1.11 Sha256WithRSAEncryption

Parameters NULL For all RSA algorithms except id-RSASSA-PSS

Issuer CN=Federal Common Policy CA,OU=FPKI,O=U.S. Government,C=US

Validity Period 10 Yrs. . Subject CN=Verizon -SSP CA A2,OU=SSP,O=Verizon,C=US Subject Public Key Information


1.2.840.113549.1.1.1 RSA Encryption Parameters Format and meaning dependent upon algorithm

NULL For RSA, parameters field is populated with NULL. subjectPublicKey RSA 2048 bits modulus Extensions Authority Key Identifier FALSE 160 bit SHA-1 Subject Key Identifier FALSE 160 bit SHA-1 Basic Constraints TRUE pathlength Constraint = None, Subject Type CA = TRUE Key Usage TRUE certificateSigning, cRLSigning Policy Constraints FALSE Inhibit Policy Mapping Skip Certs = 0

Inhibit any policy = 0 Certificate Policies FALSE Id-fpki-common-policy Policy Identifier=2.16.840.1.101.3.2.1.3.6 Id-fpki-common-hardware






Id-fpki-common-piv-contentSigning


CRL Distribution Point FALSE http://http.fpki.gov/fcpca/fcpca.crl Authority Information Access

FALSE

1.3.6.1.5.5.7.48.2 http://http.fpki.gov/fcpca/caCertsIssuedTofcpca.p7c

Subject Information Access

FALSE

1.3.6.1.5.5.7.48.5 http://sia1.ssp-strong-id.net/CA/VZ-SSP-CA-A2-SIA.p7c

Note: The following profiles have standardized naming where “<Agency>” may be replaced with either an upper cased agency or department acronym. The “<department>” string would be replaced with the primary domain of the agency or department. AGENCY Subordinate SSP CA The Agency subordinate SSP CA profile provides specifics about an Agency SSP CA for issuing user based certificates for employees and affiliated personnel. It is subordinated to a general purpose Betrusted SSP CA that is in turn subordinated to the Federal Common Policy CA under the requirements of the Federal Common Policy.

Agency Certificate Authority Bx

Field Criticality Value Version Integer value of “2” for Version 3 cert. Serial Number Integer (assigned by CA) Signature AlgorithmIdentifier Must match Algorithm Identifier in signatureAlgorithm field. The parameters

field is only populated when the algorithm is RSA. 1.2.840.113549.1.1.5 SHA-1WithRSAEncryption (used only in certs issued prior to 2011)

1.2.840.113549.1.1.10 id-RSASSA-PSS (RSA with PSS padding; 800-78-1 requires use with SHA-256 hash algorithm)

1.2.840.113549.1.1.11 Sha256WithRSAEncryption Parameters 2.16.840.1.101.3.4.2.1 For id-RSASSA-PSS only, specify the SHA-256 hash algorithm as a

parameter NULL For all RSA algorithms except id-RSASSA-PSS

Issuer CN=Verizon Z-SSP -CA -A2,OU=SSP,O=Verizon,C=US or CN=Betrusted Production SSP CA A1,OU=Betrusted Production SSP CA A1,OU=SSP,O=Betrusted US Inc,C=US

Validity Period 10 Yrs. Must span Past the Parent validity Subject

Must use one of the CA certificate name forms specified in section 3.1.5 of this CPS.

Subject Public Key Information


1.2.840.113549.1.1.1 RSA Encryption 1.2.840.10045.2.1 Elliptic curve key

Parameters Format and meaning dependent upon algorithm NULL For RSA, parameters field is populated with NULL.

EcpkParameters Named Curves (only specified if curves are used)

Implicitly specify parameters through an OID associated with a NIST approved curve referenced in 800-78-1:

1.2.840.10045.3.1.7 Curve P-256 1.3.132.0.34 Curve P-384 1.3.132.0.17 Curve B-283

subjectPublicKey BIT STRING For RSA public keys: certificates that expire before December 31, 2010 shall have a modulus of 1024, 2048, 3072, or 4096 bits; certificates that expire on or after December 31, 2010 shall have a modulus of 2048, 3072, or 4096 bits. (No sunset date for specified elliptic curves.)

Extensions Authority Key Identifier FALSE 160 bit SHA-1

Subject Key Identifier FALSE 160 bit SHA-1 Basic Constraints TRUE pathlength = Null, CA=TRUE Key Usage TRUE digitalSignature, nonRepudiation, certificateSigning, cRLSigning Certificate Policies Id-fpki-common-policy Policy Identifier=2.16.840.1.101.3.2.1.3.6 Id-fpki-common-hardware






Id-fpki-common-piv-contentSigning


CRL Distribution Point FALSE Legacy: http://cdp1.ssp-strong-id.net/CDP/SSP-CA-A1.crl

Next generation: http://cdp1.ssp-strong-id.net/CDP/VZ-SSP-CA-A2.crl Authority Information Access

FALSE

1.3.6.1.5.5.7.48.2 Legacy: http://aia1.ssp-strong-id.net/CA/SSP-CA-A1.p7c Next generation: http://aia1.ssp-strong-id.net/CA/VZ-SSP-CA-A2.p7c

1.3.6.1.5.5.7.48.1 Legacy: http://ocsp1.ssp-strong-id.net/SSP-CA-A1

Next generation: http://ocsp1.ssp-strong-id.net/VZ-SSP-CA-A2 Subject Information Access

FALSE

1.3.6.1.5.5.7.48.5 http://aia1.ssp-strong-id.net/CA/<Agency>-SSP-CA-Bx.p7c

http://cdp2.ssp-strong-id.net/CDP/SSP-CA-A1.crl

http://cdp1.ssp-strong-id.net/CDP/VZ-SSP-CA-A2.crl


http://aia1.ssp-strong-id.net/CA/VZ-SSP-CA-A2.p7c

http://ocs2.ssp-strong-id.net/SSP-CA-A1/

http://ocsp1.ssp-strong-id.net/VZ-SSP-CA-A2/

http://aia1.ssp-strong-id.net/CA/%3cAgency_CA_acronym%3e.p7c

PIV Authentication Certificate Profile EE PIV Authentication Certificate

Field Criticality Value Version Integer value of “2” for Version 3 cert. Serial Number Integer (assigned by CA) Signature Must match Algorithm Identifier in signatureAlgorithm field. The parameters field

is only populated when the algorithm is RSA. Algorithm


1.2.840.113549.1.1.11 Sha256WithRSAEncryption 1.2.840.10045.4.3.2 ecdsa-with-SHA256 1.2.840.10045.4.3.3 ecdsa-with-SHA384

Parameters 2.16.840.1.101.3.4.2.1 For id-RSASSA-PSS only, specify the SHA-256 hash algorithm as a parameter

NULL For all RSA algorithms except id-RSASSA-PSS Issuer

Must use one of the name forms specified in section 3.1. of this CPS. Validity Period 3 years maximum Subject

Must use one of the name forms specified in section 3.1.1 of this CPS. Subject Public Key Information


algorithm AlgorithmIdentifier Public key algorithm associated with the public key. May be either RSA or elliptic

curve. 1.2.840.113549.1.1.1 RSA Encryption

1.2.840.10045.2.1 Elliptic curve key parameters Format and meaning dependent upon algorithm

NULL For RSA, parameters field is populated with NULL. EcpkParameters

namedCurve Implicitly specify parameters through an OID associated with a NIST approved curve referenced in 800-78-1

1.2.840.10045.3.1.7 Curve P-256 1.3.132.0.16 34 Curve P-384

implicitlyCA NULL Obtain parameters from issuer’s certificate subjectPublicKey BIT STRING For RSA public keys: certificates shall have a modulus of at least

2048 bits. (No sunset date for specified elliptic curves.) Extensions Authority Key Identifier FALSE 160 bit SHA-1 Subject Key Identifier FALSE 160 bit SHA-1 Subject Alternate Name FALSE This extension MUST include the FASC-N and after October 15, 2015 must also

include a UUID as specified below. Any additional name types may be present; only the most common are specified here. Other names may be included to support local applications.

Other Name pivFASC-N (2.16.840.1.101.3.6.6) as Octet String This field contains the UUID from the GUID data element of the CHUID of the PIV Card encoded as a URI as specified in Section 3 of RFC 4122.

Other name Microsoft UPN (1.3.6.1.4.1.311.20.2.3) as UTF8string Key Usage TRUE digitalSignature Extended Key Usage FALSE This extension need not appear. If included to support specific applications, the

extension MUST include the anyExtendedKeyUsage value. Additional key purposes may be specified.

1.3.6.1.5.5.7.3.2 TLS Client Authentication 1.3.6.1.4.1.311.20.2.2 Microsoft Smart Card Logon 1.3.6.1.5.2.3.4 id-pkinit-KPClientAuth 1.3.6.1.5.5.7.3.21 id-kp-secureShellClient 2.5.29.37.0 anyExtendedKeyUsage OID indicates that the certificate may also be used for

other purposes meeting the requirements specified in the key usage extension. Certificate Policies One policy OID is specified for PIV Authentication certificates. Other policy OIDs

may be asserted as well. id-fpki-common-authentication

FALSE 2.16.840.1.101.3.2.1.3.13

CRL Distribution Point FALSE Public http://cdp1.ssp-strong-id.net/CDP/<Agency>-SSP-CA-Bx.crl Authority Information Access

FALSE

1.3.6.1.5.5.7.48.2 http://aia1.ssp-strong-id.net/CA/<Agency>-SSP-CA-Bx.p7c 1.3.6.1.5.5.7.48.1 http://ocsp1.ssp-strong-id.net/<Agency>-SSP-CA-Bx piv-interim (2.16.840.1.101.3.6.9.1)

The value of this extension is asserted as follows: TRUE – If at the time of credential issuance, the FBI National Criminal History Fingerprint Check is completed successfully and a NACI has been initiated but not completed. FALSE – If at the time of credential issuance, the subject’s NACI has been completed and successfully adjudicated.

interim_indicator FALSE Boolean (Defaulted to True)

http://cdp2.ssp-strong-id.net/CDP/GSA-SSP-CA-B5.crl

http://aia1.ssp-strong-id.net/CA/GSA-SSP-CA-B5.p7c

http://ocs2.ssp-strong-id.net/GSA-SSP-CA-B5/

Derived PIV Authentication Certificate Profile EE Derived PIV Authentication Certificate

Field Criticality Value Version Integer value of “2” for Version 3 cert. Serial Number Integer (assigned by CA) Signature Must match Algorithm Identifier in signatureAlgorithm field. The parameters field is

only populated when the algorithm is RSA. Algorithm


1.2.840.113549.1.1.11 Sha256WithRSAEncryption 1.2.840.10045.4.3.2 ecdsa-with-SHA256 1.2.840.10045.4.3.3 ecdsa-with-SHA384

Parameters 2.16.840.1.101.3.4.2.1 For id-RSASSA-PSS only, specify the SHA-256 hash algorithm as a parameter

NULL For all RSA algorithms except id-RSASSA-PSS Issuer

Must use one of the name forms specified in section 3.1. of this CPS. Validity Period 3 years maximum, must not go beyond the PIV card expiration date Subject








1.2.840.10045.3.1.7 Curve P-256 1.3.132.0.16 34 Curve P-384

implicitlyCA NULL Obtain parameters from issuer’s certificate subjectPublicKey BIT STRING For RSA public keys: certificates shall have a modulus of at least

2048 bits. (No sunset date for specified elliptic curves.) Extensions Authority Key Identifier FALSE 160 bit SHA-1 Subject Key Identifier FALSE 160 bit SHA-1 Subject Alternate Name FALSE This extension MUST include a UUID as specified below. Any additional name types

may be present; only the most common are specified here. Other names may be included to support local applications.

Uniform Resource Identifier

This field contains the UUID from the GUID data element of the CHUID of the PIV Card encoded as a URI as specified in Section 3 of RFC 4122.

Key Usage TRUE digitalSignature Extended Key Usage FALSE This extension need not appear. If included to support specific applications, the

extension MUST include the anyExtendedKeyUsage value. Additional key purposes may be specified.

1.3.6.1.5.5.7.3.2 TLS Client Authentication 1.3.6.1.5.2.3.4 id-pkinit-KPClientAuth

2.5.29.37.0 anyExtendedKeyUsage OID indicates that the certificate may also be used for other purposes meeting the requirements specified in the key usage extension.

Certificate Policies One policy OID is specified for PIV Authentication certificates. Other policy OIDs may be asserted as well.

Id-fpki-common-derived-pivAuth

FALSE 2.16.840.1.101.3.2.1.3.40

Id-fpki-common-derived-pivAuth-hardware

FALSE 2.16.840.1.101.3.2.1.3.41

CRL Distribution Point FALSE Public http://cdp1.ssp-strong-id.net/CDP/<Agency>-SSP-CA-Bx.crl Public Authority Information Access

FALSE

1.3.6.1.5.5.7.48.2 http://aia1.ssp-strong-id.net/CA/<Agency>-SSP-CA-Bx.p7c 1.3.6.1.5.5.7.48.1 http://ocsp1.ssp-strong-id.net/<Agency>-SSP-CA-Bx/ piv-interim (2.16.840.1.101.3.6.9.1)

The value of this extension is asserted as follows: TRUE – If at the time of credential issuance, the FBI National Criminal History Fingerprint Check is completed successfully and a NACI has been initiated but not completed. FALSE – If at the time of credential issuance, the subject’s NACI has been completed and successfully adjudicated.

interim_indicator FALSE Boolean (Defaulted to True)




PIV Card Authentication Certificate Profile EE PIV Authentication Certificate


only populated when the algorithm is RSA. Algorithm 1.2.840.113549.1.1.10 id-RSASSA-PSS (RSA with PSS padding; 800-78-1 requires use with SHA-256

hash algorithm) 1.2.840.113549.1.1.11 Sha256WithRSAEncryption 1.2.840.10045.4.3.2 ecdsa-with-SHA256 1.2.840.10045.4.3.3 ecdsa-with-SHA384 Parameters 2.16.840.1.101.3.4.2.1 For id-RSASSA-PSS only, specify the SHA-256 hash algorithm as a parameter NULL For all RSA algorithms except id-RSASSA-PSS Issuer

Must use one of the name forms specified in section 3.1.5 of this CPS. Validity Period 3 years maximum Subject Null Subject DN

or serialNumber =FASC-N2, ou=<Structural Container>, dc=<optional>, dc=<optional>,dc=<department>, dc=gov or serialNumber =FASC-N ou=<Structural Container>, ou=<agency name>, ou=<department name>,o=U.S. Government, c=US serialNumber=UUID, [ou=structural_container], [ou=agency], [ou=department], o=U.S. Government, C=US serialNumber=UUID, [ou=structural_container], [dc=orgN], …, [dc=org1], dc=org0, dc=gov serialNumber=UUID, [ou=structural_container], [dc=orgN], …, [dc=org1], dc=org0, dc=mil Must use one of the name forms specified in section 3.1.1 of the Common Certificate Policy.







2 Practice Note: The FASC-N [PACS] consists of 40 decimal digits that are encoded as a 25-byte binary value. This 25-byte binary value may be encoded directly into the pivFASC-N name type in the subject alternative name extension, but when included in the subject field the FASC-N must be encoded as a PrintableString that is at most 64 characters long. This policy does not mandate any particular method for encoding the FASC-N within the serial number attribute as long as the same encoding method is used for all certificates issued by a CA. Acceptable methods for encoding the FASC-N within the serial number attribute include encoding the 25-byte binary value as 50 bytes of ASCII HEX or encoding the 40 decimal digits as 40 bytes of ASCII decimal.


1.2.840.10045.3.1.7 Curve P-256 1.3.132.0.16 34 Curve P-384

implicitlyCA NULL Obtain parameters from issuer’s certificate subjectPublicKey BIT STRING For RSA public keys: certificates that expire before January 1, 2014

shall have a modulus of at least 1024 or 2048 bits; certificates that expire on or after January 1, 2014 shall have a modulus of at least 2048 bits. (No sunset date for specified elliptic curves.)

Extensions Authority Key Identifier FALSE 160 bit SHA-1 Subject Key Identifier FALSE 160 bit SHA-1 Subject Alternate Name FALSE Must include FASC-N name form and after October 15, 2015 must also include a

UUID. No other name forms may be included. Other Name pivFASC-N (2.16.840.1.101.3.6.6) as Octet String Uniform Resource Identifier

This field contains the UUID from the GUID data element of the CHUID of the PIV Card encoded as a URI as specified in Section 3 of RFC 4122.

Key Usage TRUE digitalSignature Extended Key Usage TRUE Key Purpose ID Id-PIV-cardAuth 2.16.840.1.101.3.6.8 Certificate Policies FALSE id-fpki-common-cardAuth 2.16.840.1.101.3.2.1.3.17 CRL Distribution Point FALSE Public http://cdp1.ssp-strong-id.net/CDP/<Agency>-SSP-CA-Bx.crl Authority Information Access

FALSE

1.3.6.1.5.5.7.48.2 http://aia1.ssp-strong-id.net/CA/<Agency>-SSP-CA-Bx.p7c 1.3.6.1.5.5.7.48.1 http://ocsp1.ssp-strong-id.net/<Agency>-SSP-CA-Bx/ piv-interim (2.16.840.1.101.3.6.9.1)

FALSE The value of this extension is asserted as follows: TRUE – If at the time of credential issuance, the FBI National Criminal History Fingerprint Check is completed successfully and a NACI has been initiated but not completed. FALSE – If at the time of credential issuance, the subject’s NACI has been completed and successfully adjudicated.

interim_indicator Boolean (Defaulted to True)




PIV Signing Certificate Profile EE Signing Certificate Field Criticality Value Version Integer value of “2” for Version 3 cert. Serial Number Integer (assigned by CA) Signature Must match Algorithm Identifier in signatureAlgorithm field. The

parameters field is only populated when the algorithm is RSA. Algorithm 1.2.840.113549.1.1.10 id-RSASSA-PSS (RSA with PSS padding; 800-78-1 requires use with

SHA-256 hash algorithm) 1.2.840.113549.1.1.11 Sha256WithRSAEncryption 1.2.840.10045.4.3.2 ecdsa-with-SHA256 1.2.840.10045.4.3.3 ecdsa-with-SHA384 Parameters 2.16.840.1.101.3.4.2.1 For id-RSASSA-PSS only, specify the SHA-256 hash algorithm as a

parameter NULL For all RSA algorithms except id-RSASSA-PSS Issuer

Must use one of the name forms specified in section 3.1.5 of this CPS.

Validity Period 3 years maximum Subject




algorithm AlgorithmIdentifier Public key algorithm associated with the public key. May be either RSA

or elliptic curve. 1.2.840.113549.1.1.1 RSA Encryption




1.2.840.10045.3.1.7 Curve P-256 1.3.132.0.16 34 Curve P-384

implicitlyCA NULL Obtain parameters from issuer’s certificate subjectPublicKey BIT STRING For RSA public keys: certificates that expire before

December 31, 2008 shall have a modulus of at least 1024 or 2048 bits; certificates that expire on or after December 31, 2008 shall have a modulus of at least 2048 bits. (No sunset date for specified elliptic curves.)

Extensions Authority Key Identifier FALSE 160 bit SHA-1 Subject Key Identifier FALSE 160 bit SHA-1 Subject Alternate Name FALSE RFC822 Email Address Key Usage TRUE digitalSignature, nonRepudiation Extended Key Usage FALSE This extension need not appear. If included in a certificate that is

specifically designated for use in a single application, the extension may be marked either critical or non-critical. If included in any other certificate (to support specific applications), the extension must include the

anyExtendedKeyUsage 2.5.29.37.0 value and must be marked non-critical. Additional key purposes may be specified.

2.5.29.37.0 anyExtendedKeyUsage OID indicates that the certificate may also be used for other purposes meeting the requirements specified in the key usage extension.

Certificate Policies FALSE Two policy OIDs are defined for digital signature certificates issued to human subscribers under the Common Certificate Policy. End Entity certificates should assert one of the three policies. Other policy OIDs may be asserted as well.

id-fpki-common-policy 2.16.840.1.101.3.2.1.3.6 id-fpki-common-hardware

2.16.840.1.101.3.2.1.3.7

CRL Distribution Point FALSE http://cdp1.ssp-strong-id.net/CDP/<Agency>-SSP-CA-Bx.crl Authority Information Access

FALSE

1.3.6.1.5.5.7.48.2 http://aia1.ssp-strong-id.net/CA/<Agency>-SSP-CA-Bx.p7c 1.3.6.1.5.5.7.48.1 http://ocsp1.ssp-strong-id.net/<Agency>-SSP-CA-Bx




PIV Key Management (Encryption) Certificate Profile EE Encryption Certificate


only populated when the algorithm is RSA. Algorithm Choice of following algorithms 1.2.840.113549.1.1.10 id-RSASSA-PSS (RSA with PSS padding; 800-78-1 requires use with SHA-256 hash

algorithm) 1.2.840.113549.1.1.11 Sha256WithRSAEncryption 1.2.840.10045.4.3.2 ecdsa-with-SHA256 1.2.840.10045.4.3.3 ecdsa-with-SHA384 Parameters 2.16.840.1.101.3.4.2.1 For id-RSASSA-PSS only, specify the SHA-256 hash algorithm as a parameter NULL For all RSA algorithms except id-RSASSA-PSS Issuer

Must use one of the name forms specified in section 3.1.5 of this CPS. Validity Period 3 Years Subject








1.2.840.10045.3.1.7 Curve P-256 1.3.132.0.16 34 Curve P-384

implicitlyCA NULL Obtain parameters from issuer’s certificate subjectPublicKey BIT STRING For RSA public keys: certificates that expire before December 31, 2008

shall have a modulus of at least 1024 or 2048 bits; certificates that expire on or after December 31, 2008 shall have a modulus of at least 2048 bits. (No sunset date for specified elliptic curves.)

Extensions Authority Key Identifier FALSE 160 bit SHA-1 Subject Key Identifier FALSE 160 bit SHA-1 Subject Alternate Name FALSE RFC822 Email Address Key Usage TRUE keyEncipherment –When Public Key is RSA keyAgreement – When Public Key is elliptic curve Certificate Policies FALSE Three policy OIDs are defined for digital signature certificates issued to human

subscribers under the Common Certificate Policy. End Entity certificates should assert one of the three policies. Other policy OIDs may be asserted as well.

id-fpki-common-policy 2.16.840.1.101.3.2.1.3.6

Id-fpki-common-hardware

2.16.840.1.101.3.2.1.3.7

CRL Distribution Point FALSE http://cdp1.ssp-strong-id.net/CDP/<Agency>-SSP-CA-Bx.crl Authority Information Access

FALSE

1.3.6.1.5.5.7.48.2 http://aia1.ssp-strong-id.net/CA/<Agency>-SSP-CA-Bx.p7c 1.3.6.1.5.5.7.48.1 http://ocsp1.ssp-strong-id.net/<Agency>-SSP-CA-Bx/




Device Certificate Profile The following profile specifies the requirements for the Device certificates which may be utilized for devices which may include TLS, VPN, or other infrastructure certificates.

TLS cert Field Criticality Value Version Integer value of “2” for Version 3 cert. Serial Number Integer (assigned by CA) Signature Must match Algorithm Identifier in signatureAlgorithm field. The

parameters field is only populated when the algorithm is RSA. Algorithm Choice of following algorithms 1.2.840.113549.1.1.10 id-RSASSA-PSS (RSA with PSS padding; 800-78-1 requires use

with SHA-256 hash algorithm) 1.2.840.113549.1.1.11 Sha256WithRSAEncryption 1.2.840.10045.4.3.2 ecdsa-with-SHA256 1.2.840.10045.4.3.3 ecdsa-with-SHA384 Parameters 2.16.840.1.101.3.4.2.1 For id-RSASSA-PSS only, specify the SHA-256 hash algorithm as a



Validity Period 3 Years. maximum Subject cn=<Device Name or Fully Qualified Domain Name or Physical IP

address>, ou=devices, dc=<optional>, dc=<optional>, dc=<Department>,dc=gov or cn=<Device Name or Fully Qualified Domain Name or Physical IP address>, ou=devices, ou=<agency name>, ou=<department name>, o=U.S. Government, c=US C=US, O=U.S. Government, ou=<department name>, <ou=agency>, ou=Devices,CN= <Device Name or Fully Qualified Domain Name or Physical IP address,or DC=gov, DC= <department acronyms>,<OU=agency>, OU=Devices, CN=<Device Name or Fully Qualified Domain Name or Physical IP address> ` Must use one of the name forms specified in section 3.1.1 of this CPS.



algorithm AlgorithmIdentifier Public key algorithm associated with the public key. May be either

RSA or elliptic curve. 1.2.840.113549.1.1.1 RSA Encryption 1.2.840.10045.2.1 Elliptic curve key parameters Format and meaning dependent upon algorithm NULL For RSA, parameters field is populated with NULL. EcpkParameters namedCurve Implicitly specify parameters through an OID associated with a NIST

approved curve referenced in 800-78-1 1.2.840.10045.3.1.7 Curve P-256 1.3.132.0.16 34 Curve P-384

implicitlyCA NULL Obtain parameters from issuer’s certificate subjectPublicKey BIT STRING For RSA public keys: certificates that expire before

December 31, 2008 shall have a modulus of at least 1024 or 2048 bits; certificates that expire on or after December 31, 2008 shall have a modulus of at least 2048 bits. (No sunset date for specified elliptic curves.)

Extensions Authority Key Identifier FALSE 160 bit SHA-1 Subject Key Identifier FALSE 160 bit SHA-1 Key Usage TRUE digitalSignature, keyEncipherment –When Public Key is RSA digitalSignature, keyAgreement – When Public Key is elliptic curve Subject Alternate Name FALSE RFC822 Email Address (Alias email of an administer) (Optional) IP Address (Optional) DNS Name (Optional) Extended Key Usage This extension may be included as either a critical or non-critical

extension if its inclusion is required by the application(s) for which the certificate will be used. Additional key purposes may be specified.

2.5.29.37.0 FALSE anyExtendedKeyUsage (Only used if other extended key usages are

required for application usage) in which case the any ExtendedKeyUage must also be asserted unless explicit usage by the extensions. .

Certificate Policies FALSE id-fpki-common-devices Policy Identifier=2.16.840.1.101.3.2.1.3.8 CRL Distribution Point FALSE http://cdp1.ssp-strong-id.net/CDP/<Agency>-SSP-CA-Bx.crl Authority Information Access FALSE 1.3.6.1.5.5.7.48.2 http://aia1.ssp-strong-id.net/CA/<Agency>-SSP-CA-Bx.p7c 1.3.6.1.5.5.7.48.1 http://ocsp1.ssp-strong-id.net/<Agency>-SSP-CA-Bx

Content Signing Certificate Profile The following profile specifies the requirements for a Content Signing certificates which may be utilized for signing the FIPS 201 Card content object. This certificate is generated for the card management system.

Content Signing cert Field Criticality Value Version Integer value of “2” for Version 3 cert. Serial Number Integer (assigned by CA) Signature Must match Algorithm Identifier in signatureAlgorithm field. The parameters

field is only populated when the algorithm is RSA. Algorithm Choice of following algorithms 1.2.840.113549.1.1.10 id-RSASSA-PSS (RSA with PSS padding; 800-78-1 requires use with SHA-256

hash algorithm) 1.2.840.113549.1.1.11 Sha256WithRSAEncryption 1.2.840.10045.4.3.2 ecdsa-with-SHA256




1.2.840.10045.4.3.3 ecdsa-with-SHA384 Parameters 2.16.840.1.101.3.4.2.1 For id-RSASSA-PSS only, specify the SHA-256 hash algorithm as a parameter NULL For all RSA algorithms except id-RSASSA-PSS Issuer

Must use one of the name forms specified in section 3.1.5 of this CPS. Validity Period 9 years maximum (3 years usages signing then replace with a new one)

this certificate should be left to expire naturally unless compromised Subject C=US, O=U.S. Government, ou=<department name>, <ou=agency>,

ou=Devices,CN=<Department Acronym>-Content-Signer> or DC=gov, DC= <department acronyms>,<OU=agency>, OU=Devices, CN=<Department Acronym>-Content-Signer> Must use one of the name forms specified in section 3.1.1 of this CPS.



algorithm AlgorithmIdentifier Public key algorithm associated with the public key. May be either RSA or

elliptic curve. 1.2.840.113549.1.1.1 RSA Encryption 1.2.840.10045.2.1 Elliptic curve key parameters Format and meaning dependent upon algorithm NULL For RSA, parameters field is populated with NULL. EcpkParameters namedCurve Implicitly specify parameters through an OID associated with a NIST approved

curve referenced in 800-78-1 1.2.840.10045.3.1.7 Curve P-256 1.3.132.0.16 34 Curve P-384 implicitlyCA NULL Obtain parameters from issuer’s certificate subjectPublicKey BIT STRING For RSA public keys: certificates have a modulus of at least

2048 bits. (No sunset date for specified elliptic curves.) Extensions Authority Key Identifier FALSE 160 bit SHA-1 Subject Key Identifier FALSE 160 bit SHA-1 Key Usage TRUE digitalSignature–When Public Key is RSA digitalSignature– When Public Key is elliptic curve Subject Alternate Name FALSE RFC822 Email Address (Alias email of an administer) (Optional) IP Address (Optional) DNS Name (Optional) Extended Key Usage boolean Note that no other extended key usages are specified to limit usage of this

certificate type to Content signing purposes. Id-PIV-content-signing keyPurposeID specified that the public key may be used to verify signatures on PIV CHUIDs and PIV biometrics

2.16.840.1.101.3.6.7 Certificate Policies FALSE id-fpki-common-PIV-contentSigning


CRL Distribution Point FALSE http://cdp1.ssp-strong-id.net/CDP/<Agency>-SSP-CA-Bx.crl



FALSE

1.3.6.1.5.5.7.48.2 http://aia1.ssp-strong-id.net/CA/<Agency>-SSP-CA-Bx.p7c 1.3.6.1.5.5.7.48.1 http://ocsp1.ssp-strong-id.net/<Agency>-SSP-CA-Bx/ SSP OCSP Responder Certificate The OCSP Responder certificate is assumed to be issued by the same CA using the same key as the Subscriber Certificate.

OCSP Responder cert Field Criticality Value Version Integer value of “2” for Version 3 cert. Serial Number Integer (assigned by CA) Signature Must match Algorithm Identifier in signatureAlgorithm field. The parameters

field is only populated when the algorithm is RSA. Algorithm Choice of following algorithms 1.2.840.113549.1.1.10 id-RSASSA-PSS (RSA with PSS padding; 800-78-1 requires use with SHA-

256 hash algorithm) 1.2.840.113549.1.1.11 Sha256WithRSAEncryption 1.2.840.10045.4.3.2 ecdsa-with-SHA256 1.2.840.10045.4.3.3 ecdsa-with-SHA384 Parameters 2.16.840.1.101.3.4.2.1 For id-RSASSA-PSS only, specify the SHA-256 hash algorithm as a


Must use one of the name forms specified in section 3.1.5 of this CPS. Validity Period Every 30 days or every or 72 hours with automatic resigning Subject CN=<Agency>-SSP-OCSP, OU=PKI, OU=Services, DC=<department>,

DC=gov Subject Public Key Information


algorithm AlgorithmIdentifier Public key algorithm associated with the public key. May be either RSA or

elliptic curve. 1.2.840.113549.1.1.1 RSA Encryption




1.2.840.10045.3.1.7 Curve P-256 1.3.132.0.16 34 Curve P-384

implicitlyCA NULL Obtain parameters from issuer’s certificate subjectPublicKey For RSA public keys: certificates shall have a modulus of 2048, 3072, or 4096

bits. (No sunset date for specified elliptic curves.) Extensions Authority Key Identifier FALSE 160 bit SHA-1 Subject Key Identifier FALSE 160 bit SHA-1 Key Usage TRUE digitalSignature Subject Alternate Name FALSE HTTP URL for the OCSP Responder



http://ocsp1.ssp-strong-id.net/<Agency>-SSP-CA-Bx Extended Key Usage TRUE id-kp-OCSPSigning {1 3 6 1 5 5 7 3 9} No Check FALSE id-pkix-ocsp-nocheck; {1 3 6 1 5 5 7 48 1 5}

Null

Certificate Policies FALSE id-fpki-common-policy Policy Identifier=2.16.840.1.101.3.2.1.3.6 id-fpki-common-hardware


id-fpki-common-devices Policy Identifier=2.16.840.1.101.3.2.1.3.8 id-fpki-common-authentication


id-fpki-common-cardAuth


id-fpki-common-piv-contentSigning



SSP CRL Format as Full and Complete CRLs CRL Profile Field Criticality Value Version V2 CRL Integer value (1) Signature Must match Algorithm Identifier in signatureAlgorithm field. The

parameters field is only populated when the algorithm is RSA. Algorithm Choice of following algorithms 1.2.840.113549.1.1.10 id-RSASSA-PSS (RSA with PSS padding; 800-78-1 requires use with

SHA-256 hash algorithm) 1.2.840.113549.1.1.11 Sha256WithRSAEncryption 1.2.840.10045.4.3.2 ecdsa-with-SHA256 1.2.840.10045.4.3.3 ecdsa-with-SHA384 Parameters 2.16.840.1.101.3.4.2.1 For id-RSASSA-PSS only, specify the SHA-256 hash algorithm as a



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 (in

Generalized Time) userCertificate Integer – serial number of the certificate being revoked Revocation Date YYMMDDHHMMSSZ Use for dates up to and including 2049.

YYYYMMDDHHMMSSZ Use for dates after 2049 CRL Entry Extension Reason Code FALSE Any one of these CRL reasons may be asserted: keyCompromise,

cAcompromise, affiliationChanged, superseded, cessationOfOperation, certificateHold. If the revocation reason is unspecified, then the reasonCode extension should not be included. The removeFromCRL reason code may only be used in delta CRLs. The certificateHold reason code may only be used for end entity certificates.

Invalidty Date FALSE YYYYMMDDHHMMSSZ use this format for all dates.

CRL Extensions CRL Number FALSE Monotonically increasing integer (never repeated) Authority Key Identifier FALSE Octet String (same as in Authority Key Identifier field in certificates issued

by the CA) Issuing Distribution Point TRUE If the issuer generates segmented CRLs (i.e., CRLs that do not cover all

unexpired certificates in which the issuer field contains the same name as the issuer field in the CRL), this field must be present and must specify the same names as are specified in the distributionPoint field of the cRLDistributionPoints extensions of certificates covered by this CRL.

PKI Entity Certificate Profile e.g. RAO, RRO, and KRO PKI Entities within the Verizon UniCERT CA , like RAO, RRO, KRO certificates, have either subscriber’s legal name in the subject DN, or the device name which uses them.

PKI Entity Certificate RA0 and Master RAO certificates, RRO and KRO Not extension Field Criticality Value Version Integer value of “2” for Version 3 cert. Serial Number Integer (assigned by CA)

Signature Must match Algorithm Identifier in signatureAlgorithm field. The parameters field is only populated when the algorithm is RSA.

Algorithm 1.2.840.113549.1.1.10 id-RSASSA-PSS (RSA with PSS padding; 800-78-1 requires use with

SHA-256 hash algorithm) 1.2.840.113549.1.1.11 Sha256WithRSAEncryption

1.2.840.10045.4.3.2 ecdsa-with-SHA256 1.2.840.10045.4.3.3 ecdsa-with-SHA384

Parameters 2.16.840.1.101.3.4.2.1 For id-RSASSA-PSS only, specify the SHA-256 hash algorithm as a

parameter NULL For all RSA algorithms except id-RSASSA-PSS

Issuer Must use one of the name forms specified in section 3.1.5 of this CPS.

Validity Period 3 years Maximum Subject cn = First name Middle Initial Last Name, ou=Master RAO, ou=PKI,

ou=Services, dc=<department>, dc=gov or cn = First name Middle Initial Last Name, ou=RAO, ou=PKI, ou=Services, dc=<department>, dc=gov or cn = First name Middle Initial Last Name, ou= RRO, ou=PKI, ou=Services, dc=<department>, dc=gov



algorithm AlgorithmIdentifier Public key algorithm associated with the public key. May be either RSA

or elliptic curve. 1.2.840.113549.1.1.1 RSA Encryption




1.2.840.10045.3.1.7 Curve P-256 1.3.132.0.16 34 Curve P-384

implicitlyCA NULL Obtain parameters from issuer’s certificate subjectPublicKey BIT STRING For RSA public keys: certificates shall have a modulus of

at least 2048 bits. (No sunset date for specified elliptic curves.) Extensions Authority Key Identifier FALSE 160 bit SHA-1 Subject Key Identifier FALSE 160 bit SHA-1 Subject Alternate Name Key Usage TRUE digitalSignature, Key Encipherment Extended Key Usage FALSE TLS Client Authentication anyExtendedKeyUsage 2.5.29.37.0 Certificate Policies FALSE

id-fpki-common-authentication

2.16.840.1.101.3.2.1.3.8

CRL Distribution Point FALSE Public http://cdp1.ssp-strong-id.net/CDP/<Agency>-SSP-CA-Bx.crl Authority Information Access

FALSE

1.3.6.1.5.5.7.48.2 http://aia1.ssp-strong-id.net/CA/<Agency>-SSP-CA-Bx.p7c 1.3.6.1.5.5.7.48.1 BLT Private Extension FALSE (Note: This private extension is required for UniCERT product

functioning. It is used to indicate RAO certificate type internal to UniCERT product.)

OID = 1.2.372.980001.3.1.3 – MASTER RAO and RAO OID = 1.2.372.980001.3.1.21 - RRO OID = 1.2.372.980001.3.1.20 - KRO

