Operational Research Consultants, Inc. (ORC) Access ...summary).pdf · This CPS version updated and...

Copyright 2007, Operational Research Consultants, Inc.

All Rights Reserved

Operational Research Consultants, Inc. (ORC)

Access Certificates For Electronic Services (ACES)

Certificate Practice Statement Summary

Version 3.3.2

May 30, 2007


All Rights Reserved

Certificate Practice Statement

Revision History

Version Date Revision Summary

1.0 01 September

1999

The initial ORC ACES Certificate Practice Statement (CPS) was the implementation document for the ORC ACES Program, submitted in accordance with GSA ACES: GS000T99ALD0007, under which ORC:

Entering into an appropriate GSA ACES contract; Documented the specific practices and procedures

implement to satisfy the requirements of the ACES Certificate Policy; and

Successfully completed GSA's ACES Security Certification and Accreditation.

2.0 10 February

2000

This CPS version updated and replaced Version 1.0, to include contract modifications stipulated by the ACES PMO as a result of the Certification and Accreditation.

2.1 10 May 2000 This CPS version updated and replaced Version 2.0, to include the review and approval of Version 2.0 changes by the ACES PMO.

3.0 20 November

2000

This CPS version updated and replaced Version 2.0, to include updates stipulated by the ACES PMO as a result of the Federal Bridge Certificate Authority Policy.

3.1 2 February

2001

This CPS version updated and replaced Version 3.0, to include contract modifications stipulated by the ACES PMO as a result of the Federal Bridge Certificate Authority Policy compliance requirements.

3.2 1 October 2004 This CPS version updated and replaced Version 3.1, to include modifications stipulated by the Federal Bridge Certificate Authority Policy audit review.

3.2.1 15 April 2005 This CPS version updated and replaced Version 3.2, to include modifications necessary to comply with the U.S. Federal PKI Common Policy Framework (FPCPF).

3.2.2 6 June 2005 This CPS version updated and replaced Version 3.2.1, to include modifications necessary to comply with FPCPF subcommittee comments.

3.3 16 September

2005 This CPS version updated and replaced Version 3.2.2, to include modifications necessary to comply with FPCPF subcommittee


All Rights Reserved

comments and OCD review.

3.3.1 9 January 2007

This CPS version updated and replaced Version 3.3, to include modifications necessary to comply with the following Common Policy Change Proposals:

2005-03, Addition of High Assurance Policy to the Common Policy Framework, 13 September 2005

2006-01, Alignment of Common Authentication Policies with FIPS 201

And, the X.509 Certificate and Certificate Revocation List (CRL) Extensions Profile for the Shared Service Providers (SSP) Program, V1.2, 5 January 2006.

3.3.2 4 May 2007 Updates concerning the report from the PKI Shared Service Provider Working Group on ORC, dated 23 April 2007

i


All Rights Reserved

Table of Contents

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

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

1.2 Policy Identification ............................................................................................ 2

1.3 Community and Applicability ............................................................................... 5

1.3.1 Certificate Service Providers .................................................................... 5

1.3.2 End Entities (EE) .................................................................................... 7

1.3.3 Policy Authority .................................................................................... 10

1.3.4 Applicability ......................................................................................... 10

1.3.5 Related Authorities ............................................................................... 15

1.4 Contact Details ................................................................................................ 15

1.4.1 Policy Administration Organization .......................................................... 15

1.4.2 Policy Contact Personnel ........................................................................ 15

1.4.3 Person Determining CPS Suitability for the Policy ...................................... 16

1.4.4 CPS Administration Organization ............................................................ 16

2 General Provisions ................................................................................................... 17

2.1 Obligations ..................................................................................................... 17

2.1.1 Authorized CA Obligations ...................................................................... 17

2.1.2 RA, LRA and IA Obligations .................................................................... 18

2.1.3 Certificate Manufacturing Authority Obligations ........................................ 20

2.1.4 Repository Obligations .......................................................................... 20

2.1.5 Subscriber Obligations........................................................................... 21

2.1.6 Server/Component Certificate Subscriber Obligations ................................ 22

2.1.7 Code Signer Certificate Subscriber Obligations ......................................... 23

2.1.8 Relying Party Obligations ....................................................................... 24

2.1.9 Policy Authority Obligations ................................................................... 25

2.1.10 ORC Certificate Status Authority (CSA) Obligations ................................... 25

2.2 Liability .......................................................................................................... 26

2.2.1 Authorized CA Liability .......................................................................... 26

2.2.2 RA, IA, CMA, and Repository Liability ...................................................... 26

2.2.3 Warranties and Limitations On Warranties ............................................... 26

2.2.4 Damages Covered and Disclaimers ......................................................... 27

2.2.5 Loss Limitations ................................................................................... 27

2.2.6 Other Exclusions ................................................................................... 27

2.3 Financial Responsibility ..................................................................................... 27

2.3.1 Indemnification By Relying Parties and Subscribers ................................... 27

2.3.2 Fiduciary Relationships .......................................................................... 27

2.3.3 Administrative Processes ....................................................................... 28

2.4 Interpretation and Enforcement ......................................................................... 28

ii


All Rights Reserved

2.4.1 Governing Law ..................................................................................... 28

2.4.2 Severability of Provisions, Survival, Merger, and Notice ............................. 28

2.4.3 Dispute Resolution Procedures ............................................................... 29

2.5 Fees ............................................................................................................... 29

2.5.1 Certificate Issuance, Renewal, Suspension, and Revocation Fees ................ 29

2.5.2 Certificate Access Fees .......................................................................... 29

2.5.3 Revocation or Status Information Access Fees .......................................... 30

2.5.4 Fees for Other Services Such as Policy Information ................................... 30

2.5.5 Refund Policy ....................................................................................... 30

2.6 Publication and Repository ................................................................................ 30

2.6.1 Publication of ORC ACES Information ...................................................... 30

2.6.2 Frequency of Publication ........................................................................ 30

2.6.3 Access Controls .................................................................................... 31

2.6.4 Repositories ......................................................................................... 31

2.7 Inspections And Reviews .................................................................................. 32

2.7.1 Certification and Accreditation ................................................................ 32

2.7.2 Quality Assurance Inspection and Review ................................................ 34

2.8 Confidentiality ................................................................................................. 35

2.8.1 Types of Information to Be Kept Confidential ........................................... 35

2.8.2 Types of Information Not Considered Confidential ..................................... 36

2.8.3 Disclosure of Certificate Revocation/Suspension Information ...................... 36

2.8.4 Release to Law Enforcement Officials ...................................................... 37

2.8.5 Release as Part of Civil Discover ............................................................. 37

2.8.6 Disclosure upon Owner's Request ........................................................... 37

2.9 Security Requirements ..................................................................................... 37

2.9.1 System Security Plan (SSP) ................................................................... 38

2.9.2 Risk Management ................................................................................. 38

2.9.3 Certification and Accreditation ................................................................ 38

2.9.4 Rules and Behavior ............................................................................... 38

2.9.5 Contingency Plan .................................................................................. 38

2.9.6 Incident Response Capability.................................................................. 38

2.10 Intellectual Property Rights ............................................................................... 39

3 Identification And Authentication ............................................................................ 40

3.1 Initial Registration ........................................................................................... 40

3.1.1 Types of Names .................................................................................... 40

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

3.1.3 Rules for Interpreting Various Name Forms .............................................. 47

3.1.4 Uniqueness of Names ............................................................................ 47

3.1.5 Name Claim Dispute Procedure .............................................................. 47

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

3.1.7 Verification of Possession of Private Key .................................................. 48

3.1.8 Authentication of Sponsoring Organizational Identity ................................ 49

iii


All Rights Reserved

3.1.9 Authentication of Individual Identity........................................................ 50

3.1.10 Code Signer Authentication .................................................................... 57

3.1.11 Authentication of Component Identities ................................................... 57

3.2 Routine Re-Key (Certificate Renewal) ................................................................. 58

3.2.1 CA Certificate Routine Re-Key ................................................................ 58

3.2.2 Certificate Re-Key ................................................................................. 58

3.2.3 Certificate Renewal ............................................................................... 59

3.3 Obtaining a New Certificate After Revocation ....................................................... 60

3.4 Revocation Request ......................................................................................... 61

4 Operational Requirements ....................................................................................... 62

4.1 Certificate Application ...................................................................................... 62

4.1.1 Application Initiation ............................................................................. 62

4.1.2 Application Rejection ............................................................................. 64

4.2 Certificate Issuance.......................................................................................... 64

4.2.1 Certificate Delivery ............................................................................... 66

4.2.2 Certificate Replacement ......................................................................... 67

4.3 Certificate Acceptance ...................................................................................... 68

4.4 Certificate Suspension and Revocation ............................................................... 69

4.4.1 Who Can Request a Revocation? ............................................................. 69

4.4.2 Circumstances for Revocation................................................................. 69

4.4.3 Revocation Request Procedure ............................................................... 71

4.4.4 Revocation Grace Period ........................................................................ 73

4.4.5 Certificate Authority Revocation Lists (CARLs)/Certificate Revocation Lists (CRLs) ................................................................................................. 73

4.4.6 Online Revocation/Status Checking Availability ......................................... 74

4.4.7 Online Revocation Checking Requirements ............................................... 74

4.4.8 Other Forms of Revocation Advertisements Available ................................ 75

4.4.9 Checking Requirements for Other Forms of Revocation Advertisements Available ............................................................................................. 75

4.4.10 Special Requirements With Respect to Key Compromise ............................ 75

4.5 Certificate Suspension ...................................................................................... 76

4.5.1 Circumstances for Suspension ................................................................ 76

4.5.2 Who Can Request Suspension ................................................................ 76

4.5.3 Procedure for Suspension Request .......................................................... 76

4.6 Computer Security and Audit Procedures ............................................................ 76

4.6.1 Types of Event Recorded ....................................................................... 77

4.6.2 Frequency of Processing Data ................................................................. 78

4.6.3 Retention Period for Security Audit Data .................................................. 78

4.6.4 Protection of Security Audit Data ............................................................ 78

4.6.5 Security Audit Data Backup Procedures ................................................... 79

4.6.6 Security Audit Collection System (Internal vs. External) ............................ 79

4.6.7 Notification to Event-Causing Subject ...................................................... 79

iv


All Rights Reserved

4.6.8 Vulnerability Assessments...................................................................... 79

4.7 Records Archival .............................................................................................. 79

4.7.1 Types of Data Archived .......................................................................... 79

4.7.2 Retention Period for Archive ................................................................... 80

4.7.3 Protection of Archive ............................................................................. 80

4.8 Key Changeover .............................................................................................. 80

4.9 Compromise and Disaster Recovery ................................................................... 81

4.9.1 Computing Resources, Software, and/or Data are Corrupted ...................... 81

4.9.2 Authorized CA Public Key Is Revoked ...................................................... 82

4.9.3 Private Key Is Compromised (Key Compromise Plan) ................................ 82

4.9.4 Facility after a Natural or Other Disaster (Disaster Recovery Plan) .............. 83

4.10 Authorized CA Cessation of Services ................................................................... 83

4.11 Customer Service Center .................................................................................. 83

5 Physical, Procedural And Personnel Security Controls ............................................. 85

5.1 Physical Security Controls ................................................................................. 85

5.1.1 Physical Access Controls ........................................................................ 85

5.1.2 Security Checks .................................................................................... 86

5.1.3 Media Storage ...................................................................................... 86

5.1.4 Environmental Security ......................................................................... 86

5.1.5 Off-site Backup..................................................................................... 87

5.2 Procedural Controls .......................................................................................... 87

5.2.1 Trusted Roles ....................................................................................... 87

5.2.2 Number of Persons Required Per Task (Separation of Roles) ...................... 89

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

5.2.4 Hardware/Software Maintenance Controls ................................................ 90

5.2.5 Documentation ..................................................................................... 90

5.2.6 Security Awareness Training .................................................................. 90

5.2.7 Retraining Frequency and Requirements .................................................. 91

5.2.8 Job Rotation Frequency and Sequence ..................................................... 91

5.2.9 Sanctions for Unauthorized Actions ......................................................... 91

5.2.10 Contracting Personnel Requirements ....................................................... 91

5.2.11 Documentation Supplied to Personnel ..................................................... 91

5.3 Personnel Security Controls............................................................................... 92

5.3.1 Access Authorization ............................................................................. 92

5.3.2 Limited Access ..................................................................................... 92

6 Technical Security Controls ...................................................................................... 94

6.1 Key Pair Generation and Installation .................................................................. 94

6.1.1 Key Pair Generation .............................................................................. 94

6.1.2 Private Key Delivery to Entity ................................................................. 94

6.1.3 Subscriber Public Key Delivery to Authorized CA (Certificate Issuer)............ 95

6.1.4 ORC ACES CA Public Key Delivery to Users .............................................. 95

6.1.5 Key Sizes ............................................................................................. 96

v


All Rights Reserved

6.1.6 Public Key Parameters Generation .......................................................... 96

6.1.7 Parameter Quality Checking ................................................................... 96

6.1.8 Key Usage Purposes (X.509 V3 Key Usage Field) ...................................... 97

6.1.9 Private Key Shared by Multiple Subscribers .............................................. 97

6.1.10 Date/Time stamping ............................................................................. 98

6.2 Private Key Protection ...................................................................................... 98

6.2.1 Standards for Cryptographic Modules ...................................................... 98

6.2.2 Private Key Backup ............................................................................... 98

6.2.3 Private Key Archival .............................................................................. 99

6.2.4 Private Key Entry Into Cryptographic Module ............................................ 99

6.2.5 Method of Activating Private Key ............................................................ 99

6.2.6 Method of Deactivating Private Key ........................................................ 100

6.2.7 Method of Destroying Private Key .......................................................... 100

6.3 Good Practices Regarding Key Pair Management ................................................. 100

6.3.1 Public Key Archival ............................................................................... 100

6.3.2 Private Key Archival ............................................................................. 100

6.3.3 Usage Periods for the Public and Private Keys ......................................... 101

6.3.4 Restrictions on CA's Private Key Use ...................................................... 101

6.3.5 Private Key Multi-person Control............................................................ 101

6.3.6 Private Key Escrow .............................................................................. 102

6.4 Activation Data ............................................................................................... 102

6.4.1 Activation Data Installation and Generation ............................................ 102

6.4.2 Activation Data Protection .................................................................... 103

6.4.3 Other Aspects of Activation Data ........................................................... 103

6.5 Computer Security Controls ............................................................................. 103

6.5.1 Audit .................................................................................................. 103

6.5.2 Technical Access Controls ..................................................................... 104

6.5.3 Identification and Authentication ........................................................... 104

6.5.4 Trusted Paths ...................................................................................... 104

6.6 Life Cycle Technical Controls ............................................................................ 104

6.6.1 System Development Controls (Environment Security) ............................. 105

6.6.2 Security Management Controls .............................................................. 105

6.6.3 Object Reuse ...................................................................................... 106

6.7 Network Security Controls ............................................................................... 106

6.7.1 Remote Access/Dial-up Access ...................... Error! Bookmark not defined.

6.7.2 Encryption .................................................. Error! Bookmark not defined.

7 Certificate And CRL Profiles ................................................................................... 108

7.1 Certificate Profile ............................................................................................ 108

7.1.1 Version Numbers ................................................................................. 108

7.1.2 Certificate Extensions ........................................................................... 108

7.1.3 Algorithm Object Identifiers .................................................................. 108

7.1.4 Name Forms ....................................................................................... 109

vi


All Rights Reserved

7.1.5 Name Constraints ................................................................................ 109

7.1.6 Certificate Policy Object Identifier .......................................................... 109

7.1.7 Usage of Policy Constraints Extension .................................................... 109

7.1.8 Policy Qualifiers Syntax and Semantics ................................................... 109

7.1.9 Processing Semantics for the Critical Certificate Policy Extension ............... 110

7.1.10 Key Usage Constraints for id-fpki-common-authentication ........................ 110

7.2 CRL Profile ..................................................................................................... 110

7.2.1 Version Numbers ................................................................................. 110

7.2.2 CRL and CRL Entry Extensions ............................................................... 110

7.3 OCSP Request – Response Format .................................................................... 110

8 CPS Administration ................................................................................................ 112

8.1 CPS Change Procedures ................................................................................... 112

8.1.1 List of Items ....................................................................................... 112

8.1.2 Comment Period .................................................................................. 112

8.2 Publication and Notification Procedures .............................................................. 112

8.3 CPS and External Approval Procedures .............................................................. 112

8.4 Waivers ......................................................................................................... 112

Appendix A: Relying Party Agreement .................................................................................. 1

Appendix B: Acronyms And Abbreviations ............................................................................. 1

Appendix C: Reserved ........................................................................................................... 1

Appendix D: Applicable Federal and GSA Regulations ........................................................... 1

Appendix E: Reserved ........................................................................................................... 1

Appendix F: References......................................................................................................... 1

Appendix G: Glossary ............................................................................................................ 1

ORCACEScpsV3_3_2(summary) 1


All Rights Reserved

1 Introduction

1.1 Overview

This document is a summary of the Certificate Practice Statement (CPS for Operational Research Consultant’s (ORC’s) Access Certificates for Electronic Services (ACES) Program (also known as the ORC ACES Public Key Infrastructure, “ORC ACES PKI”). The General Services Administration (GSA) Office of Government-wide policy (OGP) and Federal Technology Services (FTS) has designated ORC as an ACES "Authorized Certification Authority (CA)" by:

Entering into an appropriate GSA ACES contract with ORC.

Reviewing the specific practices and procedures ORC implements to satisfy the requirements of the ACES Certificate Policy (CP) in this certificate practice statement.

Successfully completing a GSA's Security Certification and Accreditation.

Approving this CPS.

This CPS is applicable to individuals, business representatives, Federal employees, State and Local Government employees, relying parties, and agency applications who [that] directly use these certificates, and who are responsible for applications or servers that use certificates. Certificate users include, but are not limited to, Certificate Management Authorities (CMAs), Registration Authorities (RAs), Issuing Authorities (IAs), Local Registration Authorities (LRAs), subscribers, and relying parties.

This CPS applies to X.509 version 3 certificates with assurance levels as defined in the ACES CP and the U.S. Federal PKI Common Policy Framework (FPCPF) CP, as used to protect information up to and including Sensitive But Unclassified (SBU). The policies and procedures in this CPS are applicable to individuals who manage the certificates, who directly use these certificates, and individuals who are responsible for applications or servers that rely on these certificates.

In accordance with the stipulations of this CPS, the ORC CAs that issue certificates asserting a FPCPF OID will be updated as required by and in accordance with the schedule stipulated in Section 6.1.5 of the current X.509 Certificate Policy for the FPCPF, version 2.5, and this CPS.

The CPS describes the operations of the ORC ACES PKI and the services that the ORC ACES PKI provides. These services include:

Subscriber Registration: A subscriber or certificate applicant must appear in person before an ORC Registration Authority (RA), an approved Local Registration Authority (LRA) or a registered Notary Public (or a person legally empowered to witness and certify the validity of documents and to take



All Rights Reserved

affidavits and depositions), as stipulated by the Policy Authority, present valid identification (driver’s license, passport, etc.), sign the subscriber’s obligation and mail the forms to ORC.

Subscriber Enrollment: The ORC ACES system provides Federal Information Processing Standards (FIPS) 140-2 Level 3 Secure Socket Layer (SSL) connections to the certification authority. The subscriber must use a FIPS 140-2 Level 1 or 2 client for connection for enrollment.

Enrollment Validation: The ORC registration process validates the subscriber enrollment information (see above).

Certificate Issuance: When notified by an RA of a valid enrollment request, an ORC IA issues the requested certificate for delivery to a FIPS 140-2 Level 1 or 2 client. A FIPS 140-2 Level 1 issuance does not require a hardware token. ORC then notifies the subscriber of the issuance and provide instructions for receiving the certificate.

Certificate Publishing: When a certificate is issued, the ORC publishes it to a Lightweight Directory Access Protocol (LDAP) directory. The directory may be accessed via Hypertext Transfer Protocol over Secure Sockets Layer (HTTPS) gateway or via the LDAP protocol.

Encryption Key Storage: Optional storage (escrow) of encryption keys.

Key Recovery: If encryption key storage (escrow) is selected.

Certificate Status information: In the form of Certificate Revocation Lists (CRLs) distribution (via LDAP and HTTP) and Online Certificate Status Protocol (OCSP) responses.

To assist in providing these services and in meeting the reporting requirements outlined in this CPS, ORC maintains a website, which contains instructions, online forms, a summary of this CPS, compliance audit results, and copies of certificates and CRLs. The majority of the information on the website is publicly accessible, although it incorporates SSL to promote data integrity and to allow users to validate the source of the information. Portions of the website are access controlled and require certificate authentication for access to authorized individuals.

ORC is periodically audited by its independent auditor against this CPS and operates primary and secondary secure data centers in conformance with the Department of Defense (DoD), National Security Agency (NSA), U.S. General Services Administration (GSA) and commercial practices.

1.2 Policy Identification

The ACES CP is registered with the Computer Security Objects Register (CSOR) at the National Institute of Standards and Technology (NIST). The ORC ACES PKI and each CA complies with the following object identifiers (OIDs) for the ACES Certificates defined in this CPS:



All Rights Reserved

ACES Authorized/ Subordinate CA Certificates: {2 16 840 1 101 3 2 1 1 1}

Unaffiliated Individual Digital Signature Certificates: {2 16 840 1 101 3 2 1 1 2}

Unaffiliated Individual Encryption Certificates: {2 16 840 1 101 3 2 1 1 2}

Business Representative Digital Signature Certificates: {2 16 840 1 101 3 2 1 1 3}

Business Representative Encryption Certificates: {2 16 840 1 101 3 2 1 1 3}

Relying Party Digital Signature Certificates: {2 16 840 1 101 3 2 1 1 4}

Relying Party Encryption Certificates: {2 16 840 1 101 3 2 1 1 4}

Agency Application SSL Server Certificates: {2 16 840 1 101 3 2 1 1 5}

Federal Employee Digital Signature Certificates: {2 16 840 1 101 3 2 1 1 6}

Federal Employee Encryption Certificates: {2 16 840 1 101 3 2 1 1 6}

Federal Employee Digital Signature Certificates on hardware tokens: {2 16 840 1 101 3 2 1 1 7}

Federal Employee Encryption Certificates on hardware tokens: {2 16 840 1 101 3 2 1 1 7}

State and Local Employee Digital Signature Certificates: {2 16 840 1 101 3 2 1 1 6}

State and Local Employee Encryption Certificates: {2 16 840 1 101 3 2 1 1 6}

State and Local Employee Digital Signature Certificates on hardware token: {2 16 840 1 101 3 2 1 1 7}

State and Local Employee Encryption Certificates on hardware token: {2 16 840 1 101 3 2 1 1 7}

VPN IPSec Certificate: {2 16 840 1 101 3 2 1 1 10}

Code Signing Certificates on hardware token: {2 16 840 1 101 3 2 1 1 11}

OCSP Signing Certificates: {2 16 840 1 101 3 2 1 1 12}



All Rights Reserved

Certificates issued under this CPS may also contain and comply with the following FPCPF

1 object identifiers (OIDs) for the certificates defined in this CPS:

Subscriber certificates not on hardware tokens, id-fpki-common-policy::={2 16 840 1 101 3 2 1 3 6}

Subscriber certificates on hardware tokens, id-fpki-common-hardware::={2 16 840 1 101 3 2 1 3 7}

Device certificates: id-fpki-common-devices::={2 16 840 1 101 3 2 1 3 8}

Authentication PIV user authentication certificates (w/o non repudiation) on hardware tokens, id-fpki-common-authentication::={2 16 840 1 101 3 2 1 3 13}

PIV card authentication certificates (w/o non repudiation) on hardware tokens, id-fpki-common-cardAuth ::= {2 16 840 1 101 3 2 1 3 17}

Certificates issued to users asserting a FPCPF OID to support digitally signed documents or key management contain either the id-fpki-common-policy or id-fpki-common-hardware. Certificates issued to devices under this policy include the id-fpki-common-devices.

Certificates issued to users supporting authentication where the private key can be used without user authentication contain id-fpki-common-cardAuth.

ORC certificates issued under this CPS reference the ACES CP and the FPCPF by including the appropriate OID, identified above, in the Certificate Policies field. Additionally, each ORC CA that issues certificates asserting a FPCPF OID shall hold a certificate signed by the FPCPF CA or an Authorized CA that holds a certificate signed by the FPCPF CA. The foregoing OIDs may not be used except as specifically authorized by the ACES CP and the FPCPF CP. Unless specifically approved by the Federal PKI Policy Authority, ORC CAs do not assert the FBCA CP OIDs in any certificates issued, except in the policyMappings extension establishing an equivalency between an FBCA OID

1 The requirements associated with the US FPCPF OIDs are incorporated by reference. ORC will

only apply the FPCPF OIDs as appropriate, in accordance with the FPCPF.



All Rights Reserved

and an OID in the ACES CP. Only the OIDs identified above are used within ORC certificates with the exception of the policyMappings extension, which may assert other PKI Policy OIDs for purposes of cross certification of the ORC ACES PKI to another PKI. CSOR information is available from 1) http://www.csrc.nist.gov/pki/CSOR/csor.html, and 2) [email protected].

The ORC PKI and this CPS support medium assurance and medium-hardware assurance levels as defined in Section 1.3.4.6.

1.3 Community and Applicability

This CPS describes the rights and obligations of persons and entities authorized under this CPS to fulfill the roles of an ORC Certificate Service Provider and End Entity (EE). As an ACES Certificate Service Provider and a GSA Shared Service Provider, ORC provides Certification Authority(s), Registration Authority(s), Certificate Manufacturing Authority(s), and Repository(s). EE roles include Subscriber, Federal Employee, Server, and Relying Party. Requirements for persons and entities authorized to fulfill any of these roles are included in this section. A description of each of these roles and their responsibilities is set forth in Section 2 of this CPS.

The ORC ACES program supports entities transacting electronic business with or business for U.S. Government entities. ORC ACES Subscribers may include Unaffiliated Individuals, Business Representatives, members of Federal, State, and Local Government agencies and their trading partners. The GSA Shared Service Provider program provides certificate issuance to Federal employees, contractors and other affiliated personnel for the purposes of authentication, signature, and confidentiality.

1.3.1 Certificate Service Providers

Under this CPS Certificate Authority Administrators (CAAs), and IAs are considered “Certificate Management Authorities” (CMAs) and are the only authorities with direct trusted access to the ORC CA’s applications and keys. This CPS uses the term CMA when a function may be assigned to an ORC CA, CAA, or IA; or when a requirement applies to an ORC CA, CAA, and/ or IA. The division of responsibilities is described in this CPS. ORC server-based Certificate Status Authorities (CSAs) are also considered CMAs. This CPS details the procedures that ensure that all CMAs are in compliance with the ACES CP.

There are two additional roles that are critical to the operation of the PKI, the Corporate Security Auditor and the System Administrator (SA). The Corporate Security Auditor is designated within ORC as an individual who is not in the reporting chain under the CAA. The Corporate Security Auditor is responsible for providing independent auditing of the CA services. Corporate Security Auditor duties are a secondary job function. The Corporate Security Auditor is an employee of ORC and is designated in by the ORC CEO.

mailto:[email protected]



All Rights Reserved

SAs are responsible for managing the CA server at the operating system level. All SAs in support of this CPS are employees of ORC.

1.3.1.1 Certification Authorities

ORC issues certificates as an ACES “Authorized CA”, as stipulated in Section 1.1 of the ACES CP. The ORC ACES PKI operates under an autonomous root. The ORC CA operations follow guidance in accordance with the IETF PKIX Part 4 format. The ORC ACES PKI generates and manages certificates and certificate revocation. It posts those certificates and CRLs to an LDAP directory.

1.3.1.1.1 Certification Authority Administrator (CAA)

CAAs, as defined herein, administer the ORC CAs and CSAs. CAAs are the only authorities authorized to administer a CA or CSA. CAAs are ORC employees designated directly by ORC’s President. ORC CAAs designate IAs and RAs and perform tasks required for CA/CRL management.

1.3.1.1.2 Issuing Authorities (IAs)

IAs are the only authorities authorized to approve the issuance of ORC certificates. IAs approve the issuance of certificates to EEs upon receipt of an identity validation, digitally signed by an authorized RA. IAs are ORC employees and are designated directly by an ORC CAA and are issued IA certificates stored on hardware tokens for the purpose of issuing validated certificates to applicants. IAs appear in person to an ORC CAA for identity verification with two valid, official photo IDs. IAs are provided training in issuing certificates and in the policies and processes of this CPS prior to being issued their IA certificates. IA duties are a primary job responsibility for these individuals. ORC IAs are employees of ORC or subcontract personnel only. The ORC IAs approve the issuance of ORC certificates by accessing an ORC CA from an ORC IA workstation that securely communicates with the CA.

