Operational Research Consultants, Inc. (ORC) Access ... · This document is a summary of the...

Operational Research Consultants, Inc. (ORC)

Access Certificates For Electronic Services (ACES)

Certificate Practice Statement Summary

Version 3.2

July 25, 2005

Copyright 2004, Operational Research Consultants, Inc. All Rights Reserved

Table of Contents

1 Introduction .............................................................................................................1 1.1 Overview .......................................................................................................1 1.2 Policy Identification .........................................................................................2 1.3 Community and Applicability.............................................................................4

1.3.1 Certificate Service Providers ..................................................................4 1.3.2 End Entities (EE)..................................................................................6 1.3.3 Policy Authority ...................................................................................9 1.3.4 Applicability ........................................................................................9 1.3.5 Related Authorities............................................................................. 13

1.4 Contact Details ............................................................................................. 13 1.4.1 Policy Administration Organization........................................................ 13 1.4.2 Policy Contact Personnel ..................................................................... 13 1.4.3 Person Determining CPS Suitability for the Policy.................................... 14 1.4.4 CPS Administration Organization .......................................................... 14

2 General Provisions..................................................................................................15 2.1 Obligations................................................................................................... 15

2.1.1 Authorized CA Obligations ................................................................... 15 2.1.2 RA, LRA and IA Obligations.................................................................. 16 2.1.3 Certificate Manufacturing Authority Obligations....................................... 18 2.1.4 Repository Obligations ........................................................................ 18 2.1.5 Subscriber Obligations ........................................................................ 19 2.1.6 Server/Component Certificate Subscriber Obligations .............................. 20 2.1.7 Code Signer Certificate Subscriber Obligations........................................ 21 2.1.8 Relying Party Obligations..................................................................... 21 2.1.9 Policy Authority Obligations ................................................................. 23 2.1.10 ORC Certificate Status Authority (CSA) Obligations ................................. 23

2.2 Liability ....................................................................................................... 23 2.2.1 Authorized CA Liability ........................................................................ 23 2.2.2 RA, IA, CMA, and Repository Liability .................................................... 24 2.2.3 Warranties and Limitations On Warranties ............................................. 24 2.2.4 Damages Covered and Disclaimers ....................................................... 24 2.2.5 Loss Limitations ................................................................................. 24 2.2.6 Other Exclusions ................................................................................ 25

2.3 Financial Responsibility .................................................................................. 25 2.3.1 Indemnification By Relying Parties and Subscribers ................................. 25 2.3.2 Fiduciary Relationships........................................................................ 25 2.3.3 Administrative Processes..................................................................... 25

2.4 Interpretation and Enforcement ...................................................................... 25 2.4.1 Governing Law................................................................................... 25

ORCACEScpsSumV3_2 i Copyright 2004, Operational Research Consultants, Inc.

All Rights Reserved

2.4.2 Severability of Provisions, Survival, Merger, and Notice ........................... 26 2.4.3 Dispute Resolution Procedures ............................................................. 26

2.5 Fees............................................................................................................ 26 2.5.1 Certificate Issuance, Renewal, Suspension, and Revocation Fees............... 27 2.5.2 Certificate Access Fees........................................................................ 27 2.5.3 Revocation or Status Information Access Fees ........................................ 27 2.5.4 Fees for Other Services Such as Policy Information ................................. 27 2.5.5 Refund Policy..................................................................................... 27

2.6 Publication and Repository ............................................................................. 27 2.6.1 Publication of ORC ACES Information .................................................... 27 2.6.2 Frequency of Publication ..................................................................... 28 2.6.3 Access Controls ................................................................................. 28 2.6.4 Repositories ...................................................................................... 29

2.7 Inspections And Reviews................................................................................ 29 2.7.1 Certification and Accreditation.............................................................. 30 2.7.2 Quality Assurance Inspection and Review .............................................. 31

2.8 Confidentiality .............................................................................................. 32 2.8.1 Types of Information to Be Kept Confidential.......................................... 32 2.8.2 Types of Information Not Considered Confidential ................................... 33 2.8.3 Disclosure of Certificate Revocation/Suspension Information .................... 33 2.8.4 Release to Law Enforcement Officials .................................................... 34 2.8.5 Release as Part of Civil Discover........................................................... 34 2.8.6 Disclosure upon Owner's Request ......................................................... 34

