X.509 Certificate Policy For The Federal Bridge Certification Authority (FBCA) Version 2.24

Transcription

1 X.509 Certificate Policy For The Federal Bridge Certification Authority (FBCA) Version 2.24 February 25, 2011

2 Signature Page Chair, Federal Public Key Infrastructure Policy Authority DATE

3 Revision History Document Version Document Date Revision Details January September March June July August September February August , Changes to the FBCA CP to modify audit cycle for consistency with Government certification and accreditation process , Omnibus Policy Issues Raised During the CertiPath Mapping and e-auth Business Rules Review , Harmonization between Federal Bridge and Common Policy Framework , Clarification on multiparty physical access control in Physical Access for CA Equipment , SAFE Harmonization Policy Change Recommendations , Citizenship/Security Clearance Policy , Alignment of Cryptographic Algorithm Requirements with SP , Alignment of Cryptographic Algorithm Requirements with NIST Special Publication , Changes to FBCA CP to clarify the archive definition and how its records are intended to be used , 8.3 Assessor s Relationship to Assessed Entity October , 1.2 Document Identification

4 November February December January , Changes to FBCA CP to include a provision for a role-based signature certificate , Change to CA Key Usage Period for CAs issuing end user certificates and clarification of organizational responsibilities concerning device certificates , Change to the FBCA CP to remove the requirement for backing up the archive , Change to the FBCA CP to align key length requirements with SP , Remote Administration of Certification Authorities April , 8.1 and May June August October November December January , Certificate Policy Updates to Address PIV-I , Specify String Format for UUID in serialnumber RDN , Addition of the Real ID credential for States to use in meeting FPKI Identity Proofing requirements , Digitally Signed Declaration of Identity , Legacy use of SHA-1 during the transition period January 1, 2011 to December 31, , Clarify requirements to support CA Key Rollover , Protection of Subscriber Information , Specify requirement for Background Check Refresh

5 February , Clarify key generation location for PIV-I Key Management certificates February , Clarify CMS requirements

6 Table of Contents 1. INTRODUCTION OVERVIEW Certificate Policy (CP) Relationship between the FBCA CP & the FBCA CPS Relationship between the FBCA CP and the Entity CP Scope Interaction with PKIs External to the Federal Government DOCUMENT IDENTIFICATION PKI ENTITIES PKI Authorities Registration Authority (RA) Card Management System (CMS) Subscribers Affiliated Organizations Relying Parties Other Participants CERTIFICATE USAGE Appropriate Certificate Uses Prohibited Certificate Uses POLICY ADMINISTRATION Organization administering the document Contact Person Person Determining Certification Practices Statement Suitability for the Policy CPS Approval Procedures DEFINITIONS AND ACRONYMS Publication & Repository responsibilities REPOSITORIES... 12

7 2.1.1 FBCA Repository Obligations PUBLICATION OF CERTIFICATION INFORMATION Publication of Certificates and Certificate Status Publication of CA Information Interoperability FREQUENCY OF PUBLICATION ACCESS CONTROLS ON REPOSITORIES Identification & Authentication NAMING Types of Names Need for Names to Be Meaningful Anonymity or Pseudonymity of Subscribers Rules for Interpreting Various Name Forms Uniqueness of Names Recognition, Authentication, & Role of Trademarks INITIAL IDENTITY VALIDATION Method to Prove Possession of Private Key Authentication of Organization Identity Authentication of Individual Identity Non-verified Subscriber Information 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 APPLICATION Submission of Certificate Application Enrollment Process and Responsibilities... 23

8 4.2 CERTIFICATE APPLICATION PROCESSING Performing Identification and Authentication Functions Approval or Rejection of Certificate Applications Time to Process Certificate Applications ISSUANCE CA Actions during Certificate Issuance Notification to Subscriber of Certificate Issuance 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 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 MODIFICATION... 28

9 4.8.1 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 & 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 of CRLs On-line Revocation/Status Checking Availability On-line Revocation Checking Requirements Other Forms of Revocation Advertisements Available 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 & RECOVERY Key Escrow and Recovery Policy and Practices... 35