1.3.1.2 Registration Authorities

RAs are designated directly by an ORC CAA and are issued RA certificates for the purpose of submitting digitally signed verification of applicant identities and information to be entered into public key certificates. ORC RAs use hardware tokens for their RA certificates. RAs appear in person to either a CAA or an IA for identity verification with official identification, in accordance with the requirements of Section 3.1.9. RAs are provided training in identity proofing and in the policies and processes of this CPS prior to being issued their RA certificates. RA certificates are not valid for performing administrative tasks on the CA or IA equipment, including issuing or revoking certificates.

1.3.1.2.1 Local Registration Authorities

ORC RAs may delegate the identity proofing tasks to LRAs. LRAs can be ORC employees on location at a subscriber’s organization or employees of a



All Rights Reserved

subscriber’s organization. LRAs perform duties identical to RAs, but have their identity validated by RAs instead of a CAA or IA. Upon performing their duties, LRAs provide verification to RAs via mail (for non-FPCPF certificates only) or signed email (using a medium hardware assurance certificate). If an RA delegates duties to one or more LRAs, the RA informs the CAAs. LRAs may not designate other LRAs. RA certificates are not valid for performing administrative tasks on the CA or IA equipment, including issuing or revoking certificates.

1.3.1.2.2 Notaries Public

Notaries Public are not designated authorities of ORC. These persons may only validate the identity of individuals who are unable to present their identity credentials in person to an RA or LRA. In this situation, the subscriber is provided with a form, which they print, and includes the subscriber’s name, organizational affiliation (as appropriate), and the certificate request identification number. The subscriber is required to present this form, along with required identification and credentials identifying organizational affiliation. The Notaries Public shall witness and certify the signature on the form and required IDs.

In certain instances, ORC may identify one of the above officials to act in the role of compliance auditor and/or attribute authority. An official performing registration functions cannot audit the registration process and vice versa. The subscriber is required to submit the notarized form and copies of the information used to establish identity via certified mail to an IA.

1.3.1.3 Certificate Manufacturing Authorities

ORC performs the role and functions of the Certificate Manufacturing Authority under the ORC ACES Program. Under this CPS, ORC performs all the functions of a “Certificate Manufacturing Authority”, as defined in the ACES CP.

1.3.1.4 Repositories

ORC performs the role and functions of the repository under the ORC ACES Program.

1.3.2 End Entities (EE)

An EE is a holder of a certificate that is at the end of a certificate chain.

1.3.2.1 Subscribers

A subscriber is the EE whose name appears as the subject in a certificate, and who asserts that it uses its key and certificate in accordance with this CPS. Subscribers are limited to the following categories of entities:

Unaffiliated Individuals, including citizens of the United States conducting personal business with a U.S. Government agency at local, state or Federal level



All Rights Reserved

Employees of businesses acting in the capacity of an employee and conducting business with a U.S. Government agency at local, state or Federal level

Employees of state and local governments conducting business on behalf of their organization

Individuals communicating securely with a U.S. Government agency at local, state or Federal level, and

Qualified Relying Parties, including: workstations, guards and firewalls, routers, trusted servers (e.g., database, File Transfer Protocol (FTP), and World Wide Web (WWW)), and other infrastructure components communicating securely with, or for, a U.S. Government agency at local, state or Federal level. These components must be under the cognizance of humans, who accept the certificate and are responsible for the correct protection and use of the associated private key.

The ORC CAs are technically a subscriber to the PKI; however, the term subscriber as used in this CPS refers only to those EEs who request certificates for uses other than signing and issuing certificates.

1.3.2.2 Relying Party

Relying parties are those persons and entities authorized to accept and rely upon ORC Certificates for purposes of verifying digital signatures. A Relying Party is an individual or organization that, by using another’s certificate can:

Verify the integrity of a digitally signed message.

Identify the creator of a message, or establish confidential communications with the holder of the certificate.

Rely on the validity of the binding of the subscriber’s name to a public key.

Under the ACES program relying parties are those eligible Federal agencies and entities that enter into an agreement with GSA to accept ACES Certificates and agree to be bound by the terms of the ACES CP and this CPS.

Other eligible federal agencies and entities under the FPCPF include all Federal agencies, authorized federal contractors, agency-sponsored universities and laboratories, other organizations, and, if authorized by law, state, local, and tribal governments.

At one’s own risk, a Relying Party may use information in the certificate (such as certificate policy identifiers) to determine the suitability of the certificate for a particular use.

1.3.2.3 Agency Applications

ORC is authorized to issue certificates to authorized agency applications performing various functions.



All Rights Reserved

SSL Server Certificates are for use on Agency Servers to allow mutual authentication and/or trusted SSL communications with Agency customers.

Signing-only certificates are for use on agency applications for the purpose of providing Agency Customers with signed return receipt notifications.

Data encryption certificates are for use on agency applications for the purposes of encrypting agency application sensitive data.

Other certificate types are for use as needed by an Agency or agency application, such as IPSEC certificates, Code signing certificates, etc.

1.3.2.3.1 Agency Application SSL Server Certificates

ORC is authorized to issue ACES Agency Application SSL Server Certificates for use on Agency Servers to allow mutual authentication and/or trusted SSL communications with Agency customers. These SSL Server Certificates are issued to the agency server where the common name is the registered Domain Name of the Agency’s Web server. Certificates allow for both server and client authentication through the extended KeyUsage extension. The server designated in the certificate request is the only system on which the certificate is to be installed. Agency applications are to use ORC ACES SSL Server Certificates only for authorized applications meeting the requirements of this CPS. All obligations related to obtaining and using ORC SSL Server Certificates can be found in Section 2.1.6 of this CPS.

1.3.2.3.2 Agency Application (Signing)

ORC is authorized to issue ACES “signing-only” certificates to agency applications for the purpose of providing Agency Customers with signed return receipt notifications acknowledging that the agency application received the customer’s transaction. Additionally, an agency application may utilize signing certificates to sign internal data (customer transactions, application log files or agency archive data) where required by the agency policies.



All Rights Reserved

1.3.2.3.3 Agency Application (Encryption)

ORC is authorized to issue ACES data encryption certificate to an agency application for the purposes of encrypting agency application sensitive data where agency policy dictates.

ORC also provides an optional encryption private key escrow and recovery service.

2

1.3.2.3.4 Agency Application (Other)

ORC is authorized to issue other ACES certificates as needed by an authorized agency or agency application including IPSEC and Code Signing Certificates.

1.3.3 Policy Authority

The GSA serves as the Policy Authority3 and is responsible for organizing and

administering the ACES Certificates Policy and the ORC ACES Contract.

1.3.4 Applicability

1.3.4.1 Purpose

The ORC ACES PKI supports the following security services: confidentiality, integrity, authentication and technical non-repudiation. The ORC ACES PKI supports these security services by providing Identification and Authentication (I&A), integrity, and technical non-repudiation through digital signatures, and confidentiality through key exchange. These basic security services support the long-term integrity of application data, but may not by themselves provide a sufficient integrity solution for all application circumstances. For example, when a

2 The optional encryption private key escrow and recovery service does not currently apply to

certificates asserting the FPCPF Policy OIDs. 3 Additionally, this CPS recognizes the FBCA and the FPCPF Policy Authorities. Throughout this

CPS where ORC is stipulated to “notify the Policy Authority” ORC will make every effort to ensure that each of the noted Policy Authorities are properly notified, as applicable.



All Rights Reserved

requirement exists to verify the authenticity of a signature beyond the certificate validity period, such as contracting, other services such as trusted archival services or trusted timestamp may be necessary. These solutions are application based, and must be addressed by subscribers and Relying Parties. ORC provides support of security services to a wide range of applications that protect various types of information, up to and including sensitive unclassified information.

ACES Digital Signature Certificates may be used to authenticate subscribers to Relying Party applications for individual and/or business purposes, and for authentication of Relying Party applications. Subscribers and Agency Applications may use ACES Encryption Certificates to employ the confidentiality service on the data exchanged. Subscribers and Agency Applications may also use ACES Code Signing Certificates for the secure distribution of code. The following table summarizes the functional uses of ORC ACES Certificates:

Table 1- ORC Certificates Functional Use

Certificate Type Subscriber Purpose Use of Certificate

Unaffiliated Individual (Medium or Medium Hardware Assurance Certificates)

Unaffiliated

Individual

Digital Signature

To enable Unaffiliated Individual ORC ACES subscribers and Relying Parties to mutually authenticate themselves electronically for information and transactions and to verify digitally signed documents/transactions

Encryption To enable an unaffiliated individual to use confidentiality services (encryption and decryption) on his/her information and transactions

Business Representative Certificates (Medium or Medium Hardware Assurance Certificates)

Business Representative authorized to act on behalf of a Sponsoring Organization

Digital Signature

To enable Business Representatives to mutually authenticate themselves to conduct business-related activities electronically and to verify digitally signed documents/ transactions

Encryption To enable a Business Representative to use confidentiality services (encryption & decryption) on his/her information and transactions

State and Local Government Representative Certificates (Medium or Medium Hardware Assurance Certificates)

Government Employees authorized to act on behalf of a State or Local Government

Digital Signature

To enable State or Local Government Representatives to mutually authenticate themselves to conduct business-related activities electronically and to verify digitally signed documents/transactions

Encryption

To enable a State or Local Government Representative to use confidentiality services (encryption and decryption) on his/her information and transactions

Relying Party (Agency Application) Certificates

Relying Party

Digital Signature

To enable Relying Party & Unaffiliated Individuals, Business Representatives (Non-Federal Employees), Federal, State, & Local Government Employees, & Authorized CAs; to mutually authenticate themselves; to make signed validation requests; & to sign log files.



All Rights Reserved

Certificate Type Subscriber Purpose Use of Certificate

Encryption

To enable a Relying Party to provide confidentiality services (encryption and decryption) to subscribers on their information and transactions

Agency Application SSL Server Certificates

Server

Authentication & Encrypted Data Transmission

To enable authenticated encrypted communications between subscribers and servers

Federal Employee Certificates (Medium or Medium Hardware Assurance Certificates)

Federal Employee

Digital Signature

To enable Federal Employees and Relying Parties to mutually authenticate themselves and verify digitally signed documents/transactions

Federal Employee

Encryption To enable a Federal Employee to use confidentiality services (encryption and decryption) on his/her information and transactions

Authorized CA Certificate/ Subordinate CA Certificate

N/A To enable the Authorized CA to issue subscriber certificates.

VPN IPSec Certificate

Server

Authentication & Encrypted Data Transmission

To enable authenticated VPN IPSec encrypted communications between subscribers and servers

Code Signing Medium Hardware Assurance Certificate

Individual authorized to act on behalf of a Sponsoring Organization

Code Signing To enable the secure distribution of code to an authorized community of users.

1.3.4.2 Suitable Uses

ACES Certificates are intended for use by individuals, businesses, and Federal, State, and Local Governments to transact business with the Federal Government. Non-Federal Government participants who would otherwise be involved in such transactions provided that the Federal Government does not incur any additional costs may also use these Certificates. Examples of suitable uses include, but are not limited to:

Personal or restricted information retrieval

Updating personal or restricted information

Filings with government agencies

Application processes, such as applying for government licenses, student loans, government benefits, etc.

Financial transactions with government agencies

Distribution of code



All Rights Reserved

Relying Parties must evaluate the environment and the associated threats and vulnerabilities, as well as determine the level of risk they are willing to accept based on the sensitivity or significance of the information. This evaluation is done by each Agency for each application and is not controlled by this CPS.

1.3.4.3 Level of Assurance

The level of assurance associated with a public key certificate is an assertion by a CA of the degree of confidence that a Relying Party may reasonably place in the binding of a subscriber’s public key to the identity and privileges asserted in the certificate. Assurance level depends on the proper registration of subscribers and the proper generation and management of the certificate and associated private keys, in accordance with the stipulations of this policy. Personnel, physical, procedural, and technical security controls are used to maintain the assurance level of the certificates issued by ORC under this CPS, defined as Medium Assurance in the ACES CP, the FPCPF and the Federal Bridge CA. Credentials issued under this CPS asserting a user software policy meet the requirements for Level 3 authentication, as defined by the OMB E-Authentication Guidance. [E-Auth]. Credentials issued under this CPS asserting a user hardware policy meet the requirements for Level 4 authentication, as defined by the OMB E-Authentication Guidance. [E-Auth].

1.3.4.4 Factors in Determining Usage

The amount of reliance a Relying Party chooses to place on the certificate is determined by various risk factors. Specifically, the value of the information, the threat environment, and the existing protection of the information environment are used to determine the appropriate level of assurance of certificates required to protect and authenticate the information.

1.3.4.5 Threat

Threat is any circumstance or event with the potential to cause harm. In terms of information systems, harm includes destruction, disclosure, denial of service, or modification of data, processes, or processing components. Threats to systems include environmental disasters, physical damage, system penetration, and violation of authorization, human error, and communications monitoring or tampering. It is the responsibility of each relying party to assess the factor.

1.3.4.6 General Usage

This section contains definitions for two levels of assurance, and guidance for their application. The guidance is based on the previous discussion of information value and environmental protection. Emphasis is placed on two types of activity: integrity and access control to information considered sensitive, and information related to electronic financial transactions and other e-commerce. The final selection of the security mechanisms, and level of strength and assurance, requires a risk management process that addresses the specific



All Rights Reserved

mission and environment. Each Relying Party is responsible for carrying out this risk analysis.

1.3.4.6.1 Medium Assurance (Software Certificate)

This level is intended for applications handling sensitive medium value information based on the relying party’s assessment, which may include:

Non-repudiation for small and medium value financial transactions other than transactions involving issuance or acceptance of contracts and contract modifications

Authorization of payment for small and medium value financial transactions

Authorization of payment for small and medium value travel claims

Authorization of payment for small and medium value payroll

Acceptance of payment for small and medium value financial transactions

1.3.4.6.2 Medium Hardware Assurance:

Medium Hardware Assurance certificate are issued to subscribers on hardware tokens (e.g. PIV).

This level is intended for all applications operating in environments appropriate for medium assurance but which require a higher degree of assurance and technical non-repudiation based on the relying party’s assessment.

All applications appropriate for medium assurance certificates

Mobile code signing

Applications performing contracting and contract modifications

1.3.4.7 Prohibited Applications

This CPS prohibits the use of any application that does not follow approved standards for the storage and transmittal of cryptographic information. Applicable standards include:

FIPS 140-2, Security Requirements for Cryptographic Modules;

FIPS 180-1, Secure Hash Algorithm;

FIPS 186-1, Digital Signature Standard

PKCS #11 Hardware Format; and

PKCS #12 Software Format.

X.509 v2 Information Technology – ASN.1 Encoding Rules 1994

ANSI X9.31 American National Standard for Digital Signature using Reversible Public Key Cryptography for the Financial Service Industry



All Rights Reserved

1.3.5 Related Authorities

1.3.5.1 Compliance Auditors

Compliance audits as stipulated in this CPS are independently administered by ORC’s Corporate Security Auditors. Corporate Security Auditors are not in any way under the control of CAAs. Nor are CAAs under the control of Corporate Security Auditors. The Corporate Security Auditors maintain the ORC internal audit system and are designated directly by ORC’s President.

ORC’s Corporate Security Auditors also coordinate and support external auditing, including aperiodical audits by: GSA, DoD and NSA; and the American Institute of Certified Public Accountants (AICPA) WebTrust Program for Certification Authorities or current industry accepted standards and practices, as described herein.

1.3.5.2 Certificate Status Authorities

A Certificate Status Authority (CSA) uses OCSP that provides revocation status and/or certificate validation responses. The ORC CSA conforms to the stipulations of the ACES CP and this CPS.

1.3.5.3 Code Signing Attribute Authorities

A Code Signing Attribute Authority (CSAA) is a duly appointed organization sponsor who has been granted signature authority for an organization/agency. The Code Signing Attribute Authority authorizes applications or individuals for a code-signing certificate for the designated organization/agency.

1.4 Contact Details

1.4.1 Policy Administration Organization

GSA, as the Policy Authority and Contract Authority administers the ACES Certificate Policy:

General Services Administration 18th and F Streets, NW Washington, DC 20405-0007

1.4.2 Policy Contact Personnel Office of Electronic Government and Technology

Office of Government-wide Policy Phone: (202) 501-0202



All Rights Reserved

1.4.3 Person Determining CPS Suitability for the Policy

The government has determined the suitability of this CPS as part of the evaluation process. Any changes to this CPS made after determination of suitability shall be transmitted to the Government for approval prior to incorporation.

GSA/FTS is responsible for ensuring that this CPS conforms to the ACES CP and ACES Contracts.

Stephen Duncan, ACES Program Manager

Federal Technology Service General Services Administration Phone: (202) 708-7626

e-mail address: [email protected]

1.4.4 CPS Administration Organization

The Board of Directors of Operational Research Consultants, Inc., administers ORC PKI organization. The ORC PKI Project Director is responsible for registration, maintenance, and interpretation of this CPS. PKI Project Director, 11250 Waples Mill, South Tower, Ste 210, Fairfax, VA 22030.



All Rights Reserved

2 General Provisions

This section provides a description of the roles and responsibilities of the ORC systems operating under this CPS.

2.1 Obligations

Additional obligations are set forth in other provisions of the ACES CP, the ORC ACES Contract (including the requirements of this CPS, System Security Plan (SSP), Privacy Practices and Procedures (PPP)), ORC-ACES Agreements with Relying Parties, and the Subscriber Agreements.

2.1.1 Authorized CA Obligations

ORC accepts responsibility for all aspects of the issuance and management of ORC Certificates, which include:

The application/enrollment process

The identification verification and authentication process

The certificate manufacturing process which has the private key residing only in the applicant’s possession (the key length is 1024 bits)

Dissemination and activation (i.e., certificate issuance/manufacturing) of the certificate

Publication of the certificate

Renewal, suspension, revocation, and replacement of the certificate

Verification of certificate status upon request

Notifying subscribers of receipt of their request to change information

Ensuring that all aspects of the Certificates issued under this CPS are in accordance with the requirements, representations, and warranties of this CPS

Provide a customer service center for answering subscriber questions

Weekly review the audit logs that are provided by the System Administrator

ORC accepts the following obligations to the Policy Authority:

Providing to the Policy Authority this CPS, as well as any subsequent changes, for conformance assessment

Conforming to the stipulations of the ACES CP and the approved CPS

Ensuring that registration information is accepted only from IAs, RAs, and LRAs who understand and are obligated to comply with this policy



All Rights Reserved

ORC accepts the following obligations to Relying Parties who follow the policies of this CPS:

Ensuring that certificates are issued to the named subscriber

Including only valid and appropriate information in the certificate, and maintaining evidence that due diligence was exercised in validating that information contained in the certificate. The information in the certificate is accurate (including, but not limited to the subscriber Distinguished Name in the subject field and the subject public key information field)

Ensuring that the subscriber has accepted their certificate

Revoking the certificates of subscribers found to have acted in a manner counter to subscriber obligations

Ensuring that obligations are imposed on subscribers in accordance with Section 2.1.5 and that subscribers are informed of the consequences of not complying with those obligations

Notifying subscribers and making public, for the benefit of subscribers and Relying Parties, any changes to the CA operations that may impact interoperability or security (i.e., re-key)

Operating or providing for the services of an online repository that satisfies the obligations under Section 2.6, and informing the repository service provider of those obligations, if applicable

Posting certificates and CRLs to the repository(s)

ORC also accepts the obligation to maintain records necessary to support requests concerning its operation, including audit files and archives.

2.1.2 RA, LRA and IA Obligations

2.1.2.1 RA Obligations

RAs are obligated to accurately represent the information prepared for the CA and to process requests and responses in a timely and secure manner. RAs may designate LRAs, however LRAs may not designate other LRAs. RAs under this CPS CA are not authorized to assume any other CA administration functions.

When validating subscriber requests for certificates issued under this CPS, an RA accepts the following obligations:

To validate the accuracy of all information contained in the subscriber’s certificate request

To validate that the named subscriber actually requested the certificate

To verify to the IA that the certificate request originated from the named subscriber and that the information contained in the certificate request is accurate

To use the RA certificate only for purposes associated with the RA function



All Rights Reserved

To request revocation and verify reissue requirements of a subscriber’s certificate upon notification of changes to information contained in the certificate

To request revocation of the certificates of subscribers found to have acted in a manner counter to subscriber obligations

To immediately request revocation of a subscriber certificate and inform the IA and the subscriber when a private key compromise is suspected

To inform subscribers and the IA of any changes in RA status

To protect the RA certificate private keys from unauthorized access

To immediately request revocation of an RA certificate and report to the IA if private key compromise is suspected

To ensure that obligations are imposed on subscribers in accordance with Section 2.1.5

To inform subscribers of the consequences of not complying with those obligations

An RA who is found to have acted in a manner inconsistent with these obligations is subject to revocation of RA responsibilities.

2.1.2.2 LRA Obligations

LRAs are obligated to accurately represent the information prepared for the RA. LRAs may not designate other LRAs under this CPS. LRAs under this CPS are not authorized to assume any other CA administration functions.

When validating subscriber requests for certificates issued under this CPS, an LRA accepts the following obligations:

To validate that the named subscriber actually requested the certificate

To use the LRA certificate only for purposes associated with the LRA function

To request revocation and verify reissue requirements of a subscriber’s certificate upon notification of changes to information contained in the certificate

To request revocation of the certificates of subscribers found to have acted in a manner counter to subscriber obligations

To inform subscribers and an RA of any changes in LRA status

To protect the LRA certificate private keys from unauthorized access

To immediately request revocation of the LRA certificate and report to the RA if private key compromise is suspected

To ensure that obligations are imposed on subscribers in accordance with Section 2.1.5



All Rights Reserved

To inform subscribers of the consequences of not complying with those obligations

An LRA who is found to have acted in a manner inconsistent with these obligations is subject to revocation of LRA responsibilities.

2.1.2.3 IA Obligations

The IA accepts the following obligations:

Approve the issuance of certificates only when both the subscriber’s request and the trusted agent validation have been received

Notify the subscriber through e-mail or mail that the certificate request has or has not been granted in accordance with Section 2.6.1

Notify a subscriber of certificate revocation in accordance with Section 2.6.2

To use the IA certificate only for purposes associated with the IA function

To immediately revoke a RA, LRA or subscriber certificate and inform the certificate holder if private key compromise is suspected

To revoke (and approve the re-issuance of, if necessary) subscriber certificates that were validated by an RA or LRA whose private key is suspected to be compromised

To inform the CAA of any changes in IA status

To protect the IA certificate private key from unauthorized access

To immediately revoke the IA certificate and report to the CAA if private key compromise is suspected

An IA who is found to have acted in a manner inconsistent with these obligations is subject to revocation of IA responsibilities.

2.1.3 Certificate Manufacturing Authority Obligations

ORC is the Certificate Manufacturing Authority responsible for the functions of manufacturing, issuance, suspension, and revocation of Certificates, refer to Section 2.1.1.

2.1.4 Repository Obligations

The ORC Repository is responsible for:

Maintaining a secure system for storing and retrieving Certificates.

Maintaining a current copy of this CPS.

Maintaining other information relevant to Certificates.

Providing information regarding the status of Certificates as valid or invalid that can be determined by a Qualified Relying Party.



All Rights Reserved

ORC posts certificates and CRL information in an LDAP enabled directory established by the ORC ACES PKI. Only information contained in the certificate(s) is posted in this directory to ensure compliance with the Privacy Act. Access is available via an interoperable implementation of an LDAP directory, with certificate storage accomplished for sub-trees identified by organization, “o=”. Access to the directory is also available via HTTPS, via a directory gateway interface. The ORC directory sub-trees identify the organization of the EE. The ORC directory gateway is located at:

https://aces.orc.com/dsgw/bin/csearch?context=dsgw

ORC also posts CRLs at the following locations, accessible via HTTP:

http://aces.orc.com/CRLs/<CA Name>.crl

LDAP and HTTP access is defined in the CRL Distribution Point field of end entity certificates.

The certificate repository meets the following obligations:

To list all un-expired certificates for the ORC CAs to relying parties

To contain an accurate and current CRL for the respective CAs for use by relying parties

To be publicly accessible

To be physically accessible, via certificate-authenticated access control over SSL, for authorized requests coordinated with the ORCs Point of Contact (PoC) during normal business hours for the operating organization

To be maintained in accordance with the practices specified in this CPS

To meet or exceed the requirement of 99% availability for all components within the control of the operating organization

Communication failures as a result of Internet problems external to the operating organization shall not count against this availability requirement.

ORC maintains a copy of at least all certificates and CRLs ORC issues and provides this information to the U.S. Government for archiving. ORC provides this information on a certificate accessed web server posted no later than 10 days after the end of the collection of the data.

2.1.5 Subscriber Obligations

When requesting and using a certificate issued under this CPS, a subscriber accepts the following obligations:

To accurately represent themselves in all communications with the PKI

http://aces.orc.com/CRLs/%3cCA



All Rights Reserved

To protect the certificate private key from unauthorized access in accordance with Section 6.2, as stipulated in their certificate acceptance agreements, and local procedures

To immediately report to the appropriate RA or LRA and request certificate revocation if private key compromise is suspected

To use the certificate only for authorized applications which have met the requirements of this CPS

To use the certificate only for the purpose for which it was issued, as indicated in the key usage extension

To report any changes to information contained in the certificate to the appropriate RA or LRA for certificate reissue

Abide by all the terms, conditions, and restrictions levied upon the use of their private keys and certificates

Subscribers leaving the organizations that sponsored their participation in the PKI shall surrender to their organization's PKI PoC (through any accountable mechanism, defined in an agencies Registrations Practice Statement (RPS) in the case of FPFCF) all cryptographic hardware tokens that were issued, under the sponsoring organization, prior to leaving the organization

These obligations are provided to the subscriber during the registration process in the form of a Subscriber Agreement that the subscriber must read and agree to prior to completing registration. Theft, compromise or misuse of the private key may cause the subscriber, Relying Party and their organization legal consequences.

2.1.6 Server/Component Certificate Subscriber Obligations

When requesting, renewing and using a server certificate or VPN IPSec issued under this CPS, the applicant agency or company and their PKI Sponsor accept the following obligations:

To accurately represent themselves in all communications with the PKI and abide by all the terms, conditions and restrictions levied upon the use of the issued private key(s) and certificate(s).

To protect the certificate private key from unauthorized access in accordance with Section 6.2.

To immediately report to the appropriate RA and request certificate revocation if private key compromise is suspected.

In the event of a PKI sponsor change, due to the verified individual having left the employ of the subscribing company or no longer being assigned as the PKI sponsor for the certificate, the applicant company must designate a new PKI sponsor and the new PKI sponsor must complete a new identity verification.



All Rights Reserved

When renewing the server certificate, the PKI sponsor must complete a new identity verification.

Confirm that you are a current employee of the applying company and that you are authorized to obtain server certificates for the company by completing and submitting the “Proof of Organizational Affiliation” letter.

The server designated in the certificate request is the only system on which the certificate is to be installed.

To use the certificate only for authorized applications that have met the requirements of this CPS.

To use the certificate only for the purpose for which it was issued, as indicated in the key usage extension.

To report any changes to information contained in the certificate to the appropriate RA for certificate reissue processing.

2.1.7 Code Signer Certificate Subscriber Obligations

When requesting and using a code-signing certificate issued under this CPS, the organization and the code signer accept the following obligations:

To accurately represent themselves in all communications with the PKI and abide by all the terms, conditions and restrictions levied upon the use of the issued private key(s) and certificate(s)

To protect the certificate private key from unauthorized access in accordance with Section 6.2

To immediately report to the RA if private key compromise is suspected

Request that the Code Signing Attribute Authority approve and forward to the RA an authorization on the code signer’s behalf to obtain a code signing certificate

To apply for (generate a key pair) and download the code signing certificate onto a FIPS 140-2 Level 2 validated smart card

When not in use, the Code Signer hardware token shall be stored in a locked container

Submit the certificate request to the CA via a secure (SSL protected) web session

Digitally sign an e-mail, using acceptable PKI credentials, that contains the subject Distinguished Name (DN), code signer DN, and the code signing certificate request number and send it to an ORC RA

In the event of Code Signer change (due to the verified individual having left the employ of the subscribing organization or no longer being assigned as the code signer for the certificate) the applicant organization must designate and notify ORC of the new Code Signer



All Rights Reserved

The Code Signer is a current employee of the organization and is authorized to obtain a code signing certificate(s) for the organization

To use the certificate only for authorized applications which have met the requirements of this CPS

To use the certificate only for the purpose for which it was issued, as indicated in the key usage extension