2.9 Security Requirements................................................................................... 34 2.9.1 System Security Plan (SSP) ................................................................. 34 2.9.2 Risk Management............................................................................... 35 2.9.3 Certification and Accreditation.............................................................. 35 2.9.4 Rules and Behavior............................................................................. 35 2.9.5 Contingency Plan ............................................................................... 35 2.9.6 Incident Response Capability ............................................................... 35

2.10 Intellectual Property Rights ............................................................................ 35 3 Identification And Authentication ...........................................................................37

3.1 Initial Registration......................................................................................... 37 3.1.1 Types of Names ................................................................................. 37 3.1.2 Need for Names to be Meaningful ......................................................... 40 3.1.3 Rules for Interpreting Various Name Forms............................................ 40 3.1.4 Uniqueness of Names ......................................................................... 41 3.1.5 Name Claim Dispute Procedure ............................................................ 41 3.1.6 Recognition, Authentication and Role of Trademarks ............................... 41 3.1.7 Verification of Possession of Private Key ................................................ 41 3.1.8 Authentication of Sponsoring Organizational Identity............................... 42 3.1.9 Authentication of Individual Identity ..................................................... 43 3.1.10 Code Signer Authentication ................................................................. 49

ORCACEScpsSumV3_2 ii Copyright 2004, Operational Research Consultants, Inc.

All Rights Reserved

3.1.11 Authentication of Component Identities ................................................. 50 3.2 Routine Re-Key (Certificate Renewal)............................................................... 51

3.2.1 CA Certificate Routine Re-Key .............................................................. 51 3.2.2 Certificate Re-Key .............................................................................. 51 3.2.3 Certificate Renewal............................................................................. 51

3.3 Obtaining a New Certificate After Revocation..................................................... 52 3.4 Revocation Request....................................................................................... 53

4 Operational Requirements ......................................................................................54 4.1 Certificate Application.................................................................................... 54

4.1.1 Application Initiation........................................................................... 54 4.1.2 Application Rejection .......................................................................... 56

4.2 Certificate Issuance....................................................................................... 56 4.2.1 Certificate Delivery............................................................................. 57 4.2.2 Certificate Replacement ...................................................................... 58

4.3 Certificate Acceptance ................................................................................... 58 4.4 Certificate Suspension and Revocation ............................................................. 59

4.4.1 Who Can Request a Revocation?........................................................... 59 4.4.2 Circumstances for Revocation .............................................................. 60 4.4.3 Revocation Request Procedure ............................................................. 61 4.4.4 Revocation Grace Period...................................................................... 63 4.4.5 Certificate Authority Revocation Lists (CARLs)/Certificate Revocation Lists

(CRLs).............................................................................................. 63 4.4.6 Online Revocation/Status Checking Availability....................................... 64 4.4.7 Online Revocation Checking Requirements............................................. 64 4.4.8 Other Forms of Revocation Advertisements Available............................... 64 4.4.9 Checking Requirements for Other Forms of Revocation Advertisements

Available........................................................................................... 64 4.4.10 Special Requirements With Respect to Key Compromise .......................... 65

4.5 Certificate Suspension ................................................................................... 65 4.5.1 Circumstances for Suspension.............................................................. 65 4.5.2 Who Can Request Suspension .............................................................. 65 4.5.3 Procedure for Suspension Request ........................................................ 65

4.6 Computer Security and Audit Procedures .......................................................... 65 4.6.1 Types of Event Recorded ..................................................................... 66 4.6.2 Frequency of Processing Data .............................................................. 67 4.6.3 Retention Period for Security Audit Data................................................ 67 4.6.4 Protection of Security Audit Data.......................................................... 67 4.6.5 Security Audit Data Backup Procedures ................................................. 68 4.6.6 Security Audit Collection System (Internal vs. External)........................... 68 4.6.7 Notification to Event-Causing Subject.................................................... 68 4.6.8 Vulnerability Assessments ................................................................... 68

4.7 Records Archival ........................................................................................... 68 4.7.1 Types of Data Archived ....................................................................... 68

ORCACEScpsSumV3_2 iii Copyright 2004, Operational Research Consultants, Inc.

All Rights Reserved

4.7.2 Retention Period for Archive ................................................................ 69 4.7.3 Protection of Archive .......................................................................... 69

4.8 Key Changeover ........................................................................................... 69 4.9 Compromise and Disaster Recovery ................................................................. 70

4.9.1 Computing Resources, Software, and/or Data are Corrupted .................... 70 4.9.2 Authorized CA Public Key Is Revoked .................................................... 70 4.9.3 Private Key Is Compromised (Key Compromise Plan)............................... 71 4.9.4 Facility after a Natural or Other Disaster (Disaster Recovery Plan)............. 71

