Entrust Managed Services Non-Federal Public Key Infrastructure X.509 Certificate Policy

Transcription

1 Entrust Managed Services Non-Federal Public Key Infrastructure X.509 Certificate Policy Version 1.4 September 30, 2010

2 Signature Page EMS PKI Policy Authority DATE i

3 Revision History Document Version Document Date Revision Details 1.0 April 24, 2009 Initial draft. 1.1 May 15, 2009 Align document more closely with FBCA CP 1.11 May 26, 2009 Align Section with the FBCA CP and other minor corrections 1.12 June 09, 2009 Updates based upon comments from the FBCA CPWG mapping review. 1.2 December 8, 2009 Changes throughout to align with SAFE Bio-Pharma SAFE CP Version March April 7, 2010 Revised Section to replace support of OCSP nonces with requirement for time-based caching responders. 1.4 November 10, Updates to align with PIV-I changes in Common Policy ii

4 Table of Contents 1. Introduction Overview Certificate Policy (CP) Relationship between the CP and the CPS Scope Interoperation with CAs Issuing under Different Policies Document Name and Identification FBCA Interoperation SAFE Interoperation PKI Participants PKI Authorities Entrust Managed Services PKI Policy Authority (EMSPKI PA) Certification Authority Certificate Status Servers Registration Authorities Trusted Agents Subscribers Relying Parties Other Participants Certificate Usage Appropriate Certificate Uses Prohibited Certificate Uses Policy Administration Organization Administering the Document Contact Person Person Determining CPS Suitability for the Policy CPS Approval Procedures Definitions and Acronyms Publication and Repository Responsibilities... 8 iii

5 2.1. Repositories Repository Obligations Publication of Certification Information Publication of Certificates and Certificate Status Publication of CA Information Interoperability Time or Frequency of Publication Access Controls on Repositories Identification and Authentication Naming Types of Names FIPS 201 PIV Policies Need for Names to Be Meaningful Anonymity or Pseudonymity of Subscribers Rules for Interpreting Various Name Forms Uniqueness of Names Recognition, Authentication, and Role of Trademarks Initial Identity Validation Method to Prove Possession of Private Key Authentication of Organization Identity Authentication of Individual Identity Authentication of Human Subscribers Basic and Rudimentary Policies PIV-I Policies All Other Policies Authentication of Human Subscribers For Role-based Certificates Authentication of Human Subscribers For Group Certificates Authentication of Devices Non-verified Subscriber Information iv

6 Validation of Authority Criteria for Interoperation Identification and Authentication for Re-key Requests Identification and Authentication for Routine Re-key Identification and Authentication for Re-key after Revocation Identification and Authentication for Revocation Request Certificate Life-Cycle Operational Requirements Certificate Application Who Can Submit a Certificate Application CA Certificates User Certificates Device Certificates Enrollment Process and Responsibilities Certificate Application Processing Performing Identification and Authentication Functions Approval or Rejection of Certificate Applications Time to Process Certificate Applications Certificate Issuance CA Actions During Certificate Issuance Notification to Subscriber by the CA of Issuance of Certificate Certificate Acceptance Conduct Constituting Certificate Acceptance Publication of the Certificate by the CA Notification of Certificate Issuance by the CA to Other Entities Key Pair and Certificate Usage Subscriber Private Key and Certificate Usage Relying Party Public key and Certificate Usage Certificate Renewal Circumstance for Certificate Renewal Who May Request Renewal Processing Certificate Renewal Requests v

7 Notification of New Certificate Issuance to Subscriber Conduct Constituting Acceptance of a Renewal Certificate Publication of the Renewal Certificate by the CA Notification of Certificate Issuance by the CA to Other Entities Certificate Re-key Circumstance for Certificate Re-key Who May Request Certification of a New Public Key Processing Certificate Re-keying Requests Notification of New Certificate Issuance to Subscriber Conduct Constituting Acceptance of a Re-keyed Certificate Publication of the Re-keyed Certificate by the CA Notification of Certificate Issuance by the CA to Other Entities Certificate Modification Circumstance for Certificate Modification Who May Request Certificate Modification Processing Certificate Modification Requests Notification of New Certificate Issuance to Subscriber Conduct Constituting Acceptance of Modified Certificate Publication of the Modified Certificate by the CA Notification of Certificate Issuance by the CA to Other Entities Certificate Revocation and Suspension Circumstances for Revocation Who Can Request Revocation Procedure for Revocation Request Revocation Request Grace Period Time within which CA must Process the Revocation Request Revocation Checking Requirements for Relying Parties CRL Issuance Frequency Maximum Latency for CRLs On-line Revocation/Status Checking Availability On-line Revocation Checking Requirements Other Forms of Revocation Advertisements Available vi