To report any changes to information contained in the certificate to the appropriate RA

2.1.8 Relying Party Obligations

This CPS is binding on each Qualified Relying Party by virtue of its GSA ACES Agreement, and governs its performance with respect to its application for, use of, and reliance on ACES Certificates.

ORC publicly posts a summary of this CPS on the ORC website (ACES.orc.com) to provide the relying party information regarding the expectation of the ORC systems. When accepting a certificate issued under this CPS, a relying party accepts the following obligations:

Perform a risk analysis to decide whether the level of assurance provided by the certificate is adequate to protect the Relying Party based upon the intended use

To ensure that the certificate is being used for an appropriate approved purpose

To check for certificate revocation prior to reliance

To use the certificate for the purpose for which it was issued, as indicated in the certificate information (e.g., the key usage extension)

To verify the digital signature of the ORC CA that issued the certificate being relied upon as stipulated in the ACES CP

To establish trust in the ORC ACES PKI by verifying the chain of CA certificates starting from a trust anchor of the relying party in accordance with the guidelines set by the X.509 Version 3 Amendment:

o for the ORC ACES PKI, this trust anchor is the ORC ACES Self-signed Root CA with no additional chaining

o for ORC certificates asserting a FPCPF OID, this trust anchor is the FPCPF Self-signed CA with no additional chaining

To acknowledge all warranty and liability limitations

Preserve original signed data, the applications necessary to read and process that data, and the cryptographic applications needed to verify the digital signatures on that data for as long as it may be necessary to verify the signature on that data



All Rights Reserved

To abide by all the terms, conditions and restrictions levied upon the use of the issued private key(s) and certificate(s) as stipulated in the ACES CP

Data format changes associated with application upgrades may invalidate digital signatures and will be avoided.

Relying parties that do not abide by these obligations assume all risks associated with the certificates upon which they are relying.

2.1.8.1 Acceptance of Certificates

As stipulated in the ACES CP, each Qualified Relying Party will validate Certificates issued by all ORC CAs under this CPS.

2.1.8.2 Certificate Validation

As stipulated in the ACES CP, each Qualified Relying Party will validate every Certificate it requests and receives with the CA that issued the certificate.

2.1.8.3 Reliance

A Qualified Relying Party may rely on a valid Certificate for purposes of verifying the digital signature only if:

The ACES Certificate is used and relied upon to authenticate a subscriber’s digital signature by an application bound under the ACES CP.

Prior to reliance, the Qualified Relying Party (1) verified the digital signature by reference to the public key in the ACES Certificate, and (2) checked the status of the ACES Certificate by generating an online status request to the ORC systems, and a check of the certificate’s status indicated that the certificate was valid.

The reliance was reasonable and in good faith in light of all the circumstances known to the Qualified Relying Party at the time of reliance.

2.1.9 Policy Authority Obligations

The Policy Authority, as designated in Section 1.4, is responsible for the terms of this CPS and contract administration.

2.1.10 ORC Certificate Status Authority (CSA) Obligations

ORC operates a CSA using an OCSP responder that provides revocation status and/or certificate validation responses. The ORC CSA practices conform to the stipulations of the ACES CP and this CPS. All ORC CSA practice updates, as well as any subsequent changes are updated in this CPS and submitted to the Policy Authority for conformance assessment. The CSA practices include:

Conformance to the stipulations of the ACES CP and this CPS.



All Rights Reserved

Ensuring that certificate and revocation information is accepted only from valid CAs.

Providing only valid and appropriate responses.

Maintaining evidence of due diligence being exercised in validating certificate status.

2.2 Liability

Nothing in this CPS creates, alters, or eliminates any other obligation, responsibility, or liability that may be imposed on any Program Participant by virtue of any contract or obligation that is otherwise determined by applicable law.

2.2.1 Authorized CA Liability

As an Authorized CA, ORC stipulates that tort liability for transactions involving services under the ACES contract(s) are governed by the Federal Tort Claims Act. The Government Contractor defense is available to ORC to the extent that ORC has met the standard of care spelled out in this CPS.

2.2.2 RA, IA, CMA, and Repository Liability

No additional stipulations.

2.2.3 Warranties and Limitations On Warranties

ORC warrants that its procedures are implemented in accordance with this CPS, and that any issued certificates that assert the policy OIDs identified in this CPS, are issued in accordance with the stipulations of this CPS. ORC warrants that CRLs are issued and keys generated by ORC are in conformance with this CPS. ORC warrants that any CMA or ORC designated authority operates in accordance with the applicable sections of this CPS.

Subscriber organizations that authorize and employ LRAs warrant that:

The LRA procedures are implemented in accordance with the ACES CP and this CPS;

All LRA actions are accomplished in accordance with this CPS;

LRAs operate in accordance with the applicable sections of this CPS;

The organization’s PKI Sponsor will cooperate and assist ORC in monitoring and auditing authorized LRAs operating in accordance with the applicable sections of this CPS;

Network security controls to LRA equipment are in accordance with the applicable sections of this CPS; and,



All Rights Reserved

PKI Sponsor(s) and/or LRA(s) meet the personnel and training requirements stipulated in this CPS.

ORC does not warrant the actions of Notaries Public to witness and certify the validity of documents and to take affidavits and depositions.

2.2.4 Damages Covered and Disclaimers

Without limiting other subscriber obligations stated in this CPS, subscribers are liable for any misrepresentations they make in certificates to third parties who, having verified one or more digital signatures with the certificate, reasonably rely on the representations contained therein.

ORC disclaims all warranties and obligations of any type other than those listed in Sections 2.1 and 2.2.

2.2.5 Loss Limitations

ORC disclaims any liability for loss due to use of certificates issued by the ORC ACES PKI provided that the certificate(s) and associated CRLs were issued in accordance with this CPS. ORC disclaims any liability for loss due to use of certificates issued by the ORC ACES PKI where the relying party has not used validation information in compliance with this CPS and the ACES CP. ORC acknowledges professional liability with respect to the ORC ACES PKI, ORC CAs, CMAs and/or the ORC RAs and ORC LRAs.

2.2.6 Other Exclusions

Certificate applicants and subscribers signify and guarantee that their application does not interfere with or infringe upon the rights of any others regarding their trademarks, trade names or any other intellectual property. Certificate applicants and subscribers shall hold ORC harmless for any losses resulting from any such act.

As a result of issuing a certificate that identifies a person as an employee or member of an organization, ORC does not represent that the individual has authority to act for that organization.

2.3 Financial Responsibility

2.3.1 Indemnification By Relying Parties and Subscribers

ORC assumes no financial responsibility for improperly used certificates.

2.3.2 Fiduciary Relationships

Issuance of certificates in accordance with this CPS does not make ORC (its designated authorities or employees) an agent, fiduciary, trustee, or other



All Rights Reserved

representative of subscribers or relying parties. The relationship between ORC (or its designated authorities or employees) and subscribers and that between ORC (or its designated authorities or employees) and relying parties is not that of agent and principal. Neither subscribers nor relying parties have any authority to bind ORC (or its designated authorities or employees) by contract or otherwise, to any obligation. ORC (or its designated authorities or employees) make no representations to the contrary, either expressly, implicitly, by appearance, or otherwise.

2.3.3 Administrative Processes

A nationally known accounting company (approved by the ACES PMO) audits ORC annually, in accordance with WebTrust. ORC is also audited aperiodically by: GSA, DoD and NSA. ORC has an independent internal department that performs weekly procedures in order to attest to ORC’s compliance with this CPS. Audit and inspection is accomplished in accordance with the American Institute of Certified Public Accountants (AICPA) WebTrust Program for Certification Authorities or current industry accepted standards and practices.

2.4 Interpretation and Enforcement

2.4.1 Governing Law

The laws of the United States of America govern the enforceability, construction, interpretation, and validity of this CPS with respect to the ACES CP and the Contract between GSA and ORC (the ACES provider).

With respect to Subscriber or Relying Party Agreements or Obligations made by a U.S. Government entity by purchasing the services associated with this CPS, agreement and interpretation will be governed by the Contracts Disputes Act of 1978 as amended (codified at 41 U.S.C. section 601). If the individuals or organizations purchasing the services associated with this CPS are not within the jurisdiction of the U.S. Government, the laws of the Commonwealth of Virginia apply.

Various laws and regulations may apply, based on the jurisdiction in which a certificate is issued or used. It is the responsibility of the certificate holder, or user, to ensure that all applicable laws and regulations are adhered to.

2.4.2 Severability of Provisions, Survival, Merger, and Notice

All contracts or orders negotiated, for the purpose of providing ORC services under this CPS, shall contain clauses that ensure continuity and stability of the ORC PKI operations.

Should it be determined that one section of this CPS is incorrect or invalid, the other sections shall remain in effect until the CPS is updated. Requirements for updating this CPS are described in Section 8. Responsibilities, requirements,



All Rights Reserved

and privileges of this document are transferred to the newer edition upon release of that newer edition.

2.4.3 Dispute Resolution Procedures

In the event of any dispute or disagreement between two or more of the program participants (“disputing parties”) arising out of or relating to ACES Contracts, CPS, or agreements, the disputing parties shall use their best efforts to settle the dispute or disagreement through negotiations in good faith following notice from one disputing party to the other(s). If the disputing parties cannot reach a mutually agreeable resolution of the dispute or disagreement within 60 days following the date of such notice, then the disputing parties may present the dispute to the GSA ACES Contract Officer for resolution.

Any contract dispute between ORC and GSA shall be handled under the terms and conditions of the ACES contract. An attempt shall be made to resolve any dispute through an independent mediator, mutually agreed to by all disputing parties. If mediation is unsuccessful in resolving a dispute, it shall be resolved by arbitration in accordance with applicable statutes.

2.5 Fees

All fees are set in accordance with the terms of the ORC ACES Contract. Fees are published on the ORC website or established contractually. Fees are published at http://aces.orc.com and may change with a 7-day notice.

2.5.1 Certificate Issuance, Renewal, Suspension, and Revocation Fees

A fee per validity year, unless otherwise negotiated, is levied by ORC to issue Identity and Encryption certificates. A fee per year, unless otherwise negotiated, is levied by ORC to issue Server and Code Signer certificates. Likewise, a fee per each additional year, unless otherwise negotiated, is levied by ORC to renew an ORC ACES certificate. A fee per encryption certificate is levied for the escrowing of encryption keys.

A fee, unless otherwise negotiated, is levied by ORC for the replacement of certificates and or tokens when the subscriber’s private key has not been compromised and there are no changes to the certificate.

Fees for tokens are separate from Certificate Issuance, Renewal, and Replacement Fees.

2.5.2 Certificate Access Fees

ORC does not impose any certificate access fees on subscribers with respect to its own ACES Certificate(s) or the status of such Certificate(s). No fee is levied by ORC for access to information about any certificate issued by the ORC that is



All Rights Reserved

requested under a court order. ORC assesses a fee from subscribers and Relying Parties for recovering archived certificates.

2.5.3 Revocation or Status Information Access Fees

Fees may be assessed for certificate validation services as set forth in the Authorized ORC-GSA ACES Contract. ORC CSA services are priced separate from certificate issuance services, on a transaction and subscription basis.

2.5.4 Fees for Other Services Such as Policy Information

No fee is levied for online access to policy information. A reasonable fee to cover media reproduction and distribution costs may be levied for a physical media copy of this policy information. A consulting fee per hour is levied for certificate support required in addition to the detailed instructions delivered with the notification of subscriber certificate issuance. This additional support includes documentation, telephone and on-site support.

2.5.5 Refund Policy

Refunds may be negotiated on a case-by-case basis.

2.6 Publication and Repository

2.6.1 Publication of ORC ACES Information

ORC maintains a publicly accessible repository that is available to subscribers and relying parties that contains:

A listing of all current signature and encryption certificates signed by the ORC ACES CAs

Current, complete, and accurate CRLs

ORC ACES certificates for signing keys

ORC ACES certificates for CRL signing keys

A copy or link to the current ACES CP

A summary of this approved CPS

Any additional policy, waiver, or practice information that is supplemental to the ACES CP or this CPS

The repository is located at http://aces.orc.com.

2.6.2 Frequency of Publication

Certificates are published to a repository at the time of issuance and remain accessible from the repository following subscriber acceptance. CRL publication

http://aces.orc.com/



All Rights Reserved

is in accordance with Section 4.4.5.1. This CPS is published in accordance with Section 8.2.

2.6.3 Access Controls

There are no access controls on the reading the CPS summary, any supplemental policy information, or any supplemental practice information published by ORC. Certificate and CRL information are publicly available.

Access to ACES Certificates and ACES Certificate status information is in accordance with provisions of the ORC ACES Contract. Access controls include:

Access to ORC Electronic Resources are be controlled by job requirements and authentication, as stipulated in this CPS.

ORC employees are only able to access those resources that they require to accomplish the tasks they are assigned, as stipulated in this CPS (access rights are assigned by resource (server, computer, share, volume, printer, etc.)).

User authentication is via certificate authentication (or UserID and password when appropriate) and data encryption is used, as stipulated in this CPS.

ORC employees are assigned access rights before accessing any electronic resources.

The ORC Corporate Security Auditor determines and periodically reviews user access rights.

The CAA and SA are notified of any changes that affect employee access rights.

These policies are elaborated upon in the ORC Systems Security Plan (SSP).

2.6.4 Repositories

ORC maintains a master directory accessible through an LDAP interface. This directory is protected by a firewall and is accessible through the Internet. Information in ACES repositories is protected in accordance with the Privacy Act of 1974 as set forth in ORC’s Privacy Policy and Procedures documents. See Section 2.8.1.1.

Updating the repository is restricted only to authorized individuals using certificate authenticated access control over SSL. The directory is configured by the CAA to recognize ORC IAs and CAAs as authorized to make changes. ORC protects any and all repository information not intended for public dissemination or modification.

The directory is located at:

ldap://aces-ds.orc.com.



All Rights Reserved

The CRLs are located at:

ldap://aces-ds.orc.com/ cn=ORC ACES <CA Name>, o=ORC PKI, c=US?certificaterevocationlist;binary


The ORC CA signing certificates are located at:

ldap://aces-ds.orc.com/ cn=<CA Name>, o= ORC PKI, c=US

The ORC ACES Root Certificate is located at:

ldap://aces-ds.orc.com/ cn=ORC Government Root CA, o=ORC PKI , c=US

A link to the FPCPF Trust Anchor is located at:

http://aces.orc.com/FICC

2.7 Inspections And Reviews

The ORC ACES system, including all of its CMA and repository roles underwent an ACES Security Certification and Accreditation (C&A) as a condition of obtaining and retaining approval to operate as an “Authorized CA” in accordance with the ACES CP and the GSA ACES Contract. The purpose of the C&A process is to verify that the CA has in place and follows a system that assures that the quality of its “Authorized CA” Services; and conforms to the requirements of the ACES CP, the GSA ACES Contract and this CPS.

2.7.1 Certification and Accreditation

ORC (including all of its RA, CMA, and Repository subcontractor(s), if applicable), undergo ACES Security C&A as a condition of obtaining and retaining approval to operate as an “Authorized CA” as stipulated in the ACES CP and GSA ACES Contract and in accordance with Federal regulations and GSA policy and supporting security guidelines. See Appendix D: Applicable Federal and GSA Regulations.

Management authorization is based on an assessment of management, operational, and technical controls. Since the SSP establishes the security controls, it forms the basis for the accreditation, supplemented by more specific studies as needed. In addition, periodic review of controls contributes to future accreditations.

Depending upon the risk and magnitude of harm that could result, weaknesses identified during the review of security controls are reported by the GSA ACES Program Manager as deficiencies in accordance with OMB Circular A-123,




All Rights Reserved

Management Accountability and Control, and the Federal Managers' Financial Integrity Act.

Re-authorization occurs prior to a significant change in processing, but at least every three years, as required by the GSA ACES Program Manager. It may be done more often where there is a high risk and potential magnitude of harm.

2.7.1.1 Frequency of Certification Authority Compliance Review

ORC has undergone a C&A from GSA prior to initial approval as an ACES “Authorized CA”. ORC acknowledges the Government’s right to require periodic and aperiodic inspections and audits of the ACES system within its domain to validate the CA is operating in accordance with the security practices and procedures set forth in this CPS as stipulated in the ACES CP and the GSA ACES Program Manager.

ORC shall submit to a technical evaluation by the Government and support a Government evaluation of the system. Audit results shall be provided to the Government for review. If ORC fails to demonstrate the proper implementation of the PKI, documentation shall be provided to the Government indicating areas that are deficient. A second audit shall be performed to demonstrate the PKI has been properly implemented. Refer to Section 2.3.3.

2.7.1.2 Identity/ Qualifications of Reviewer

The C&A process shall be conducted by an independent security audit firm acceptable to GSA that is qualified to perform a security audit on a CA.

ORC contracts to an auditing firm to perform an independent audit. This audit team, in total, meets or exceeds the following qualifications:

More than three years experience performing security audits

More than one year PKI engineering experience

More than three years cryptography engineering experience

More than three years of computer security experience

GSA or ORC engages the services of an auditor that is competent in the field of security compliance audits of Information Technology systems and is thoroughly familiar with the CPS. In all cases, the selected auditor will have experience in information security, cryptography and PKI.

2.7.1.3 Auditor's Relationship to Audited Party

The auditor identified above is an independent entity and may have a contractual relationship with ORC for performance of the audit. ORC also performs internal audits of CMA facilities, conducted by a Corporate Security Auditor, as defined herein.



All Rights Reserved

2.7.1.4 Communication of Results

Results of the C&A review are made available to GSA, to be used in determining the CA’s suitability for continued performance as an Authorized CA.

2.7.2 Quality Assurance Inspection and Review

2.7.2.1 Topics Covered by Quality Assurance Inspection and Review

All aspects of CA operation as specified in this CPS are subject to Quality Assurance compliance inspections and reviews. The quality assurance inspection shall be conducted in concert with the C&A (Section 2.7.1) and pursuant to the guidance provided in the American Institute of Certified Public Accountants (AICPA) WebTrust Program for Certification Authorities or current industry accepted standards and practices, as described herein.

2.7.2.2 Identity/Qualifications of Reviewer

Stipulated in Section 2.7.1.2.

2.7.2.3 Auditor's Relationship to Audited Party


2.7.2.4 Audit Compliance Report


2.7.2.5 Actions Taken as a Result of Deficiency

GSA will address any identified deficiencies with ORC. Any discrepancies between the actual operation and the stipulations of this CPS and the ACES CP shall be noted. The Government shall be immediately notified of all discrepancies. A remedy will be determined, including a reasonable time for completion.

Any remedy may include permanent or temporary CA cessation or termination of CA accreditation, but several factors must be considered in this decision, including the severity of the discrepancy and the risks it imposes, and the disruption to the certificate using community.

Remedies shall be defined and communicated to ORC as soon as possible to limit the risks created. The implementation of remedies shall be communicated to the appropriate authority. A special audit may be required to confirm the implementation and effectiveness of the remedy.



All Rights Reserved

2.7.2.6 Communication of Results

Results of the QA compliance inspection and review are made available to GSA. The results will be used in determining the CA’s suitability for continued performance as an “Authorized CA”.

The auditor shall communicate the results of any inspection or audit, in whole, to ORC and to the Government. Complete audit information shall be posted on the ORC ACES PKI website in an access-controlled area. This website operates using SSL. If found not to be in compliance with this CPS, or the policy identified in Section 1.2, ORC shall be notified immediately upon completion of the audit. Required remedies shall be defined and communicated to ORC as soon as possible to limit the risks created. The implementation of remedies shall be communicated to the appropriate authority. A special audit may be required to confirm the implementation and effectiveness of the remedy.

ORC shall post a compliance audit summary outlining key results on the ORC ACES PKI website in a publicly accessible area to allow inspection by the interested persons. This website operate using the SSL protocol to protect against alteration of result information.

2.8 Confidentiality

As an ACES “Authorized CA”, ORC maintains an ACES system of records under established administrative, technical, and physical safeguards to ensure the security and confidentiality of records and to protect against any anticipated threats or hazards to their security or integrity which could result in substantial harm, embarrassment, inconvenience, or unfairness to any individual on whom information is maintained IAW Title 5, U.S.C., Sec. 552a.

2.8.1 Types of Information to Be Kept Confidential

2.8.1.1 Privacy Policy and Procedures

As an ACES “Authorized CA”, ORC maintains an ACES system of records on behalf of the Government under a written Privacy Policies and Procedures (PPP) designed to ensure compliance with the requirements of 5 U.S.C. 552a, Appendix I to OMB Circular A-130, and the ACES Contract. These policies and procedures are incorporated into this CPS.

2.8.1.2 Subscriber Information

The ORC ACES system protects the confidentiality of personal information regarding subscribers that is collected during the applicant registration, ACES Certificate application, authentication, and certificate status checking processes in accordance with the Privacy Act of 1974, and Appendix III to Office of Management and Budget (OMB) Circular A-130. The procedures followed by ORC for Privacy Act requirements, and all aspects of CA administration, are



All Rights Reserved

contained in Appendix B: Acronyms And Abbreviations. Such information shall be used only for the purpose of providing Authorized CA Services and carrying out the provisions of the ACES CP, the GSA ACES Contract and this CPS. This information shall not be disclosed in any manner to any person without the prior consent of the subscriber, unless otherwise required by law, except as may be necessary for the performance of the Authorized CA services in accordance with the ACES Contract. In addition, personal information submitted by subscribers:

Must be made available by ORC to the subscriber involved following an appropriate request by such subscriber

Must be subject to correction and/or revision by such subscriber

Must be protected by ORC in a manner designed to ensure the data’s integrity

Cannot be used or disclosed by ORC for purposes other than the direct operational support of ACES unless such use is authorized by the subscriber involved

Under no circumstances does ORC (or any authorized IA, RA, CMA, or Repository) have access to the private keys of any subscriber to whom it issues an ACES Certificate, with the exception of escrowed private encryption keys.

2.8.1.3 GSA and Other Government Information

ORC takes reasonable steps to protect the confidentiality of any GSA, Qualified Relying Party, or other Government information provided to the Authorized CA. Such information is used only for the purpose of providing ACES Services and carrying out the provisions of the ACES CP, the GSA ACES Contract and this CPS. This information is not disclosed in any manner to any person except as may be necessary for the performance of the ACES Services in accordance with the GSA ACES contract.

2.8.2 Types of Information Not Considered Confidential

Information contained on a single ACES Certificate or related status information is not considered confidential, when the information is used in accordance with the purposes of providing ORC ACES Services and carrying out the provisions of this CPS and the GSA ACES contract and in accordance with the Privacy Act of 1974, and Appendix III to Office of Management and Budget (OMB) Circular A-130. However, a compilation of such information is treated as confidential. Information not considered includes the subscriber’s name, e-mail address, certificate public key, and certificate validity period.

2.8.3 Disclosure of Certificate Revocation/Suspension Information

When applicable, the CRL for a CA is updated in accordance with Section 4.4.5.1. This information shall be available in the CA repository. Information concerning the revocation of a certificate or events leading to such a revocation should be limited to the individuals involved.



All Rights Reserved

2.8.4 Release to Law Enforcement Officials

Sensitive data shall be released to law enforcement officials only under a proper court order. ORC does not disclose certificate or certificate-related information to any third party unless expressly authorized by the ACES Program Manager, required by criminal law, government rule or regulation, or order of a criminal court with jurisdiction. ORC authenticates such requests prior to disclosure. External requests must be made via the subscriber’s organization, unless under court order.

2.8.5 Release as Part of Civil Discover

Sensitive information shall be released to civil authorities only under a proper subpoena.

2.8.6 Disclosure upon Owner's Request

Subscriber’s information shall be made available to an identified party, upon the request of that subscriber, for any purpose related to the issue of the subscriber’s certificate. See also Section 2.8.1.

2.9 Security Requirements

The ACES Program and all GSA Federal employees and authorized users of IT including contractors, consultants, or other third parties who are specifically granted access to the ACES Program shall comply with GSA Order CIO 2100.1A. At a minimum ORC met the following security controls prior to being approved as an ACES “Authorized CA”:

Technical and/or security evaluation complete

Risk assessment conducted

Rules of behavior established and process to be signed by users

Contingency Plan developed and tested

Security Plan developed, updated, and reviewed

System evaluated meeting all applicable Federal laws, regulations, policies, guidelines, and standards

In-place and planned security safeguards adequate and appropriate for the system, i.e., the level of controls are consistent with the level of sensitivity of the system

ORC does not publish or disclose in any manner, without the GSA Administrative Contracting Officer’s (ACO) written consent, the details of any safeguards either designed or developed by ORC under the ACES Contract or otherwise provided by the Government.



All Rights Reserved

2.9.1 System Security Plan (SSP)

ORC maintains an SSP in accordance with requirements set forth in OMB Circular A-130, NIST 800-18, GSA Order 2100.1A and all supporting GSA security guidelines, as well as the ACES Contract.

2.9.2 Risk Management

ORC conducts periodic risk assessments and maintains the ORC ACES system at the level of residual risk accepted by the designated approving authority in accordance with OMB Circular A-130, NIST 800-18, GSA Order 2100.1A and all supporting GSA security guidelines, and the ACES Contract. The ORC risk assessment is included in the ORC SSP.

2.9.3 Certification and Accreditation

Certification and Accreditation of the ORC ACES system has been performed and is maintained in accordance with requirements set forth in OMB Circular A-130, NIST 800-18, GSA Order 2100.1A and all supporting GSA security guidelines, and the ACES Contract.

2.9.4 Rules and Behavior

The ACES SSP includes the rules of conduct that is used to instruct ORC’s officers and employees in compliance requirements and penalties for noncompliance. The rules of behavior have been developed and are implemented in accordance with requirements set forth in OMB Circular A-130, NIST 800-18, GSA Order 2100.1A and all supporting GSA security guidelines, and the ACES Contract.

2.9.5 Contingency Plan

The ORC SSP includes a contingency plan under which ORC has implemented and periodically tests the ACES system in accordance with guidelines provided in OMB Circular A-130, NIST 800-18, FIPS PUB 87, and GSA Order 2100.1A and all supporting GSA security guidelines. The contingency plan is maintained in accordance with the requirements of the SSP.

2.9.6 Incident Response Capability

ORC ensures that there is a capability to provide help to users when a security incident occurs in the system and to share information concerning common vulnerabilities and threats. A security incident is defined to be any adverse event that threatens the security of information resources. Adverse events include compromises of integrity, denial of service, compromises of confidentiality, loss of accountability, or damage to any part of the system.

Incident response procedures and reporting of security incidents are in accordance with guidelines provided in OMB Circular A-130, NIST 800-18, GSA



All Rights Reserved

Order 2100.1A and all supporting GSA security guidelines, and the ACES contract.

2.10 Intellectual Property Rights

“Access Certificates for Electronic Services,” “ACES”, and the ACES OIDs are the property of GSA, which is used only by ORC in accordance with the provisions of this CPS and the ORC-GSA ACES Contract. Any other use of the above without the express written permission of GSA is expressly prohibited.

Distinguished names are the property of the individuals named or their employer. Unless otherwise agreed, property interests in the following security-related information materials and data are regarded as the property of the parties indicated below:

Certificates and CRLs issued under this CPS are the personal property of Operational Research Consultants, Inc. Permission is granted to reproduce and distribute certificates issued by ORC on a non-exclusive, royalty-free basis, provided that they are reproduced and distributed in full. Certificates and CRLs shall not be published in any publicly accessible repository or directory without the express written permission of ORC

This CPS is the sole property of Operational Research Consultants, Inc.

Private keys are the personal property of the subscribers who rightfully use or are capable of using them (or their employer or principal), regardless of the physical medium within which they are stored and protected

Public keys are the personal property of subscribers (or their employer or principal), regardless of the physical medium within which they are stored and protected

ORC public keys, including ORC CA public keys, are the property of Operational Research Consultants, Inc. ORC licenses relying parties to use such keys only in conjunction with FIPS 140-2 validated encryption modules



All Rights Reserved

3 Identification And Authentication

3.1 Initial Registration

This section contains the practices to be followed in identifying and authenticating individuals involved in the certification request process.

3.1.1 Types of Names

All certificates issued by the ORC under this CPS use the Distinguished Name (DN) format for subject and issuer name fields. In the case of individual certificates, ORC assigns an X.501 distinguished name specifying a geo-political name. In the case of component/ device certificates, ORC assigns a geo-political name.

DNs consist of a combination of a Common Name (CN) and a Relative Distinguished Name (RDN). CNs are either full names for individuals, Uniform Resource Locators (URLs) or Internet Protocol (IP) addresses for servers or name of the code signer’s organization for code signing certificates.

