Operational Research Consultants, Inc. (ORC) Access Certificates For Electronic Services (ACES) Certificate Practice Statement Summary. Version 3.3.

Transcription

1 Operational Research Consultants, Inc. (ORC) Access Certificates For Electronic Services (ACES) Certificate Practice Statement Summary Version May 30, 2007 Copyright 2007, Operational Research Consultants, Inc.

2 Certificate Practice Statement Revision History Version Date Revision Summary September February 2000 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. 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 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 November February 2001 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. 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 October April June 2005 This CPS version updated and replaced Version 3.1, to include modifications stipulated by the Federal Bridge Certificate Authority Policy audit review. 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). This CPS version updated and replaced Version 3.2.1, to include modifications necessary to comply with FPCPF subcommittee comments September 2005 This CPS version updated and replaced Version 3.2.2, to include modifications necessary to comply with FPCPF subcommittee Copyright 2007, Operational Research Consultants, Inc.

3 comments and OCD review January 2007 This CPS version updated and replaced Version 3.3, to include modifications necessary to comply with the following Common Policy Change Proposals: , Addition of High Assurance Policy to the Common Policy Framework, 13 September , 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 May 2007 Updates concerning the report from the PKI Shared Service Provider Working Group on ORC, dated 23 April 2007 Copyright 2007, Operational Research Consultants, Inc.

4 Table of Contents 1 Introduction Overview Policy Identification Community and Applicability Certificate Service Providers End Entities (EE) Policy Authority Applicability Related Authorities Contact Details Policy Administration Organization Policy Contact Personnel Person Determining CPS Suitability for the Policy CPS Administration Organization General Provisions Obligations Authorized CA Obligations RA, LRA and IA Obligations Certificate Manufacturing Authority Obligations Repository Obligations Subscriber Obligations Server/Component Certificate Subscriber Obligations Code Signer Certificate Subscriber Obligations Relying Party Obligations Policy Authority Obligations ORC Certificate Status Authority (CSA) Obligations Liability Authorized CA Liability RA, IA, CMA, and Repository Liability Warranties and Limitations On Warranties Damages Covered and Disclaimers Loss Limitations Other Exclusions Financial Responsibility Indemnification By Relying Parties and Subscribers Fiduciary Relationships Administrative Processes Interpretation and Enforcement i Copyright 2007, Operational Research Consultants, Inc.

5 2.4.1 Governing Law Severability of Provisions, Survival, Merger, and Notice Dispute Resolution Procedures Fees Certificate Issuance, Renewal, Suspension, and Revocation Fees Certificate Access Fees Revocation or Status Information Access Fees Fees for Other Services Such as Policy Information Refund Policy Publication and Repository Publication of ORC ACES Information Frequency of Publication Access Controls Repositories Inspections And Reviews Certification and Accreditation Quality Assurance Inspection and Review Confidentiality Types of Information to Be Kept Confidential Types of Information Not Considered Confidential Disclosure of Certificate Revocation/Suspension Information Release to Law Enforcement Officials Release as Part of Civil Discover Disclosure upon Owner's Request Security Requirements System Security Plan (SSP) Risk Management Certification and Accreditation Rules and Behavior Contingency Plan Incident Response Capability Intellectual Property Rights Identification And Authentication Initial Registration Types of Names Need for Names to be Meaningful Rules for Interpreting Various Name Forms Uniqueness of Names Name Claim Dispute Procedure Recognition, Authentication and Role of Trademarks Verification of Possession of Private Key Authentication of Sponsoring Organizational Identity ii Copyright 2007, Operational Research Consultants, Inc.

6 3.1.9 Authentication of Individual Identity Code Signer Authentication Authentication of Component Identities Routine Re-Key (Certificate Renewal) CA Certificate Routine Re-Key Certificate Re-Key Certificate Renewal Obtaining a New Certificate After Revocation Revocation Request Operational Requirements Certificate Application Application Initiation Application Rejection Certificate Issuance Certificate Delivery Certificate Replacement Certificate Acceptance Certificate Suspension and Revocation Who Can Request a Revocation? Circumstances for Revocation Revocation Request Procedure Revocation Grace Period Certificate Authority Revocation Lists (CARLs)/Certificate Revocation Lists (CRLs) Online Revocation/Status Checking Availability Online Revocation Checking Requirements Other Forms of Revocation Advertisements Available Checking Requirements for Other Forms of Revocation Advertisements Available Special Requirements With Respect to Key Compromise Certificate Suspension Circumstances for Suspension Who Can Request Suspension Procedure for Suspension Request Computer Security and Audit Procedures Types of Event Recorded Frequency of Processing Data Retention Period for Security Audit Data Protection of Security Audit Data Security Audit Data Backup Procedures Security Audit Collection System (Internal vs. External) Notification to Event-Causing Subject iii Copyright 2007, Operational Research Consultants, Inc.