8 Special Requirements Related To Key Compromise Circumstances for Suspension Who Can Request Suspension Procedure for Suspension Request Limits on Suspension Period Certificate Status Services Operational Characteristics Service Availability Optional Features End Of Subscription Key Escrow and Recovery Key Escrow and Recovery Policy and Practices Session Key Encapsulation and Recovery Policy and Practices Facility, Management, and Operational Controls Physical Controls Site Location and Construction Physical Access Physical Access for CA Equipment Physical Access for RA Equipment Physical Access for CSS Equipment Power and Air Conditioning Water Exposures Fire Prevention and Protection Media Storage Waste Disposal Off-Site Backup Procedural Controls Trusted Roles Administrator Officer vii

9 Auditor Operator Number of Persons Required per Task Identification and Authentication for Each Role Roles Requiring Separation of Duties Personnel Controls Qualifications, Experience, and Clearance Requirements Background Check Procedures Training Requirements Retraining Frequency and Requirements Job Rotation Frequency and Sequence Sanctions for Unauthorized Actions Independent Contractor Requirements Documentation Supplied to Personnel Audit Logging Procedures Types of Events Recorded Frequency of Processing Log Retention Period for Audit Log Protection of Audit Log Audit Log Backup Procedures Audit Collection System (Internal vs. External) Notification to Event-Causing Subject Vulnerability Assessments Records Archival Types of Events Archived Retention Period for Archive Protection of Archive Archive Backup Procedures Requirements for Time-Stamping of Records Archive Collection System (Internal or External) Procedures to Obtain and Verify Archive Information Key Changeover viii

10 5.7. Compromise and Disaster Recovery Incident and Compromise Handling Procedures Computing Resources, Software, and/or Data Are Corrupted Entity (CA) Private Key Compromise Procedures Business Continuity Capabilities after a Disaster CA or RA Termination Technical Security Controls Key Pair Generation and Installation Key Pair Generation CA Key Pair Generation Subscriber Key Pair Generation CSS Key Pair Generation RA Key Pair Generation Private Key Delivery to Subscriber Public Key Delivery to Certificate Issuer CA Public Key Delivery to Relying Parties Key Sizes Public Key Parameters Generation and Quality Checking Key Usage Purposes (as per X.509 v3 Key Usage Field) Private Key Protection and Cryptographic Module Engineering Controls Cryptographic Module Standards and Controls Private Key (n out of m) Multi-Person Control Private Key Escrow Private Key Backup Backup of CA Private Signature Key Backup of Subscriber Private Signature Key Backup of Subscriber Private Key Management Key Backup of CSS Private Key Backup of Content Signing Private Key ix

11 Private Key Archival Private Key Transfer into or from a Cryptographic Module Private Key Storage on Cryptographic Module Method of Activating Private Key Method of Deactivating Private Key Method of Destroying Private Key Cryptographic Module Rating Other Aspects of Key Pair Management Public Key Archival Certificate Operational Periods and Key Usage Periods Subscriber Private Key Usage Environment Activation Data Activation Data Generation and Installation Activation Data Protection Other Aspects of Activation Data Computer Security Controls Specific Computer Security Technical Requirements Computer Security Rating Life Cycle Technical Controls System Development Controls System Development Controls for SAFE Interoperation Security Management Controls Life Cycle Security Controls Network Security Controls Time-Stamping Certificate, CRL, and OCSP Profiles Certificate Profile Version Number(s) Certificate Extensions Basic Constraints for CA Certificates Algorithm Object Identifiers x

12 Name Forms Name Constraints Certificate Policy Object Identifier Usage of Policy Constraints Extension Policy Qualifiers Syntax and Semantics Processing Semantics for the Critical Certificate Policies Extension CRL Profile Version Number(s) CRL and CRL Entry Extensions OCSP Profile Version Number(s) OCSP Extensions Compliance Audit and Other Assessments Frequency or Circumstances of Assessment Identity/Qualifications of Assessor Assessor s Relationship to Assessed Entity Topics Covered by Assessment Actions Taken as a Result of Deficiency Communication of Results Other Business and Legal Matters Fees Certificate Issuance or Renewal Fees Certificate Access Fees Revocation or Status Information Access Fees Fees for other Services Refund Policy Financial Responsibility Insurance Coverage Other Assets Insurance or Warranty Coverage for End-Entities Confidentiality of Business Information xi