A generational qualifier, such as “Sr.” or “III”, may be appended to any of the common name forms (detailed below), as required. For names assigned to federal contractors and other affiliated persons, the generational qualifier is inserted between lastname and “(affiliate)”.

ORC enforces name uniqueness in the case of individual certificates by including a dnQualifier defined as a unique ten-digit number preceded by “ORC” (unique identification string) and assigned sequentially by ORC, followed by:

.ID, for Identity Certificates

.encrypt, for Encryption Certificates

The unique identifier is the same for all certificates (digital signature/non-repudiation and key encipherment) issued to a single subscriber. For code signing certificates, the unique identification number may be assigned by the requesting organization.

In the case of the User Certificates the unique identification string may be the serialNumber=FASC-N. In the case of the Card Authentication Certificates the unique identification string must be the serialNumber=FASC-N.

The ORC Authorized CA CNs are:

cn=ORC ACES Unaffiliated cn=ORC ACES Business cn=ORC ACES Government (for federal, state, and local Government)



All Rights Reserved

The RDN for ORC Authorized ACES CA Certificates is:

o=ORC PKI, c=US

Since the DN is ‘DN = CN, RDN ’, the ORC Authorized CA DNs are ‘cn=ORC ACES <CA name>, o=ORC PKI, c=US’.

The RDN for Unaffiliated Subscriber Certificates is:

ou=<State of Residence or citizenship4>, c=US

or, in the case of certificates asserting FPCPF OIDs:

[ou=department]5, ou=<FPCPF sponsoring agency>, o=U.S.

Government, c=US

The RDN for Business Representative certificates is:

ou=<Location or Department Name>, ou=<State of Residence or citizenship

6>, o=<Organizations Name> c=US, where

ou=<Location or Department Name> is optional


[ou=structural container]7, [ou=department]

8, ou=< FPCPF

sponsoring agency>, o=U.S. Government, c=US

The RDN for Federal Government entity certificates is:

4 State of Residence is used for U.S. Citizens and Citizenship for non-U.S. citizens.

5 Optional.

6 State of Residence is used for U.S. Citizens and Citizenship for non-U.S. citizens.

7 The ou==structural container is optional to support local directory requirements, such as

differentiation between human subscribers and devices. This ou may not be employed to further between subcomponents within an agency. 8 Optional.



All Rights Reserved

[ou=structural container], ou=<department>, ou=<Agency Name>, o=U.S. Government, c=US

The RDN for State and Local Government entity certificates is:

ou=<Agency Name>, o=<State Name>, c=US, where ou=<Agency Name> is optional


[ou=structural container], [ou=department]9, ou=< FPCPF

sponsoring agency>, o=U.S. Government, c=US

The ORC Authorized CAs also sign ORC subordinate certificate authorities to support specific organizational requirements. The RDN for these subordinate CA Certificates is:

o=ORC PKI, c=US

Since the DN is ‘DN = CN, RDN ’, the ORC subordinate CA DNs are ‘cn=<CA name>, o=ORC PKI, c=US’.

For ACES certificates only, additional ‘ou’ fields may be added to any RDN to support organizational needs. Additional ‘ou’ fields are not added on any certificates asserting a FPCPF OID.

3.1.1.1 ACES Unaffiliated Individual Digital Signature and Encryption

Certificates

The subject name used for ORC ACES Unaffiliated Individual Digital Signature and Encryption Certificates applicants is the subscriber’s authenticated Common Name and optional Subject Alternative Name marked non-critical, where:

CN = John.J.Smith; or CN = John.Jay.Smith

9 Optional.



All Rights Reserved

Except in the case of Individual Digital Signature and Encryption Certificates asserting FPCPF OIDs, where:

CN = Nickname Smith (affiliate); or CN = John J. Smith (affiliate); or CN = John Jay Smith (affiliate)

3.1.1.2 ACES Business Representative Digital Signature and Encryption

Certificates

ORC ACES Business Representative Digital Signature and Encryption certificates shall X.500 Distinguished Name, and optional Subject Alternative Name. Subject Alternative Names are marked non-critical. DNs are assigned by ORC, in accordance with a naming authority, where:


Except in the case of Business Representative Digital Signature and Encryption Certificates asserting FPCPF OIDs, where:


ACES Business Representative Digital Signature Certificates assert an alternate name form subject to requirements set forth in Section 3.1.2.2, below intended to ensure name uniqueness.

3.1.1.3 ACES Agency (Relying Party Applications) Digital Signature and

Encryption Certificates

ORC ACES Agency (Relying Party Applications) Digital Signature and Encryption certificates assert X.500 Distinguished Name, and optional Subject Alternative Name marked non-critical. ORC ACES Agency (Relying Party Applications) Digital Signature and Encryption certificates contain an X.500 DN that contains domain component elements assigned by ORC, in accordance with the agency’s naming scheme under government-wide policy, where:

CN = Host URL, Name or IP Address of the ACES Relying Party Application Digital Signature and Encryption Certificates assert an alternate name form subject to requirements, as set forth in Section 3.1.2.3, below, intended to ensure name uniqueness.

3.1.1.4 Agency Applications SSL Server Certificates

ORC Agency Applications SSL Server certificates assert the X.500 Distinguished Name of the server including the identification of the organization and organizational unit sponsoring the server, where:



All Rights Reserved

CN = <fully qualified domain name of the server>

3.1.1.5 ACES Federal Employee Digital Signature and Encryption

Certificates

ORC ACES Federal Employee Digital Signature and Encryption certificates assert an X.500 Distinguished Name, and optional Subject Alternative Name marked non-critical. DNs are assigned by ORC, in accordance with a naming authority, where:

CN = Nickname Smith; or CN = John J. Smith; or CN = John Jay Smith

Every ACES Federal Employee subscriber certificate contain an Organization field wherein O=U.S. Government and an Organizational Unit field wherein OU=agency name as stipulated by the agency. ACES Federal Employee Digital Signature Certificates assert an alternate name form subject to requirements, as set forth in Section 3.1.2.6 below, intended to ensure name uniqueness.

3.1.1.6 ACES State and Local Government Employee Digital Signature and


ORC ACES State and Local Government Employee Digital Signature and Encryption certificates assert an X.500 Distinguished Name, and optional Subject Alternative Name marked non-critical. DNs are assigned by ORC, in accordance with a naming authority, where:


Every ACES State and Local Government Employee subscriber certificate contain an Organization field wherein O=State and an Organizational Unit fields wherein OU=agency name, as stipulated by the agency. ACES State and Local Government Employee Digital Signature Certificates assert an alternate name form subject to requirements, as set forth in Section 3.1.2.7, below, intended to ensure name uniqueness.

Except in the case of Digital Signature and Encryption Certificates asserting FPCPF OIDs, where:


3.1.1.7 Common Policy PIV Authentication Certificates

Certificates issued that assert an id-fpki-common-authentication and/ or id-fpki-common-cardAuth OID include a subject alternative name that includes the



All Rights Reserved

pivFASC-N name type, where this name shall be the FASC-N of the subjects PIV card.

When desired by the sponsoring organization a subject distinguished name is included that follows the rules specified above for an individual identity certificate.

3.1.1.8 Common Policy PIV Card Authentication Certificates

Certificates issued that assert the id-fpki-common-cardAuth OID include a subject alternative name that will include the pivFASC-N name type, where this name shall be the FASC-N of the subjects PIV card. PIV Card Authentication Certificates do not include any other name in the subject alternative name extension but may include a non-NULL name in the subject field.

When desired by the sponsoring organization the subject distinguished name shall take the following form:

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

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. The 25-byte FASC-N is encoded by ORC CAs as 50 bytes of ASCII HEX.

3.1.2 Need for Names to be Meaningful

Common Names are meaningful as individual names, as actual server Uniform Resource Locators (URLs) or Internet Protocol (IP) addresses or as code signing organizational names. Names identify the person or object to which they are assigned. ORC ensures that an affiliation exists between the subscriber and any organization that is identified by any component of any name in its certificate.

The common name used represents the subscriber in a way that is easily understandable for humans. For people, this is typically a legal name. For equipment, this may be a model name and serial number, or an application process (e.g., Organization X Mail List or Organization Y Multifunction Interpreter).

ORC CAs asserting this policy only sign certificates with subject names from within a name-space approved by the GSA ACES Program Manager.

In the case of all Digital Signature and Encryption Certificates asserting FPCPF OIDs issued to federal employees:

CN = Nickname Smith; or



All Rights Reserved

CN = John J. Smith; or CN = John Jay Smith

In the case of all Digital Signature and Encryption Certificates asserting FPCPF OIDs issued to federal contractors and other affiliates designated by a sponsoring agency:


3.1.2.1 ACES Unaffiliated Individual Digital Signature and Encryption

Certificates

In the case of ORC ACES Unaffiliated Individuals, the authenticated Common Name shall be as described in Section 3.1.1.1.

3.1.2.2 ACES Business Representative Digital Signature and Encryption

Certificates

In the case of ORC ACES Business Representatives, the authenticated Common Name shall be as described in Section 3.1.1.2.

The legal name of the organization and/or unit is reflected in the RDN.

3.1.2.3 ACES Agency (Relying Party Applications) Digital Signature and


In the case of Relying Parties, the Common Name should be the authenticated name of the Relying Party application:

cn= (unique application name).(unique identification string)

3.1.2.4 ACES Authorized CA Digital Signature Certificates

ORC implements the name constraint extension of the X.509 version 3 certificate profile in issuing cross certificates, in accordance with the FBCA:

cn=ORC Government Root CA, o=ORC PKI, c=US

The ORC Government Root only signs certificates for the ORC authorized ORC ACES CAs identified in Section 3.1.1, above. ORC ACES CAs are not authorized to sign CAs external to the ORC ACES PKI.

3.1.2.5 Agency Applications SSL Server Certificates

In the case of Agency Application Servers, the Common Name should be the authenticated registered domain name of the server Agency Application:



All Rights Reserved

cn=<fully qualified domain name of the server>

3.1.2.6 ACES Federal Employee Digital Signature and Encryption

Certificates

In the case of Federal Employees, the authenticated Common Name shall be as described in Section 3.1.1.5.

The Agency legal name of the organization and/or unit is reflected in the RDN.

3.1.2.7 ACES State Employee Digital Signature and Encryption Certificates

ORC ACES State Employee Digital Signature and Encryption Certificates authenticated Common Name shall be as described in Section 3.1.1.6. The Agency legal name of the organization and/or unit is reflected in the RDN.

3.1.3 Rules for Interpreting Various Name Forms

Rules for interpreting name forms are contained in the applicable certificate profile (see Section 7.1.4), and are established by the GSA/FTS Center for Information Security. The ACES Program Management Office is responsible for Agency CA name space control.

Rules for interpreting the pivFASC-N name type are specified in [PACS].

3.1.4 Uniqueness of Names

ORC complies with uniqueness of names; including X.500 DNs. ORC enforces name uniqueness, as described in Sections 3.1.1 and 3.1.2.

ORC ensures the following for subscriber names:

The name contains the subscriber identity and organization affiliation (if applicable) that is meaningful to humans

The naming convention is described in this CPS (Section 3.1.1)

ORC complies with the Policy Authority for the naming convention

This does not prevent devices from sharing a Fully Qualified Domain Name (FQDN) as CN.

3.1.5 Name Claim Dispute Procedure

ORC investigates and corrects, as necessary, any name collisions brought to its attention. If appropriate, ORC shall coordinate with and/or defer to the GSA/FTS Center for Information Security and/or the GSA ACES Policy Authority.



All Rights Reserved

3.1.6 Recognition, Authentication and Role of Trademarks

A corporate entity is not guaranteed that its Common Name will contain a trademark if requested. ORC will not issue that name to the rightful owner if it has already issued one sufficient for identification. See Section 2.2.6.

The use of trademarks in a name form or as any part of a name form is discouraged. Trademarks shall not be used as a name form or as a part of the name form for certificates issued to government employees unless U.S. Government personnel hold them or devices have a legitimate right to their use. The holder of the trademark shall only use trademarks in certificates issued to contractors, contractor-owned servers, foreign nationals, or organizations with specific permission.

3.1.7 Verification of Possession of Private Key

In all cases where the subscriber generates key pairs, the subscriber is required to prove, to an ORC ACES CA, possession of the private key that corresponds to the public key in the certificate request. Subscribers are required to use a FIPS 140-2 validated cryptographic module for generation of keys. In the case of a Level 1 cryptographic module, the ORC ACES CAs perform a browser check prior to registration to ensure compliance against a list of FIPS 140-2 Level 1 browsers and upon submitting a registration request. ORC ACES CAs only allows compliant key pair generation. In the case of Level 2 tokens, required for medium hardware assurance certificates, key pair generation is accomplished with a Level 2-compliant token in the presence of an ORC RA or LRA, or other specifically assigned authority.