7 4.6.8 Vulnerability Assessments Records Archival Types of Data Archived Retention Period for Archive Protection of Archive Key Changeover Compromise and Disaster Recovery Computing Resources, Software, and/or Data are Corrupted Authorized CA Public Key Is Revoked Private Key Is Compromised (Key Compromise Plan) Facility after a Natural or Other Disaster (Disaster Recovery Plan) Authorized CA Cessation of Services Customer Service Center Physical, Procedural And Personnel Security Controls Physical Security Controls Physical Access Controls Security Checks Media Storage Environmental Security Off-site Backup Procedural Controls Trusted Roles Number of Persons Required Per Task (Separation of Roles) Identification and Authentication for Each Role Hardware/Software Maintenance Controls Documentation Security Awareness Training Retraining Frequency and Requirements Job Rotation Frequency and Sequence Sanctions for Unauthorized Actions Contracting Personnel Requirements Documentation Supplied to Personnel Personnel Security Controls Access Authorization Limited Access Technical Security Controls Key Pair Generation and Installation Key Pair Generation Private Key Delivery to Entity Subscriber Public Key Delivery to Authorized CA (Certificate Issuer) ORC ACES CA Public Key Delivery to Users Key Sizes iv Copyright 2007, Operational Research Consultants, Inc.

8 6.1.6 Public Key Parameters Generation Parameter Quality Checking Key Usage Purposes (X.509 V3 Key Usage Field) Private Key Shared by Multiple Subscribers Date/Time stamping Private Key Protection Standards for Cryptographic Modules Private Key Backup Private Key Archival Private Key Entry Into Cryptographic Module Method of Activating Private Key Method of Deactivating Private Key Method of Destroying Private Key Good Practices Regarding Key Pair Management Public Key Archival Private Key Archival Usage Periods for the Public and Private Keys Restrictions on CA's Private Key Use Private Key Multi-person Control Private Key Escrow Activation Data Activation Data Installation and Generation Activation Data Protection Other Aspects of Activation Data Computer Security Controls Audit Technical Access Controls Identification and Authentication Trusted Paths Life Cycle Technical Controls System Development Controls (Environment Security) Security Management Controls Object Reuse Network Security Controls Remote Access/Dial-up Access... Error! Bookmark not defined Encryption... Error! Bookmark not defined. 7 Certificate And CRL Profiles Certificate Profile Version Numbers Certificate Extensions Algorithm Object Identifiers Name Forms v Copyright 2007, Operational Research Consultants, Inc.

9 7.1.5 Name Constraints Certificate Policy Object Identifier Usage of Policy Constraints Extension Policy Qualifiers Syntax and Semantics Processing Semantics for the Critical Certificate Policy Extension Key Usage Constraints for id-fpki-common-authentication CRL Profile Version Numbers CRL and CRL Entry Extensions OCSP Request Response Format CPS Administration CPS Change Procedures List of Items Comment Period Publication and Notification Procedures CPS and External Approval Procedures Waivers 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 vi Copyright 2007, Operational Research Consultants, Inc.

10 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 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 ORCACEScpsV3_3_2(summary) 1 Copyright 2007, Operational Research Consultants, Inc.

11 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) Level 3 Secure Socket Layer (SSL) connections to the certification authority. The subscriber must use a FIPS 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 Level 1 or 2 client. A FIPS 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: ORCACEScpsV3_3_2(summary) 2 Copyright 2007, Operational Research Consultants, Inc.

12 ACES Authorized/ Subordinate CA Certificates: { } Unaffiliated Individual Digital Signature Certificates: { } Unaffiliated Individual Encryption Certificates: { } Business Representative Digital Signature Certificates: { } Business Representative Encryption Certificates: { } Relying Party Digital Signature Certificates: { } Relying Party Encryption Certificates: { } Agency Application SSL Server Certificates: { } Federal Employee Digital Signature Certificates: { } Federal Employee Encryption Certificates: { } Federal Employee Digital Signature Certificates on hardware tokens: { } Federal Employee Encryption Certificates on hardware tokens: { } State and Local Employee Digital Signature Certificates: { } State and Local Employee Encryption Certificates: { } State and Local Employee Digital Signature Certificates on hardware token: { } State and Local Employee Encryption Certificates on hardware token: { } VPN IPSec Certificate: { } Code Signing Certificates on hardware token: { } OCSP Signing Certificates: { } ORCACEScpsV3_3_2(summary) 3 Copyright 2007, Operational Research Consultants, Inc.

13 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::={ } Subscriber certificates on hardware tokens, id-fpki-common-hardware::={ } Device certificates: id-fpki-common-devices::={ } Authentication PIV user authentication certificates (w/o non repudiation) on hardware tokens, id-fpki-common-authentication::={ } PIV card authentication certificates (w/o non repudiation) on hardware tokens, id-fpki-common-cardauth ::= { } Certificates issued to users asserting a FPCPF OID to support digitally signed documents or key management contain either the id-fpki-common-policy or idfpki-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. ORCACEScpsV3_3_2(summary) 4 Copyright 2007, Operational Research Consultants, Inc.