13 Scope of Confidential Information Information not within the Scope of Confidential Information Responsibility to Protect Confidential Information Privacy of Personal Information Privacy Plan Information Treated as Private Information not Deemed Private Responsibility to Protect Private Information Notice and Consent to Use Private Information Disclosure Pursuant to Judicial or Administrative Process Other Information Disclosure Circumstances Intellectual Property Rights Representations and Warranties CA Representations and Warranties RA Representations and Warranties Subscriber Representations and Warranties Relying Parties Representations and Warranties Representations and Warranties of Other Participants CSS Representations and Warranties Disclaimers of Warranties Limitations of Liability Indemnities Term and Termination Term Termination Effect of Termination and Survival Individual Notices and Communications with Participants Amendments Procedure for Amendment Notification Mechanism and Period Circumstances under which OID must be Changed xii

14 9.13. Dispute Resolution Provisions Governing Law Compliance with Applicable Law Miscellaneous Provisions Entire Agreement Assignment Severability Enforcement (Attorneys Fees and Waiver of Rights) Force Majeure Other Provisions Bibliography Acronyms and Abbreviations Glossary xiii

15 1. INTRODUCTION This certificate policy (CP) includes eleven (11) policies including: policies for users with software cryptographic modules, policies for users with hardware cryptographic modules, a policy for devices, a policy for PIV-I content signing, a medium assurance policy, a basic assurance policy, a rudimentary assurance policy, a user authentication policy, and a card authentication policy. Where a specific policy is not stated, the policies and procedures in this specification apply equally to all policies. Any use of the term assurance in this Certificate Policy shall not be construed to be a representation or warranty. Any representations, warranties, or liability for damages shall be specifically documented in separate written agreements and shall be appropriately titled as such. The user policies apply to certificates issued to state government, local government, and commercial employees, contractors, and other affiliated personnel for the purposes of authentication, signature, and confidentiality. This CP was explicitly designed to support access to systems that have not been designated national security systems. A PKI that uses this CP will provide the following security management services: Key generation/storage Certificate generation, modification, re-key, and distribution Certificate revocation list (CRL) generation and distribution Directory management of certificate related items Certificate token initialization/programming/management System management functions (e.g., security audit, configuration management, archive.) Some of the policies require Non-Federal employees, contractors, and other affiliated personnel to use FIPS 140 validated cryptographic modules for cryptographic operations and the protection of trusted public keys. The device policy also requires use of FIPS 140 validated cryptographic modules for cryptographic operations and the protection of trusted public keys. This policy does not presume any particular PKI architecture. The policy may be implemented through a hierarchical PKI or mesh PKI. Any CA that asserts this policy in certificates must obtain prior approval from the Entrust Managed Services Policy Authority (EMS PA). CAs that issue certificates under this policy may operate simultaneously under other policies. Such CAs must not assert the OIDs in this policy in certificates unless they are issued in accordance with all the requirements of this policy. This policy establishes requirements for the secure distribution of self-signed certificates for use as trust anchors. These constraints apply only to CAs that chose to distribute self-signed certificates, such as a hierarchical PKI s root CA. One of the goals of the EMS NFI PKI is to facilitate interoperation between the NFI PKI and other external PKI domains. In particular, this CP has been constructed to facilitate policy mappings with the Federal PKI Bridge CA (FBCA) CP and with the Signatures and Authentication For Everyone (SAFE) Bridge CA (SBCA) CP. 1

16 This CP is consistent with request for comments (RFC) 3647, the Internet Engineering Task Force (IETF) Public Key Infrastructure X.509 (IETF PKIX) Certificate Policy and Certification Practices Framework. 1.1 OVERVIEW Certificate Policy (CP) Certificates issued under this policy contain a registered certificate policy object identifier (OID), which may be used by a relying party to decide whether a certificate is trusted for a particular purpose Relationship between the CP and the CPS This CP states what assurance can be placed in a certificate issued by the CA. The certification practice statement (CPS) states how the CA establishes that assurance. Each CA that issues certificates under this CP shall have a corresponding CPS. It is permissible to combine two CPS documents into one document if the CAs are related (e.g., a Root CA and its subordinate CA) Scope This CP applies to certificates issued to CAs, devices, and Non-Federal employees, contractors and other affiliated personnel Interoperation with CAs Issuing under Different Policies Interoperation with CAs that issue under different policies will be achieved through policy mapping and cross-certification through the Federal Bridge Certification Authority. Note that interoperability may also be achieved through other means, such as trust lists, to meet local requirements DOCUMENT NAME AND IDENTIFICATION This CP provides substantial assurance concerning identity of certificate subjects. Certificates issued in accordance with this CP shall assert at least one of the following OIDs in the certificate policy extension: Table 1: Certificate Policy Identifiers Policy Type Policy Name Policy OID Medium Software id-emspki-nfssp-medium-policy ::= { } id-emspki-nfssp-medium-devices ::= { } id-emspki-safeca-medium-software ::= { } Medium id-emspki-nfssp-medium-hardware ::= { } 2