10 Session Key Encapsulation and Recovery Policy and Practices Facility Management & Operations Controls PHYSICAL CONTROLS Site Location & Construction Physical Access Power and Air Conditioning Water Exposures Fire Prevention & Protection Media Storage Waste Disposal Off-Site backup PROCEDURAL CONTROLS Trusted Roles Number of Persons Required per Task Identification and Authentication for Each Role Separation of Roles PERSONNEL CONTROLS Background, Qualifications, Experience, & Security Clearance Requirements Background Check Procedures Training Requirements Retraining Frequency & Requirements Job Rotation Frequency & 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 Logs Protection of Audit Logs Audit Log Backup Procedures... 51

11 5.4.6 Audit Collection System (internal vs. external) Notification to Event-Causing Subject Vulnerability Assessments RECORDS ARCHIVE 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 & Verify Archive Information KEY CHANGEOVER COMPROMISE & 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 & RA TERMINATION Technical Security Controls KEY PAIR GENERATION & INSTALLATION 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 & CRYPTOGRAPHIC MODULE ENGINEERING CONTROLS Cryptographic Module Standards & Controls Private Key Multi-Person Control... 64

12 6.2.3 Private Key Escrow Private Key Backup Private Key Archival Private Key Transfer into or from a Cryptographic Module Private Key Storage on Cryptographic Module Method of Activating Private Keys Methods of Deactivating Private Keys Method of Destroying Private Keys Cryptographic Module Rating OTHER ASPECTS OF KEY MANAGEMENT Public Key Archival Certificate Operational Periods/Key Usage Periods ACTIVATION DATA Activation Data Generation & Installation Activation Data Protection Other Aspects of Activation Data COMPUTER SECURITY CONTROLS Specific Computer Security Technical Requirements Computer Security Rating LIFE-CYCLE SECURITY CONTROLS System Development Controls Security Management Controls Life Cycle Security Ratings NETWORK SECURITY CONTROLS TIME STAMPING Certificate, CARL/CRL, And ocsp profiles Format CERTIFICATE PROFILE Version Numbers Certificate Extensions Algorithm Object Identifiers... 73

13 7.1.4 Name Forms Name Constraints Certificate Policy Object Identifier Usage of Policy Constraints Extension Policy Qualifiers Syntax & Semantics Processing Semantics for the Critical Certificate Policy Extension CRL PROFILE Version Numbers CRL Entry Extensions OCSP PROFILE Compliance Audit & Other Assessments FREQUENCY OF AUDIT OR ASSESSMENTS 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 & Legal Matters FEES Certificate Issuance/Renewal Fees Certificate Access Fees Revocation or Status Information Access Fee Fees for other Services Refund Policy FINANCIAL RESPONSIBILITY Insurance Coverage Other Assets Insurance/warranty Coverage for End-Entities CONFIDENTIALITY OF BUSINESS INFORMATION... 80

14 9.3.1 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/Administrative Process Other Information Disclosure Circumstances INTELLECTUAL PROPERTY RIGHTS REPRESENTATIONS & WARRANTIES CA Representations and Warranties RA Representations and Warranties Subscriber Representations and Warranties Relying Parties Representations and Warranties Representations and Warranties of Affiliated Organizations Representations and Warranties of other Participants DISCLAIMERS OF WARRANTIES LIMITATIONS OF LIABILITY INDEMNITIES TERM & TERMINATION Term Termination Effect of Termination and Survival INDIVIDUAL NOTICES & COMMUNICATIONS WITH PARTICIPANTS AMENDMENTS Procedure for Amendment Notification Mechanism and Period... 84

15 Circumstances under which OID must be changed DISPUTE RESOLUTION PROVISIONS GOVERNING LAW COMPLIANCE WITH APPLICABLE LAW MISCELLANEOUS PROVISIONS Entire agreement Assignment Severability Enforcement (Attorney Fees/Waiver of Rights) Force Majeure OTHER PROVISIONS BIBLIOGRAPHY ACRONYMS & ABBREVIATIONS GLOSSARY ACKNOWLEDGEMENTS Appendix A PIV-Interoperable Smart Card Definition Appendix B Card Management System Requirements