4.10 Authorized CA Cessation of Services ................................................................ 71 4.11 Customer Service Center................................................................................ 72

5 Physical, Procedural And Personnel Security Controls ............................................73 5.1 Physical Security Controls .............................................................................. 73

5.1.1 Physical Access Controls...................................................................... 73 5.1.2 Security Checks ................................................................................. 74 5.1.3 Media Storage ................................................................................... 74 5.1.4 Environmental Security ....................................................................... 74 5.1.5 Off-site Backup.................................................................................. 75

5.2 Procedural Controls ....................................................................................... 75 5.2.1 Trusted Roles .................................................................................... 75 5.2.2 Number of Persons Required Per Task (Separation of Roles) ..................... 77 5.2.3 Identification and Authentication for Each Role ....................................... 78 5.2.4 Hardware/Software Maintenance Controls.............................................. 78 5.2.5 Documentation .................................................................................. 78 5.2.6 Security Awareness Training ................................................................ 78 5.2.7 Retraining Frequency and Requirements................................................ 78 5.2.8 Job Rotation Frequency and Sequence................................................... 79 5.2.9 Sanctions for Unauthorized Actions....................................................... 79 5.2.10 Contracting Personnel Requirements ..................................................... 79 5.2.11 Documentation Supplied to Personnel ................................................... 79

5.3 Personnel Security Controls ............................................................................ 79 5.3.1 Access Authorization........................................................................... 79 5.3.2 Limited Access................................................................................... 80

6 Technical Security Controls.....................................................................................81 6.1 Key Pair Generation and Installation ................................................................ 81

6.1.1 Key Pair Generation............................................................................ 81 6.1.2 Private Key Delivery to Entity .............................................................. 81 6.1.3 Subscriber Public Key Delivery to Authorized CA (Certificate Issuer) .......... 82 6.1.4 ORC ACES CA Public Key Delivery to Users ............................................ 82 6.1.5 Key Delivery Sizes.............................................................................. 82 6.1.6 Public Key Parameters Generation ........................................................ 82 6.1.7 Parameter Quality Checking................................................................. 82 6.1.8 Key Usage Purposes (X.509 V3 Key Usage Field) .................................... 83 6.1.9 Private Key Shared by Multiple Subscribers............................................ 83

ORCACEScpsSumV3_2 iv Copyright 2004, Operational Research Consultants, Inc.

All Rights Reserved

6.1.10 Date/Time stamping ........................................................................... 83 6.2 Private Key Protection.................................................................................... 83

6.2.1 Standards for Cryptographic Modules .................................................... 83 6.2.2 Private Key Backup ............................................................................ 84 6.2.3 Private Key Archival ........................................................................... 84 6.2.4 Private Key Entry Into Cryptographic Module.......................................... 84 6.2.5 Method of Activating Private Key .......................................................... 85 6.2.6 Method of Deactivating Private Key....................................................... 85 6.2.7 Method of Destroying Private Key ......................................................... 85

6.3 Good Practices Regarding Key Pair Management ................................................ 86 6.3.1 Public Key Archival ............................................................................. 86 6.3.2 Private Key Archival ........................................................................... 86 6.3.3 Usage Periods for the Public and Private Keys......................................... 86 6.3.4 Restrictions on CA's Private Key Use ..................................................... 86 6.3.5 Private Key Multi-person Control .......................................................... 86 6.3.6 Private Key Escrow............................................................................. 87

6.4 Activation Data............................................................................................. 87 6.4.1 Activation Data Installation and Generation............................................ 87 6.4.2 Activation Data Protection ................................................................... 87 6.4.3 Other Aspects of Activation Data .......................................................... 88

6.5 Computer Security Controls............................................................................ 88 6.5.1 Audit ................................................................................................ 88 6.5.2 Technical Access Controls.................................................................... 88 6.5.3 Identification and Authentication .......................................................... 88 6.5.4 Trusted Paths .................................................................................... 88

6.6 Life Cycle Technical Controls........................................................................... 89 6.6.1 System Development Controls (Environment Security) ............................ 89 6.6.2 Security Management Controls............................................................. 89 6.6.3 Object Reuse..................................................................................... 90

6.7 Network Security Controls .............................................................................. 90 7 Certificate And CRL Profiles ....................................................................................92