17 Policy Type Hardware Policy Name Policy OID id-emspki-safeca-medium-hardware ::= { } id-emspki-nfssp-mediumauthentication ::= { } FIPS 201 PIV-I id-emspki-nfssp-medium-cardauth ::= { } id-emspki-nfssp-pivi-hardware ::= { } id-emspki-nfssp-pivi-contentsigning ::= { } Basic id-emspki-nfssp-basic-policy ::= { } id-emspki-safeca-basic ::= { } Rudimen -tary id-emspki-nfssp-rudimentary-policy ::= { } FBCA Interoperation Certificates issued to CAs may contain any or all of the OIDs listed in Table 1. This document includes three policies specific to the FIPS 201 Personal Identity Verification Card. Certificates issued to PIV-I users supporting authentication but not digital signature shall contain id-emspki-nfssp-pivi-hardware. Certificates issued to users supporting authentication where the private key can be used without user authentication shall contain id-emspki-nfsspmedium-cardauth. Entity certificates issued to a Card Management System (CMS) to sign the PIV-I card security objects shall contain id-emspki-nfssp-pivi-contentsigning. The id-emspkinfssp-pivi-contentsigning policy OID is reserved for this specific purpose. An entity certificate asserting id-emspki-nfssp-pivi-contentsigning will be issued to a Card Management System (CMS) if the operator of the CMS has been authorized by the Entrust Managed Services PKI Policy Authority. This authorization shall only be completed after the CMS operator has agreed to compliance with the requirements of Card Management System Requirements to Comply with PIV-I Policy, v1.0, dated November 1, Certificates issued to non-piv-i users, other than devices, to support digitally signed documents or key management may contain either: id-emspki-nfssp-medium-policy; id-emspki-safecamedium-software; id-emspki-nfssp-medium-hardware; id-emspki-safeca-medium-hardware; idemspki-nfssp-rudimentary-policy; id-emspki-safeca-basic; or id-emspki-nfssp-basic-policy. Subscriber certificates issued to non-piv-i devices under this policy shall include id-emspkinfssp-medium-devices. 3

18 NOTE: The FIPS 201 PIV Card is specific to the U.S. Federal Government. The CIO Council has released the following paper regarding interoperability between U.S. Federal Government PIV systems and non-federally issued identity cards: Personal Identity Verification Interoperability For Non-Federal Issuers; Issued by Federal CIO Council; March 2009 Per CIO Council s document, cards issued under this policy, with the id-emspki-nfssp-pivihardware policy asserted, will be referred to as PIV Interoperable Cards. The generation of PIV Interoperable Cards is the responsibility of each individual non-federal organization (state and local governments or commercial entities). EMSPKI will only provide the PKI credentials that will be populated on the PIV Interoperable Cards issued by each non-federal organization SAFE Interoperation The EMSPKI PA has assigned OIDs to be asserted exclusively for interoperation with the SAFE environment. These OIDs are named with a prefix of id-emspki-safe as documented in Table 1: Certificate Policy Identifiers PKI PARTICIPANTS The following are roles relevant to the administration and operation of CAs under this policy: PKI Authorities Entrust Managed Services PKI Policy Authority (EMSPKI PA) The Entrust Managed Services PKI Policy Authority (PA) is the custodian of the Entrust Managed Services Non-Federal Public Key Infrastructure X.509 Certificate Policy and is responsible for PKI policy administration including the approval of policy changes Certification Authority The CA is the collection of hardware, software and operating personnel that create, sign, and issue public key certificates to subscribers. The CA is responsible for the issuing and managing certificates including: The certificate manufacturing process Publication of certificates Revocation of certificates Generation and destruction of CA signing keys Ensuring that all aspects of the CA services, operations, and infrastructure related to certificates issued under this CP are performed in accordance with the requirements, representations, and warranties of this CP. This policy does not presume any particular PKI architecture. The policy may be implemented through a hierarchical PKI or mesh PKI. The CPS shall describe the PKI architecture for CAs operated under this CP. 4

