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

Transcription

1 Operational Research Consultants, Inc. (ORC) Access Certificates For Electronic Services (ACES) Certificate Practice Statement Summary Version 3.2 July 25, 2005

2 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 Governing Law ORCACEScpsSumV3_2 i

3 2.4.2 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 Authentication of Individual Identity Code Signer Authentication ORCACEScpsSumV3_2 ii

4 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 Vulnerability Assessments Records Archival Types of Data Archived ORCACEScpsSumV3_2 iii

5 4.7.2 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 Delivery Sizes Public Key Parameters Generation Parameter Quality Checking Key Usage Purposes (X.509 V3 Key Usage Field) Private Key Shared by Multiple Subscribers ORCACEScpsSumV3_2 iv

6 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 Certificate And CRL Profiles Certificate Profile Version Numbers Certificate Extensions Algorithm Object Identifiers Name Forms 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 ORCACEScpsSumV3_2 v

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

8 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

9 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 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: { } Unaffiliated Individual Digital Signature Certificates: { } Unaffiliated Individual Encryption Certificates: { } ORCACEScpsSumV3_2 2

10 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: { }, { } Certificates issued under The ORC ACES CPS may also contain and comply with the following U.S. Federal PKI Common Policy Framework 1 object identifiers (OIDs) for the ACES Certificates defined in The ORC ACES 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 certificates (w/o digital signature) on hardware tokens, id-fpkicommon-authentication::={ } 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. ORCACEScpsSumV3_2 3

11 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) csor.html, and 2) csor@nist.gov. The ORC ACES PKI and CPS support medium assurance and medium-hardware assurance levels as defined in Section 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 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 ORCACEScpsSumV3_2 4

12 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 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 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 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 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 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 Local Registration Authorities ORCACEScpsSumV3_2 5

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

14 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 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 Agency Applications ORC is authorized to issue ACES certificates to authorized agency applications performing various functions. ORCACEScpsSumV3_2 7

15 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 the ORC ACES CPS. All obligations related to obtaining and using ORC ACES SSL Server Certificates can be found in Section of the ORC ACES 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 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 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. ORCACEScpsSumV3_2 8

16 1.3.3 Policy Authority The GSA serves as the Policy Authority 2 and is responsible for organizing and administering the ACES Certificates Policy and the ORC ACES Contract Applicability 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 Unaffiliated Individual (Medium or Medium Hardware Assurance Certificates) Business Representative Certificates (Medium or Unaffiliated Individual Business Representative authorized to act on behalf of 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 ORC ACES subscriber to use confidentiality services (encryption and decryption) on his/her information and transactions 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. ORCACEScpsSumV3_2 9

17 Certificate Type Subscriber Purpose Use of Certificate Medium a Sponsoring Hardware Organization Assurance Encryption Certificates) State and Local Government Representative Certificates (Medium or Medium Hardware Assurance Certificates) Relying Party (Agency Application) Certificates Agency Application SSL Server Certificates Federal Employee Certificates (Medium or Medium Hardware Assurance Certificates) Authorized CA Certificate VPN IPsec Certificate Code Signing Medium Hardware Assurance Certificate Government Employees authorized to act on behalf of a State or Local Government Relying Party Server Federal Employee Federal Employee N/A Server Individual authorized to act on behalf of a Sponsoring Organization Suitable Uses Digital Signature Encryption Digital Signature Encryption Authentication & Encrypted Data Transmission Digital Signature Encryption Authentication & Encrypted Data Transmission Code Signing 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. 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 ACES Certificates. Examples of suitable uses include, but are not limited to: ORCACEScpsSumV3_2 10

18 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 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] 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. ORCACEScpsSumV3_2 11

19 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 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: This level is intended for all applications operating in environments appropriate for medium assurance but which require a higher degree of assurance and technical nonrepudiation 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 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 ORCACEScpsSumV3_2 12

20 ANSI X9.31 American National Standard for Digital Signature using Reversible Public Key Cryptography for the Financial Service Industry Related Authorities 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 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 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) ORCACEScpsSumV3_2 13

21 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) 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 the ORC ACES CPS. PKI Project Director, Waples Mill, South Tower, Ste 210, Fairfax, VA ORCACEScpsSumV3_2 14

22 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 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 ORCACEScpsSumV3_2 15

23 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 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 RA, LRA and IA Obligations 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 ORCACEScpsSumV3_2 16

24 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 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 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 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. ORCACEScpsSumV3_2 17