7.1 Certificate Profile .......................................................................................... 92 7.1.1 Version Numbers ............................................................................... 92 7.1.2 Certificate Extensions ......................................................................... 92 7.1.3 Algorithm Object Identifiers................................................................. 92 7.1.4 Name Forms...................................................................................... 93 7.1.5 Name Constraints .............................................................................. 93 7.1.6 Certificate Policy Object Identifier......................................................... 93 7.1.7 Usage of Policy Constraints Extension ................................................... 93 7.1.8 Policy Qualifiers Syntax and Semantics.................................................. 93 7.1.9 Processing Semantics for the Critical Certificate Policy Extension............... 93 7.1.10 Key Usage Constraints for id-fpki-common-authentication........................ 93

7.2 CRL Profile ................................................................................................... 94

ORCACEScpsSumV3_2 v Copyright 2004, Operational Research Consultants, Inc.

All Rights Reserved

7.2.1 Version Numbers ............................................................................... 94 7.2.2 CRL and CRL Entry Extensions ............................................................. 94

7.3 OCSP Request – Response Format ................................................................... 94 8 CPS Administration .................................................................................................96

8.1 CPS Change Procedures ................................................................................. 96 8.1.1 List of Items...................................................................................... 96 8.1.2 Comment Period ................................................................................ 96

8.2 Publication and Notification Procedures ............................................................ 96 8.3 CPS and External Approval Procedures ............................................................. 96 8.4 Waivers ....................................................................................................... 96

Appendix A: Relying Party Agreement ............................................................................. A-1 Appendix B: Acronyms And Abbreviations........................................................................ B-1 Appendix C: Reserved ...................................................................................................... C-1 Appendix D: Applicable Federal and GSA Regulations ......................................................D-1 Appendix E: ORC ACES Profile Formats ............................................................................ E-1 Appendix F: Reserved ...................................................................................................... F-1 Appendix G: References ...................................................................................................G-1 Appendix H: Glossary.......................................................................................................H-1

ORCACEScpsSumV3_2 vi Copyright 2004, Operational Research Consultants, Inc.

All Rights Reserved

1 Introduction

1.1 Overview

This document is a summary of the Operational Research Consultants, Inc. (ORC) Access Certificates for Electronic Services (ACES) Certificate Practice Statement (CPS) that describes the implementation ORC’s 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 ACES Security Certification and Accreditation.

• Approving the ORC ACES CPS.

The ORC ACES 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.

The ORC ACES CPS applies to X.509 version 3 certificates with assurance levels as defined in the ACES CP and the Common Policy Framework CP, as used to protect information up to and including Sensitive But Unclassified (SBU). The policies and procedures in the ORC ACES 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 the Common Policy Framework CP, The ORC ACES CPS and the ORC ACES subordinate CAs that issue certificates asserting a Common Policy Framework OID will be updated to support the use of 2048 bit RSA keys and the SHA-256 hash algorithm.

The ORC ACES 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 affidavits and depositions),

ORCACEScpsSumV3_2 1 Copyright 2004, Operational Research Consultants, Inc.

All Rights Reserved

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-1/2 Level 3 Secure Socket Layer (SSL) connections to the certification authority. The subscriber must use a FIPS 140-1/2 Level 1 or 2 client for connection for enrollment.

• Enrollment Validation: The ORC ACES 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-1/2 Level 1 or 2 client. A FIPS 140-1 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 the ORC ACES CPS, ORC maintains a website, which contains instructions, online forms, a summary of the ORC ACES 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 The ORC ACES 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 the ORC ACES CPS:

• ACES Authorized 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}


All Rights Reserved

• 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}, {2 16 840 1 101 3 2 1 1 12}

Certificates issued under The ORC ACES CPS may also contain and comply with the following U.S. Federal PKI Common Policy Framework1 object identifiers (OIDs) for the ACES Certificates defined in The ORC ACES 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 6}

• Authentication certificates (w/o digital signature) on hardware tokens, id-fpki-common-authentication::={2 16 840 1 101 3 2 1 3 13}

ORC ACES Certificates issued under The ORC ACES reference the ACES CP and the Common Policy Framework by including the appropriate OID, identified above, in the Certificate Policies field. Additionally, each authorized CA that issues certificates

1 The requirements associated with the US Federal PKI Common Policy Framework OIDs are incorporated by reference. ORC will only apply the Federal Common Policy OIDs as appropriate, in accordance with the Federal Common Policy.


All Rights Reserved