19 It is the responsibility of the PA to designate which CAs shall be cross-certified with external entity CAs as a Principal CA. A CA that is to be designated as a Principal CA: Shall be a self-signed CA; Shall comply with the requirements of a Principal CA under the policies of any external entity to which it cross-certifies; and Shall not issue certificates to subscribers as defined in section A CA that issues subscriber certificates, referred to as an Issuing CA, shall not issue CA certificates Certificate Status Servers PKIs may optionally include an authority that provides status information about certificates on behalf of a CA through on-line transactions. In particular, PKIs may include OCSP responders to provide on-line status information. Such an authority is termed a certificate status server (CSS). Where the CSS is identified in certificates as an authoritative source for revocation information, the operations of that authority are considered within the scope of this CP. Examples include OCSP servers that are identified in the authority information access (AIA) extension. OCSP servers that are locally trusted, as described in RFC 2560, are not covered by this policy. Certificates asserting a id-emspki-safeca OID shall include the authorityinformationaccess (AIA) extension with a pointer to an OCSP Responder that has been issued a delegated certificate Registration Authorities The registration authorities (RAs) collect and verify each subscriber s identity and information that is to be entered into the subscriber s public key certificate. The RA performs its function in accordance with a CPS approved by the PA. The RA is responsible for: Control over the registration process The identification and authentication process. The CA reserves the right to audit records kept by delegated RAs to ensure the RAs processes and procedures are in compliance with this CP and any applicable CPS Trusted Agents The trusted agent is a person who satisfies all the trustworthiness requirements for an RA and who performs identity proofing as a proxy for the RA. The trusted agent records information from and verifies biometrics (e.g., photographs) on presented credentials for applicants who cannot appear in person at an RA. The CPS will identify the parties responsible for providing such services, and the mechanisms for determining their trustworthiness Subscribers The user policies apply to certificates issued to state government, local government, and commercial employees, contractors, and other affiliated personnel for the purposes of 5

20 authentication, signature, and confidentiality. The term agency is used to specify the state government, local government, or commercial entity that employs the subscriber. A subscriber is the entity whose name appears as the subject in a certificate. The subscriber asserts that he or she uses the key and certificate in accordance with the certificate policy asserted in the certificate, and does not issue certificates. CAs are sometimes technically considered subscribers in a PKI. However, the term subscriber as used in this document refers only to those who request certificates for uses other than signing and issuing certificates or certificate status information. There may be a subset of human subscribers that can be issued role-based certificates. These certificates identify a specific role on behalf of which the subscriber is authorized to act rather than the subscriber s name and are issued in the interest of supporting accepted business practices. The role-based certificate can be used in situations where non-repudiation is desired. Normally, role-based certificates are issued in addition to an individual subscriber certificate. A specific role may be identified in certificates issued to multiple subscribers, however, the key pair will be unique to each individual role-based certificate (i.e. there may be four individuals carrying a certificate issued in the role of Secretary of Commerce however, each of the four individual certificates will carry unique keys and certificate identifiers). Roles for which rolebased certificates may be issued are limited to those that are held by a unique individual within an organization (e.g. Chief Information Officer, GSA is a unique individual whereas Program Analyst, GSA is not) Relying Parties A relying party is the entity that relies on the validity of the binding of the subscriber s name to a public key. The relying party is responsible for deciding whether or how to check the validity of the certificate by checking the appropriate certificate status information. The relying party can use the certificate to verify the integrity of a digitally signed message, to identify the creator of a message, or to establish confidential communications with the holder of the certificate. A relying party may use information in the certificate (such as CP identifiers) to determine the suitability of the certificate for a particular use. For this certificate policy, the relying party may be any entity that wishes to validate the binding of a public key to the name (or role) of a subscriber Other Participants The CAs and RAs operating under this CP may require the services of other security, community, and application authorities, such as compliance auditors and attribute authorities. The CPS will identify the parties responsible for providing such services, and the mechanisms used to support these services CERTIFICATE USAGE Appropriate Certificate Uses The sensitivity of the information processed or protected using certificates issued by the CA will vary significantly. Organizations must evaluate the environment and the associated threats and vulnerabilities and determine the level of risk they are willing to accept based on the sensitivity 6