16 1. INTRODUCTION This Certificate Policy (CP) defines ten certificate policies for use by the Federal Bridge Certification Authority (FBCA) to facilitate interoperability between the FBCA and other Entity PKI domains. The policies represent six different assurance levels (Rudimentary, Basic, Medium, PIV-I Card Authentication, Medium Hardware, and High) for public key certificates. The level of assurance refers to the strength of the binding between the public key and the individual whose subject name is cited in the certificate, the mechanisms used to control the use of the private key, and the security provided by the PKI itself. The use of SHA-1 to create digital signatures is deprecated beginning January 1, However, there are some applications in use within the federal government that cannot process certificates or certificate revocation information signed using SHA-256. Therefore, a new parallel SHA-1 FPKI shall be created to facilitate the interoperability for those unable to transition to SHA-256 by January 1, Accordingly, this CP additionally defines two certificate policies for use by the SHA-1 Federal Root Certification Authority (SHA1 Federal Root CA) and allows mapping to additional SHA- 1 certificate policies defined in the X.509 U.S. Federal PKI Common Policy Framework Certificate Policy to facilitate interoperability between Federal agencies and other Entity PKI domains that require the use of SHA-1 after December 31, Use of certificates asserting certificate policy OIDs that identify the use of SHA-1 under this policy should be limited to applications for which the risks associated with the use of a deprecated cryptographic algorithm have been deemed acceptable and will only be asserted within the parallel SHA-1 FPKI. CAs that issue SHA-1 end entity certificates after December 31, 2010 may not also issue SHA-256 certificates. Personal Identity Verification Interoperable (PIV-I) policies for PIV-I Hardware, PIV-I Card Authentication, and PIV-I Content Signing are for use with PIV-I smart cards (see Appendix A for more information). The FBCA enables interoperability among Entity PKI domains in a peer-to-peer fashion. The FBCA issues certificates only to those CAs designated by the Entity operating that PKI (called Principal CAs ). The FBCA may also issue certificates to individuals who operate the FBCA. The FBCA certificates issued to Principal CAs act as a conduit of trust. Any use of or reference to this FBCA CP outside the purview of the Federal PKI Policy Authority is completely at the using party s risk. An Entity shall not assert the FBCA CP OIDs in any certificates the Entity CA issues, except in the policymappings extension establishing an equivalency between an FBCA OID and an OID in the Entity CA s CP. 1

17 This FBCA CP is consistent with the Internet Engineering Task Force (IETF) Public Key Infrastructure X.509 (IETF PKIX) RFC 3647, Certificate Policy and Certification Practices Framework. The terms and provisions of this FBCA CP shall be interpreted under and governed by applicable Federal law. 1.1 OVERVIEW Certificate Policy (CP) FBCA certificates 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. The OID corresponds to a specific level of assurance established by this Certificate Policy (CP) which shall be available to Relying Parties. Each certificate issued by the FBCA will assert the appropriate level of assurance in the certificatepolicies extension Relationship between the FBCA CP & the FBCA CPS The FBCA CP states what assurance can be placed in a certificate issued by the FBCA. The FBCA Certification Practices Statement (CPS) states how the FBCA establishes that assurance Relationship between the FBCA CP and the Entity CP The FPKI Policy Authority maps Entity CP(s) to one or more of the levels of assurance in the FBCA CP. The relationship between these CPs and the FBCA is asserted in CA certificates issued by the FBCA in the policymappings extension Scope The FBCA exists to facilitate trusted electronic business transactions for Federal organizations. To facilitate the missions of the organizations, interoperability is offered to non-federal entities. The generic term entity applies equally to Federal organizations and other organizations owning or operating PKI domains. As used in this CP, Entity PKI or Entity CA may refer to an organization s PKI, a PKI provided by a commercial service, or a bridge CA serving a community of interest Interaction with PKIs External to the Federal Government The FBCA will extend interoperability with non-federal entities only when it is beneficial to the Federal Government. 1.2 DOCUMENT IDENTIFICATION There are ten policies specified at six different levels of assurance in this Certificate Policy, which are defined in subsequent sections. Each level of assurance has an Object 2