asserting a Common Policy Framework OID shall hold a certificate signed by the Common Policy Framework CA. The foregoing OIDs may not be used except as specifically authorized by the ACES CP and the Common Policy Framework CP. Unless specifically approved by the Federal PKI Policy Authority, ORC ACES CAs do not assert the FBCA CP OIDs in any certificates issued, except in the policyMappings extension establishing an equivalency between an FBCA OID and an OID in the ACES CP. Only the OIDs identified above are used within ORC ACES 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://csrc.nist.gov/csor/ csor.html, and 2) [email protected].

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

1.3 Community and Applicability

The ORC ACES describes the rights and obligations of persons and entities authorized under the ORC ACES CPS to fulfill the roles of an ORC ACES Certificate Service Provider and End Entity (EE). As an ACES Certificate Service Provider and a GSA Shared Service Provider, ORC provides an ACES Certification Authority, Registration Authority, Certificate Manufacturing Authority, and Repository. 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 the ORC ACES 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 The ORC ACES CPS, the ORC ACES CAs, Certificate Authority Administrators (CAAs), and IAs are considered “Certificate Management Authorities” (CMAs) and are the only authorities with direct trusted access to the ORC ACES CA’s applications and keys. The ORC ACES CPS uses the term CMA when a function may be assigned to an ORC ACES CA, CAA, or IA; or when a requirement applies to an ORC ACES CA, CAA, and/ or IA. The division of responsibilities is described in the ORC ACES CPS. ORC server-based Certificate Status Authorities (CSAs) are also considered CMAs. The ORC ACES 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


All Rights Reserved

CA services. Corporate Security Auditor duties are a secondary job function. The Corporate Security Auditor is an employee of ORC and is designated in Appendix G of the ORC CPS.

SAs are responsible for managing the CA server at the operating system level. All SAs in support of the ORC ACES 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. Each ORC ACES CA is under an autonomous root. The ORC ACES 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 ACES 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 the ORC ACES 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 ACES CA from an ORC IA workstation that securely communicates with the CA.

1.3.1.2 Registration Authorities

RAs are employed by ORC and 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 the ORC ACES 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


All Rights Reserved

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 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 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 (or other persons legally empowered to witness and certify the validity of documents and to take affidavits and depositions) 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 (or other persons legally empowered to witness and certify the validity of documents and to take affidavits and depositions) shall witness and certify the signature on the form and required IDs.

Note: 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 the ORC ACES 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 the ORC ACES CPS. Subscribers are limited to the following categories of entities:


All Rights Reserved

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

• 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 ACES CAs are technically a subscriber to the PKI; however, the term subscriber as used in the ORC ACES 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 ACES 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 the ORC ACES CPS.

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

Note: At their 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 ACES 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 the ORC ACES CPS. All obligations related to obtaining and using ORC ACES SSL Server Certificates can be found in Section 2.1.5 of the ORC ACES 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.

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.

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

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.


All Rights Reserved

1.3.3 Policy Authority

The GSA serves as the Policy Authority2 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 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 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 ACES Certificates Functional Use

Certificate Type Subscriber Purpose Use of Certificate

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

Unaffiliated Individual (Medium or Medium Hardware Assurance Certificates)

Unaffiliated Individual

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

Business Representative Certificates (Medium or

Business Representative authorized to act on behalf of

Digital Signature

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

2 Additionally, the ORC ACES CPS recognizes the FBCA and the U.S. Federal PKI Common Policy Framework Policy Authorities. Throughout the ORC ACES 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

Certificate Type Subscriber Purpose Use of Certificate Medium Hardware Assurance Certificates)

a Sponsoring Organization Encryption

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

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

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

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

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.

Relying Party (Agency Application) Certificates

Relying Party

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

Digital Signature

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

Federal Employee Certificates (Medium or Medium Hardware Assurance Certificates)

Federal Employee Encryption

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

Authorized 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 ACES Certificates. Examples of suitable uses include, but are not limited to:


All Rights Reserved

• 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

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 the ORC ACES 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 the ORC ACES CPS, defined as Medium Assurance in the ACES CP, the US Federal PKI Common Policy Framework and the Federal Bridge CA. Credentials issued under the ORC ACES 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 the ORC ACES 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.


All Rights Reserved

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 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:

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

The ORC ACES 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-1, 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


All Rights Reserved

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

1.3.5 Related Authorities

1.3.5.1 Compliance Auditors