FPCPF PIV certificates are issued on a PIV card via a GSA FIPS-201 approved Card Management System (CMS), refer to FIPS 201 Evaluation Program Approved Product List (http://fips201ep.cio.gov/apl.php).

The subscriber is in possession and control of the private key from time of generation or benign transfer. The ORC ACES CAs authenticate the subscriber with a Proof of Possession (POP) test when requesting and retrieving a certificate by requiring the subscriber to perform a private key operation and verifying that the public key presented by the subscriber matches the private key. ORC supports multiple enrollment protocols which support POP including: KEYGEN/SPAC, CRMF/CMMF, PKCS #10 and CMC.

To effect POP the CA supplies a random challenge string to the browser as part of the KEYGEN tag. The public key generated by the browser and the challenge string supplied by the CA are DER (Distinguished Encoding Rules) encoded together, and the resulting PublicKeyAndChallenge value is then digitally signed with the private key to produce a SignedPublicKeyAndChallenge value. This signed value is then base 64 encoded and sent to the CA as part of the certificate request; the CA verifies the signature using the included public key, thus proving possession by the browser of the private key corresponding to that public key.



All Rights Reserved

The public key and challenge strings are DER encoded as PublicKeyAndChallenge and then digitally signed with the private key to produce a SignedPublicKeyAndChallenge. The SignedPublicKeyAndChallenge is base64 encoded, and the ASCII data is finally submitted to the server as the value of a name-value pair, where the name is specified by the NAME attribute of the KEYGEN tag. When retrieving the completed certificate the browser also checks before importing the certificate into its database, to verify that the public key in the certificate being installed matches the private key it originally generated.

An additional out-of-band check is preformed by requiring the requestor to print the base 64 of the DER encoded certificate request and present it in person during the validation process. The RA validates both the person’s identity and their possession of a certificate request corresponding to their private key.

In all cases, IAs may request additional information or verification from an RA or LRA if deemed necessary by the IA to confirm the requestor’s identity.

3.1.7.1 Hardware Tokens

When hardware tokens are used for private key storage, the ORC maintains a record of validation for receipt of the token by the subject.

3.1.7.2 Use of Shared Secrets

ORC does not use shared secrets.

3.1.8 Authentication of Sponsoring Organizational Identity

If the applicant is requesting a Business Representative, Federal Employee or State Employee ACES Certificate, in addition to verifying the applicant’s authorization to represent the Sponsoring Organization, ORC verifies the Sponsoring Organization's current operating status and that said organization conducts business at the address listed in the ACES Certificate application. ORC provides validation of information concerning the Sponsoring Organization, such as legal company name, type of entity, year of formation, names of directors and officers, address (number and street, city, ZIP code), and telephone number. All applicants are notified, on the website application process, that the process is secure.

Users shall provide proof of their relationship to the company/organization they work for. This proof can be accomplished by:

Applicant requesting a certificate accompanied by a U.S. Government sponsor

Applicant presenting a government-issued photo ID badge including the applicants company affiliation

Applicant providing a signed letter on company or agency letterhead from an authorized organization official attesting to the relationship (this is the only



All Rights Reserved

method approved for server certificate requests and code signing certificate requests)

Applicant presenting an un-expired photo ID badge issued by the organization

In all cases, in order to issue a certificate asserting a FPCPF OID, the applicant shall obtain, from an authorized organization official, approval to hold a FPCPF certificate, as stipulated in Section 3.1.9.7, below.

3.1.9 Authentication of Individual Identity

Verification of an applicant’s identity shall be performed prior to certificate issuance. All applicants for medium assurance certificates are required to appear in person before an RA, an LRA, or Notary Public (or a person legally empowered to witness and certify the validity of documents and to take affidavits and depositions) for identity authentication. All applicants for medium hardware assurance certificates are required to appear in person before an RA or LRA. Applicants for medium assurance and medium hardware assurance certificates are required to present two (2) official photo credentials along with other application information, identified below, and the applicant form generated during the certificate request process containing the public key.

Minors and others not competent to perform face-to-face registration alone are not supported under this CPS.

When the applicant’s identity is validated by a Notary Public (or a person legally empowered to witness and certify the validity of documents and to take affidavits and depositions), the applicant shall submit the notarized statement of identity along with copies of the information used to verify the applicant’s identity directly to an ORC RA or LRA, as prescribed in the subscriber agreement. Applicants must fill out and sign a form acknowledging understanding and acceptance of the responsibilities associated with accepting a certificate. The Subscriber Agreement may also serve as a testimonial to the accuracy of the information provided in the certificate request.

The RA or LRA shall archive a copy of all information used in the verification process. In all cases, the RA or LRA shall submit a digitally signed e-mail message to an ORC IA, including the public key, attesting that the identity of the individual has been authenticated.

In all cases, ORC records the following information:

The Identity of the person performing the validation process

Applicant’s name as it appears in the certificate Common Name field

A signed declaration by the identity-verifying agent that they verified the identity of the applicant

Method of application (i.e., online, in-person)



All Rights Reserved

The method used to authenticate the applicant’s identity, including identification type and unique number or alphanumeric identifier on the ID

The date of verification

A handwritten signature by the applicant in the presence of the person performing the identity verification

For each data element accepted for proofing, including electronic forms:

o Name of document presented for identity proofing

Issuing authority

o Date of issuance

o Date of expiration

o All fields verified

o Source of verification (i.e., which databases used for cross-checks)

o Method of verification (i.e., online, in-person)

o Date/time of verification

The ORC ACES name, including subcontractors, if any

All associated error messages and codes

Date/time of process completion

Names (IDs) of ORC PKI processes, including subcontractors’ processes, if any.

Alternately, certificate requests may be validated and authenticated on the basis of electronically authenticated subscriber requests using a current, valid PKI signature certificate issued by an ORC ACES CA and associated private key. The following restrictions apply:

The assurance level of the new certificate shall be the same or lower than the certificate used as the authentication credential.

The DN of the new certificate shall be identical to the DN of the certificate used as the authentication credential.

Information in the new certificate that could be used for authorization shall be identical to that of the certificate used as the authentication credential.

The expiration date of the new certificate shall be no later than the next required in-person authentication date associated with the certificate used as the authentication credential.

The validity period of the new certificate shall not be greater than the maximum validity period requirements of the ACES CP for that particular type of certificate.



All Rights Reserved

The in-person authentication date associated with the new certificate shall be no later than the in-person authentication date associated with the certificate used for authentication.

In all cases, ORC may request additional information or verification if deemed necessary to confirm the requestor’s identity.

3.1.9.1 Authentication of Unaffiliated Individual ACES Digital Signature

and Encryption Certificates

Unaffiliated Individuals are required to appear in person before an ORC RA, an LRA, or a Notary Public (or a person legally empowered to witness and certify the validity of documents and to take affidavits and depositions) for identity authentication. ORC verifies all of the following identification information supplied by the applicant: first name, middle initial, and last name, date of birth, current address (number and street, city, ZIP code), and telephone number.

An exception to the above is provided to the Government when the Government provides identity proofing. Any exception is the subject of an approved Registration Practice Statement.

3.1.9.2 Authentication of ACES Business Representative Digital Signature

and Encryption Certificates

Verification of an applicant’s identity for an ACES Business Representative Digital Signature or Encryption Certificate shall be performed prior to certificate issuance. Applicants are required to appear in person before an RA, an LRA, or a Notary Public (or a person legally empowered to witness and certify the validity of documents and to take affidavits and depositions) for identity authentication.

The ORC ACES RA, LRA or Trusted Agent shall verify:

That the applicant is a duly authorized representative of the Sponsoring Organization as an employee, partner, member, agent, or other association, in good standing.

The Sponsoring Organization’s identity as specified in Section 3.1.8.

The process documentation and authentication requirements shall include the following:

Identity of the person performing the identification

A signed declaration by that person that he or she verified the identity of the subscriber as required by the applicable certificate policy which may be met by establishing how the applicant is known to the verifier as required by this certificate policy

A unique identifying number from the ID of the verifier and from the ID of the applicant

The date and time of the verification



All Rights Reserved

A declaration of identity signed by the applicant, using a handwritten signature, performed in the presence of the person performing the identity authentication.

3.1.9.3 Authentication of ACES Agency (Relying Party Applications) Digital

Signature and Encryption Certificates

If the applicant is requesting an ORC ACES Agency (Relying Party Applications) Digital Signature or Encryption Certificate, ORC verifies:

that the applicant is authorized to act on behalf of the Relying Party

the affiliation of the ACES Certificate applicant with the Relying Party

that the applicant’s organization has completed a Relying Party Agreement with GSA

3.1.9.4 Authentication of Component Identity Certificates (e.g. Agency

Application SSL Server or VPN IPSec Certificates)

Some computing and communications components (web servers, routers, firewalls, etc.) may be named as certificate subjects. In such cases, the component must have a human PKI Sponsor as described in Section 5.2.1.2.4. The PKI Sponsor is responsible for providing the ORC ACES approved IA’s, through an application form, correct information regarding:

Equipment identification

Equipment public keys

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

Contact information to enable the ORC to communicate with the PKI sponsor when required

An ORC ACES IA shall authenticate the validity of any authorizations to be asserted in the certificate, and shall verify source and integrity of the data collected to an assurance level commensurate with the certificate level being requested. Authentication and integrity checking is accomplished by one of the following methods:

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

In person registration by the PKI Sponsor, with the identity of the PKI Sponsor confirmed in accordance with the requirements of Section 3.1.9.

3.1.9.5 Authentication of ACES Federal Employee Digital Signature and


For ACES Federal Employee Digital Signature and Encryption Certificates, identity shall be established in-person. Information provided is checked to ensure



All Rights Reserved

its legitimacy. Federal Government-issued Photo I.D Credentials are required. The Federal Employee’s identity must be personally verified prior to the certificate being issued. The applicant shall appear personally before either:

An ORC authorized RA or LRA

A Trusted Agent approved by the ORC or appointed in writing by name by ORC

A person certified by a State or Federal Government as being authorized to confirm identities (such as Notaries Public), that use a stamp, or seal to authenticate their identity confirmation

The ORC ACES RA, LRA or trusted agent shall verify:

That the applicant is a duly authorized representative of the Sponsoring Organization as an employee, partner, member, agent, or other association, in good standing.

The Sponsoring Organization’s identity as specified in Section 3.1.8.

The process documentation and authentication requirements shall include the following:

Identity of the person performing the identification

A signed declaration by that person that he or she verified the identity of the subscriber as required by the applicable certificate policy which may be met by establishing how the applicant is known to the verifier as required by this certificate policy

A unique identifying number from the ID of the verifier and from the ID of the applicant


A declaration of identity signed by the applicant using a handwritten signature. This shall be performed in the presence of the person performing the identity authentication

The applicant shall personally appear before one of the required identity verifiers at any time prior to application of an ORC ACES CA’s signature to the applicant’s certificate. Alternatively, when private keys are delivered to subscribers via hardware tokens, the subscribers shall personally appear before the ORC ACES RA, LRA or Trusted Agent to obtain their tokens or token activation data.

3.1.9.6 Qualified Relying Party ACES Certificates

If the applicant is requesting a Qualified Relying Party ACES Certificate, ORC verifies:

That the applicant is authorized to act on behalf of the Qualified Relying Party.



All Rights Reserved

The affiliation of the ACES Certificate applicant with the Qualified Relying Party, GSA, or Agency Application.

3.1.9.7 Special Procedures for Certificates Asserting a FPCPF OID

ORC will support special procedures used by individual agencies to issue identification to their own personnel and affiliates in accordance with the requirements of the FPCPF or as may be more stringent than that set forth in the policy. Prior to issuance of Certificates issued under the FPCPF, ORC will coordinate with the sponsoring agency to ensure that the agency procedures for authentication of personnel are documented in a RPS and comply with the FPCPF. The RPS shall require that RA/ LRA functions ensure that the applicant’s identity information is verified. RA/ LRAs may accept notarized authentication of an applicant’s identity to support identity proofing of remote applicants, assuming agency identity “badging” requirements are otherwise satisfied. The RPS shall require that minimal procedures for RA/ LRA authentication and notarized authentication of employees and affiliated personnel are detailed, and shall clearly define those functions that are internal (as in the case of an LRA) or outsourced to ORC (as in the case of an RA). At a minimum, the RPS shall require authentication procedures for employees include the following steps:

Identify agency management personnel authorized to approved the issuance of a certificate to an applicant

Collect a signed approval for the issuance of a certificate to an applicant on letterhead or via digitally signed email from an agency management personnel authorized to approved the issuance of a certificate to an applicant

Verify that a request for certificate issuance to an applicant was submitted by agency management authorized to do so by comparing the approval letter or email to the list of approved agency management personnel authorized to approve the issuance of a certificate to an applicant

Verify applicant’s employment through use of official agency records

Establish applicant’s identity by in-person proofing before an RA or LRA, based on either of the processes defined in the FPCPF

For contractors and other affiliated personnel, the RPS authentication procedures shall include the following steps:

Identify agency management personnel authorized to approved the issuance of a certificate to an applicant (e.g., contracting officer or contracting officer’s technical representative)

Collect a signed approval for the issuance of a certificate to an applicant via digitally signed email from an agency management personnel authorized to approved the issuance of a certificate to an applicant

Verify that a request for certificate issuance to an applicant was submitted by agency management authorized to do so via by comparing the approval letter or email to the list of approved agency management personnel authorized to approved the issuance of a certificate to an applicant



All Rights Reserved

Verify applicant’s employment through use of official agency records

Establish applicant’s identity by in-person proofing before an RA or LRA, based on either of the processes defined in the FPCPF

In all cases a biometric of the applicant (e.g., a photograph or fingerprint) shall be recorded and maintained by the LRA or ORC (as defined in the RPS) to establish an audit trail for dispute resolution. (Handwritten signatures and other behavioral characteristics are not accepted as biometrics for the purposes of this policy.) This establishes an audit trail for dispute resolution.

FPCPF PIV certificates are issued on a PIV card via a GSA FIPS-201 approved CMS, (refer to FIPS 201 Evaluation Program Approved Product List (http://fips201ep.cio.gov/apl.php)).

Additionally, the RPS shall require the RA or LRA to record the process that was followed for issuance of each certificate. The process documentation and authentication requirements shall include the following:

The identity of the person performing the 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)

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

The biometric of the applicant


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).

Where it is not possible for applicants to appear in person before the RA, a trusted agent (such as a notary) may serve as proxy for the RA/LRA as described in, Section 3.1.9 above. The requirement for recording a biometric of the applicant may be satisfied by providing passport-style photographs to the notary. The trusted agent shall 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 the notarized package. Packages secured in a tamper-evident manner by the trusted agent satisfy this requirement; secure methods are acceptable only after the Agency RPS is audited and approved compliant with the FPCPF. Authentication by a trusted agent does not relieve the RA or LRA of its responsibility to perform the verification of identifying information (e.g., by checking official records) and/ or the maintenance of biometrics.



All Rights Reserved

3.1.10 Code Signer Authentication

Code signing certificates are issued to individuals on behalf of the CSAA sponsoring organization. Each sponsoring organization is required to send a signed letter on organizational/agency letterhead to ORC authorizing CSAA(s). The CAA maintains a log of these letters, which is available to all RAs for verification purposes. The CSAA is required to send a signed memorandum on organizational/agency letterhead to the RA authorizing the code signer to receive a code-signing certificate. The memorandum could be either a hard copy with ink signature or an electronic copy that is digitally signed. The memorandum specifies, at a minimum, the subject DN to be asserted including the office symbol and an optional number (in order to make the code signing certificate’s subject DN unique). The memorandum also contains the DN of the person authorized as the code signer. If digitally signed, the public key certificate used to verify the digital signature is an ORC medium hardware assurance certificate.

After generating a key-pair and submitting a certificate request to an ORC ACES CA, the Code Signer is required to send a digitally signed e-mail to the RA. The e-mail will contain the following information:

Request number

Subject DN in the certificate request

DN of the code signer as it appears in the subject alternate name field

The e-mail shall be digitally signed using an approved ORC medium hardware assurance certificate. If the person authorized to become a code signer does not possess the required certificate, the person obtains the credential using the process defined in this CPS, prior to making the code signer request.

The RA performs the following steps:

Verify that it has received a signed memorandum from the valid attribute authority (i.e., the attribute authority identified in this CPS) for the code signer. This verification includes the verification of digital signature if it received an electronic copy of the memorandum

Verify the digital signature on the e-mail from the code signer. Verify that the e-mail was signed using the acceptable PKI credentials. Verify that the subject alternate name DN in the e-mail is same as the DN of the e-mail signer

In all cases, the public key certificate used to verify the digital signature shall be an ORC medium hardware assurance certificate. In no cases shall the ORC ACES PKI issue a code-signing certificate that asserts any FPCPF OID.

3.1.11 Authentication of Component Identities

Some computing and communications components (web servers, routers, firewalls, etc.) may be named as certificate subjects. In such cases, the



All Rights Reserved

component must have a human PKI Sponsor as described in Section 5.2.1.2.4. The PKI Sponsor is responsible for providing the CAA, or approved IAs, through an application form, correct information regarding:

Equipment identification

Equipment public keys

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

Contact information to enable ORC to communicate with the PKI sponsor when required

An ORC IA authenticates the validity of any authorizations to be asserted in the certificate, and verifies source and integrity of the data collected to an assurance level commensurate with the certificate level being requested. Authentication and integrity checking is accomplished by one of the following methods:

Verification of digitally signed messages sent from PKI sponsors (using certificates of equivalent or greater assurance than that being requested)

In person registration by the PKI Sponsor, with the identity of the PKI Sponsor confirmed in accordance with the requirements of Section 3.1.9

3.2 Routine Re-Key (Certificate Renewal)

3.2.1 CA Certificate Routine Re-Key

When an ORC ACES CA private signature key is updated, and thus generates a new public key, ORC notifies all CAAs, IAs, RAs, LRAs, and subscribers that rely on the CA’s certificate that it has been changed.

CA and OCSP responder certificates may be renewed.

3.2.2 Certificate Re-Key

ACES Certificate re-keying (signing and encryption) is accomplished through the limitation on certificate renewal, see Section 3.2.3. The minimum requirement for all ACES certificate re-keying, with the exception of CA certificates, is once every 8 years from the time of initial registration (i.e., after three 2-year renewals). ORC ACES subscribers shall identify themselves for the purpose of re-keying through use of their current signature key, except that identity shall be established through initial registration process described in Section 3.1.

CA certificate re-key follows the same procedure as is performed for initial CA certificate generation (see Section 4.8).



All Rights Reserved

3.2.3 Certificate Renewal

3.2.3.1 ACES Certificates

ORC accepts ACES Certificate renewal requests from their subscribers within 90 days from the scheduled end of the operational period (expiration date) of the ACES Certificate, provided the ACES Certificate is not revoked, suspended, or expired. ACES Certificates are renewed in 2-year increments, no more than 3 times before certificate re-key is required.

To renew a certificate, as described in the ACES CP, the subscriber obtains a new certificate based on an existing key pair. ORC authenticates the subscriber’s renewal request using the subscriber’s current certificate for authentication in the renewal process. In the event that subject information has changed (and/or the key pair is required to be changed for any reason), ORC requires the subscriber to request a new ACES Certificate. The old certificate (as a result of an update action) may or may not be revoked, but is not further re-keyed, renewed, or updated. A certificate that is not renewed by the end of the operation period reflects an expired status.

ORC renews ACES Certificates issued to Relying Parties only after completing successful identity proofing verification in accordance with the requirements for identity proofing specified in Section 3.1.9.3.

Server subscribers (PKI Sponsors) are required to revalidate their identity and any equipment authorizations and/or attributes (if any are to be included in the certificate). The subscriber is required to present a currently valid certificate to request a new certificate. End-users are required to renew their certificates through a web-based electronic form.

Medium assurance certificate may be renewed or updated on the basis of electronically authenticated subscriber requests three times. Every eight years, in-person authentication is required.

Medium hardware assurance certificates may be renewed or updated on the basis of electronically authenticated subscriber requests only one time. Every four years, in-person authentication is required.

Certificates issued by an ORC ACES CA have a validity period of two years. Prior to the expiration of these certificates, identity and encryption certificate subscribers are required to request a new certificate, which may be done by electronically submitting their existing certificates.

During the renewal process the user must present his or her current identity certificate during an SSL client authentication to the CA. The CA validates the authenticity of the certificate being presented by verifying that the certificate was issued by the CA in question and mapping the subject name in the certificate to its corresponding certificate in the database. This process verifies that the subscriber is eligible for renewal on the basis of the subscriber’s existing certificate, as stipulated above. If the subscriber is not eligible for renewal on the



All Rights Reserved

basis of the subscriber’s existing certificate, ORC redirects the subscriber to the in-person registration process. The forms to accomplish this process are controlled by access control lists on a secure web server that binds to the corresponding users with certificates in an LDAP directory. Access control to the renewal forms is based on comparing the certificate with the Distinguished Name of the subscriber (based on an X.509 certificate-based authentication) against the certificate with DN in the directory.

Provisions for the renewal of Code signing certificates are in accordance with the Medium Hardware Assurance criteria below.

In cases where a subscriber’s organization (including PKI Sponsors or CSAAs) has required authorizations to be included in an ORC ACES certificate, the person responsible for that organization ORC ACES agreement shall notify an ORC ACES RA of the withdrawal of authorizations, via digitally signed e-mail using a medium assurance hardware certificate. The RA verifies the signature of the subscriber’s organization.

3.2.3.2 Shared Service Provider Certificates

In the case of certificates issued asserting the FPCPF OIDs certificate renewal requests will not be accepted. In no case will ORC renew certificates issued asserting the FPCPF OIDs.

At the end of the validity period for an ORC issued certificate asserting an FPCPF OID, the certificate holder must make a new certificate request and complete the identity verification process, as described in Section 3.1, the same as is performed by a new user.

In cases where a subscriber’s information changes (e.g. name change due to marriage, etc.) or a new key-pair is required, ORC requires the subscriber to request a new certificate, following the same procedures as are required for initial certificate generation.

Certificates issued by an ORC CA, asserting a FPCPF OID have a maximum validity period of three years.

3.3 Obtaining a New Certificate After Revocation

Identification and authentication of individuals after certificate revocation requires following the steps outlined in Section 3.1.9. If private key compromise is suspected, additional steps shall be taken to minimize key compromise risk as outlined in Section 4.4.

Invalid, suspended, revoked, or expired ACES Certificates are not renewed. Applicants without a valid ACES Certificate are re-authenticated by ORC via a new ACES Certificate application, just as with an initial applicant registration, and issued a new ACES Certificate.



All Rights Reserved

ORC provides for the revocation of certificates when requested, as stipulated in Section 4.4.. If the Government provides RA functions, or if ORC has delegated revocation functions to subcontractor RA(s), all information is transmitted via a network between ORC and/or subcontractors and/or government RAs using mutual authentication.

3.4 Revocation Request

Certificate revocation requests may be made using the same practices as certificate issuance requests in accordance with Section 3.1.9. In addition, certificate revocation requests may be made electronically using e-mail digitally signed by a certificate of equal or greater level of assurance than that of the certificate for which the request is made. In either case, the request must include the reason for revocation. See Section 4.4 for details on certificate revocation procedures. Subscribers who are in possession of their private keys may also revoke their own certificates at any time via the ORC ACES website (http://aces.orc.com).

A subscriber may request revocation of a certificate regardless of whether or not it has been compromised. ORC may revoke a subscriber’s certificate for cause. The RA collects signed documentation stating the reason and circumstances for the revocation. If an RA performs this on behalf of a subscriber, a formal, signed message format known to the ORC IA is employed.

In accordance with the ACES contract, an ACES Certificate revocation request that is submitted electronically may be authenticated on the basis of a digital signature using the ACES Certificate’s associated key pair. The identity of the person submitting a revocation request in any other manner is authenticated in accordance with Section 3 of this CPS. Revocation requests authenticated on the basis of the ACES Certificate’s associated key pair are always accepted as valid. Other revocation request authentication mechanisms for non-FPCPF certificates include a request in writing signed by the subscriber and sent via U.S. Postal Service first-class mail. ORC RAs are verify the authentication mechanism and balances the need to prevent unauthorized revocation requests against the need to quickly revoke certificates. In the case of certificates asserting FPCPF OIDs, ORC will only accept revocation requests from the subscriber or persons authorized by each sponsoring agency to make revocation requests.

http://aces.orc.com/



All Rights Reserved

4 Operational Requirements

4.1 Certificate Application

ORC ACES offers the certificate types as defined in Section 1.3.4.1.

4.1.1 Application Initiation

The following parties may initiate the ORC ACES Certificate application process:

Potential Subscriber Authorized Initiator

Unaffiliated Individual Potential subscriber only

Business Representative Sponsoring Organization; or potential subscriber

Qualified Relying Party Duly authorized representative of the Qualified Relying Party, in good standing

Application Server PKI sponsor responsible for the component receiving the certificate

Federal/State Employee Sponsoring Organization; or potential subscriber

The application is available only on the Internet at http://aces.orc.com. Once the applicant starts the application process, the Internet protocol changes from non-secure to secure using the SSL protocol.

The individual requiring the certificate shall make a certificate request. When applicable, the subscriber’s organization is required to provide a PoC for verification of any roles or authorizations to be included in the subscriber’s certificates, via signed letterhead or digitally signed e-mail. The CAAs record all such appointments in a log available to all RAs. This point of contact may be the PKI Sponsor or CSAA. A request is made from a workstation via a web interface. When making the certificate request, the applicant shall submit a proposed distinguished name in accordance with local naming conventions, generate the public private key pair using FIPS 140-2 Level 1 approved software or Level 2 hardware tokens, and submit the information and the public key to the CA for disposition.

The applicant shall protect the private key with a password. This password shall be kept confidential and shall not be recorded or given to any other parties except in accordance with locally approved key escrow procedures.

In the case of medium assurance certificates, the applicant shall make the request using a web browser incorporating a FIPS 140-2 Level 1 cryptographic module for generating the key pair and submitting the required information through an online form. In the case of medium hardware assurance certificates, the applicant shall make the request at the RA workstation using a web browser



All Rights Reserved

and a FIPS 140-2 Level 2 token for generating the key pair and submitting the required information through an online form. The following instructions explain the steps necessary for an applicant to apply for a certificate:

Connect to the ORC ACES web page (http://aces.orc.com) and follow the directions filling out the electronic and printed forms

For encryption keys, the application process asks if the subscriber desires to escrow the encryption key and notifies subscriber upon successful completion or failure of key escrow

Present the printed application and two photo IDs to an RA, LRA, or Notaries Public (or a person legally empowered to witness and certify the validity of documents and to take affidavits and depositions)

Upon notification of certificate issuance by e-mail, the certificate is accepted and retrieved.

4.1.1.1 Application Form

ORC CAs issues certificates to EEs. ORC CAs do not issue certificates to or cross-certify with external CAs without express permission from the Government.

The individuals requiring certificates shall make certificate requests. Requests are made from a workstation via a web interface. When making a certificate request, the applicant shall complete an ACES Certificate application and provide requested information requested by an online form. The following steps occur during the application process:

The applicant is presented with the Root CA certificate and requested to trust this CA. The site is be protected by a firewall and incorporates SSL to ensure secure distribution of the certificate and to prevent substitution, as stipulated in Section 5

The applicant is presented with a screen detailing the subscriber obligations and required to accept these obligations prior to continuing

The applicant completes the online form which includes his or her name, address, phone number, e-mail address (if available), and identifying information

The applicant generates a public and private key pair and is required to use a password to protect the private key, as stipulated in the Subscriber Agreement. This password is stored locally and is required to be kept confidential and not be recorded or given to any other parties. An applicant should create passwords in accordance with the relevant passage in Section 6.2.5, “Method of Activating Private Key”

The applicant submits identifying information and the public key to the CA

The applicant proves to the CA that the public key forms a functioning key pair with the private key via the proof of possession functionality as described in Section 3.1.7



All Rights Reserved

Upon submission of the completed application form, the applicant is provided with a request number and is required to print the form, and take it, with the appropriate identity credentials, to an authorized RA, LRA, trusted agent or member of the Notary Public to have the identity credentials verified. If the applicant goes in person to an RA, LRA or trusted agent, the application process for the applicant is completed. If the applicant has the forms notarized, the applicant is required to send the notarized form via U.S. postal service to ORC or personally deliver the forms to an ORC facility. This information is provided on the printed form.

In the case of certificates asserting a FPCPF OID, if the sponsoring agency's RPS allows applicants the option to use a notary, the applicant is required to send the notarized form via U.S. postal service to a sponsoring agency's designated RA or personally deliver the forms to a sponsoring agency's designated RA, in accordance with the stipulations of the agency RPS.

4.1.1.2 Applicant Education and Disclosure

At the time of an ORC ACES certificate application ORC ACES website:

Informs applicants of the need for independent verification of their identity

Requests permission to perform this independent verification

Indicates the advantages and potential risks associated with using ACES Certificates to access Qualified Relying Parties electronically

Provides information to subscribers regarding the use of private keys and digital signatures created with such keys

The subscriber acknowledges, via the application form, the subscriber obligations as defined in this CPS.

4.1.2 Application Rejection

If verification is not successful or the application is otherwise rejected, ORC notifies the applicant of the verification failure or rejection via an out-of-band notification process linked to the certificate applicant’s physical postal address. This notification includes the steps required by the applicant to resume processing of the certificate request.

4.2 Certificate Issuance

Upon successful completion of the subscriber identification and authentication process in accordance with the GSA ACES Contract, ORC creates the requested ACES Certificate, notifies the applicant thereof, and makes the ACES Certificate available to the applicant. If the applicant provided an e-mail address, ORC sends the notification message via e-mail. If no e-mail address was provided, ORC sends the notification to the U.S. postal address provided.



All Rights Reserved

The notification informs the applicant of the creation of a certificate, states a URL for use by the applicant for retrieving the certificate, contain a unique serial number, and reaffirm the subscriber’s responsibilities as explained in the application process and described in Section 3.1.9. The notification also obligates the subscriber to:

Accurately represent themselves in all communications with the ORC PKI;

Protect the private keys at all times, in accordance with this policy, as stipulated in their certificate acceptance agreements, and local procedures;

Notify ORC, in a timely manner, of the suspicion that his or her private key(s) is compromised or lost. Such notification through mechanisms consistent with this CPS; and,

Abide by all the terms, conditions, and restrictions levied upon the use of his or her private key(s) and certificate(s).

Upon issuance of an ACES Certificate, ORC warrants to all program participants that:

ORC has issued, and manages, the ACES Certificate in accordance with the requirements in this CPS

ORC has complied with all requirements in this CPS when identifying the subscriber and issuing the ACES Certificate

There are no misrepresentations of fact in the ACES Certificate known to ORC and that ORC has verified the information in the ACES Certificate

Information provided by the subscriber for inclusion in the ACES Certificate has been accurately transcribed to the ACES Certificate

The ACES Certificate meets the material requirements of this CPS

The ORC ACES CAs are configured to establish client authenticated SSL sessions and is configured (by the CAA) to recognize IAs as legitimate issuers via certificate authentication. IAs using CA issued medium hardware assurance certificates, and recognized by the CA, are required to initiate the SSL session with the CA to begin the issuance process. Upon successful authentication, the IA searches the CA database for the appropriate certificate request.

The IA issues certificates upon receipt of the RA digitally signed e-mail only after verifying that the applicant’s subject DN (provided in the RAs e-mail) matches the subject DN in the CA database. The IA archives the e-mails signed by RAs when issued certificates are published and issuance transactions automatically logged.

In the case of code signing certificate issuance, the IA verifies that the subject DN and the DN in the subject alternate name field match those provided by the attribute authority and the code signer.



All Rights Reserved

4.2.1 Certificate Delivery

4.2.1.1 Delivery of Subscriber’s Public Key to Certificate Issuer

After the subscriber has read and agreed to the Subscriber Agreement (obligations) as defined in this CPS, public keys are delivered to the certificate issuer in a way that binds the applicant’s verified identification to the public key being certified. The binding is accomplished using means that are as secure as the security offered by the keys being certified. The binding is accomplished using cryptographic, physical, procedural, and the methods described in this CPS.

Medium assurance and medium hardware assurance requests are treated the same, except that all medium hardware assurance requests are made in the presence of an RA, LRA or a designated trusted agent.

FPCPF PIV certificates are issued on a PIV card via a GSA FIPS-201 approved CMS, (refer to FIPS 201 Evaluation Program Approved Product List (http://fips201ep.cio.gov/apl.php)).

4.2.1.2 Delivery of Subscriber’s Private Key to Subscriber

Private keys associated with medium assurance certificates are generated and stored in the subscriber’s software or hardware cryptographic modules. There is no need to deliver them. Except that, if a subscriber has requested their medium hardware encryption private key be escrowed, the encryption key pair is generated on a FIPS 140-2 Level 3 device at the CA. Those keys are delivered (escrowed) first to the ORC Key Recovery System (KRS) and then to the user’s hardware token under multi person control.

The keys are encrypted and protected by a FIPS 140-2 Level 3 device in the case of the KRS, and a FIPS 140-2 Level 2 in the case of the token.

The ORC KRS uses three component certificates used for 1) establishing an SSL session, 2) transporting private keys, and 3) protecting stored archived private keys. These key pairs are separately generated during key ceremonies and managed under two party control with ORC trusted roles acting as sponsors, in accordance with the requirements for issuing server certificates in this CPS. Each key pair is generated by and issued to the KRS hardware encryption module in the presence of an RA and SA, and audited by a Corporate Security Auditor.

The SSL certificate is used to enable the KRS to establish authenticated SSL sessions. The KRS is configured (by the CAA) to recognize the ORC authorized CAs as a legitimate user via certificate authentication. The authorized CA certificate, recognized by the KRS, initiates an SSL session with the KRS to carry out the escrow process.



All Rights Reserved

When requesting an encryption certificate the KRS transport public key certificate is used to encrypt the private key (to be escrowed) that is generated by the Subscriber in the case of medium assurance certificates or on the FIPS 140-2 Level 3 device in the case of medium hardware assurance certificates. The KRS accepts the encrypted key, decrypts the key and encrypts it using a random symmetric key.

In the case of medium hardware assurance certificates, when the CA receives verification from the KRS that the private key has been received and stored the private key is deleted from the FIPS 140-2 Level 3 device. At this point the applicant has completed the registration process in the presence of an RA and the CA can issue the certificate. The applicant will then be assisted by two Key Recovery Agents (KRAs) to recover and import the escrowed private key to the subscriber’s hardware token.

The ORC KRS is configured (by the CAA) to recognize KRAs as legitimate users via medium hardware assurance certificate authentication to initiate an SSL session to begin the recovery process. Upon successful authentication of the two KRAs, the two KRAs apply their identifiers/ passwords that were established to protect a ‘k of m’ secret splitting mechanism. After verifying these passwords, the KRS reconstructs the PIN that enables the KRS to use the storage private key to decrypt the key(s) to be recovered. The recovered key(s) are imported to the K/RA workstation where the subscriber is asked to apply a password, when challenged by the KRS, the KRS then encrypts the recovered key(s) to a PKCS 12 format. The “PKCS 12” file is imported to the Subscribers token at a KRA workstation by the Subscriber. Once imported to the Subscriber’s token a KRA deletes the “PKCS 12” file from the K/RA workstation.

4.2.1.3 CA Public Key Delivery to Users

ORC supports delivery of the ORC ACES CA and trust anchor public keys (including the FPCPF trust anchor) as stipulated in Section 6.1.4, herein.

4.2.2 Certificate Replacement

ORC provides for the replacement of non-FPCPF certificates when the subscriber’s private key has not been compromised and there are no changes to the certificate.

Upon receiving an authenticated request to replace a damaged or lost certificate from a subscriber (i.e., unaffiliated individual, business representative, agency application server, or Federal, State and Local Government employee) or an authorized official of a business entity for a business representative subscriber, ORC records the following certificate replacement transaction data:

Certificate serial number

Certificate common name

Certificate policy OID



All Rights Reserved

Date/time of completion of replacement process

Name (ID) of ORC ACES PKI process(es)

Fees associated with certificate and/or token replacement are stipulated in Section 2.5.

4.3 Certificate Acceptance

As described in the ACES Contract, a condition to issuing an ACES Certificate is that the subscriber shall indicate acceptance or rejection of the ORC ACES Certificate to ORC and acknowledge the subscriber obligations. By accepting the ORC ACES Certificate, the subscriber is warranting that all information and representations made by the subscriber that are included in the ORC ACES Certificate are true.

ORC notifies the certificate applicant of certificate issuance through e-mail. The notification includes the URL that the applicant uses to receive the approved certificate. ORC verifies possession of the subscriber’s private key at the time the applicant accepts the issued certificate.

The notification informs the subscriber of the creation of the certificate, contents of the certificate and reaffirms the subscriber’s responsibilities as explained in the application process and described in Section 3.1.9. The notification informs the subscriber if the private key has been escrowed.

The subscriber agreement includes the following subscriber obligations. The subscriber shall:

Accurately represent themselves in all communications with the ORC.

Protect their private keys at all times, in accordance with this policy, as stipulated in their certificate acceptance agreements, and local procedures.

Notify ORC, in a timely manner, of the suspicion that their private keys are compromised or lost. Such notification shall be made directly, or indirectly through mechanisms consistent with this CPS.

Abide by all the terms, conditions, and restrictions levied upon the use of their private keys and certificates.

Formally accept the certificate at the designated ORC web page during certificate retrieval. (Failure to do so will result in revocation of the certificate.)

The subscriber has already agreed to the obligations during the request phase (as stipulated in the Subscriber Agreement), and the certificate can only be accepted during a PoP of private key test. ORC logs the acceptance of the certificate.

A subscriber who does not provide this verification notice within 30 calendar days of receiving notification that his or her approved certificate is available for



All Rights Reserved

downloading, or who is found to have acted in a manner counter to these obligations shall have his or her certificate revoked, and will forfeit all claims he or she may have against the ORC ACES PKI in the event of a dispute arising from the failure to fulfill the obligations above.

4.4 Certificate Suspension and Revocation

The individual making the request shall either digitally sign requests for certificate revocation, or the individual shall present the request in person to an RA.

Code signer certificates may not be revoked when the code signer departs or is no longer with the organization. Code signer’s suspected of having signed (intentionally or unintentionally) unapproved code, may have their code signing certificate revoked by the IA.

4.4.1 Who Can Request a Revocation?

The following authorized parties may request a revocation of a certificate:

Any EE may request revocation of his or her own certificate(s)

RAs and LRAs may request revocation of any EE certificate on behalf of the EE or an authorized party.

An ORC IA may revoke any certificate within its domain for reasons identified in this CPS.

Other parties may also request revocation of certificates through an RA or LRA. The ORC RA or LRA validates the credentials of the requesting party, and the RA determines if the revocation request meets the requirements of this CPS. In the case of certificates issued under the FPCPF, each agency will designate persons authorized to request revocation of certificates.

If any individual has reason to believe that a certificate private key has been compromised, that individual is required to notify the ORC RA or LRA of the compromise suspicion. It is the responsibility of the ORC RA to investigate the information and determine if certificate revocation is warranted.

If so, the RA forwards the revocation request along with documentation of the reason for the request to the ORC IA. ORC sends a written notice and brief explanation for the revocation to the subscriber.

4.4.2 Circumstances for Revocation

Whenever any of the circumstances below occur, the associated certificate shall be revoked and placed on the CRL, except for OCSP Responder certificates that include the id-pkix-ocsp-nocheck extension. In addition, if it is determined, subsequent to issuance of new certificates, that a private key used to sign requests for one or more additional certificates may have been compromised at



All Rights Reserved

the time the requests for additional certificates were made, all certificates authorized by directly or indirectly chaining back to that compromised key shall be revoked. Certificates shall remain on the CRL until they expire. They shall be removed after they expire, but must at least appear in one CRL.

4.4.2.1 Permissive Revocation

As described in the ACES contract, a subscriber may request revocation of his/her/its ORC ACES Certificate at any time for any reason. A Sponsoring Organization may request revocation of an ACES Certificate issued to its Business Representative at any time for any reason. If the Government provided RA functions, or if ORC has delegated revocation functions to subcontractor RAs, all information is transmitted via a network between ORC and/or subcontractors and/or government RAs using mutual authentication.

4.4.2.2 Required Revocation

A subscriber, or a Sponsoring Organization (where applicable), is responsible for promptly requesting revocation of an ACES certificate:

When the private key, or the media holding the private key, associated with the ORC ACES Certificate is, or is suspected of having been, compromised

When the individual named as a Business Representative no longer represents, or is no longer affiliated with, the Sponsoring Organization

If ORC learns, or reasonably suspects, that the subscriber’s private key has been compromised or the subscriber has failed to meet their responsibilities

If ORC determines that the ORC ACES Certificate was not properly issued in accordance with this CPS

The certificate holder requests that the certificate be revoked

The certificate holder can be shown to have violated the subscriber obligations, including payment of any required fees

The certificate holder is no longer authorized to hold the certificate (e.g. termination of employment or change in responsibilities)

The information in the certificate is no longer accurate so that identifying information needs to be changed (e.g. change of name or privilege attributes asserted in the subscriber’s certificate are reduced)

The subscriber’s employer or organization requests revocation

The certificate was obtained by fraud or mistake

The certificate was not correctly requested, issued or accepted

The certificate contains incorrect information, is defective or creates a possibility of incorrect reliance or usage

Certificate private key compromise is suspected



All Rights Reserved

The certificate holder fails to make a payment or other contractual obligations related to the certificate

ORC reserves the right to revoke any ORC ACES issued certificate at its discretion.

ORC provides for the revocation of certificates when requested, at any time for any reason. If the Government provided RA functions, or if ORC has delegated revocation functions to subcontractor RAs, all information is transmitted via a network between ORC and/or subcontractors and/or government RAs using mutual authentication.

4.4.3 Revocation Request Procedure

As described in the ACES Contract, an ORC ACES certificate revocation request should be promptly communicated directly to an RA or LRA who are authorized to accept such notices on behalf of the CA.

If the subscriber is making the revocation request for their identity certificate, and is in possession of their private identity key associated with the certificate, the subscriber may access the ORC ACES website to revoke his or her own certificate at any time. Upon accessing the User Certificate Revocation Page the users is presented with a radio button list with the following “Revocation Reason”:

Unspecified Key Compromise Cessation of Operation Affiliation Changed Superseded

A mutually authenticated SSL session is established using the private identity key, which provides proof of possession of the subscriber's private key associated with the identity certificate to be revoked. This revocation is immediate. If a subscriber revokes their private identity key, but continues to hold a key management certificate they must either submit a request for a new identity certificate or a request to revoke their key management certificate(s). If ORC does not receive such a request within 30 days the subscriber's key management certificate(s) will be administratively revoked.

If a subscriber intends to revoke all of their certificates it is recommended that they submit a digitally signed certificate request, as stipulated below, prior then performing the immediate revocation of their identity certificate.

In the case of a subscriber's key management certificate or if the subscriber is no longer in possession of the private key, or an entity other than the subscriber is making the revocation request, this request may be communicated via an online form, electronically via digitally signed e-mail, or in person to an ORC RA, or via U.S. postal mail. In the case of a digitally signed email from the subscriber's the signature shall be generated using the subscriber's identity



All Rights Reserved

certificate When revoking a subscriber's key management certificate the IA will verify that the subscriber's identity certificate dnQualifier is consistent with the dnQualifier of the subscriber's key management certificate.

All revocation requests are verified prior to certificate revocation. If the subscriber makes the request and has the private key, this proof of possession test is considered adequate and the certificate is revoked immediately.

If the request comes via a digitally signed e-mail message (signed with a certificate at least of the same assurance level as the certificate to be revoked) sent from an ORC CMA or an authorized Sponsoring Organization representative, validation of the e-mail signature is considered adequate and the certificate is revoked.

If the request comes from an in person visit, identity credentials are required (at least to the same assurance level as the certificate to be revoked) from the individual making the request and verified prior to revoking the certificate. If the request is made via online form or unsigned e-mail, ORC contacts the subscriber via the information kept in the database from the request process to verify the request prior to certificate revocation. For these cases, the certificate is suspended pending verification of the revocation request.

In the case of certificates issued under the FPCPF, if the request comes from an agency designated person authorized to request revocation of certificates and signed with identity credentials at least to the same assurance level as the certificate to be revoked, ORC will revoke the certificate immediately.

If an ORC CMA or RA is making the request, the reason for the revocation request is documented. If an LRA is requesting the revocation, the reason shall be sent to an RA via a digitally signed e-mail message for revocation, who investigates the request, document the reason for the revocation request and archive. Upon disposition, the CMA or RA sends the reason for revocation and confirm that it was vetted to the IA via a digitally signed e-mail message for revocation.

ORC shall revoke or suspend the certificate by placing its serial number and identifying information on a CRL. ORC shall also remove the certificate from any repositories containing that certificate.

The subscriber is notified of the revocation request, reason for the request, and status of the request. If appropriate, the subscriber is provided information on obtaining a new certificate and a list of all certificates issued.

If an ORC CMA is choosing to revoke a certificate because of sufficient evidence of noncompliance with this CPS, an ORC IA documents the reason for certificate revocation and notifies the subscriber of the revocation.

Subscribers leaving the organizations that sponsored their participation in the PKI shall surrender to their organization's PKI PoC (through any accountable



All Rights Reserved

mechanism, defined in the RPS in the case of FPCPF) all cryptographic hardware tokens that were issued, under the sponsoring organization, prior to leaving the organization. The PKI PoC shall zero (refer to Section 6.2.7) or destroy the token promptly upon surrender and shall protect the token from malicious use from the time of surrender. In all cases, whether software or hardware tokens are involved, the organization shall promptly notify an ORC RA to revoke the certificate and attest to the disposition of the token, via a digitally signed e-mail.

4.4.4 Revocation Grace Period

Certificates are revoked upon request as soon as the need can be verified. There is no grace period. The subscriber, or sponsoring organization, must request revocation from ORC as soon as the need for revocation has been determined.

4.4.5 Certificate Authority Revocation Lists (CARLs)/Certificate Revocation Lists (CRLs)

4.4.5.1 CRL Issuance Frequency

The ORC ACES CAs issue CRLs every 12 hours with a validity period of 18 hours. New CRLs are issued twice per day even if there are no changes or updates to be made. When a revocation request is granted for the reason of key compromise, the revocation information will be posted on the next CRL, except that, if the revocation request is made within two hours of the next schedule CRL, the revocation information may be posted on the very next CRL. All superseded CRLs are removed from the repository upon posting of the latest CRL.

When a CA certificate or subscriber certificate is revoked because of compromise, or suspected compromise, of a private key, a CRL is issued immediately as stipulated in Section 4.4.3 above.

ORC ACES CRLs may be obtained from:

ldap://aces-ds.orc.com/cn=ORC ACES <CA Name>, o=ORC PKI, c=US?certificaterevocationlist;binary.


4.4.5.2 CRL Checking Requirements

It is the responsibility of the relying party to verify that certificates have not been revoked. Certificates may be stored locally by a relying party, but should be validated at least daily before use. The relying party shall always check a certificate against a CRL that has not expired.




All Rights Reserved

Any relying party that downloads an ORC CRL shall verify the authenticity of the CRL by verifying the signature and associated certification path. They should also check the CRL date to confirm that old CRLs are not presented in a replay attack. The following text is included in the Subscriber Agreement and posted on the ORC ACES website:

“USE OF REVOKED CERTIFICATES COULD HAVE DAMAGING OR

CATASTROPHIC CONSEQUENCES IN CERTAIN APPLICATIONS. THE

MATTER OF HOW OFTEN NEW REVOCATION DATA SHOULD BE

OBTAINED IS A DETERMINATION TO BE MADE BY THE RELYING PARTY

AND THE SYSTEM ACCREDITOR. IF IT IS TEMPORARILY INFEASIBLE TO

OBTAIN REVOCATION INFORMATION, THEN THE RELYING PARTY MUST

EITHER REJECT USE OF THE CERTIFICATE, OR MAKE AN INFORMED

DECISION TO ACCEPT THE RISK, RESPONSIBILITY, AND

CONSEQUENCES FOR USING A CERTIFICATE WHOSE AUTHENTICITY

CANNOT BE GUARANTEED TO THE STANDARDS OF THIS PRACTICE

STATEMENT.”

4.4.6 Online Revocation/Status Checking Availability

ORC validates online and near-real-time the status (Valid, Invalid or Suspended) and signature of the ACES Certificate indicated in an ACES Certificate Validation Request message. The CA returns in the Certificate Status Response message a signed message. This functionality is integrated with the GSA-approved Certificate Arbitrator Module (CAM) using the OCSP.

The ORC WAN OCSP Responder (CSP) is located at: http://aces.eva.orc.com. Contact ORC to register for use.

ORC supports online status checking via OCSP [RFC 2560] for end entity certificates issued under id-fpki-common-authentication and id-fpki-common-cardAuth. Status information maintained by the OCSP server is updated and available to relying parties within 6 hours.

4.4.7 Online Revocation Checking Requirements

Each Qualified Relying Party will validate every ACES Certificate it receives in connection with a transaction. Any self-signed OCSP responder used for verifying certificates asserting a policy OID from this CPS are required to meet the certificate profile stipulated in the X.509 Certificate and CRL Extensions Profile for the FPCPF [CCP-PROF] (refer to sample profile below) and ensure that:

Certificates indicated as being valid have a chain of valid certificates (valid as defined by [X.509]) linking back to a “trusted Root CA”

Each certificate in the certificate chain used to validate the certificate whose status is being requested is checked for revocation, such that the Relying



All Rights Reserved

Party need not check more than one responder to validate a subscriber certificate

Certificate status responses provide authentication and integrity services commensurate with the assurance level of the certificate being verified

It is made clear in the certificate status response the attributes (other than certificate subject name (e.g., citizenship, clearance authorizations, etc.)) being authenticated by the responder

Accurate and up-to-date CRLs, from the ORC CAs, are used to provide the revocation status

Revocation status responses provide authentication and integrity services commensurate with the assurance level of the certificate being checked

ORC disclaims any liability for loss due to use of any validation information relied on by any party that does not comply with this stipulation, in accordance with this CPS.

4.4.8 Other Forms of Revocation Advertisements Available

No stipulation.

4.4.9 Checking Requirements for Other Forms of Revocation Advertisements Available

No stipulation.

4.4.10 Special Requirements With Respect to Key Compromise

If an ORC ACES certificate is revoked because of suspicion of private key compromise, the following additional requirements apply in addition to requirements specified above.

ORC issues new CRLs with date of compromise and notifies, through website posting, any relying parties that download the CRL that a certificate has been revoked because of key compromise, and the date that the suspected compromise occurred.

If the compromised certificate was an RA certificate, the RA revalidates any subscriber certificates validated after the date of the suspected compromise, and revokes any certificates not revalidated.

ORC uses reason codes and has the ability to transition any reason code to compromise.



All Rights Reserved

4.5 Certificate Suspension

4.5.1 Circumstances for Suspension

If a certificate revocation request is received in an unverified manner, the certificate is placed in suspended status pending authentication of the request. See Section 4.4.3 for details. At no time does ORC suspend a CA certificate.

4.5.2 Who Can Request Suspension

See Section 4.4.1.

4.5.3 Procedure for Suspension Request

See Section 4.4.1. The suspension state remains until the revocation request is verified.

4.6 Computer Security and Audit Procedures

All significant security events on the ORC ACES system are automatically recorded in audit trail files. Such files shall be securely archived in accordance with Section 4.6.1.

The ORC CA equipment records, for purposes of security audit, events as described below, whether the events are attributable to human action (in any role) or are automatically invoked by the equipment. The information recorded includes the type of event, and the date and time the event occurred. Where appropriate, ORC records the success or failure, the source or destination of a message, or the disposition of a created object (e.g., a filename). The auditing capability of the underlying CA equipment operating system is enabled during all installations. Where possible, the audit data is automatically collected. When this is not possible, a logbook is used. Logbook entries include records of hardware and software maintenance, designation of official personnel and certain RA, LRA, and IA responsibilities that require out-of-band activity, as stipulated below; as well as, records of any paper forms or copies of identity credentials collected from subscribers.

PoP checks for the applicant’s private key are performed for correlation with the applicant's public key at two separate instances as described in Section 3.1.7. The first check is performed during the certificate request process where the public private key pair is generated and the public key is passed on to the CA. At this time the CA automatically records the:

Request ID

Module which accomplishes authentication

DNCN Requested



All Rights Reserved

The second check is performed after a certificate has been generated. The CA signs the public key and user subsequently collects his/her certificate.

4.6.1 Types of Event Recorded

ORC archives data and files that include ACES certificate application information, certificate issuance, and transaction data.

ORC records events attributable to human intervention or automatically invoked by the equipment. At a minimum, the information recorded includes the type of event and the time the event occurred. Where appropriate, additional information is recorded. Where possible, the security audit data is automatically collected; when this is not possible, a logbook or paper physical mechanism is used. All security audit logs, both electronic and non-electronic, are retained in accordance with the requirements of Section 4.6.3, and made available during compliance audits.

For each auditable event, CMA security audit records include, at a minimum:

The type of event

The date and time the event occurred

Messages from RAs (or other trusted entities) requesting CA actions, the message source, destination and contents

Attempted CA certificate signature or revocation, a success or failure indication

Operator initiated actions (including equipment and application access), the identity of the equipment operator who initiated the action

The equipment records server installation, access, and modification (to include changes in configuration files, security profiles, and administrator privileges). Security auditing capabilities of the underlying CMA equipment operating system are enabled during installation. The following operations are recorded:

Equipment configuration (manually logged)

Equipment access (e.g., room access) (automatically and manually logged)

File manipulation and account management (automatically logged)

Posting of any material to a repository (automatically logged)

Access to databases (automatically logged)

Any use of a signing key (automatically logged)

Any actions taken during the processing of a request and generation of a response will be recorded. Many RA responsibilities require out-of-band activity. Records of such activity shall be recorded in a logbook or other physical medium. A record of any paper forms or copies of photo IDs collected from users shall be maintained.



All Rights Reserved

The following events applying to humans and physical operations are audited:

Appointment of CAA, IA, RA and LRA personnel (manually logged)

Training of CAA, IA, RA and LRA personnel (manually logged)

Physical access to the CA, CSA and IA equipment (automatically and manually logged)

Operator initiated actions (including equipment and application access), the identity of the equipment operator who initiated the action (automatically and manually logged)

4.6.2 Frequency of Processing Data

The CA, RA, IA, and system audit logs and personnel access logs are consolidated (summarized) and reviewed weekly by the Corporate Security Auditor. As stated in the ACES CP, 25% of all of the security audit data is reviewed, at a minimum. IAs review RA audit logs. The audit logs are removed monthly to CDROM for archival purposes and to ensure that the security audit data is transferred prior to overwriting or overflow of automated security audit log files.

4.6.3 Retention Period for Security Audit Data

The information generated on the CA, IA and CSA equipment is kept on the CA, IA and CSA equipment until the information is moved to an appropriate archive facility. The SA in coordination with the Corporate Security Auditor performs deletion of the audit log from the CA, IA and CSA equipment. Security audit data is retained on-site for at least two months. Audit and security logs are retained off-site as archive records in accordance with this CPS.

4.6.4 Protection of Security Audit Data

Audit logs are protected from unauthorized modification or unauthorized deletion. No person is authorized to modify the content of audit logs, except for appending new audit records without overwriting existing audit records. The action of two parties is required to protect the data, as described in this CPS, the Operating Procedures, and the Roles Manual. This two party control ensures that audit data cannot be open for reading or modification by any human, or by any automated process, other than those that perform security audit processing and that no unauthorized user is able to write to, modify, or delete the archive.

Electronic audit logs are deleted only after they have been copied to archive media. Only ORC SAs are authorized to delete CA, CSA, or IA logs. RAs each manage their respective audit records. Before deleting any electronic audit log, ORC’s Corporate Security Auditors verifies that the audit log data has been successfully copied to archive media. No person is authorized to delete or destroy audit data recorded on archive media, except as stipulated in Section 4.7.2.



All Rights Reserved

4.6.5 Security Audit Data Backup Procedures

Audit logs are backed up along with the rest of the data on the CA, IA and CSA equipment, as described in this CPS, in addition to the weekly and monthly consolidation, as described in the same Section 4.7. Detailed procedures for to creating, verifying, packaging, transmitting, and storing CA archive information is provided in the ORC SSP (Appendix B).

4.6.6 Security Audit Collection System (Internal vs. External)

The ORC security audit process is independently controlled through the Corporate Security Auditor and the SA. The audit system is internal to CA, IA and CSA equipment and operates at the network, operating system and application level. Should it become apparent that an automated security audit system has failed, ORC shall cease all operation except for revocation processing until the security audit capability can be restored. ORC shall invoke the audit processes at system startup and shall cease audit processes only at system shutdown. At no time does ORC operate the CA, IA or CSA without a functioning audit capability.

4.6.7 Notification to Event-Causing Subject

ORC does not necessarily notify an entity of an auditable event caused by that entity.

4.6.8 Vulnerability Assessments

SAs and other operating personnel are instructed to be watchful for attempts to violate the integrity of the CA, including the equipment, physical location, and personnel. The intrusion detection audit logs are checked at the end of each week for anomalies in support of any suspected violation. The weekly-consolidated audit logs are reviewed at the end of each week by a Corporate Security Auditor for continuity of audit data and events such as repeated failed actions, requests for privileged information and attempted access of system files.

ORC operates secure systems in accordance with WebTrust security guidelines and undergoes independent audit of its operations once a year.

4.7 Records Archival

4.7.1 Types of Data Archived

The ORC ACES archive records are kept with sufficient detail to establish the validity of a signature and of the proper operation of the CA, IA and CSA.



All Rights Reserved

4.7.2 Retention Period for Archive

Archived records are retained for twenty (20) years and six months. Prior to the end of the archive retention period, ORC will provide archived data to a Policy Authority approved archival facility, upon request. ORC could itself own that facility.

4.7.3 Protection of Archive

No unauthorized users are able to write to, modify, or delete the archive. The archive is transferred to CDROM (or Policy Authority approved media) and stored off-site in a secured location. The ORC CAAs maintain a list of individuals authorized to modify or delete the archive. The list is available during compliance audits.

4.7.3.1 Archive Backup Procedures

Audit data is backed-up on a weekly basis. ORC creates a monthly backup of audit data for off-site storage labeled with the ORC ACES name and date, and stored in a separate location under the control of individuals other than the designated CAA and the SA.

4.7.3.2 Archive Collection System (Internal or External)

Consolidated audit logs are stored on the ORC CA equipment until copied to unalterable media (e.g., recordable CDROM (CDR)). Consolidated audit logs are moved monthly to unalterable media. The unalterable media are stored off-site in a secure location. Additional consolidated logs may be stored on the media without modifying previously stored audit logs.

4.7.3.3 Procedures to Obtain and Verify Archive Information

Archive data is obtained from the archive media by the Corporate Security Auditor only in response to a verified request for review of archived information.

4.8 Key Changeover

A self-signed ORC Government Root CA signs the ORC ACES CA certificates. This Root CA private key is used only to sign CA certificates, cross certificates, and CRLs. A new self-signed Root CA signing authority certificate will be issued to sign CA certificates when the validity period of the CA exceeds the remaining validity period of the Root CA. The old Root CA certificate continues to be used to sign CRLs until all CA certificates issued by that Root CA certificate have expired.

ORC uses a signing (private) key for creating certificates; however, Relying Parties employ the ORC ACES CA certificates for the life of the subscriber certificate beyond that signing. Therefore, the CA does not issue subscriber



All Rights Reserved

certificates that extend beyond the expiration dates of its own certificates and public keys, and the CA certificate validity period will extend one subscriber certificate validity period (listed in this CPS) past the last use of the CA private key. To minimize risk to the PKI through compromise of the CA key, the private signing key is changed more frequently, and only the new key is used for certificate signing purposes from that time forward. This is accomplished by setting up a new CA with a new signing key. The older, but still valid, certificate will be available to verify old signatures until all of the subscriber certificates signed under it have also expired. Since the old private key is used to sign CRLs that contain certificates signed with that key and OCSP responder certificates, the old key will be retained and protected. Key changeover is accomplished in accordance with Certificate Management Protocol [RFC4210].

The validity period of an ORC ACES CA signature certificate is 6 years. RA key lifetimes are as described for subscribers in this CPS.

Signature keys that have expired for the purposes of certificate signature may still be used for CRL signature.

4.9 Compromise and Disaster Recovery

Compromise or disaster notification and recovery procedures are employed by ORC to ensure a secure state. The security provided by the PKI is dependent on protection of the CA private keys. The CA keys are protected from compromise due to malicious attack or inadvertent loss of key/ activation data; as well as, from disasters causing the loss of essential equipment, by employing controls such as:

Two person control procedures of the CA and CSA hardware encryption modules, which includes physical separation of its activation mechanism

Two person control procedures of the CA and CSA key activation data

Assignment of passwords only to authorized trusted users

Backup and recovery systems

Periodic changing of passwords

These measures minimize the risk of compromise due to use, storage, or knowledge of key activation mechanisms.

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

CA data, including audit logs and the certificate database, are backed up on a tape backup system. Differential backups are run weekly, as a minimum, to back up all files modified since the last full backup. A full backup is run at least monthly where all files are saved to the tape.



All Rights Reserved

4.9.2 Authorized CA Public Key Is Revoked

CA termination is handled in accordance with Section 4.10. If the termination is for convenience, contract expiration, re-organization, or other non-security related reason, certificates may continue to be considered valid at the discretion of the program or relying party (who has been made aware of the termination). In this case, provision must be made for compromise recovery, audit, archive, and data recovery material, either by transferring the current agreements to the new CA, or by the program otherwise upholding the current contractual agreements or making new arrangements.

The Government will communicate the revocation of the CA’s certificate to relying parties in a manner to ensure maximum dissemination of the revocation notice.

4.9.3 Private Key Is Compromised (Key Compromise Plan10

)

As required by the ACES contract, ORC has in place an appropriate key compromise plan that addresses the procedures that are followed in the event of a compromise of the private signing key to issue certificates. This plan includes procedures for revoking all affected ACES Certificates and promptly notifying the Policy Authority, all subscribers and all Qualified Relying Parties.

In the case of an ORC ACES CA key compromise, the U.S. Government shall communicate the revocation of the ORC ACES certificate to relying parties. Subsequently, the CA installation shall be re-established as described in ORC ACES Installation Manual. The ORC ACES CA shall subsequently be re-keyed. The outstanding certificates will be re-issued using the new CA keys.

In case of an ORC CSA key compromise, the ORC CA that issued the CSA a certificate shall revoke that CSA’s certificate, and the revocation information shall be published immediately in the most expedient manner. The ORC CSA is subsequently re-keyed. The ORC CSA does not use self-signed certificates.

10 Step 7 of ORC Pol 7.0, Contingency Plan



All Rights Reserved

4.9.4 Facility after a Natural or Other Disaster (Disaster Recovery

Plan)

ORC maintains a Disaster Recovery Plan (DRP) as part of the SSP. The DRP is based upon a combination warm site/hot site located in ORC’s backup Secure Network Operations Center (SNOC). The ORC DRP comes into effect only if an outage of more than 24 hours is anticipated. Since the ORC ACES CA servers operate with backup generator power and telecommunications, long outages are unlikely.

In the event of an extended outage, a second suite of equipment will be brought on line to provide temporary ORC ACES CA services. Backup tapes from the primary CA server(s) will be used to synchronize the temporary CA(s).

In the case of a disaster in which CA equipment is damaged and inoperative, CA operations are reestablished as quickly as possible, giving priority to the ability to revoke subscriber’s certificates. If a CA cannot reestablish revocation capabilities prior to the next update field in the latest CRL issued by the CA, then ORC will report to the Policy Authority. The Policy Authority shall decide whether to declare the CA private signing key as compromised and reestablish the CA keys and certificates, or allow additional time for reestablishment of the CA’s revocation capability.

4.10 Authorized CA Cessation of Services

In the event that ORC ceases operation of its participation as an Authorized CA in ACES or is otherwise terminated:

All subscribers, Sponsoring Organizations, and Qualified Relying Parties must be promptly notified of the cessation, via the ACES website.

All ACES Certificates issued by ORC under this CPS shall be revoked no later than the time of cessation

All current and archived ACES identity proofing, certificate, validation, revocation/suspension, renewal, policy and practices, billing, and audit data shall be transferred to GSA within 24 hours of cessation and in accordance with this CPS. Transferred data shall not include any non-ACES data

4.11 Customer Service Center

As described in the ACES Contract, ORC has implemented and maintains an ACES customer service center to provide assistance and services to subscribers and Qualified Relying Parties. The customer service center is the focal point for receiving, recording, addressing, and reporting any issues regarding to the operation and maintenance of the ORC ACES PKI. The customer service center provides resources via the ORC ACES website (http://aces.orc.com), via e-mail and via phone (listed on the website). Support is available to subscribers, ORC employees and subcontractors, and the Government. All incidents reported to



All Rights Reserved

the customer service center are tracked. Issues that have not been resolved in a timely manner are elevated to ensure prompt and professional response. Capabilities provided by the center include:

Emergency response available 24/7/365

Prompt acknowledgement of problem receipt

Online ability to check status of certificate requests via request identifier

Immediate revocation of certificates when validated with proof of possession test on private key

End user instructions and technical documentation

Professionally staffed center from 7:30 am – 6:00 pm eastern time, with on-call support at all times

Direct link to engineering staff for escalation and resolution of technical issues

The ORC ACES customer service center maintains records related to customer requests for service, including:

o Date and time initially contacted

o Method of contact (e.g., telephone, e-mail, etc.)

o Name of individual making the contact, individual agency application (if applicable)

o Type of service requested or problem reported

o Action taken

o Date and time action completed

o Name of person taking the action

o Requirements for follow-up action (if any)

o Date/time report filed

o Name of person filing report



All Rights Reserved

5 Physical, Procedural And Personnel Security Controls

5.1 Physical Security Controls

ORC’s CA equipment is dedicated to the CA function. IA workstations and IA hardware tokens are dedicated to the use of issuing certificates. RAs and LRAs use general-purpose workstations and medium hardware assurance certificates dedicated to the ACES certificate application process.

The CA, IA and CSA equipment consists of equipment dedicated to the CA, IA and CSA functions, and do not perform non-related functions. The equipment includes, but is not limited to, the system running the CA, IA and CSA software, hardware cryptographic modules, and databases and directories located on the equipment. In addition, databases and directories located on the equipment are not accessible to the subscribers and Relying Parties.

Unauthorized use of CA, IA and CSA equipment is forbidden. Physical security controls are implemented that protect the hardware and software from unauthorized use. Cryptographic modules are protected against theft, loss, and unauthorized use through multiple party management.

A check is made at least once every 24 hours to ensure that no attempts to defeat the physical security mechanisms have been made.

5.1.1 Physical Access Controls

Physical access to CA, IA and CSA hardware, including the firewall server, and any external cryptographic hardware tokens, is limited to those personnel performing one of the roles identified in Section 5.2. Access to any media containing CA, IA or CSA information is also physically protected and access restricted to authorized personnel. Such information includes:

Certificate database and database backups

ORC ACES CA private keys and private key backups

Audit logs

Archives

Access restrictions do not necessarily apply to copies of audit log information or archive information made in response to authorized requests.

ORC employs five levels of physical access control and two separate physical access alarm systems.



All Rights Reserved

5.1.2 Security Checks

A security check of the facility housing CA, IA and CSA equipment is made at the end of each workday. The check ensures that:

The equipment is in a state appropriate to the current mode of operation (e.g., that cryptographic modules and removable hard disks are in place when in use, and secured when not in use)

Security containers are properly secured, including the file cabinet storing sensitive data and the safe containing backup material

Physical security systems including door locks are functioning properly

The area is secured against unauthorized access

An individual is assigned explicit responsibility for making these checks once a day. This individual also ensures that the CA sign-out sheet is available and complete. A record is kept that describes the type of checks performed, the time, the date, and the person who performed them.

ORC’s facility is continually alarmed and guarded.

5.1.3 Media Storage

ORC ensures that media is stored so as to protect it from accidental damage (water, fire, electromagnetic). Backup tapes re stored at the same level of security as the computer from which they were made. Weekly and monthly backup tapes and monthly archive media are stored either on-site in a safe of fireproof cabinet or off-site in a safe deposit box. Tapes and media remain off-site until such time as they are to be reused or additional data is to be appended.

5.1.4 Environmental Security

5.1.4.1 Power and Air Conditioning (Environmental Controls)

The ORC facilities have adequate power and backup power resources to provide unlimited uptime to the Internet through a central UPS and backup diesel generator power system, which also powers an independent air conditioner during a power disaster. The power requirement covers any and all equipment required for the ORC ACES system to provide all functionality indefinitely or to provide for a normal shutdown.

A separate air conditioning unit is used as required to maintain the operating environment within normal operating temperatures (70 degrees Fahrenheit +/- 5) for the equipment and personnel operating and administering the ORC ACES system. The system is set so that at no time can the lack of air conditioning be able to damage the equipment and cryptographic tokens.



All Rights Reserved

5.1.4.2 Water Exposures

The ORC facility is located above ground and off of the floor by two feet to prevent internal flooding from damaging this CA, IA and CSA equipment. All backup materials and CA, IA and CSA documentation storage devices are located in areas not prone to water damage.

5.1.4.3 Fire Prevention and Protection

The ORC facility complies with all applicable national, state, and local fire regulations for a commercial office building. Fire prevention devices are enabled to eliminate or reduce fire and smoke damage to the CA, IA and CSA equipment. Backup materials and documentation are located in fire resistant storage devices to reduce or eliminate damage to such materials.

5.1.4.4 Waste Disposal

Any media that contains privacy act or other sensitive information is crosscut shredded or overwritten to be rendered unrecoverable prior to disposal.

5.1.5 Off-site Backup

Backup media for critical data and programs are stored in a secure, off-site location. Backup media is rotated to ensure that the information contained is no more than one week old. The SSP details tape rotation schedule and archive schedule for the CA, IA and CSA. The backup is stored at a site with physical and procedural controls commensurate to that of the operational system.

5.2 Procedural Controls

The ACES system is controlled in accordance with National Institute of Standards and Technology (NIST), DoD, GSA, Association for Independent Certified Public Accountants (AICPA), and National Security Agency (NSA) guidelines for certification authority operations.

5.2.1 Trusted Roles

A trusted role is one whose incumbent performs functions that can introduce security problems if not carried out properly, whether accidentally or maliciously. The people selected to fill these roles have proven to be diligent and trustworthy as described in the next section. The functions performed in these roles form the basis of trust in the entire PKI. ORC uses two approaches to increase the likelihood that these roles can be successfully carried out. The first approach is to ensure that the persons filling the roles are trustworthy and properly trained. The second is to distribute the functions of the role among several people, so that any malicious activity requires collusion. Details regarding the design and configuration of the technology to avoid mistakes and counter inappropriate behavior are described in Section 6.



All Rights Reserved

5.2.1.1 CA Trusted Roles (Physical Security in CP)

To ensure that one person acting alone cannot circumvent safeguards, CA responsibilities are shared between multiple roles and individuals. Access permissions on the CA server are limited to capabilities required by the role.

There are three trusted roles relating to operation of the CA: the CAA, the SA, and the Corporate Security Auditor. The Corporate Security Auditor examines system records or audit logs to ensure that persons are acting within the realms of their responsibilities and within the stated security policy. Multiple individuals perform these trusted roles.

5.2.1.2 Other Trusted Roles

5.2.1.2.1 Registration Authority (RA) /Local Registration Authority (LRA)

ORC RAs and LRAs are designated trusted agents of ORC. The difference between RAs and LRAs is that RA identity proofing and training are the responsibility of the IA, and LRAs perform identity proofing only. RAs can designate LRAs and are responsible for their identity proofing and training. LRAs may not designate other LRAs. RAs are responsible for:

Authentication of user identity and organizational relationship upon notification of certificate request

Processing and archiving notarized identity validation packages submitted by applicants

Submittal of digitally signed validation approval to IA or CAA

Authentication of user identity upon revocation request

Submittal of digitally signed revocation requests to IA

Archival of user authentication information

Generation of certificate and revocation requests and processing of associated responses

LRAs are responsible for:

Authentication of user identity and organizational relationship upon notification of certificate request

Authentication of user identity upon revocation request

RAs and LRAs do not have privileged access to the CA.

5.2.1.2.2 Network and Firewall Administrators

Network Administrators are responsible for integrity, confidentiality and availability of internal and external communications with the CA, in accordance with the requirements of the CAA.



All Rights Reserved

Firewall Administrators are responsible for the installation and operation of the CA firewall, in accordance with the requirements of the CAA.

5.2.1.2.3 Certificate Status Authority (CSA)

The ORC CSA operating under this CPS is subject to the stipulations of this policy, and of the GSA-approved CPS under which it operates. The CSA provides OCSP responses to subscribers and is responsible for:

Providing certificate revocation status and/or complete certification path validation (including revocation checking) to the Relying Parties upon request

Ensuring that the status and validation responses contain authentication and integrity services commensurate with the assurance level of the certificate being checked

The CAA administers the CSA

5.2.1.2.4 PKI Sponsor

A PKI Sponsor fills the role of a subscriber for non-human system components and organizations that are named as public key certificate subjects. The PKI Sponsor works with the CAA, IA, and RA to register components (routers, firewalls, etc.) in accordance with this CPS, and is responsible for meeting the obligations of subscribers as defined throughout this document.

5.2.2 Number of Persons Required Per Task (Separation of Roles)

ORC implements commercially reasonable practices that ensure that one person acting alone cannot circumvent safeguards. To increase the likelihood that these roles can be successfully carried out the functions are distributed among more than one person, so that any malicious activity would require collusion. Trusted roles include:

Administrators (ORC CAA) – authorized to install, configure, and maintain the CMA software to include: the establishment and maintenance of privileged user accounts, configuration of profiles and audit parameters, and generation of component keys.

Officers (ORC IA) – authorized to request or approve certificates or certificate revocations.

Auditors (ORC Corporate Security Auditor) – authorized to view and maintain audit logs.

Operators (ORC SA) – authorized to install, configure, and maintain the CMA hardware and operating systems to include: the establishment and maintenance of privileged user accounts; configuration of profiles and audit parameters and system archival, backup, and recovery.



All Rights Reserved

Under no circumstances shall the incumbent of these roles perform their own auditing function. No individual is assigned more than one trusted role.

At least two parties are necessary to do any key management or log operations. CA/ CSA key-pair generation and initialization of CA/CSA tokens require the active participation of at least a CAA and the SA or the Corporate Security Auditor. CA/ CSA systems startup requires the active participation of a CAA and a SA. The individual operator’s roles and responsibilities including separation of roles are detailed in the “ORC PKI Roles Manual”. An IA, RA or LRA is not permitted to perform any CAA, SA, or Corporate Security Auditor functions, or any compliance audit role.

5.2.3 Identification and Authentication for Each Role

All persons fulfilling one of the CMA roles defined in this CPS shall be capable of identifying themselves with two forms of picture identification.

5.2.4 Hardware/Software Maintenance Controls

Areas of control include system software controls in accordance with Federal laws, regulations, and guidelines and GSA security policy and supporting security guidelines.

The ORC CA equipment is hosted on evaluated platforms in support of computer security assurance requirements, and the system (hardware, software, operating system) is, when possible, operated in an evaluated configuration. At a minimum, the ORC CA platform uses the same version of the computer operating system as that which was used when it received the evaluation rating.

5.2.5 Documentation

Operations and maintenance documentation is supplied to authorized individuals performing the roles of CAA and SA. An operations manual for CAAs and an operations manual for SAs have been written and is managed for each logical instance of the CMA and each physical instance of the CMA.

Documentation is provided to personnel, as required for fulfilling the requirements of their respective role.

5.2.6 Security Awareness Training

All personnel, and contractors located or working on-site or accessing U.S. Government IT resources, receive information systems security awareness training annually. Additionally, periodic refresher training is provided to all personnel. The training program covers the requirements of the Computer Security Act of 1987, Public Law 100-235, which are adequately detailed in the Office of Personnel Management Computer Security Awareness Training materials. The Security Auditor is responsible for managing this training.



All Rights Reserved

5.2.7 Retraining Frequency and Requirements

Those involved in filling trusted roles are made aware of changes in an ORC authorized CA operation. Any significant changes to the operation require retraining. ORC maintains a file of signed and dated statements from the ACES personnel listing their names, roles, re-training received, and date training completed. The ORC PKI Project Director established a training plan and training completed by the above personnel is documented.

5.2.8 Job Rotation Frequency and Sequence

ORC ensures the continuity and integrity of the ORC ACES services.

5.2.9 Sanctions for Unauthorized Actions

Any unauthorized actions resulting in irreparable damage to the ACES system such as compromising the private key shall be prosecuted to the fullest extent of the law. The responsible individuals may be prosecuted to the maximum of extent that the law affords, both criminal and civil.

Any unauthorized actions by an IA shall result in the immediate revocation of the IA certificate and the removal of that individual from the IA role. Certificates issued by that IA might also be revoked. The IA may be prosecuted for any damages caused to the ORC ACES system.

Any unauthorized actions by an RA or LRA shall result in the immediate revocation of the RA/ LRA certificate and the removal of that individual from the RA/ LRA role. Certificates validated by that RA/ LRA might also be revoked. The RA/ LRA may be prosecuted for any damages caused to the ORC ACES system.

5.2.10 Contracting Personnel Requirements

Any company subcontracting to provide services for any CMA role with regards to the ORC ACES system is required to establish procedures, which are reviewed and approved by ORC. The subcontractor shall require all employees delivering such services to be in accordance with this CPS and the ACES CP, and subject to the compliance audit requirements of this CPS.

5.2.11 Documentation Supplied to Personnel

Operations and maintenance documentation is supplied to authorized individuals performing the roles of CAA and SA. Operations manuals for systems and CA administration are written and managed for each logical instance of the ORC ACES system and each physical instance of an ORC ACES system.

Documentation is provided to personnel as required for fulfilling the requirements of each role.



All Rights Reserved

5.3 Personnel Security Controls

5.3.1 Access Authorization

The persons filling CMA roles are trustworthy, and of the highest integrity from a financial perspective and selected on the basis of Loyalty to the United States of America. The Board of Directors of Operational Research Consultants, Inc, administers ORC ACES PKI operations. Personnel appointed to operate CMA equipment shall:

Have not knowingly been denied a security clearance, or had a security clearance revoked

Have not been convicted of a felony offense

Be appointed in writing by an approving authority or be party to a contract for PKI services

5.3.2 Limited Access

5.3.2.1 Background Screening, Qualifications, Experience and Clearance

Requirements

All personnel performing one of the roles identified in Section 5.2.1 are required to have a personal security investigation that has been favorably adjudicated, to be assigned to sensitive positions. An active secret clearance shall be sufficient to meet this requirement. For individuals who do not have an active clearance, ORC requests the individual to provide references and sign a background verification disclosure and authorization and release. As a member of the American Society of Industrial Security (ASIS), ORC can access ASIS Online to complete Criminal History, Civil History, Financial Status and Work History background checks. If additional detailed investigation is required, ORC uses the Pinkerton Services Group (or equivalent) to provide background checks covering the past seven years including: Criminal History, Civil History, Financial Status and Work History.

An active secret clearance is sufficient to meet this requirement. The results of these checks will not be released except as required by the ACES CP.

5.3.2.2 Least Privilege

Users must be restricted to data files, processing capability, or peripherals, and type of access (read, write, execute, delete) to the minimum necessary for the efficient completion of their job responsibilities. ORC provides physical access controls designed to provide least privilege as stipulated in Section 5.1.1.



All Rights Reserved

5.3.2.3 Separation of Duties

Critical functions are divided among individuals (separation of duties) to ensure that no individual has all necessary authority or information access that could result in fraudulent activity without collusion as stipulated in Section 5.2.2.

5.3.2.4 Individual Accountability

ORC provides physical access controls designed to provide individual accountability. Individual accountability requires the linking of activities on the ORC ACES system to specific individuals, and therefore, requires the system to internally maintain the identity of all active users. ORC allows only one user per account and users never share user IDs or passwords. Section 5.2 describes how the access control mechanism supports individual accountability and audit trails.



All Rights Reserved

6 Technical Security Controls

ORC and all authorized ORC IAs, RAs, CMAs, and Repositories implement appropriate technical security controls in accordance with protection under 15 U.S.C. 278g(3) and (4), the responding regulations relating to protection of these systems as set forth in Appendix III (Security of Federal Automated Information Resources) to Office of Management and Budget (OMB) Circular Number A-130 (Management of Federal Information Resources), and the GSA ACES Contract.

6.1 Key Pair Generation and Installation

6.1.1 Key Pair Generation

Users generate the key pair, as stipulated in Section 4.2.1. This is accomplished in a FIPS 140-2 Level 1 Approved Web browser (such as Netscape Communicator, Mozilla/ FireFox, etc.) for medium assurance certificates or in a FIPS 140-2 Level 2 validated hardware token for medium hardware assurance certificates. ORC’s CA certificate-signing keys are generated in FIPS 140-2 Level 3 validated cryptographic Hardware Security Modules (HSM). The CSA OCSP responder certificate signing keys are generated in a FIPS 140-2 Level 2 validated cryptographic HSM.

IA, RA, and LRA medium assurance hardware and Code Signing keys are generated on cryptographic smart cards. ORC uses smart cards from a vendor(s) with certified FIPS 140-2 Level 2 compliance.

Subscribers may use software for medium assurance or hardware tokens for medium assurance hardware, for key generation. In the case of medium hardware assurance encryption key pairs generated off the token, ORC assures that no copies other than authorized key escrow copies of the keys continue to exist after the generation and insertion process has completed in accordance with the ORC KRPS. Medium hardware assurance signature key pairs are to be generated on the token, in the presence of an ORC ACES RA or LRA.

For all key generation, random numbers are generated using a FIPS approved method.

A private key will never appear outside of the module in which it was generated in plain text form.

6.1.2 Private Key Delivery to Entity

The ORC ACES subscriber’s private key is generated directly on the subscriber’s token, or in a key generator that benignly transfers the key to the subscriber’s token. The subscriber is in possession and control of the private key from the time of generation or benign transfer.



All Rights Reserved

6.1.3 Subscriber Public Key Delivery to Authorized CA (Certificate Issuer)

As part of the ACES Certificate application process, the subscriber’s public key is transferred to the ORC ACES CAs in a way that ensures:

It has not been changed during transit

The sender possesses the private key that corresponds to the transferred public key

The sender of the public key is the legitimate user claimed in the certificate application

Public keys are delivered to the certificate issuer in a PKCS#10 or Certificate Request Message Format (CRMF) certificate request.

6.1.4 ORC ACES CA Public Key Delivery to Users

ORC supports delivery of the ORC ACES CA and trust anchor public keys (including the FPCPF trust anchor) via a web interface to a protected server using SSL. The public key is stored such that it is unalterable and not subject to substitution. Relying Parties must contact the help desk to receive the official certificate hashes to compare them with the certificates downloaded from the site.

In the case of the FPCPF trust anchor information will be provided to the certificate subject through one of the following secure processes (that will be identified in the sponsoring agencies RPS):

Government RA provides the trust anchor to the certificate subject during in person identity proofing.

Government RA provides a hash of the trust anchor information (a.k.a., a “fingerprint”) to the certificate subject during in-person identity proofing; the certificate subject downloads the trust anchor information from the ORC ACES website and verifies the “fingerprint”. The ORC ACES website includes instructions to the certificate subject on how to verify the “fingerprint”.

The certificate subject obtains the trust anchor information from the ORC ACES website (or other Government sponsored web server) and calculates the “fingerprint”. The ORC ACES website includes instructions to the certificate subject on how to calculate the “fingerprint”. The subject confirms the fingerprint against a value obtained through a secure independent process, such as a letter sent through first class mail from a Government RA or ORC RA.



All Rights Reserved

6.1.5 Key Sizes

Rivest, Shamir, Adleman (RSA) keys, including CA keys, that have an expiration date prior to or equal to December 30, 2010 will use a 1024 bit modulus. RSA keys, including CA keys, that have an expiration date after December 30, 2010 must use a 2048 bit modulus. Digital Signature certificates asserting the FPCPF OIDs that have an expiration date on or before December 30, 2008 will use a 1024 bit modulus. Digital Signature certificates asserting the FPCPF OIDs that have an expiration date after December 30, 2008 will use a 2048 bit modulus. Digital Signature Standard (DSS) and Elliptic Curve are not supported.

As indicated in Section 1.1, ORC will update all Certificates and CRLs to use signature keys, in accordance with X.509 Certificate Policy for the FPCPF, of at least 2048 bits, SHA256:

For 3 year certificates no later than December 30, 2007

For 2 year certificates no later than December 30, 2008

Key sizes generated will be in accordance with the requirements and schedule stipulated in Section 6.1.5 of the current X.509 Certificate Policy for the FPCPF, version 2.5.

For SSL ORC employs, at a minimum, three key triple-Data Encryption Standard (triple-DES) (or equivalent) for the symmetric key algorithm. In accordance with the X.509 Certificate Policy for the FPCPF, ORC will:

Use, at a minimum, triple-DES or equivalent for the symmetric key, and at least 1024 bit RSA or 163 bit elliptic curve keys through December 30, 2008.

In the use of TLS or another protocol providing similar security, at a minimum, use AES (128 bits) or equivalent for the symmetric key, and at least 2048 bit RSA or 224 bit elliptic curve keys after December 30, 2008.

The ORC ACES CAs issuing certificates asserting a FPCPF OID are signed by the FPCPF trust anchor, which uses 2048 bit keys.

6.1.6 Public Key Parameters Generation

Public key parameters for use with the RSA algorithm defined in PKCS#-1 are generated and checked in accordance with PKCS#-1.

6.1.7 Parameter Quality Checking

See Section 6.1.6 above.



All Rights Reserved

6.1.8 Key Usage Purposes (X.509 V3 Key Usage Field)

ORC certifies keys for use in signing or encrypting, but not both. The use of a specific key is determined by the key usage extension. The key usage extension is included in all certificates and is always marked critical in order to limit the use of public key certificate for its intended purpose, as stipulated in the X.509 Certificate and CRL Extensions Profile for the FPCPF [CCP-PROF].

6.1.8.1 ACES Certificates

ORC ACES certificates issued for digital signature with non-repudiation assert the digitalSignature and nonRepudiation bits. ORC ACES certificates issued for key transport assert the keyEncipherment bit.

ORC public keys that are bound into the ORC ACES CA certificates are only used for signing certificates and status information (e.g., CRLs/ OCSP responders). The subject public keys of the ORC ACES CA certificates are used to verify other certificates within the PKI; as well as, CRLs, and assert both the keyCertSign and cRLSign bits (as stipulated by the FPCPF).

6.1.8.2 Shared Service Provider Certificates

ORC user certificates that assert id-fpki-common-authentication or id-fpki-common-cardAuth only assert the digitalSignature bit and do not assert the nonRepudiation bit.

Device certificates issued by ORC that assert the FPCPF OID assert the digitalSignature bit. Device certificates issued by ORC that contain RSA public keys that are to be used for key transport assert the keyEncipherment bit. Device certificates that contain elliptic curve public keys that are to be used for key agreement assert the keyAgreement bit. Device certificates do not assert the nonRepudiation bit.

ORC public keys that are bound into the ORC CA certificates are only used for signing certificates and status information (e.g., CRLs/ OCSP responders). The subject public keys of the ORC CA certificates are used to verify other certificates within the PKI; as well as, CRLs, and assert both the keyCertSign and cRLSign bits (as stipulated by the FPCPF).

The dataEncipherment, encipherOnly, and decipherOnly bits shall not be asserted in any certificates issued under this CPS asserting a FPCPF OID.

6.1.9 Private Key Shared by Multiple Subscribers

ORC does not approve of any Private Key Shared by Multiple subscribers. Public keys that are bound into subscriber certificates are used only for signing or encrypting, but not both. Certificates issued for digital signatures (including authentication) assert the digitalSignature and/or nonRepudiation bits. Certificates issued for key transport assert the keyEncipherment bit.



All Rights Reserved

6.1.10 Date/Time stamping

ORC date/time stamps conform to the ITU-T Recommendation X.690 and the X.690 v2, Information Technology – ASN.1 Encoding Rules, 1994.

6.2 Private Key Protection

An ORC CA signing private key never appears outside of the module in which it was generated in plain text form.

6.2.1 Standards for Cryptographic Modules

The relevant standard for cryptographic modules is Security Requirements for Cryptographic Modules [current version of FIPS140]. Cryptographic modules are validated to the FIPS 140 Level identified in this section.

Subscribers shall use cryptographic modules that have been validated to meet at least the criteria specified for FIPS 140 Level 1. FIPS 140 Level 2 must be used to receive a Medium Hardware Assurance certificate.

All ORC CA certificates are signed using a hardware cryptographic module that has been validated to meet FIPS 140-2 Level 3. The ORC CA private keys are protected by a hardware cryptographic module that are FIPS 140-2 Level 3 validated for key storage, as listed on the NIST website.

CAA, IA, RA and LRA private keys (for identity and encryption certificates) are protected by cryptographic hardware tokens that are FIPS 140-2 Level 2 validated, as listed on the NIST website.

All cryptographic modules are operated such that the private asymmetric cryptographic keys are never being output in plaintext. No private key shall appear unencrypted outside the ORC CA, IA or CSA equipment.

No one shall have access to a private signing key but the subscriber. Any private encryption keys held by ORC are held in strictest confidence and controlled as described in the ORC Key Recovery Practice Statement (KRPS). The ORC Key Recovery System only employs cryptographic modules validated to the FIPS 140-2, as identified in this section.

Section 6.1.1 stipulates cryptographic module requirements for key generation.

6.2.2 Private Key Backup

ORC recommends to users that they make backup copies of software based encryption private keys and provides recommended procedures on the ACES website. Backup of private signature keys for the sole purpose of key recovery shall not be made. Backup copies are stored in an encrypted form and protected by a password from unauthorized access. The subscriber (PKI Sponsor for Component) is responsible for ensuring that all copies of private keys, including



All Rights Reserved

those that might be embedded in component backups, are protected. This includes protecting any workstation on which any of its private keys reside.

In the case of individual subscriber certificates on a smart card asserting a FPCPF OID, private signing keys are generated on the smart card (PIV) and are not backed up.

Subscribers are permitted to backup their own private keys.

6.2.3 Private Key Archival

Under no circumstances is a non-repudiation signature or authentication key archived. Archival of confidentiality keys is recommended if any information encrypted with those keys is archived in its encrypted state.

Escrowed keys are stored in a protected KED, in accordance with the ORC KRPS. The KED consists of equipment dedicated to the key recovery and archival functions.

6.2.4 Private Key Entry Into Cryptographic Module

Private keys are generated by and in a cryptographic module. For the CA and CSA, the cryptographic module must be a FIPS 140-2 Level 3 module. For IA/ RA/ LRA/ subscriber medium hardware assurance, the cryptographic module must be a FIPS 140-2 Level 2 module. For subscriber medium assurance, the cryptographic module must be a FIPS 140-2 Level 1 module.

In the event that a private key is to be transported from one cryptographic module to another, the private key will be encrypted during transport using FIPS 140-1/2 protection for the private key at the level commensurate with the level of the key to be transported; private keys must never exist in plaintext form outside the cryptographic module boundary, in accordance with the ORC KRPS.

If a user, via a software process, generates the key, and the key will be stored by and used by the application that generated it, no further action is required. Otherwise, the key is extracted for use by other applications or in other locations (key extraction for use by other applications is restricted to keys used with medium assurance certificates). Use of a protected data structure (such as defined in [Public Key Certificate Standard, PKCS#12]) is required. The resulting file may be kept on a magnetic medium.

6.2.5 Method of Activating Private Key

A password shall be used to activate the private key for IA, RA, LRA, subscriber medium assurance and medium hardware assurance (e.g. PIV). Passwords shall be generated by the subscriber and entered at the time of key generation (at the RA/LRA workstation in the case of medium hardware assurance) and managed according to the FIPS 140-2 guidance for strong passwords in accordance with the subscriber obligation agreement. Entry of activation data will be protected



All Rights Reserved

from disclosure. The strength of the passwords and the controls used to limit guessing attacks shall have a probability of success of less than 2

-23 chance (1

chance in 8,338,608) of success over the life of the password. ORC uses the NIST E-Authentication Token Strength Module (TSM) to calculate resistance to online guessing. The strength of password shall be at least eight (8) characters with the following diversity: one upper case alpha, one lower case alpha, one numeric, and one special.

Certificates that assert the id-fpki-common-cardAuth OID, subscriber authentication is not required to use the associated private key.

6.2.6 Method of Deactivating Private Key

Cryptographic modules that have been activated shall not be left unattended or otherwise available to unauthorized access. Private keys stored in hardware tokens, excluding end user tokens, shall be removed from the token reader and stored in a locked container when not in use. End users will protect his or her token in accordance with the subscriber obligation agreement. The CA hardware token shall be stored in a locked container when not in use.

Private keys stored in software shall be deactivated via a logout procedure. End entities will be advised to also implement a time-out procedure for automatically deactivating private keys after a period of 15 minutes of non-use.

6.2.7 Method of Destroying Private Key

Private signature keys shall be destroyed when they are no longer needed, or when the certificates to which they correspond expire or are revoked. For software cryptographic modules, is accomplished by overwriting the data. For hardware cryptographic modules, this is accomplished by executing a “zero” command. Physical destruction of hardware should not be required. Destruction of the private signature key is then documented via signed email, as stipulated in Section 4.4.3.

6.3 Good Practices Regarding Key Pair Management

6.3.1 Public Key Archival

Archival of public keys is achieved via certificate archival.

6.3.2 Private Key Archival

ACES encryption keys are intended to provide for the confidentiality of data during transmission, and not for the confidentiality of data at rest. Therefore, ACES does not normally provide for the escrow of private keys. However, ACES may support the escrow of encryption keys when this is required.



All Rights Reserved

6.3.3 Usage Periods for the Public and Private Keys

The maximum validity period of an ORC ACES CA signature certificate is 6 years. RA key lifetimes are as described for subscribers in this CPS.

The validity period of an ORC ACES end entity certificate is 2 years, with a maximum of 3 renewals before requiring re-key.

The maximum validity period of an ORC CA signature certificate asserting a FPCPF OID is 6 years. RA key lifetimes are as described for subscribers in this CPS.

Certificates issued to end entities by an ORC CA asserting a FPCPF OID have a maximum validity period of three years. In no case will ORC renew certificates issued asserting the FPCPF OIDs.

6.3.4 Restrictions on CA's Private Key Use

The private keys used by ORC for issuing ACES Certificates are used only for signing such Certificates, associated CRLs, or validation service responses.

A private key issued under this CPS and used for purposes of manufacturing ACES Certificates is considered an ORC ACES CA signing key, and is held by an authorized entity as a fiduciary. It shall not be used for any other purposes, except as agreed by GSA and ORC. Any private key used for purposes associated with functions described in this CPS shall not be used for any other purpose without the express permission of ORC.

6.3.5 Private Key Multi-person Control

A single person is not permitted to activate an ORC CA signature key or access any cryptographic module containing a complete CA private signing key. See Section 5.2.1. Access to the CA signing keys backed up for disaster recovery is under the same multi-person control as the original CA signing key.

The CA and CSA private keys are controlled under a ‘k of m’ (two or more) person control. The names of the individuals used for two-person control are maintained on a list that is available for compliance audits.

When not in use, the CA and CSA hardware cryptographic module tokens are stored in a GSA-approved security container in accordance with the physical security requirements of Section 5.1 of this CPS.

Private encryption keys requested by other than the subscriber/PKI sponsor may only be extracted from key recovery databases under two-person control, as described in the ORC KRPS. The names of the parties used for two-person



All Rights Reserved

control are maintained on a list that is made available for inspection during compliance audits.

The private components of IA, RA, and LRA signature key pairs and encryption key pairs are under single person control. When not in use, IA, RA, and LRA cryptographic hardware tokens must be remove from the workstation/computer and kept in the possession of the IA, RA, and LRA or stored in a locked container.

6.3.6 Private Key Escrow11

Under no circumstances shall a signature key be escrowed. ORC does not require private key escrow for confidentiality keys. However, ORC recommends to EEs that they locally escrow a copy of the confidentiality private key.

For some purposes (such as data recovery), some organizations may desire key archival and key retrieval for the private component of the encryption certificate key pair. To facilitate this, ORC offers a key escrow and recovery capability.

The method, procedures and controls which apply to the storage, request for, extraction and/or retrieval, delivery, protection and destruction of the requested copy of an escrowed key are described in the ORC KRPS.

6.4 Activation Data

6.4.1 Activation Data Installation and Generation

The CA, IA, RA, LRA, CSA and other end entities shall use passwords to protect access to private keys. The passwords need not be automatically generated.

In addition, subscribers will sign and return a subscriber advisory statement to help understand responsibilities for the use and control of the cryptographic

11 The optional encryption private key escrow and recovery service does not currently apply to

certificates asserting the FPCPF Policy OIDs.



All Rights Reserved

module. Not all software currently available allows for technically enforced password expiration. Activation data (password or pass-phrase) is generated by the subscriber in accordance with the stipulations of the subscriber’s agreement.

ORC does not support transport of activation data.

6.4.2 Activation Data Protection

Cryptographic modules are used to protect activation data and critical security parameters in accordance with FIPS 140-2 requirements.

The activation data protection mechanism for ORC’s CA, IA and CSA equipment or applications is accomplished by distributing the functions of the role among several people, so that any malicious activity requires collusion. All CA and CSA actions require two-party participation in accordance with the ORC PKI Roles Manual. Activation requires the SA who holds the hardware token in his or her individual safe drawer to provide it to the CAA for activation of either the CA or CSA. The CAA, with the SA observing, must then provide the token password to activate the FIPS 140-2 Level 3 cryptographic module. For administrator logins, the witnessing party counts up to three attempts for a successful login. If login fails after three attempts, the witnessing party terminates the login session and reports the problem to the Corporate Auditor.

The subscribers shall protect their activation data from access by others, in accordance with the subscriber’s agreement. If the activation data is not entered directly in the cryptographic module, procedures or protocols shall be used so that the activation data is protected against eavesdropping and replay. Examples of protocol are encrypting the data with a new random session key each time, and challenge response.

6.4.3 Other Aspects of Activation Data

All ORC CMA personnel are required to change their individual token passwords no less than once every three months and log this action in the audit notebook.

CMS passwords should be changed every six (6) months and in no event shall a CA application CMS password be maintained more than one year.

6.5 Computer Security Controls

Upon establishment and periodically thereafter, the most current DoD system security audit script are run on the ORC PKI infrastructure.

6.5.1 Audit

The ORC ACES system creates, maintains, and protects from modification, unauthorized access, or destruction an audit trail of accesses to the resources it protects in accordance with Federal law, regulations, guidelines, as well as GSA security policy and supporting security guidelines. Activity-auditing capabilities



All Rights Reserved

employed by ORC on the ACES system maintain a record of system activity by system, by application processes and by users. The ORC ACES system protects the audit data from destruction and provides alternative audit options when the standard audit mechanism is unable to record events. The ORC Corporate Security Auditor is responsible for changes in the ORC audit policies and procedures and for the frequent review for signs of unauthorized activity or security vulnerabilities.

The duration of storage of audit data is adequate to ensure recognition of security incidents and subsequent analysis of their occurrence, a minimum of 30 days.

6.5.2 Technical Access Controls

The ORC PKI suite provides technical access controls designed to provide least privilege and protections against unauthorized access to ACES system resources. Technical controls have been developed and are implemented in accordance with FIPS Publication 83, Federal law, regulations and guidelines in addition to GSA security policy and supporting security guidelines. Technical security controls are detailed in the ORC SSP.

6.5.3 Identification and Authentication

The ORC PKI suite employs proper user authentication and identification methodology. This methodology includes the use of user ID/password, token-based, and/or digital certificate authentication schemes. The use and enforcement of password security is in accordance with GSA security policy and supporting security guidelines as stipulated in Section 6.2.5.

6.5.4 Trusted Paths

ORC PKI accountability covers a trusted path between the user and the system. A trusted path is a secure means of communication between the user and the system.

6.6 Life Cycle Technical Controls

Individuals filling trusted roles within the ORC facility use security management tools and procedures to ensure that the operational systems and networks adhere to the security requirements that check the integrity of the system data, software, discretionary access controls, audit profiles, firmware, and hardware to ensure secure operation.

Security management control includes the execution of tools and procedures to ensure that the operational system and network adhere to configured security. These tools and procedures include checking the integrity of the security software, firmware, and hardware to ensure their correct operation.



All Rights Reserved

6.6.1 System Development Controls (Environment Security)

All assembly and maintenance of CA and CSA systems is accomplished in the controlled environment of the SNOC as described in Section 5.1.1. Only personnel designated in this CPS perform maintenance on the PKI systems. The CAA and SA in accordance with the Procedural Controls in Section 5.2 accomplish hardware and software upgrades.

6.6.2 Security Management Controls

All ORC PKI system security features described in this CPS are configured and enabled. The configuration of the ORC ACES system (including hardware, software, and operating system) as well as any modifications and upgrades are documented and controlled with mechanisms for detecting unauthorized modification to the software or configuration.

ORC conducts design review and system tests prior to placing systems or system updates into operation to assure that they meet security specifications. If new controls are added to the application or the support system, testing of those new controls are performed to ensure that the new controls meet security specifications and do not conflict with or invalidate existing controls. The results of the design reviews and system tests are fully documented, updated as new reviews or tests are performed, and maintained in the ORC ACES build control documents.

ORC employs a formal configuration management methodology for installation and ongoing maintenance of the ACES system. All CMA software, when first loaded, is verified as being that supplied from the vendor, with no modifications, and being the version intended for use. ORC authorized CA and CSA systems Configuration Management (CM) records are maintained by the Corporate Security Auditor as described in Section 5.2.1. These records are stored in a locked container under the Security Auditor's control. CM documents include the ORC authorized CA signing key ceremony document, CA electronic forms, and CA and CSA creation log and procedures.

ORC authorized CA equipment is dedicated to administering a key management infrastructure and does not have installed applications or component software, which are not part of the PKI configuration. Equipment (hardware and software) procured to operate the PKI is purchased in a fashion to reduce the likelihood that any particular component was tampered with, such as random selection. In the event that equipment is developed for the PKI, it shall be developed in a controlled environment and the development process shall be defined and documented.

All CMA hardware and software is shipped or delivered via controlled methods that provide a continuous chain of accountability, from the location where it has been identified as supporting a CMA function to the using facility.



All Rights Reserved

For all entities responsible for local registration (including Federal, State and Local Government agencies/personnel), reasonable care shall be taken to prevent malicious software from being loaded on any equipment used in the registration process. Only applications required to perform the organization's mission shall be loaded on these computers, and all such software shall be obtained from sources authorized by local policy. Data on such equipment shall be scanned for malicious code on first use and periodically afterward.

Hardware and software updates shall be purchased or developed in the same manner as original equipment, and be installed by trusted and trained personnel in a defined manner, as stipulated in the ORC SSP.

6.6.3 Object Reuse

When a storage object (e.g., core area, disk file, etc.) is initially assigned, allocated, or reallocated to a system user, the system is insured to cleared in accordance with Federal law, regulations, and guidelines, as well as GSA security policy and supporting security guidelines by the SA. The ORC SSP specifies procedures for sanitizing electronic media for reuse (e.g., overwrite or degaussing of electronic media) and controlled storage, handling, or destruction of spoiled media, or media that cannot be effectively sanitized for reuse.

All magnetic media used to store sensitive unclassified information is purged or destroyed when no longer needed. The ACES system ensures that a user is not able to access the prior contents of a resource that has been allocated to that user by the system. Care is taken to ensure that the Recycle Bin does not store deleted files and standard industrial security procedures ensure the proper disposal of printed output based on the sensitivity of the data.

6.7 Network Security Controls

Access to the CA data is protected by a firewall specifically allocated to the protection of the ORC PKI suite. Only required accounts are present on the firewall. HTTPS and OCSP requests are the only type of data access that is allowed in. OCSP, HTTPS and LDAP/S are the only packet types allowed out. The firewall is secured in the locked CA environment area and not accessible over the network. Restricted IA access to the CA is via a dedicated authenticated VPN. An approved trusted SA makes all changes at the firewall station itself.

Network security controls for LRA equipment are the responsibility of the LRA’s organization, whether the LRA is an employee of ORC or another organization. The PKI Sponsor shall ensure that the LRA equipment is protected, as specified in the U.S. Government CA CP for CMA equipment. Where practical, the subscriber’s organization will only allow services to and from LRA equipment limited to those required to perform LRA functions. However, additional services consistent with the organization’s policy may be enabled. Protection shall be



All Rights Reserved

provided against known network attacks. All unused network ports and services shall be turned off. Any network software present on LRA equipment shall be necessary to the LRA function. Boundary control devices used to protect LRA equipment shall deny all but necessary services to the LRA equipment even if those services are enabled for devices on the network. Firewall shall meet the security functional requirements as specified in the DoD for medium robustness Firewall Protection Profile [FWPP]. Boundary control devices shall include an Intrusion Detection capability that meets the security functional requirements as specified in the Intrusion Detection System Protection Profile [IDSPP]. The PKI Sponsor will certify compliance with these requirements, in writing to the ORC Corporate Security Auditor, prior to approval of performing LRA functions and will certify compliance with these requirements, in writing to the ORC Corporate Security Auditor, annually.



All Rights Reserved

7 Certificate And CRL Profiles

7.1 Certificate Profile

ORC ACES Certificates contain public keys used for authenticating the sender and receiver of an electronic message and verifying the integrity of such messages, i.e., public keys used for digital signature verification.

ORC creates and maintains ACES Certificates that conform to the ITU-T Recommendation X.509, “The Directory: Authentication Framework,” June 1997.

All ORC ACES Certificates include a reference to an OID for this CPS within the appropriate field, and contain the required certificate fields according to this CPS and the GSA ACES Contract.

Complete certificate profile information, including key generation methods, for ORC certificates can be found in the X.509 Certificate and CRL Extensions Profile for the Common Policy [CCP-PROF] and the applicable ORC CA build document.

7.1.1 Version Numbers

ORC issues X.509 v3 ACES certificates (populate version field with integer 2).

7.1.2 Certificate Extensions

ORC ACES certificate profiles are in accordance with the requirements of the certificate profiles described in the ACES CP and the applicable ORC CA build document. In the case of certificates issued under this CPS and asserting a FPCPF OID, profiles are in accordance with the requirements of the certificate profiles described in the X.509 Certificate and CRL Extensions Profile for the FPCPF [CCP-PROF] and the applicable ORC CA build document.

Access control information may be carried in the subjectDirectoryAttributes non-critical extension. The syntax is defined in detail in [SDN702].

7.1.3 Algorithm Object Identifiers

Certificates issued by ORC CAs use the following OIDs for signatures.

sha-1WithRSAEncryption {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 5}

Certificates under this Policy use the following OIDs for identifying the algorithm for which the subject key was generated.



All Rights Reserved

rsaEncryption {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1}

dhpublicnumber {iso(1) member-body(2) us(840) ansi-x942(10046) number-type(2) 1}

id-keyExchangeAlgorithm {joint-iso-ccitt(2) country(16) us(840) organization(1) gov(101) dod(2) infosec(1) algorithms(1) 22}

ORC certifies only public keys associated with the crypto-algorithms identified above, and only uses the signature crypto-algorithms described above to sign certificates, certificate revocation lists and ORC’s OCSP responses.

ORC does not implement RSA with PSS padding.

7.1.4 Name Forms

X.500 Distinguished Names (DNs) are used by all ORC CAs in the issuer and subject fields of the certificates, with the attribute type as further constrained by RFC 3280.

X.500 Directories use the DN for lookups. All Relying Parties will have the ability to process DNs. If communities request to use other names, for example certificates used to implement a hardware protocol, where device addresses are most useful and certificate lookup is not performed, ORC will define alternate name forms to be included in the subjectAltName extension and provide the alternative name form to the Policy Authority. Any name form, defining GeneralName in [ISO9594-8] is used, in accordance with the required profile (Section 7.1.2).

7.1.5 Name Constraints

FBCA cross certificates issued by an ORC CA contains the Name Constraints extension set by the Policy Authority.

7.1.6 Certificate Policy Object Identifier

Certificates issued by the ORC CAs assert the OID appropriate to the level of assurance with which it was issued, as defined in Section 1.2.

7.1.7 Usage of Policy Constraints Extension

No Stipulation, unless cross-certification policy stipulates use of policy constraints.

7.1.8 Policy Qualifiers Syntax and Semantics

The certificates issued under this CPS shall not contain policy qualifiers.



All Rights Reserved

7.1.9 Processing Semantics for the Critical Certificate Policy Extension

ORC does not set the certificate policies extension to be critical. Relying Parties whose client software does not process this extension operate in this regard at their own risk. Processing semantics for the critical certificate policy extension used by ORC conforms to [FPKI-PROF] and [CCP-PROF].

7.1.10 Key Usage Constraints for id-fpki-common-authentication

Certificates asserting the id-fpki-common-authentication shall include a critical keyusage extension, asserting only the digitalSignature value.

7.2 CRL Profile

ORC CRL profiles addressing the use of each extension are provided in and conform to the X.509 Certificate and CRL Extensions Profile for the FPCPF [CCP-PROF] and the applicable ORC CA build document.

7.2.1 Version Numbers

CRLs issued under this CPS assert a version number as described in the X.509 standard [ISO9594-8]. CRLs assert Version 2.

7.2.2 CRL and CRL Entry Extensions

Detailed CRL profiles covering the use of each extension are available and described in the X.509 Certificate and CRL Extensions Profile for the FPCPF [CCP-PROF] and are in accordance with the ACES CP CRL profile. The CA supports CRL Distribution Points (CRL DP) in all EE certificates. The CRL DP is as follows:

ldap://aces-ds.orc.com/cn=ORC ACES <CA Name>, o=ORC PKI, c=US?certificaterevocationlist;binary


7.3 OCSP Request – Response Format

OCSP requests are not required to be signed (refer to RFC2560 for detailed syntax). OCSP requests and responses contain the following formats

http://aces/



All Rights Reserved

Field Expected Value

Version V1 (0)

Requester Name Not Required

Request List List of certificates – generally this should be the list of two certificates: ORC certificate and end entity certificate

Signature Not Required

Extensions Not Required

OCSP Request Format

The following table lists which fields are populated by an ORC OCSP Responder:

Field Expected Value

Response Status Successful | Malformed Request | Internal Error | Try Later

Response Type id-pkix-ocsp-basic {1 3 6 1 5 5 7 48 1 1}

Version V1 (0)

Responder ID Hash of Responder public key

Produced At Generalized Time

List of Responses Each response will contain certificate id; certificate status

12, thisUpdate, nextUpdate

13,

Extension

Nonce Will be present if nonce extension is present in the request

Signature Algorithm sha-1WithRSAEncryption {1 2 840 113549 1 1 5}

Signature Present

Certificates Applicable certificates issued to the OCSP Responder

OCSP Response Format

12

If the certificate is revoked, the OCSP Responder will provide revocation time and revocation reason from CRL entry and CRL entry extension. 13

The OCSP Responder will use thisUpdate and nextUpdate from CA CRL.



All Rights Reserved

8 CPS Administration

8.1 CPS Change Procedures

ORC will process any recommended changes communicated to the contact identified in Section 1.4 by the Government. ORC may choose to update this CPS at any time, but will submit draft changes to the Government for approval before incorporating in the official CPS.

8.1.1 List of Items

Notice of all proposed changes to this CPS under consideration by GSA that may materially affect users of this CPS (other than editorial or typographical corrections, changes to the contact details, or other minor changes) will be provided to Authorized CAs and Qualified Relying Parties, and will be posted on the GSA website. ORC posts notice of such proposed changes and advise subscribers under this CPS of such proposed changes, via the ORC ACES website.

8.1.2 Comment Period

Any interested person may file comments with GSA within 45 days of original notice. If the proposed change is modified as a result of such comments, a new notice of the modified proposed change is provided.

8.2 Publication and Notification Procedures

ORC shall notify the Policy Authority of any changes to this CPS. ORC posts notification of changes on the website associated with the CA operations as applicable to the CPS summary and other publicly available documentation. ORC notifies subscribers via e-mail of any changes to subscriber obligations. ORC posts a summary of this CPS on its ACES website. Subscriber obligation changes are published within seven (7) days.

8.3 CPS and External Approval Procedures

GSA will make the determination that this CPS complies with the policy identified in Section 1.2.

8.4 Waivers

No Stipulation.

ORCACEScpsV3_3_2(summary) B-1


All Rights Reserved

Appendix B: Acronyms And Abbreviations

ACES Access Certificates for Electronic Services

ACL Access Control List

ACO Administrative Contracting Officer

AICPA American Institute of Certified Public Accountants

ANSI American National Standards Institute

ASIS American Society of Industrial Security

ASN.1 Abstract Syntax Notation One

BSM Basic Security Module

C&A Certification and Accreditation

CA Certification Authority

CAA Certificate Authority Administrator

CAM Certificate Arbitrator Module

CARL Certificate Authority Revocation List

CMA Certificate Management Authorities

CMC Certificate Management Messages over Cryptographic Message Syntax

CMMF Certificate Management Message Format

CMS Card Management System

CN Common Name

COTS Commercial Off The Shelf

CP Certificate Policy

CPS Certificate Practice Statement

CRL Certificate Revocation List

CRL DP CRL Distribution Point

CRMF Certificate Request Message Format

CSA Certificate Status Authority

CSAA Code Signing Attribute Authority

CSOR Computer Security Objects Register

DER Distinguished Encoding Rules

DES Data Encryption Standard

DN Distinguished Name



All Rights Reserved

DoD Department of Defense

DRP Disaster Recovery Plan

DSA Digital Signature Algorithm

DSS Digital Signature Standard

EAL Evaluation Assurance Level

EE End Entity

FAR Federal Acquisition Regulation

FBCA Federal Bridge Certification Authority

FIPS Federal Information Processing Standard

FPCPF Federal PKI Common Policy Framework

FQDN Fully Qualified Domain Name

FTP File Transfer Protocol

FTS Federal Technology Service

GSA General Services Administration

GSII Government Services Information Infrastructure

HSM Hardware Security Module

HTTP Hypertext Transfer Protocol

HTTPS Transfer Protocol over Secure Sockets Layer

IA Issuing Authority

IDS Intrusion Detection System

IETF Internet Engineering Task Force

IP Internet Protocol

IPSEC IP Security

ISO International Standards Organization

ITU International Telecommunications Union

ITU-T International Telecommunications Union – Telecommunications Sector

ITU-TSS International Telecommunications Union – Telecommunications Systems Sector

KED Key Escrow Database

KRPS Key Recovery Practices Statement

KRS Key Recovery System

LDAP Lightweight Directory Access Protocol

LRA Local Registration Authority



All Rights Reserved

NIST National Institute of Standards and Technology

NSA National Security Agency

OCSP Online Certificate Status Protocol

OGP Office of Government-wide Policy

OID Object Identifier

OMB Office of Management and Budget

ORC Operational Research Consultants

PIN Personal Identification Number

PKCS Public Key Cryptography Standard

PKI Public Key Infrastructure

PKIX Public Key Infrastructure X.509

POP Proof of Possession

PPP Privacy Practices and Procedures

RA Registration Authority

RAID Redundant Array of Independent (or Inexpensive) Disks

RDN Relative Distinguished Name

RFC Request For Comments

RPS Registration Practice Statement

RSA Rivest Shamir Adleman

SA System Administrator

SAS Statement on Auditing Standards

SBU Sensitive But Unclassified

SHA Secure Hash Algorithms

SNOC Secure Network Operations Center

SSL Secure Sockets Layer

SSP System Security Plan

TCSEC Trusted Computer System Evaluation Criteria

TSM Token Strength Module

U.S. United States

U.S.C. United States Code

UPS Uninterruptible Power Supply

URL Uniform Resource Locator

WWW World Wide Web

ORCACEScpsV3_3_2(summary) F-1


All Rights Reserved

Appendix F: References

The following documents contain information that provides background, examples, or details about the contents of this policy.

Number Title Revision Date

OMB Circular No. A-123

Management’s Responsibility for Internal Control

http://www.whitehouse.gov/omb/circulars/a123/a123_rev.pdf,

ABADSG Digital Signature Guidelines

http://www.abanet.org/scitech/ec/isc/dsgfree.html

1 Aug 1996

FIPS140-2 Security Requirements for Cryptographic Modules -- 01 May 25

http://www.itl.nist.gov/fipspubs/by-num.htm

25 May 2001

FIPS186-2 Digital Signature Standard

http://csrc.nist.gov/fips/fips186-2.pdf

27 Jan 2000

FOIAACT The Freedom of Information Act, 5 U.S.C. § 552, As Amended By Public Law No. 104-231, 110 Stat. 3048

http://www.usdoj.gov/oip/foia_updates/Vol_XVII_4/page2.htm

FPKI-Prof Federal Public Key Infrastructure (PKI) X.509 Certificate and CRL Extensions Profile

http://www.cio.gov/fpkipa/documents/fpki_certificate_profile.pdf

12 Oct 2005

FWPP U.S. Department of Defense Traffic-FilterFirewall Protection Profile for Medium Robustness Environments

http://www.iatf.net

Version 1.4

1 May 2000

IDSPP Intrusion Detection System Protection Version 1.4

4 Feb 2002

http://www/

http://csrc/

http://www.iatf.net/



All Rights Reserved


http://www.iatf.net

ISO9594-8 Information Technology – Open Systems Interconnection – The Directory: Authentication Framework

ftp://ftp.bull.com/pub/OSIdirectotry/ITU/97x509final.doc

1997

ITMRA 40 U.S.C. 1452, Information Technology Management Reform Act

http://www4.law.cornell.edu/uscode/40/1452.html

NAG69C Information System Security Policy and Certification Practice Statement for Certification Authorities,

Revision C

Nov 1999

NS4009 NSTISSI 4009, National Information Systems Security Glossary

Jan 1999

NSD42 National Policy for the Security of National Security Telecom and Information Systems

http://snyside.sunnyside.com/cpsr/privacy/computer_security/nsd_42.txt (redacted version)

5 Jul 1990

PKCS-1 PKCS #1 v2.0: RSA Cryptography Standard

http://www.rsa,com

1 Oct 1998

PKCS-12 Personal Information Exchange Syntax Standard

http://www.rsa.com/rsalabs/pubs/PKCS/html/pkcs-12.html

Apr 1997

ACES CP Revised Certificate Policy For Access Certificates for Electronic Services

6 May 2004

FPCPF CP X.509 Certificate Policy for the Common Policy Framework

Version 2.52

16 Oct 2006

CCP-PROF

X.509 Certificate and Certificate Revocation List (CRL) Extensions Profile for the Shared Service Providers (SSP) Program

http://www.cio.gov/fpkipa/documents/CertCRLprofileForCP.pdf

6 Feb 2006

http://www.iatf.net/

ftp://ftp/

http://www/

http://snyside.sunnyside.com/cpsr/privacy/computer_security/nsd_42.txt

http://snyside.sunnyside.com/cpsr/privacy/computer_security/nsd_42.txt

http://www.rsa,com/

http://www/



All Rights Reserved


ECAKRP Key Recovery Policy for External Certification Authorities

Version 3.0

31 Aug 2003

RFC4210 Certificate Management Protocol, Adams, Farrell, Krause and Mononen

http://www.ietf.org/rfc/rfc4210.txt

Sep 2005

RFC2527 Certificate Policy and Certification Practices Framework, Chokhani and Ford

http://www.ietf.org/rfc/rfc2527.txt

Mar 1999

SDN702 SDN.702, Abstract Syntax for Utilization with Common Security Profile (CSP), Version 3 X.509 Certificates and Version 2 CRLs

http://www.armadillo.Huntsville.al.us/Forteza_docs/sdn702rev3.pdf

Revision 3

31 Jul 1997

ORC SSP Operational Research Consultants, Inc. Secure Network Operations Center System Security Plan (SSP)

Feb 2004

ORC PPP Operational Research Consultants, Inc. Privacy Policies and Procedures (PPP)

Feb 2004

AES Advanced Encryption Standard; NIST Special Publication 800-57

May 2006

2048 Digital Signature Algorithm; NIST Special Publication 800-57

May 2006

SHA 256 Secure Hash Algorithm 256; NIST Special Publication 800-57

May 2006

ORC KRPS

Key Recovery Practice Statement for External Certification Authorities

http://www/

http://www.armadillo.huntsville.al.us/Forteza_docs/sdn702rev3.pdf

http://www.armadillo.huntsville.al.us/Forteza_docs/sdn702rev3.pdf

ORCACEScpsV3_3_2(summary) G-1


All Rights Reserved

Appendix G: Glossary

ACES. Access Certificates for Electronic Services. This is a project of GSA’s Office of Government wide Policy (OGP) and Federal Technology Service (FTS) that is aimed at providing commercial public key certificate services to the American public.

ACES Certificates. Certificates issued by an Authorized CA in accordance with this CPS, which certificates reference this CPS by inclusion of the ACES OID.

ACES CPS. An ACES CPS is a certification practice statement of the practices that an Authorized CA employs in issuing, suspending, and revoking ACES Certificates and providing access to the same.

Agency. A term used to identify all federal agencies, authorized federal contractors, agency-sponsored universities and laboratories, and, when authorized by law or regulation, state, local, and tribal Governments.

Agency Applications. See “Qualified Relying Party.”

Authenticate. Relates to a situation where one party has presented an identity and claims to be that identity. Authentication enables another party to gain confidence that the claim is legitimate.

Authorized CA. A certification authority that has been authorized by GSA to issue ACES Certificates and provide Authorized CA Services.

Authorized CA Services. The services relating to ACES Certificates to be provided by Authorized CAs (See Section 2.1.1).

Certificate Authority Administrator - A Certificate Authority Administrator (CAA) is an individual who is the responsible party for a CA. The CAA possesses the private key of the CA’s certificate. The CAA may be collocated with the CA, but may also perform administration tasks remotely.

Certificate Policy - A Certificate Policy is a document that defines the policy requirements that must be met by any CA implemented under the policy.

Certificate Practice Statement - A Certificate Practice Statement (CPS) is a document which details the requirements and procedures that are followed by a CA in issuing and maintaining certificates, and the purposes and allowed uses of those certificates.

Certificate. A data record that, at a minimum: (a) identifies the Authorized CA issuing it; (b) names or otherwise identifies its subscriber; (c) contains a public key that corresponds to a private key under the control of the subscriber; (d)



All Rights Reserved

identifies its operational period; and (e) contains an ACES Certificate unique serial number and is digitally signed by the Authorized CA issuing it. As used in this CPS, the term of “Certificate” refers to certificates that expressly reference the OID of this CA in the “Certificate Policies” field of an X.509 v.3 certificate.

Certificate Management System (CMS). A Certificate Management System (Netscape and RSA Keon) provides a highly scalable, easily deployable certificate infrastructure for supporting encryption, authentication, tamper detection, and digital signatures in networked communications. It is based on open standards and protocols such as Public-Key Cryptography Standard (PKCS) #7, 10, 11, and 12, Secure Sockets Layer (SSL), Lightweight Directory Access Protocol (LDAP), and the X.509 certificate formats recommended by the International Telecommunications Union (ITU). Certificate Management System is highly customizable and configurable, permitting rapid integration with existing client and server software, customer databases, security systems, and authentication procedures.

Certificate Manufacturing Authority (CMA). An entity that is responsible for the manufacturing and delivery of ACES Certificates signed by an Authorized CA, but is not responsible for identification and authentication of certificate subjects (i.e., a CMA is an entity that is delegated or outsourced the task of actually manufacturing the Certificate on behalf of an Authorized CA).

Certificate Practice Statement (CPS). A Certification Practice Statement is a statement of the practices that a certification authority employs in issuing, suspending, revoking, and renewing certificates and providing access to same, in accordance with specific requirements (i.e., requirements specified in this CPS, requirements specified in a contract for services).

Certificate Repository. A certificate repository is a system that holds certificates and information about all active certificates including revocation information.

Certificate Revocation List. A Certificate Revocation List (CRL) is a list of certificates that have been revoked but have not yet expired. A CRL should be digitally signed by the CA to ensure its validity to relying parties.

Certification Authority. A certification authority is an entity that is responsible for authorizing and causing the issuance of a Certificate. The actual certificate is from the CMA.

Digital Certificate. A digital certificate is electronic information that indicates the identity of the subscriber, the identity of the issuing CA, the operational period of the certificate, and the public key of the subscriber. The certificate is digitally signed by the issuing CA to show validity.

Digital Signature. A digital signature is a string of bits associated with a collection of data (e.g., a file, document, message, transaction); this string of bits



All Rights Reserved

can only be generated by the holder of a private key, but can be verified by anyone with access to the corresponding public key.

Some algorithms include additional steps (e.g., one-way hashes, timestamps) in this basic process.

End Entity. An end entity is any individual or server who holds a digital certificate. See also subscriber.

Federal Information Processing Standards (FIPS). These are Federal standards that prescribe specific performance requirements, practices, formats, communications protocols, etc. for hardware, software, data, telecommunications operation, etc. Federal agencies are expected to apply these standards as specified unless a waiver has been granted in accordance to agency waiver procedures.

Government. Federal Government and authorized agencies and entities.

Hypertext Transfer Protocol over SSL (HTTPS). HTTPS is the use of Secure Socket Layer (SSL) for data transfer via the World Wide Web. HTTPS uses port 443 instead of HTTP port 80 in its interactions with the lower layer, TCP/IP. SSL uses a 128-bit key size for the RC4 stream encryption algorithm, which is considered an adequate degree of encryption for commercial exchange.

Identity Proofing. Method used for verifying the information provided on subscriber application.

Internet Engineering Task Force (IETF). The Internet Engineering Task Force is a large open international community of network designers, operators, vendors, and researches concerned with the evolution of the Internet architecture and the smooth operation of the Internet.

Issuing Authority. An Issuing Authority (IA) is an individual who is responsible for granting certificate requests. There can be multiple IAs for a single CA. IAs can be collocated with the subscribers requesting certificates, but can also issue certificates remotely.

Key Changeover. The procedure used by an Authority to replace its own private key (e.g., due to compromise) and replace current valid certificates issued with old key.

Key pair. Means 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.

Mutual Authentication. Parties at both ends of a communication activity authenticate each other (see authentication).



All Rights Reserved

Object Identifier (OID). An object identifier is a specially formatted number that is registered with an internationally recognized standards organization.

Operational Period of an ACES Certificate. The operational period of an ACES Certificate is the period of its validity. It would typically begin on the date the certificate is issued (or such later date as specified in the certificate), and ends on the date and time it expires as noted in the certificate.

Out-of-band. Communication between parties utilizing a means or method that differs from the current method of communication (e.g., one party using U.S. Postal mail to communicate with another party where current communication is online communication).

Policy Authority. The entity specified in Section 1.4 (the General Services Administration).

Private Key. The key of a key pair used to create a digital signature. This key must be kept a secret.

Program Participants. Collectively, the Authorized CAs, Registration Authorities, Certificate Manufacturing Authorities, Repositories, subscribers, Qualified Relying Parties, and Policy Authority authorized to participate in the public key infrastructure defined by this CPS.

Public Key. The key of a key pair used to verify a digital signature. The public key is made freely available to anyone who will receive digitally signed messages from the holder of the key pair. The public key is usually provided via an ACES Certificate issued by an Authorized CA and is often obtained by accessing a repository. A public key is used to verify the digital signature of a message purportedly sent by the holder of the corresponding private key.

Public Key Infrastructure. A Public Key Infrastructure (PKI) is a system of policies, CAs, certificates, information repositories, and trusted individuals, that is used to verify and authenticate individuals and servers, and to encrypt and decrypt information exchanged by these individuals and servers

Qualified Relying Party. A recipient of a digitally signed message who is authorized by this CPS to rely on an ACES Certificate to verify the digital signature on the message.

Registration Authority (RA). An entity that is responsible for identification and authentication of certificate subjects, and issues certificates (i.e., a Registration Authority is delegated certain tasks on behalf of an Authorized CA). The RA functions (verify and issue) can be split between the IA and LRA.

Relying Party. A relying party is any entity that relies on digital certificate credentials. See also Qualified Relying Party.



All Rights Reserved

Repository. A database containing information and data relating to certificates, and an Authorized CA, as specified in this CPS.

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. Means to prematurely end the operational period of a Certificate from a specified time forward.

Secure Sockets Layer. A protocol for providing data security layered between application protocols (such as HTTP, Telnet, NNTP, or FTP) and TCP/IP. This security protocol supports data encryption, server authentication, message integrity, and optional client authentication for a TCP/IP connection.

Sponsoring Organization. A business entity, government agency, or other organization with which a Business Representative is affiliated (e.g., as an employee, agent, member, user of a service, business partner, customer, etc.).

Subscriber. A subscriber is a person who (1) is the subject named or identified in an ACES Certificate issued to such person and (2) holds a private key that corresponds to a public key listed in that certificate, and (3) the person to whom digitally signed messages verified by reference to such certificate are to be attributed.

Suspend a Certificate. Means to temporarily suspend the operational period of a Certificate for a specified time period or from a specified time forward.

Trustworthy System. Means computer hardware, software, and procedures that: (a) are reasonably secure from intrusion and misuse; (b) provide a reasonable level of availability, reliability, and correct operation; (c) are reasonably suited to performing their intended functions, and (d) adhere to generally accepted security procedures.

Valid Certificate. Means an ACES Certificate that (1) an Authorized CA has issued, (2) the subscriber listed in it has accepted, (3) has not expired, and (4) has not been revoked. Thus, an ACES Certificate is not “valid” until it is both issued by an Authorized CA and has been accepted by the subscriber.

Operational Research Consultants, Inc. (ORC) Access ...summary).pdf · This CPS version updated and...

Documents

Transcript of Operational Research Consultants, Inc. (ORC) Access ...summary).pdf · This CPS version updated and...