18 Identifier (OID), to be asserted in certificates issued by the FBCA. Entity Principal CAs may assert these OIDs in policymappings extensions of certificates issued to the FBCA. The FBCA policy OIDs are registered in the NIST Computer Security Objects Registry as follows: Table 1 - FBCA Certificate Policies csor-certpolicy OBJECT IDENTIFIER ::= { } fbca-policies OBJECT IDENTIFIER ::= { csor-certpolicy 3 } id-fpki-certpcy-rudimentaryassurance ::= { fbca-policies 1 } id-fpki-certpcy-basicassurance ::= { fbca-policies 2 } id-fpki-certpcy-mediumassurance ::= { fbca-policies 3 } id-fpki-certpcy-mediumhardware ::= { fbca-policies 12 } id-fpki-certpcy-medium-cbp ::={ fbca-policies 14 } id-fpki-certpcy-mediumhw-cbp ::={ fbca-policies 15 } id-fpki-certpcy-highassurance ::= { fbca-policies 4 } id-fpki-certpcy-pivi-hardware ::= { fbca-policies 18 } id-fpki-certpcy-pivi-cardauth ::= { fbca-policies 19 } id-fpki-certpcy-pivi-contentsigning ::= { fbca-policies 20 } In addition, there are two certificate policies specified at two different levels of assurance associated with the SHA-1 Federal Root CA. Each level of assurance has an OID to be asserted in certificates issued by the SHA-1 Federal Root CA. Entity Principal CAs may assert these OIDs in policymappings extensions of certificates issued to the SHA-1 Federal Root CA. The id-fpki-sha1 policy OIDs are registered in the NIST Computer Security Objects Registry as follows: Table 1 - Certificate Policy OIDs Identifying the Use of SHA-1 id-fpki-sha1-medium-cbp ::= { fbca-policies 21 } id-fpki-sha1-mediumhw-cbp ::= { fbca-policies 22 } 3

19 The High Assurance policy is reserved for U.S. Federal government entity PKI operation and use. The requirements associated with the medium-cbp (commercial best practice) policy are identical to those defined for the Medium Assurance policy with the exception of personnel security requirements (see Section 5.3.1). The requirements associated with the Medium Hardware policy are identical to those defined for the Medium Assurance policy with the exception of subscriber cryptographic module requirements (see Section 6.2.1). The requirements associated with the mediumhw-cbp policy are identical to those defined for the Medium Hardware Assurance policy with the exception of personnel security requirements (see Section 5.3.1). The requirements associated with PIV-I Hardware and PIV-I Content Signing are identical to Medium Hardware except where specifically noted in the text and further described in Appendix A. In addition, the PIV-I Content Signing policy is reserved for certificates used by the Card Management System (CMS) to sign the PIV-I card security objects. The requirements associated with id-fpki-sha1-medium-cbp (commercial best practice) policy are identical to those defined for the FBCA medium-cbp policy, except that the certificates asserting id-fpki-sha1-medium-cbp are signed with SHA-1, and the issuing CAs can use SHA-1 for generation of PKI objects such as CRLs and OCSP responses until December 31, The requirements associated with id-fpki-sha1-mediumhw-cbp (commercial best practice) policy are identical to those defined for the FBCA mediumhw-cbp policy, except that the certificates asserting id-fpki-sha1-mediumhw-cbp are signed with SHA-1, and the issuing CAs can use SHA-1 for generation of PKI objects such as CRLs and OCSP responses until December 31, The SHA-1 Federal Root CA also includes the following policy OIDs defined in the X.509 U.S. Federal PKI Common Policy Framework and compatible with the FBCA as follows: 4

20 Table 3 - id-fpki-sha1 Policy OIDs SHA1 Policy OID Corresponding id-fpki-common policy id-fpki-sha1-policy ::= { fbca-policies 23 } id-fpki-common-policy id-fpki-certpcy-mediumassurance id-fpki-sha1-hardware ::= { fbca-policies 24 } id-fpki-common-hardware id-fpki-certpcy-mediumhardware id-fpki-sha1-devices ::= { fbca-policies 25 } id-fpki-common-devices id-fpki-certpcy-mediumassurance id-fpki-sha1-authentication ::= { fbca-policies 26 } id-fpki-common-authentication id-fpki-certpcy-mediumhardware id-fpki-sha1-cardauth ::= { fbca-policies 27} id-fpki-common-cardauth 1.3 PKI ENTITIES The following are roles relevant to the administration and operation of the FBCA PKI Authorities Federal Chief Information Officers Council The Federal CIO Council comprises the Chief Information Officers of all cabinet level departments and other independent agencies. The Federal CIO Council has established the framework for the interoperable FPKI and oversees the operation of the organizations responsible for governing and promoting its use. In particular, this CP was established under the authority of and with the approval of the Federal CIO Council Federal PKI Policy Authority (FPKIPA) The Federal PKI Policy Authority (FPKIPA) is a group of U.S. Federal Government Agencies (including cabinet-level Departments) chartered by the Federal CIO Council. The FPKIPA owns this policy and represents the interest of the Federal CIOs. The FPKIPA is responsible for: The FBCA CP, The FBCA CPS, Accepting applications from Entities desiring to interoperate using the FBCA, 5