Compliance audits as stipulated in the ORC ACES 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 other 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 ACES CSA conforms to the stipulations of the ACES CP and the ORC ACES 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 the ORC ACES CPS as part of the evaluation process. Any changes to the ORC ACES CPS made after determination of suitability shall be transmitted to the Government for approval prior to incorporation.

GSA/FTS is responsible for ensuring that the ORC ACES 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 the ORC ACES 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 ACES system operating under the ORC ACES CPS.

2.1 Obligations

Additional obligations are set forth in other provisions of the ACES CP, the ORC ACES Contract (including the requirements of the ORC ACES 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 ACES 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 ACES Certificates issued under the ORC ACES CPS are in accordance with the requirements, representations, and warranties of the ORC ACES 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 the ORC ACES 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 the ORC ACES CPS:

• Ensuring that ACES 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 the ORC ACES CPS CA are not authorized to assume any other CA administration functions.

When validating subscriber requests for certificates issued under the ORC ACES 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 the ORC ACES CPS. LRAs under the ORC ACES CPS are not authorized to assume any other CA administration functions.

When validating subscriber requests for certificates issued under the ORC ACES 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

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


All Rights Reserved

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 other means 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 ACES Certificates Refer to Section 2.1.1.

2.1.4 Repository Obligations

The ORC ACES Repository is responsible for:

• Maintaining a secure system for storing and retrieving ACES Certificates.

• Maintaining a current copy of the ORC ACES CPS.

• Maintaining other information relevant to ACES Certificates.

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

ORC posts ACES 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 ACES directory


All Rights Reserved

sub-trees identify the organization of the EE. The ORC ACES 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/.crl

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

The certificate repository meets the following obligations:

• To list all un-expired certificates for the ORC ACES 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 ORC Point of Contact (PoC) during normal business hours for the operating organization

• To be maintained in accordance with the practices specified in the ORC ACES CPS

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

Note: 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 the ORC ACES CPS, a subscriber accepts the following obligations:

• To accurately represent themselves in all communications with the PKI

• 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 the ORC ACES CPS


All Rights Reserved
http://aces.orc.com/CRLs/

• 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) 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 the ORC ACES 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.

• 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 the ORC ACES CPS.

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


All Rights Reserved

• 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 the ORC ACES 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-1/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

• 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 the ORC ACES 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

The ORC ACES 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.


All Rights Reserved

ORC publicly posts a summary of the ORC ACES CPS on the ORC ACES website (ACES.orc.com) to provide the relying party information regarding the expectation of the ORC ACES system. When accepting a certificate issued under the ORC ACES 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 ACE 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 the ORC ACES Federal Common Policy Framework, this trust anchor is the ORC Federal Common Policy 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

• 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

Note: Data format changes associated with application upgrades may invalidate digital signatures and shall 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 ACES Certificates issued by all Authorized CAs.

2.1.8.2 Certificate Validation

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


All Rights Reserved

2.1.8.3 Reliance

A Qualified Relying Party may rely on a valid ACES 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 Certificate Policy.

• 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 ACES system, 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 the ORC ACES 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 the ORC ACES CPS. All ORC CSA practice updates, as well as any subsequent changes are updated in the ORC ACES CPS and submitted to the Policy Authority for conformance assessment. The CSA practices include:

• Conformance to the stipulations of the ACES CP and the ORC ACES CPS.

• 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 the ORC ACES 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 the ORC ACES CPS.


All Rights Reserved

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 the ORC ACES CPS, and that any issued certificates that assert the policy OIDs identified in the ORC ACES CPS, are issued in accordance with the stipulations of the ORC ACES CPS. ORC warrants that CRLs are issued and keys generated by ORC are in conformance with the ORC ACES CPS. ORC warrants that any CMA or ORC designated authority operates in accordance with the applicable sections of the ORC ACES CPS.

Subscriber organizations that authorize and employ LRAs warrant that:

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

• All LRA actions are accomplished in accordance with the ORC ACES CPS;

• LRAs operate in accordance with the applicable sections of the ORC ACES 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 the ORC ACES CPS;

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

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

ORC does not warrant the actions of Notaries Public or other persons legally empowered 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 the ORC ACES 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 the ORC ACES 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 the ORC ACES CPS and the ACES CP. ORC acknowledges


All Rights Reserved

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 o

Operational Research Consultants, Inc. (ORC) Access ... · This document is a summary of the...

Documents

Transcript of Operational Research Consultants, Inc. (ORC) Access ... · This document is a summary of the...