14 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) and 2) The ORC PKI and this CPS support medium assurance and medium-hardware assurance levels as defined in Section 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 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. ORCACEScpsV3_3_2(summary) 5 Copyright 2007, Operational Research Consultants, Inc.

15 SAs are responsible for managing the CA server at the operating system level. All SAs in support of this CPS are employees of ORC 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 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 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 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 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 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 ORCACEScpsV3_3_2(summary) 6 Copyright 2007, Operational Research Consultants, Inc.

16 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 (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 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 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 Repositories ORC performs the role and functions of the repository under the ORC ACES Program End Entities (EE) An EE is a holder of a certificate that is at the end of a certificate chain 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 ORCACEScpsV3_3_2(summary) 7 Copyright 2007, Operational Research Consultants, Inc.

17 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 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 Agency Applications ORC is authorized to issue certificates to authorized agency applications performing various functions. ORCACEScpsV3_3_2(summary) 8 Copyright 2007, Operational Research Consultants, Inc.

18 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 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 of this CPS 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. ORCACEScpsV3_3_2(summary) 9 Copyright 2007, Operational Research Consultants, Inc.

19 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 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 Policy Authority The GSA serves as the Policy Authority 3 and is responsible for organizing and administering the ACES Certificates Policy and the ORC ACES Contract Applicability 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. ORCACEScpsV3_3_2(summary) 10 Copyright 2007, Operational Research Consultants, Inc.

20 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) Business Representative Certificates (Medium or Medium Hardware Assurance Certificates) State and Local Government Representative Certificates (Medium or Medium Hardware Assurance Certificates) Relying Party (Agency Application) Certificates Unaffiliated Individual Business Representativ e authorized to act on behalf of a Sponsoring Organization Government Employees authorized to act on behalf of a State or Local Government Relying Party Digital Signature Encryption Digital Signature Encryption Digital Signature Encryption 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 To enable an unaffiliated individual to use confidentiality services (encryption and decryption) on his/her information and transactions To enable Business Representatives to mutually authenticate themselves to conduct businessrelated activities electronically and to verify digitally signed documents/ transactions To enable a Business Representative to use confidentiality services (encryption & decryption) on his/her information and transactions To enable State or Local Government Representatives to mutually authenticate themselves to conduct business-related activities electronically and to verify digitally signed documents/transactions To enable a State or Local Government Representative to use confidentiality services (encryption and decryption) on his/her information and transactions 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. ORCACEScpsV3_3_2(summary) 11 Copyright 2007, Operational Research Consultants, Inc.

21 Certificate Type Subscriber Purpose Use of Certificate Agency Application SSL Server Certificates Federal Employee Certificates (Medium or Medium Hardware Assurance Certificates) Authorized CA Certificate/ Subordinate CA Certificate VPN IPSec Certificate Code Signing Medium Hardware Assurance Certificate Server Federal Employee Federal Employee N/A Server Individual authorized to act on behalf of a Sponsoring Organization Suitable Uses Encryption Authentication & Encrypted Data Transmission Digital Signature Encryption Authentication & Encrypted Data Transmission Code Signing To enable a Relying Party to provide confidentiality services (encryption and decryption) to subscribers on their information and transactions To enable authenticated encrypted communications between subscribers and servers To enable Federal Employees and Relying Parties to mutually authenticate themselves and verify digitally signed documents/transactions To enable a Federal Employee to use confidentiality services (encryption and decryption) on his/her information and transactions To enable the Authorized CA to issue subscriber certificates. To enable authenticated VPN IPSec encrypted communications between subscribers and servers To enable the secure distribution of code to an authorized community of users. 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 ORCACEScpsV3_3_2(summary) 12 Copyright 2007, Operational Research Consultants, Inc.

22 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 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] 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 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 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 ORCACEScpsV3_3_2(summary) 13 Copyright 2007, Operational Research Consultants, Inc.

23 mission and environment. Each Relying Party is responsible for carrying out this risk analysis 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 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 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 ORCACEScpsV3_3_2(summary) 14 Copyright 2007, Operational Research Consultants, Inc.

24 1.3.5 Related Authorities 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 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 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 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 Policy Contact Personnel Office of Electronic Government and Technology Office of Government-wide Policy Phone: (202) ORCACEScpsV3_3_2(summary) 15 Copyright 2007, Operational Research Consultants, Inc.

25 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) address: 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, Waples Mill, South Tower, Ste 210, Fairfax, VA ORCACEScpsV3_3_2(summary) 16 Copyright 2007, Operational Research Consultants, Inc.

26 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 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 ORCACEScpsV3_3_2(summary) 17 Copyright 2007, Operational Research Consultants, Inc.