21 Determining the mappings between certificates issued by applicant Entity CAs and the levels of assurance set forth in the FBCA CP (which will include objective and subjective evaluation of the respective CP contents and any other facts deemed relevant by the FPKIPA), and After an Entity is authorized to interoperate using the FBCA, ensuring continued conformance of that Entity with applicable requirements as a condition for allowing continued interoperability using the FBCA. The FPKIPA will execute a Memorandum of Agreement (MOA) with each crosscertified Entity setting forth the respective responsibilities and obligations of both parties and the mappings between the certificate levels of assurance contained in this CP and those in the Entity CP. (When the entity belongs to a sovereign nation, the United States Department of State may execute the MOA or delegate the authority to execute the MOA on its behalf.) FPKI Management Authority (FPKI MA) The FPKI Management Authority is the organization that operates and maintains the FBCA and the SHA1 Federal Root CA on behalf of the U.S. Government, subject to the direction of the FPKIPA. All of the requirements for the SHA1 Federal Root CA are identical to the FBCA except that the SHA1 Federal Root CA and entity CAs cross certified with the SHA1 Federal Root CA use SHA-1 for generation of PKI objects such as certificates, Certificate Revocation Lists (CRLs) and Online Certificate Status Protocol (OCSP) responses after December 31, 2010 and before December 31, FPKI Management Authority Program Manager The Program Manager is the individual within the FPKI Management Authority who has principal responsibility for overseeing the proper operation of the FBCA including the FBCA repository, and selecting the FPKI Management Authority Staff. The Program Manager is selected by the FPKI Management Authority and reports to the FPKIPA. The FPKI Management Authority Program Manager must hold a Top Secret security clearance Entity Principal Certification Authority (CA) The Principal CA is a CA within a PKI that has been designated to cross-certify directly with the FBCA (e.g., through the exchange of cross-certificates). The Principal CA issues either end-entity certificates, or CA certificates to other Entity or external party CAs, or both. Where the Entity operates a hierarchical PKI, the Principal CA is typically the Entity Root CA. Where the Entity operates a mesh PKI, the Principal CA may be any CA designated by the Entity for cross-certification with the FBCA. It should be noted that an Entity may request that the FBCA cross-certify with more than one CA within the Entity; that is, an Entity may have more than one Principal CA. Additionally, this CP may refer to CAs that are subordinate to the Principal CA. The use of the term subordinate CA shall encompass any CA under the control of the Entity 6

22 that has a certificate issued to it by the Entity Principal CA or any CA subordinate to the Principal CA, whether or not the Entity employs a hierarchical or other PKI architecture Federal Bridge Certification Authority (FBCA) The FBCA is the entity operated by the FPKI Management Authority that is authorized by the Federal PKI Policy Authority to create, sign, and issue public key certificates to Principal CAs. As operated by the FPKI Management Authority, the FBCA is responsible for all aspects of the issuance and management of a certificate including: Control over the registration process, The identification and authentication process, The certificate manufacturing process, Publication of certificates, Revocation of certificates, Re-key of FBCA signing material, and Ensuring that all aspects of the FBCA services and FBCA operations and infrastructure related to certificates issued under this CP are performed in accordance with the requirements, representations, and warranties of this CP Certificate Status Servers PKIs may optionally include an authority that provides status information about certificates on behalf of a CA through online transactions. In particular, PKIs may include OCSP responders to provide online 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. Entity CAs that issue PIV-I certificates must provide an OCSP responder Registration Authority (RA) The RA collects and verifies each Subscriber s identity and information for inclusion in the Subscriber s public key certificate. The FPKI Management Authority acts as the RA for the FBCA, and performs its function in accordance with a CPS approved by the Federal PKI Policy Authority. Entity CAs designate their own RAs. The requirements for RAs in the FBCA and Entity PKIs are set forth elsewhere in this document Card Management System (CMS) The Card Management System is responsible for managing smart card token content. In the context of this policy, the CMS requirements are associated with the PIV-I policies 7