![](media/image1.jpeg){width="3.0in" height="3.0in"}X.509 Certificate
Policy

For The

Federal Bridge Certification Authority (FBCA)

Version 2.12

February 11, 2009

**Signature Page**

\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Chair, Federal Public Key Infrastructure Policy Authority DATE

**Revision History**

+-------------------+---------------+----------------------------------+
| **Document        | **Document    | **Revision Details**             |
| Version**         | Date**        |                                  |
+-------------------+---------------+----------------------------------+
| 2.1               | 12 January    | This FBCA CP updates and         |
|                   | 2006          | replaces Version 2.0, dated 13   |
|                   |               | September 2005.                  |
|                   |               |                                  |
|                   |               | Text changes are specified in    |
|                   |               | the following FBCA CP Change     |
|                   |               | Proposals (**change proposal     |
|                   |               | number**, title, date):          |
|                   |               |                                  |
|                   |               | **2005-03**, Changes to the FBCA |
|                   |               | CP to modify audit cycle for     |
|                   |               | consistency with Government      |
|                   |               | certification and accreditation  |
|                   |               | process,\                        |
|                   |               | 13 December 2005                 |
+-------------------+---------------+----------------------------------+
| 2.2               | 28 September  | This FBCA CP updates and         |
|                   | 2006          | replaces Version 2.1, dated 12   |
|                   |               | January 2006.                    |
|                   |               |                                  |
|                   |               | **2006-02**, Omnibus Policy      |
|                   |               | Issues Raised During the         |
|                   |               | CertiPath Mapping and e-Auth     |
|                   |               | Business Rules Review,\          |
|                   |               | 7 September 2006                 |
+-------------------+---------------+----------------------------------+
| 2.3               | 14 March 2007 | This FBCA CP updates and         |
|                   |               | replaces Version 2.2, dated 28   |
|                   |               | September 2006.                  |
|                   |               |                                  |
|                   |               | **2007-01**, Harmonization       |
|                   |               | between Federal Bridge and       |
|                   |               | Common Policy Framework,\        |
|                   |               | 9 March 2007                     |
+-------------------+---------------+----------------------------------+
| 2.4               | 13 June 2007  | This FBCA CP updates and         |
|                   |               | replaces Version 2.3, dated 14   |
|                   |               | March 2007.                      |
|                   |               |                                  |
|                   |               | **2007-02**, Clarification on    |
|                   |               | multiparty physical access       |
|                   |               | control in Physical Access for   |
|                   |               | CA Equipment, 3 May 2007         |
+-------------------+---------------+----------------------------------+
| 2.5               | 12 July 2007  | This FBCA CP updates and         |
|                   |               | replaces Version 2.4, dated 13   |
|                   |               | June 2007.                       |
|                   |               |                                  |
|                   |               | **2007-03**, SAFE Harmonization  |
|                   |               | Policy Change Recommendations,   |
|                   |               | 10 May 2007                      |
+-------------------+---------------+----------------------------------+
| 2.6               | 16 August     | This FBCA CP updates and         |
|                   | 2007          | replaces Version 2.5, dated 12   |
|                   |               | July 2007.                       |
|                   |               |                                  |
|                   |               | **2007-04**,                     |
|                   |               | Citizenship/Security Clearance   |
|                   |               | Policy, 17 July 2007             |
+-------------------+---------------+----------------------------------+
| 2.7               | 26 September  | This FBCA CP updates and         |
|                   | 2007          | replaces Version 2.6, dated 16   |
|                   |               | August 2007.                     |
|                   |               |                                  |
|                   |               | **2007-05**, Alignment of        |
|                   |               | Cryptographic Algorithm          |
|                   |               | Requirements with SP 800-78-1,   |
|                   |               | 17 July 2007                     |
+-------------------+---------------+----------------------------------+
| 2.8               | 15 February   | This FBCA CP updates and         |
|                   | 2008          | replaces Version 2.7, dated 26   |
|                   |               | September 2007.                  |
|                   |               |                                  |
|                   |               | **2008-01**, Alignment of        |
|                   |               | Cryptographic Algorithm          |
|                   |               | Requirements with NIST Special   |
|                   |               | Publication 800-57, 11 January   |
|                   |               | 2008                             |
+-------------------+---------------+----------------------------------+
| 2.9               | 13 August     | This FBCA CP updates and         |
|                   | 2008          | replaces Version 2.8, dated 15   |
|                   |               | February 2008.                   |
|                   |               |                                  |
|                   |               | **2008-02**, Changes to FBCA CP  |
|                   |               | to clarify the archive           |
|                   |               | definition and how its records   |
|                   |               | are intended to be used, 24 June |
|                   |               | 2008                             |
|                   |               |                                  |
|                   |               | **2008-03**, § 8.3 Assessor's    |
|                   |               | Relationship to Assessed Entity, |
|                   |               | 3 April 2008                     |
+-------------------+---------------+----------------------------------+
| 2.10              | 16 October    | This FBCA CP updates and         |
|                   | 2008          | replaces Version 2.9, dated 13   |
|                   |               | August 2008.                     |
|                   |               |                                  |
|                   |               | **2008-04**, § 1.2 Document      |
|                   |               | Identification,\                 |
|                   |               | 14 October 2008                  |
+-------------------+---------------+----------------------------------+
| 2.11              | 20 November   | This FBCA CP updates and         |
|                   | 2008          | replaces Version 2.10, dated 16  |
|                   |               | October 2008.                    |
|                   |               |                                  |
|                   |               | **2008-05,** Changes to FBCA CP  |
|                   |               | to include a provision for a     |
|                   |               | role-based signature             |
|                   |               | certificate, 26 August 2008      |
|                   |               |                                  |
|                   |               | **2008-06,** Change to CA Key    |
|                   |               | Usage Period for CAs issuing end |
|                   |               | user certificates and            |
|                   |               | clarification of organizational  |
|                   |               | responsibilities concerning      |
|                   |               | device certificates, 15 July     |
|                   |               | 2008                             |
+-------------------+---------------+----------------------------------+
| 2.12              | 11 February   | This FBCA CP updates and         |
|                   | 2009          | replaces Version 2.11, dated 20  |
|                   |               | November 2008.                   |
|                   |               |                                  |
|                   |               | **2009-01,** Change to the FBCA  |
|                   |               | CP to remove the requirement for |
|                   |               | backing up the archive, 8        |
|                   |               | January 2009                     |
+-------------------+---------------+----------------------------------+

Table of Contents

1\. INTRODUCTION [1](#introduction)

1.1 Overview [1](#overview)

1.1.1 Certificate Policy (CP) [1](#certificate-policy-cp)

1.1.2 Relationship between the FBCA CP & the FBCA CPS
[1](#relationship-between-the-fbca-cp-the-fbca-cps)

1.1.3 Relationship between the FBCA CP and the Entity CP
[2](#relationship-between-the-fbca-cp-and-the-entity-cp)

1.1.4 Scope [2](#scope)

1.1.5 Interaction with PKIs External to the Federal Government
[2](#interaction-with-pkis-external-to-the-federal-government)

1.2 Document Identification [2](#document-identification)

1.3 PKI Entities [3](#pki-entities)

1.3.1 PKI Authorities [3](#pki-authorities)

1.3.2 Registration Authority (RA) [5](#registration-authority-ra)

1.3.3 Subscribers [5](#subscribers)

1.3.4 Relying Parties [5](#relying-parties)

1.3.5 Other Participants [6](#other-participants)

1.4 Certificate Usage [6](#certificate-usage)

1.4.1 Appropriate Certificate Uses [6](#appropriate-certificate-uses)

1.4.2 Prohibited Certificate Uses [7](#prohibited-certificate-uses)

1.5 Policy Administration [7](#policy-administration)

1.5.1 Organization administering the document
[7](#organization-administering-the-document)

1.5.2 Contact Person [7](#contact-person)

1.5.3 Person Determining Certification Practices Statement Suitability
for the Policy
[7](#person-determining-certification-practices-statement-suitability-for-the-policy)

1.5.4 CPS Approval Procedures [8](#cps-approval-procedures)

1.6 Definitions and acronyms [8](#definitions-and-acronyms)

2\. Publication & Repository responsibilitIes
[9](#publication-repository-responsibilities)

2.1 repositories [9](#repositories)

2.1.1 FBCA Repository Obligations [9](#fbca-repository-obligations)

2.2 PUBLICATION of certification information
[9](#publication-of-certification-information)

2.2.1 Publication of Certificates and Certificate Status
[9](#publication-of-certificates-and-certificate-status)

2.2.2 Publication of CA Information [10](#publication-of-ca-information)

2.2.3 Interoperability [10](#interoperability)

2.3 Frequency of Publication [10](#frequency-of-publication)

2.4 access controls on repositories
[10](#access-controls-on-repositories)

3\. Identification & Authentication [11](#identification-authentication)

3.1 Naming [11](#naming)

3.1.1 Types of Names [11](#types-of-names)

3.1.2 Need for Names to Be Meaningful
[11](#need-for-names-to-be-meaningful)

3.1.3 Anonymity or Pseudonymity of Subscribers
[12](#anonymity-or-pseudonymity-of-subscribers)

3.1.4 Rules for Interpreting Various Name Forms
[12](#rules-for-interpreting-various-name-forms)

3.1.5 Uniqueness of Names [12](#uniqueness-of-names)

3.1.6 Recognition, Authentication, & Role of Trademarks
[12](#recognition-authentication-role-of-trademarks)

3.2 INITIAL Identity Validation [12](#initial-identity-validation)

3.2.1 Method to Prove Possession of Private Key
[12](#method-to-prove-possession-of-private-key)

3.2.2 Authentication of Organization Identity
[13](#authentication-of-organization-identity)

3.2.3 Authentication of Individual Identity
[13](#authentication-of-individual-identity)

3.2.4 Non-verified Subscriber Information
[17](#non-verified-subscriber-information)

3.2.5 Validation of Authority [17](#validation-of-authority)

3.2.6 Criteria for Interoperation [17](#criteria-for-interoperation)

3.3 Identification and authentication for re-key requests
[17](#identification-and-authentication-for-re-key-requests)

3.3.1 Identification and Authentication for Routine Re-key
[17](#identification-and-authentication-for-routine-re-key)

3.3.2 Identification and Authentication for Re-key after Revocation
[18](#identification-and-authentication-for-re-key-after-revocation)

3.4 Identification and authentication for revocation request
[18](#identification-and-authentication-for-revocation-request)

4\. Certificate Life-Cycle [19](#certificate-life-cycle)

4.1 Application [19](#application)

4.1.1 Submission of Certificate Application
[19](#submission-of-certificate-application)

4.1.2 Enrollment Process and Responsibilities
[19](#enrollment-process-and-responsibilities)

4.2 Certificate Application Processing
[19](#certificate-application-processing)

4.2.1 Performing Identification and Authentication Functions
[19](#performing-identification-and-authentication-functions)

4.2.2 Approval or Rejection of Certificate Applications
[20](#approval-or-rejection-of-certificate-applications)

4.2.3 Time to Process Certificate Applications
[20](#time-to-process-certificate-applications)

4.3 Issuance [20](#issuance)

4.3.1 CA Actions during Certificate Issuance
[20](#ca-actions-during-certificate-issuance)

4.3.2 Notification to Subscriber of Certificate Issuance
[20](#notification-to-subscriber-of-certificate-issuance)

4.4 CERTIFICATE Acceptance [20](#certificate-acceptance)

4.4.1 Conduct constituting certificate acceptance
[20](#conduct-constituting-certificate-acceptance)

4.4.2 Publication of the Certificate by the CA
[21](#publication-of-the-certificate-by-the-ca)

4.4.3 Notification of Certificate Issuance by the CA to other entities
[21](#notification-of-certificate-issuance-by-the-ca-to-other-entities)

4.5 key pair and certificate Usage [21](#key-pair-and-certificate-usage)

4.5.1 Subscriber Private Key and Certificate Usage
[21](#subscriber-private-key-and-certificate-usage)

4.5.2 Relying Party Public key and Certificate Usage
[21](#relying-party-public-key-and-certificate-usage)

4.6 Certificate Renewal [21](#certificate-renewal)

4.6.1 Circumstance for Certificate Renewal
[22](#circumstance-for-certificate-renewal)

4.6.2 Who may request Renewal [22](#who-may-request-renewal)

4.6.3 Processing Certificate Renewal Requests
[22](#processing-certificate-renewal-requests)

4.6.4 Notification of new certificate issuance to Subscriber
[22](#notification-of-new-certificate-issuance-to-subscriber)

4.6.5 Conduct constituting acceptance of a Renewal certificate
[22](#conduct-constituting-acceptance-of-a-renewal-certificate)

4.6.6 Publication of the Renewal certificate by the CA
[22](#publication-of-the-renewal-certificate-by-the-ca)

4.6.7 Notification of Certificate Issuance by the CA to other entities
[22](#notification-of-certificate-issuance-by-the-ca-to-other-entities-1)

4.7 Certificate Re-Key [23](#certificate-re-key)

4.7.1 Circumstance for Certificate Re-key
[23](#circumstance-for-certificate-re-key)

4.7.2 Who may request certification of a new public key
[23](#who-may-request-certification-of-a-new-public-key)

4.7.3 Processing certificate Re-keying requests
[23](#processing-certificate-re-keying-requests)

4.7.4 Notification of new certificate issuance to Subscriber
[23](#notification-of-new-certificate-issuance-to-subscriber-1)

4.7.5 Conduct constituting acceptance of a Re-keyed certificate
[24](#conduct-constituting-acceptance-of-a-re-keyed-certificate)

4.7.6 Publication of the Re-keyed certificate by the CA
[24](#publication-of-the-re-keyed-certificate-by-the-ca)

4.7.7 Notification of certificate issuance by the CA to other Entities
[24](#notification-of-certificate-issuance-by-the-ca-to-other-entities-2)

4.8 Modification [24](#modification)

4.8.1 Circumstance for Certificate Modification
[24](#circumstance-for-certificate-modification)

4.8.2 Who may request Certificate Modification
[24](#who-may-request-certificate-modification)

4.8.3 Processing Certificate Modification Requests
[24](#processing-certificate-modification-requests)

4.8.4 Notification of new certificate issuance to Subscriber
[25](#notification-of-new-certificate-issuance-to-subscriber-2)

4.8.5 Conduct constituting acceptance of modified certificate
[25](#conduct-constituting-acceptance-of-modified-certificate)

4.8.6 Publication of the modified certificate by the CA
[25](#publication-of-the-modified-certificate-by-the-ca)

4.8.7 Notification of certificate issuance by the CA to other Entities
[25](#notification-of-certificate-issuance-by-the-ca-to-other-entities-3)

4.9 Certificate Revocation & Suspension
[25](#certificate-revocation-suspension)

4.9.1 Circumstances for Revocation [25](#circumstances-for-revocation)

4.9.2 Who Can Request Revocation [26](#who-can-request-revocation)

4.9.3 Procedure for Revocation Request
[26](#procedure-for-revocation-request)

4.9.4 Revocation Request Grace Period
[27](#revocation-request-grace-period)

4.9.5 Time within which CA must Process the Revocation Request
[27](#time-within-which-ca-must-process-the-revocation-request)

4.9.6 Revocation Checking Requirements for Relying Parties
[27](#revocation-checking-requirements-for-relying-parties)

4.9.7 CRL Issuance Frequency [28](#crl-issuance-frequency)

4.9.8 Maximum Latency of CRLs [28](#maximum-latency-of-crls)

4.9.9 On-line Revocation/Status Checking Availability
[29](#on-line-revocationstatus-checking-availability)

4.9.10 On-line Revocation Checking Requirements
[29](#on-line-revocation-checking-requirements)

4.9.11 Other Forms of Revocation Advertisements Available
[29](#other-forms-of-revocation-advertisements-available)

4.9.12 Special Requirements Related To Key Compromise
[29](#special-requirements-related-to-key-compromise)

4.9.13 Circumstances for Suspension [29](#circumstances-for-suspension)

4.9.14 Who can Request Suspension [30](#who-can-request-suspension)

4.9.15 Procedure for Suspension Request
[30](#procedure-for-suspension-request)

4.9.16 Limits on Suspension Period [30](#limits-on-suspension-period)

4.10 Certificate Status Services [30](#certificate-status-services)

4.10.1 Operational Characteristics [30](#operational-characteristics)

4.10.2 Service Availability [30](#service-availability)

4.10.3 Optional Features [30](#optional-features)

4.11 End Of Subscription [30](#end-of-subscription)

4.12 Key Escrow & Recovery [30](#key-escrow-recovery)

4.12.1 Key Escrow and Recovery Policy and Practices
[30](#key-escrow-and-recovery-policy-and-practices)

4.12.2 Session Key Encapsulation and Recovery Policy and Practices
[31](#session-key-encapsulation-and-recovery-policy-and-practices)

5\. Facility Management & Operations Controls
[32](#facility-management-operations-controls)

5.1 Physical Controls [32](#physical-controls)

5.1.1 Site Location & Construction [32](#site-location-construction)

5.1.2 Physical Access [32](#physical-access)

5.1.3 Power and Air Conditioning [34](#power-and-air-conditioning)

5.1.4 Water Exposures [34](#water-exposures)

5.1.5 Fire Prevention & Protection [34](#fire-prevention-protection)

5.1.6 Media Storage [34](#media-storage)

5.1.7 Waste Disposal [34](#waste-disposal)

5.1.8 Off-Site backup [34](#off-site-backup)

5.2 Procedural Controls [34](#procedural-controls)

5.2.1 Trusted Roles [35](#trusted-roles)

5.2.2 Number of Persons Required per Task
[36](#number-of-persons-required-per-task)

5.2.3 Identification and Authentication for Each Role
[36](#identification-and-authentication-for-each-role)

5.2.4 Separation of Roles [36](#separation-of-roles)

5.3 Personnel Controls [37](#personnel-controls)

5.3.1 Background, Qualifications, Experience, & Security Clearance
Requirements
[37](#background-qualifications-experience-security-clearance-requirements)

5.3.2 Background Check Procedures [38](#background-check-procedures)

5.3.3 Training Requirements [39](#training-requirements)

5.3.4 Retraining Frequency & Requirements
[39](#retraining-frequency-requirements)

5.3.5 Job Rotation Frequency & Sequence
[39](#job-rotation-frequency-sequence)

5.3.6 Sanctions for Unauthorized Actions
[39](#sanctions-for-unauthorized-actions)

5.3.7 Independent Contractor Requirements
[40](#independent-contractor-requirements)

5.3.8 Documentation Supplied To Personnel
[40](#documentation-supplied-to-personnel)

5.4 Audit Logging Procedures [40](#audit-logging-procedures)

5.4.1 Types of Events Recorded [40](#types-of-events-recorded)

5.4.2 Frequency of Processing Log [45](#frequency-of-processing-log)

5.4.3 Retention Period for Audit Logs
[46](#retention-period-for-audit-logs)

5.4.4 Protection of Audit Logs [46](#protection-of-audit-logs)

5.4.5 Audit Log Backup Procedures [46](#audit-log-backup-procedures)

5.4.6 Audit Collection System (internal vs. external)
[46](#audit-collection-system-internal-vs.-external)

5.4.7 Notification to Event-Causing Subject
[46](#notification-to-event-causing-subject)

5.4.8 Vulnerability Assessments [47](#vulnerability-assessments)

5.5 Records Archive [47](#records-archive)

5.5.1 Types of Events Archived [47](#types-of-events-archived)

5.5.2 Retention Period for Archive [49](#retention-period-for-archive)

5.5.3 Protection of Archive [49](#protection-of-archive)

5.5.4 Archive Backup Procedures [50](#archive-backup-procedures)

5.5.5 Requirements for Time-Stamping of Records
[50](#requirements-for-time-stamping-of-records)

5.5.6 Archive Collection System (internal or external)
[50](#archive-collection-system-internal-or-external)

5.5.7 Procedures to Obtain & Verify Archive Information
[50](#procedures-to-obtain-verify-archive-information)

5.6 Key Changeover [50](#key-changeover)

5.7 Compromise & Disaster Recovery [51](#compromise-disaster-recovery)

5.7.1 Incident and Compromise Handling Procedures
[51](#incident-and-compromise-handling-procedures)

5.7.2 Computing Resources, Software, and/Or Data Are Corrupted
[51](#computing-resources-software-andor-data-are-corrupted)

5.7.3 Entity (CA) Private Key Compromise Procedures
[51](#entity-ca-private-key-compromise-procedures)

5.7.4 Business Continuity Capabilities after a Disaster
[52](#business-continuity-capabilities-after-a-disaster)

5.8 CA & RA Termination [52](#ca-ra-termination)

6\. Technical Security Controls [53](#technical-security-controls)

6.1 Key Pair Generation & Installation
[53](#key-pair-generation-installation)

6.1.1 Key Pair Generation [53](#key-pair-generation)

6.1.2 Private Key Delivery to Subscriber
[54](#private-key-delivery-to-subscriber)

6.1.3 Public Key Delivery to Certificate Issuer
[54](#public-key-delivery-to-certificate-issuer)

6.1.4 CA Public Key Delivery to Relying Parties
[54](#ca-public-key-delivery-to-relying-parties)

6.1.5 Key Sizes [55](#key-sizes)

6.1.6 Public Key Parameters Generation and Quality Checking
[56](#public-key-parameters-generation-and-quality-checking)

6.1.7 Key Usage Purposes (as per X.509 v3 key usage field)
[57](#key-usage-purposes-as-per-x.509-v3-key-usage-field)

6.2 Private Key Protection & CryptoGraphic Module Engineering Controls
[57](#private-key-protection-cryptographic-module-engineering-controls)

6.2.1 Cryptographic Module Standards & Controls
[57](#cryptographic-module-standards-controls)

6.2.2 Private Key Multi-Person Control
[58](#private-key-multi-person-control)

6.2.3 Private Key Escrow [58](#private-key-escrow)

6.2.4 Private Key Backup [59](#private-key-backup)

6.2.5 Private Key Archival [59](#private-key-archival)

6.2.6 Private Key Transfer into or from a Cryptographic Module
[59](#private-key-transfer-into-or-from-a-cryptographic-module)

6.2.7 Private Key Storage on Cryptographic Module
[60](#private-key-storage-on-cryptographic-module)

6.2.8 Method of Activating Private Keys
[60](#method-of-activating-private-keys)

6.2.9 Methods of Deactivating Private Keys
[60](#methods-of-deactivating-private-keys)

6.2.10 Method of Destroying Private Keys
[60](#method-of-destroying-private-keys)

6.2.11 Cryptographic Module Rating [60](#cryptographic-module-rating)

6.3 Other Aspects Of Key Management
[61](#other-aspects-of-key-management)

6.3.1 Public Key Archival [61](#public-key-archival)

6.3.2 Certificate Operational Periods/Key Usage Periods
[61](#certificate-operational-periodskey-usage-periods)

6.4 Activation Data [62](#activation-data)

6.4.1 Activation Data Generation & Installation
[62](#activation-data-generation-installation)

6.4.2 Activation Data Protection [62](#activation-data-protection)

6.4.3 Other Aspects of Activation Data
[62](#other-aspects-of-activation-data)

6.5 Computer Security Controls [62](#computer-security-controls)

6.5.1 Specific Computer Security Technical Requirements
[62](#specific-computer-security-technical-requirements)

6.5.2 Computer Security Rating [63](#computer-security-rating)

6.6 Life-Cycle Security Controls [63](#life-cycle-security-controls)

6.6.1 System Development Controls [63](#system-development-controls)

6.6.2 Security Management Controls [64](#security-management-controls)

6.6.3 Life Cycle Security Ratings [64](#life-cycle-security-ratings)

6.7 Network Security Controls [64](#network-security-controls)

6.8 Time Stamping [65](#time-stamping)

7\. Certificate, CARL/CRL, And ocsp profiles Format
[66](#certificate-carlcrl-and-ocsp-profiles-format)

7.1 Certificate Profile [66](#certificate-profile)

7.1.1 Version Numbers [66](#version-numbers)

7.1.2 Certificate Extensions [66](#certificate-extensions)

7.1.3 Algorithm Object Identifiers [66](#algorithm-object-identifiers)

7.1.4 Name Forms [68](#name-forms)

7.1.5 Name Constraints [68](#name-constraints)

7.1.6 Certificate Policy Object Identifier
[68](#certificate-policy-object-identifier)

7.1.7 Usage of Policy Constraints Extension
[69](#usage-of-policy-constraints-extension)

7.1.8 Policy Qualifiers Syntax & Semantics
[69](#policy-qualifiers-syntax-semantics)

7.1.9 Processing Semantics for the Critical Certificate Policy Extension
[69](#processing-semantics-for-the-critical-certificate-policy-extension)

7.2 CRL Profile [69](#crl-profile)

7.2.1 Version Numbers [69](#version-numbers-1)

7.2.2 CRL Entry Extensions [69](#crl-entry-extensions)

7.3 OCSP Profile [69](#ocsp-profile)

8\. Compliance Audit & Other Assessments
[70](#compliance-audit-other-assessments)

8.1 Frequency Of Audit Or Assessments
[70](#frequency-of-audit-or-assessments)

8.2 Identity & Qualifications Of Assessor
[71](#identity-qualifications-of-assessor)

8.3 Assessor's Relationship To Assessed Entity
[71](#assessors-relationship-to-assessed-entity)

8.4 Topics Covered By Assessment [71](#topics-covered-by-assessment)

8.5 Actions Taken As A Result Of Deficiency
[72](#actions-taken-as-a-result-of-deficiency)

8.6 Communication Of Results [73](#communication-of-results)

9\. Other Business & Legal Matters [74](#other-business-legal-matters)

9.1 Fees [74](#fees)

9.1.1 Certificate Issuance/Renewal Fees
[74](#certificate-issuancerenewal-fees)

9.1.2 Certificate Access Fees [74](#certificate-access-fees)

9.1.3 Revocation or Status Information Access Fee
[74](#revocation-or-status-information-access-fee)

9.1.4 Fees for other Services [74](#fees-for-other-services)

9.1.5 Refund Policy [74](#refund-policy)

9.2 Financial Responsibility [74](#financial-responsibility)

9.2.1 Insurance Coverage [74](#insurance-coverage)

9.2.2 Other Assets [74](#other-assets)

9.2.3 Insurance/warranty Coverage for End-Entities
[74](#insurancewarranty-coverage-for-end-entities)

9.3 Confidentiality Of Business Information
[74](#confidentiality-of-business-information)

9.3.1 Scope of Confidential Information
[75](#scope-of-confidential-information)

9.3.2 Information not within the scope of Confidential Information
[75](#information-not-within-the-scope-of-confidential-information)

9.3.3 Responsibility to Protect Confidential Information
[75](#responsibility-to-protect-confidential-information)

9.4 Privacy Of Personal Information
[75](#privacy-of-personal-information)

9.4.1 Privacy Plan [75](#privacy-plan)

9.4.2 Information treated as Private
[75](#information-treated-as-private)

9.4.3 Information not deemed Private
[75](#information-not-deemed-private)

9.4.4 Responsibility to Protect Private Information
[75](#responsibility-to-protect-private-information)

9.4.5 Notice and Consent to use Private Information
[75](#notice-and-consent-to-use-private-information)

9.4.6 Disclosure Pursuant to Judicial/Administrative Process
[76](#disclosure-pursuant-to-judicialadministrative-process)

9.4.7 Other Information Disclosure Circumstances
[76](#other-information-disclosure-circumstances)

9.5 Intellectual Property Rights [76](#intellectual-property-rights)

9.6 Representations & Warranties [76](#representations-warranties)

9.6.1 CA Representations and Warranties
[76](#ca-representations-and-warranties)

9.6.2 RA Representations and Warranties
[76](#ra-representations-and-warranties)

9.6.3 Subscriber Representations and Warranties
[77](#subscriber-representations-and-warranties)

9.6.4 Relying Parties Representations and Warranties
[77](#relying-parties-representations-and-warranties)

9.6.5 Representations and Warranties of other Participants
[77](#representations-and-warranties-of-other-participants)

9.7 Disclaimers Of Warranties [77](#disclaimers-of-warranties)

9.8 Limitations of Liability [77](#limitations-of-liability)

9.9 Indemnities [77](#indemnities)

9.10 Term & Termination [78](#term-termination)

9.10.1 Term [78](#term)

9.10.2 Termination [78](#termination)

9.10.3 Effect of Termination and Survival
[78](#effect-of-termination-and-survival)

9.11 Individual Notices & Communications With participants
[78](#individual-notices-communications-with-participants)

9.12 Amendments [78](#amendments)

9.12.1 Procedure for Amendment [78](#procedure-for-amendment)

9.12.2 Notification Mechanism and Period
[78](#notification-mechanism-and-period)

9.12.3 Circumstances under which OID must be changed
[78](#circumstances-under-which-oid-must-be-changed)

9.13 Dispute Resolution Provisions [78](#dispute-resolution-provisions)

9.14 Governing Law [79](#governing-law)

9.15 Compliance With Applicable Law
[79](#compliance-with-applicable-law)

9.16 Miscellaneous Provisions [79](#miscellaneous-provisions)

9.16.1 Entire agreement [79](#entire-agreement)

9.16.2 Assignment [79](#assignment)

9.16.3 Severability [79](#severability)

9.16.4 Enforcement (Attorney Fees/Waiver of Rights)
[79](#enforcement-attorney-feeswaiver-of-rights)

9.16.5 Force Majeure [79](#force-majeure)

9.17 Other Provisions [79](#other-provisions)

10\. BIBLIOGRAPHY [80](#bibliography)

11\. ACRONYMS & ABBREVIATIONS [82](#acronyms-abbreviations)

12\. GLOSSARY [85](#glossary)

13\. ACKNOWLEDGEMENTS [95](#acknowledgements)

# INTRODUCTION

This Certificate Policy (CP) defines seven 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 five different assurance levels (Rudimentary, Basic,
Medium, 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 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.

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 {#overview .unnumbered}

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

## Document Identification 

There are seven policies specified at five levels of assurance in this
Certificate Policy, which are defined in subsequent sections. Each level
of assurance has an Object 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:

  ----------------------------------------- -----------------------------
  fbca-policies OBJECT IDENTIFIER           ::= { csor-certpolicy 3 }

  csor-certpolicy OBJECT IDENTIFIER         ::= { 2 16 840 1 101 3 2 1 }

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

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

## 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,

-   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
> cross-certified 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 on behalf of the U.S. Government, subject to the
direction of the FPKIPA.

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

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

### Subscribers

A Subscriber is the user or device to whom or to which a certificate is
issued. FBCA Subscribers include only FPKI Management Authority
personnel and, when determined by the Federal PKI Policy Authority,
network or hardware devices. Note that CAs are sometimes technically
considered "subscribers" in a PKI. However, the term "Subscriber" as
used in this document does not refer to CAs.

### Relying Parties

A Relying Party uses a Subscriber's certificate to verify the integrity
of a digitally signed message, to identify the creator of a message, or
to establish confidential communications with the Subscriber. The
Relying Party is responsible for deciding whether or how to check the
validity of the certificate by checking the appropriate certificate
status information. 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.

This CP makes no assumptions or limitations regarding the identity of
Relying Parties. While Relying Parties are generally Subscribers,
Relying Parties are not required to have an established relationship
with the FBCA or an Entity CA.

### Other Participants

The FBCA and Entity CAs may require the services of other security,
community, and application authorities. If required, the FBCA or Entity
CPS shall identify the parties, define the services, and designate the
mechanisms used to support these services.

## Certificate Usage

### Appropriate Certificate Uses 

The sensitivity of the information processed or protected using
certificates issued by FBCA or an Entity CA will vary significantly.
Relying Parties 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 or significance of the information. This
evaluation is done by each Relying Party for its application and is not
controlled by this CP. To provide sufficient granularity, this CP
specifies security requirements at five increasing, qualitative levels
of assurance: Rudimentary, Basic, Medium, Medium Hardware, and High. It
is assumed that the FBCA will issue at least one High assurance
certificate, so the FBCA will be operated at that level. The FBCA is
intended to support applications involving unclassified information,
which can include sensitive unclassified data protected pursuant to
Federal statues and regulations.

The following table provides a brief description of the appropriate uses
for certificates at each level of assurance defined in this CP. These
descriptions are intended as guidance and are not binding.

  ----------------- -----------------------------------------------------
  **Assurance       **Appropriate Certificate Uses**
  Level**           

  Rudimentary       This level provides the lowest degree of assurance
                    concerning identity of the individual. One of the
                    primary functions of this level is to provide data
                    integrity to the information being signed. This level
                    is relevant to environments in which the risk of
                    malicious activity is considered to be low. It is not
                    suitable for transactions requiring authentication,
                    and is generally insufficient for transactions
                    requiring confidentiality, but may be used for the
                    latter where certificates having higher levels of
                    assurance are unavailable.

  Basic             This level provides a basic level of assurance
                    relevant to environments where there are risks and
                    consequences of data compromise, but they are not
                    considered to be of major significance. This may
                    include access to private information where the
                    likelihood of malicious access is not high. It is
                    assumed at this security level that users are not
                    likely to be malicious.

  Medium            This level is relevant to environments where risks
                    and consequences of data compromise are moderate.
                    This may include transactions having substantial
                    monetary value or risk of fraud, or involving access
                    to private information where the likelihood of
                    malicious access is substantial.

  Medium Hardware   This level is relevant to environments where threats
                    to data are high or the consequences of the failure
                    of security services are high. This may include very
                    high value transactions or high levels of fraud risk.

  High              This level is reserved for cross-certification with
                    government entities and is appropriate for those
                    environments where the threats to data are high, or
                    the consequences of the failure of security services
                    are high. This may include very high value
                    transactions or high levels of fraud risk.
  ----------------- -----------------------------------------------------

Federal Relying Parties should review more detailed guidance governing
the use of electronic signatures (which include the use of digital
certificates) issued by the Office of Management and Budget implementing
the Government Paperwork Elimination Act (Federal Register May 2000:
Volume 65, Number 85, Page 25508), as well as more detailed subordinate
guidance issued by other agencies pursuant to OMB direction (such as
Federal Information Processing Standards, NIST Special Publications and
electronic record retention guidance provided by the National Archives
and Records Administration).

### Prohibited Certificate Uses

No stipulation.

## Policy Administration

### Organization administering the document

The Federal PKI Policy Authority is responsible for all aspects of this
CP.

### Contact Person

Questions regarding this CP shall be directed to the Chair of the
Federal PKI Policy

Authority, whose address can be found at http://www.cio.gov/fpkipa.

### Person Determining Certification Practices Statement Suitability for the Policy

The Certification Practices Statement must conform to the corresponding
Certificate Policy. The Federal PKI Policy Authority is responsible for
asserting whether the FBCA CPS conforms to the FBCA CP. Entities must
designate the person or organization that asserts that their CPS(s)
conforms to their CP(s).

In each case, the determination of suitability shall be based on an
independent compliance auditor's results and recommendations. See
Section 8 for further details.

### CPS Approval Procedures

The FPKI Management Authority shall submit the FBCA CPS and the results
of a compliance audit to the FPKI PA for approval. The FPKI PA shall
vote to accept or reject the CPS. If rejected, the FPKI Management
Authority shall resolve the identified discrepancies and resubmit to the
FPKI PA. The FBCA is required to meet all facets of the policy. The FPKI
PA will not issue waivers.

Entity CAs shall submit their CPS and the results of their compliance
audit to the appropriate authority (See Section 1.5.3) for approval. An
Entity CA's CPS shall be required to meet all facets of its policy.
Waivers, while discouraged, may be permitted in order to meet urgent
unforeseen operational requirements. Any waivers issued by Entity CAs
are considered changes to the corresponding CP, and may result in
revocation of the cross-certificate by the FPKI PA.

## Definitions and acronyms

See Sections 11 and 12.

# Publication & Repository responsibilitIes

## repositories

The FPKI Management Authority shall operate repositories to support FBCA
operations.

Entity PKIs are responsible for operation of repositories to support
their PKI operations.

Entities who cross-certify with the FBCA shall ensure interoperability
with the FBCA repository.

### FBCA Repository Obligations

The FPKI Management Authority may use a variety of mechanisms for
posting information into a repository as required by this CP. These
mechanisms at a minimum shall include:

-   X.500 Directory Server System that is also accessible through the
    Lightweight Directory Access Protocol,

-   Availability of the information as required by the certificate
    information posting and retrieval stipulations of this CP, and

-   Access control mechanisms when needed to protect repository
    information as described in later sections.

## PUBLICATION of certification information

### Publication of Certificates and Certificate Status

The FPKI Management Authority shall publish all CA certificates issued
by or to the FBCA and all CRLs issued by the FBCA in the FBCA
repository.

At a minimum, the Entity repositories shall contain all CA certificates
issued by or to the Entity PKI and CRLs issued by the Entity PKI.

For the FBCA, mechanisms and procedures shall be designed to ensure CA
certificates and CRLs are available for retrieval 24 hours a day, 7 days
a week, with a minimum of 99% availability overall per year and
scheduled down-time not to exceed 0.5% annually.

Entity CAs being considered for cross certification shall be designed to
comply with this requirement.

### Publication of CA Information

The FPKI Management Authority shall publish information concerning the
FBCA necessary to support its use and operation. The FBCA CP shall be
publicly available on the FPKI PA website (see
http://www.cio.gov/fpkipa). The FBCA CPS will not be published; a
redacted version of the CPS will be publicly available from the FPKI PA
website (see http://www.cio.gov/fpkipa).

Publication of CA information in the Entity repositories is a local
decision.

### Interoperability

Where certificates and CRLs are published in directories,
standards-based schemas for directory objects and attributes are
recommended. Detailed information is available in technical guidance
from the FPKI Management Authority; for more information see the Federal
PKI Architecture website (see http://www.cio.gov/fpkia).

## Frequency of Publication

This CP and any subsequent changes shall be made publicly available
within thirty days of approval.

## access controls on repositories

The FPKI Management Authority and Entity CAs shall protect any
repository information not intended for public dissemination or
modification. Certificates and certificate status information in the
FBCA repository shall be publicly available through the Internet.

Access to information in Entity CA repositories shall be determined by
the Entity pursuant to the rules and statutes that apply to that entity.
Certificates and certificate status information in the Entity repository
should be publicly available through the Internet wherever reasonable.
At a minimum, the Entity repositories shall make CA certificates and
CRLs issued by the Entity PKI and CA certificates issued to the Entity
PKI available to Federal Relying Parties.

# Identification & Authentication

## Naming

### Types of Names

The FBCA shall only generate and sign certificates that contain a
non-null subject Distinguished Name (DN). Certificates issued by the
FBCA may also include alternative name forms.

For Entity CAs, the following rules apply. All CA and RA certificates
shall include a non-NULL subject DN. All certificates issued to end
entities, except those issued at the Rudimentary level of assurance,
shall include a non-NULL subject DN. Certificates issued at the
Rudimentary level of assurance may include a null subject DN if they
include at least one alternative name form. Certificates at all levels
of assurance may include alternative name forms. This CP does not
restrict the types of names that can be used.

The table below summarizes the naming requirements that apply to each
level of assurance.

+----------------+-----------------------------------------------------+
| Rudimentary    | Non-Null Subject Name, or Null Subject Name if      |
|                | Subject Alternative Name is populated and marked    |
|                | critical                                            |
+----------------+-----------------------------------------------------+
| Basic          | Non-Null Subject Name, and optional Subject         |
|                | Alternative Name if marked non-critical             |
+----------------+-----------------------------------------------------+
| Medium         | Non-Null Subject Name, and optional Subject         |
|                | Alternative Name if marked non-critical             |
| (all policies) |                                                     |
+----------------+-----------------------------------------------------+
| High           | Non-Null Subject Name, and optional Subject         |
|                | Alternative Name if marked non-critical             |
+----------------+-----------------------------------------------------+

### Need for Names to Be Meaningful

Names used in the certificates issued by the FBCA and/or Entity CAs must
identify the person or object to which they are assigned.

When DNs are used, the directory information tree must accurately
reflect organizational structures.

When DNs are used, the common name must respect name space uniqueness
requirements and must not be misleading. This does not preclude the use
of pseudonymous certificates as defined in Section 3.1.3.

### Anonymity or Pseudonymity of Subscribers

The FBCA shall not issue anonymous certificates. Pseudonymous
certificates may be issued by the FBCA to support internal operations.
CA certificates issued by the FBCA shall not contain anonymous or
pseudonymous identities.

DNs in certificates issued by Entity CAs may contain a pseudonym (such
as a large number) as long as name space uniqueness requirements are
met.

### Rules for Interpreting Various Name Forms

No stipulation for the FBCA.

Entity CAs must specify rules for interpreting names in Subscriber
certificates in the Entity CP or a referenced certificate profile. (The
rules may be simply a description of naming conventions.)

### Uniqueness of Names

Name uniqueness must be enforced by the FBCA and Entity CAs.

The Federal PKI Policy Authority is responsible for ensuring name
uniqueness in certificates issued by the FBCA. Entity CAs shall identify
the authority that is responsible for ensuring name uniqueness in
certificates issued by the entity CA.

### Recognition, Authentication, & Role of Trademarks

The FPKIPA shall resolve any name collisions or disputes regarding
FBCA-issued certificates brought to its attention. Consistent with
Federal Policy, the FBCA will not knowingly use trademarks in names
unless the subject has the rights to use that name.

## INITIAL Identity Validation

### Method to Prove Possession of Private Key

In all cases where the party named in a certificate generates its own
keys that party shall be required to prove possession of the private key
that corresponds to the public key in the certificate request.

In the case where a key is generated by the CA or RA either (1) directly
on the party's hardware or software token; or (2) in a key generator
that benignly transfers the key to the party's token, then proof of
possession is not required.

### Authentication of Organization Identity

Requests for FBCA or Entity CA certificates in the name of an
organization shall include the organization name, address, and
documentation of the existence of the organization.

The FPKI Management Authority or Entity RA shall verify the information,
in addition to the authenticity of the requesting representative and the
representative's authorization to act in the name of the organization.

### Authentication of Individual Identity

#### Authentication of Human Subscribers

For Subscribers, the FPKI Management Authority or Entity CA, and/or
associated RAs shall ensure that the applicant's identity information is
verified in accordance with the process established by the applicable CP
and CPS. Process information shall depend upon the certificate level of
assurance and shall be addressed in the FBCA or Entity CPS. The
documentation and authentication requirements shall vary depending upon
the level of assurance.

For Medium and High Assurance, identity shall be established no more
than 30 days before initial certificate issuance Entity CAs being
considered for cross certification must comply with this requirement.

The FPKI Management Authority, Entity CAs and/or RAs shall record the
information set forth below for issuance of each certificate:

-   The identity of the person performing the identification;

-   A signed declaration by that person that he or she verified the
    identity of the applicant as required using the format set forth at
    28 U.S.C. 1746 (declaration under penalty of perjury) or comparable
    procedure under local law;

-   If in-person identity proofing is done, a unique identifying
    number(s) from the ID(s) of the applicant, or a facsimile of the
    ID(s);

-   The date of the verification; and

-   A declaration of identity signed by the applicant using a
    handwritten signature and performed in the presence of the person
    performing the identity authentication, using the format set forth
    at 28 U.S.C. 1746 (declaration under penalty of perjury) or
    comparable procedure under local law.

**For All Levels**: If an applicant is unable to perform face-to-face
registration (e.g., a network device), the applicant may be represented
by a trusted person already issued a digital certificate by the Entity.
The trusted person will present information sufficient for registration
at the level of the certificate being requested, for both
himself/herself and the applicant who the trusted person is
representing.

**For the Basic and Medium Assurance Levels:** An entity certified by a
State or Federal Entity as being authorized to confirm identities may
perform in-person authentication on behalf of the RA. The certified
entity forwards the information collected from the applicant directly to
the RA in a secure manner. Packages secured in a tamper-evident manner
by the certified entity satisfy this requirement; other secure methods
are also acceptable. Such authentication does not relieve the RA of its
responsibility to verify the presented data.

The table below summarizes the identification requirements for each
level of assurance.

+------------+---------------------------------------------------------+
| *          | **Identification Requirements**                         |
| *Assurance |                                                         |
| Level**    |                                                         |
+------------+---------------------------------------------------------+
| R          | No identification requirement; applicant may apply and  |
| udimentary | receive a certificate by providing his or her e-mail    |
|            | address                                                 |
+------------+---------------------------------------------------------+
| Basic      | Identity may be established by in-person proofing       |
|            | before a Registration Authority or Trusted Agent; or    |
|            | remotely verifying information provided by applicant    |
|            | including ID number and account number through record   |
|            | checks either with the applicable agency or institution |
|            | or through credit bureaus or similar databases, and     |
|            | confirms that: name, DoB, address and other personal    |
|            | information in records are consistent with the          |
|            | application and sufficient to identify a unique         |
|            | individual.                                             |
|            |                                                         |
|            | Address confirmation: a) Issue credentials in a manner  |
|            | that confirms the address of record supplied by the     |
|            | applicant; or                                           |
|            |                                                         |
|            | b\) Issue credentials in a manner that confirms the     |
|            | ability of the applicant to receive telephone           |
|            | communications at a number associated with the          |
|            | applicant in records, while recording the applicant's   |
|            | voice.                                                  |
+------------+---------------------------------------------------------+
| Medium     | Identity shall be established by in-person proofing     |
|            | before the Registration Authority, Trusted Agent or an  |
| (all       | entity certified by a State or Federal Entity as being  |
| policies)  | authorized to confirm identities; information provided  |
|            | shall be verified to ensure legitimacy. A trust         |
|            | relationship between the Trusted Agent and the          |
|            | applicant which is based on an in-person antecedent may |
|            | suffice as meeting the in-person identity proofing      |
|            | requirement. Credentials required are either one        |
|            | Federal Government-issued Picture I.D., or two          |
|            | Non-Federal Government I.D.s, one of which shall be a   |
|            | photo I.D. (e.g., Drivers License)                      |
+------------+---------------------------------------------------------+
| High       | Identity established by in-person appearance before the |
|            | Registration Authority or Trusted Agent; information    |
|            | provided shall be checked to ensure legitimacy          |
|            |                                                         |
|            | Credentials required are either one Federal             |
|            | Government-issued Picture I.D., or two Non-Federal      |
|            | Government I.D.s, one of which shall be a photo I.D.    |
|            | (e.g., Drivers License)                                 |
+------------+---------------------------------------------------------+

#### Authentication of Human Subscribers For Role-based Certificates

There is a subset of human subscribers who will be issued role-based
certificates. These certificates will 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, it will be 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 "*Chief Information Officer*" however, each of the four individual
certificates will carry unique keys and certificate identifiers). Roles
for which role-based certificates may be issued are limited to those
that uniquely identify a specific individual within an organization
(e.g., *Chief Information Officer* is a unique individual whereas
*Program Analyst* is not). Role-based certificates shall not be shared,
but shall be issued to individual subscribers and protected in the same
manner as individual certificates.

The FPKI Management Authority and/or Entity CAs shall record the
information identified in Section 3.2.3.1 for a sponsor associated with
the role before issuing a role-based certificate. The sponsor must hold
an individual certificate in his/her own name issued by the same CA at
the same or higher assurance level as the role-based certificate.

The procedures for issuing role-based tokens must comply with all other
stipulations of this CP (e.g., key generation, private key protection,
and Subscriber obligations).

For pseudonymous certificates that identify subjects by their
organizational roles, the CA shall validate that the individual either
holds that role or has been delegated the authority to sign on behalf of
the role.

#### Authentication of Human Subscribers For Group Certificates

Normally, a certificate shall be issued to a single Subscriber. For
cases where there are several entities acting in one capacity, and where
non-repudiation for transactions is not desired, a certificate may be
issued that corresponds to a private key that is shared by multiple
Subscribers. The FPKI Management Authority, Entities and/or RAs shall
record the information identified in Section 3.2.3.1 for a sponsor from
the Information Systems Security Office or equivalent before issuing a
group certificate.

In addition to the authentication of the sponsor, the following
procedures shall be performed for members of the group:

-   The Information Systems Security Office or equivalent shall be
    responsible for ensuring control of the private key, including
    maintaining a list of Subscribers who have access to use of the
    private key, and accounting for which Subscriber had control of the
    key at what time.

-   The subjectName DN must not imply that the subject is a single
    individual, e.g. by inclusion of a human name form;

-   The list of those holding the shared private key must be provided
    to, and retained by, the applicable CA or its designated
    representative; and

-   The procedures for issuing tokens for use in shared key applications
    must comply with all other stipulations of this CP (e.g., key
    generation, private key protection, and Subscriber obligations).

#### Authentication of Devices

Some computing and communications devices (routers, firewalls, servers,
etc.) will be named as certificate subjects. In such cases, the device
must have a human sponsor. The sponsor is responsible for providing the
following registration information:

-   Equipment identification (e.g., serial number) or service name
    (e.g., DNS name)

-   Equipment public keys

-   Equipment authorizations and attributes (if any are to be included
    in the certificate)

-   Contact information to enable the CA or RA to communicate with the
    sponsor when required

These certificates shall be issued only to devices under the issuing
entity's control (i.e., require registration and validation that meets
all issuing agency's requirements, as well as requiring re-validation
prior to being re-issued). In the case a human sponsor is changed, the
new sponsor shall review the status of each device under his/her
sponsorship to ensure it is still authorized to receive certificates.
The CPS shall describe procedures to ensure that certificate
accountability is maintained.

The registration information shall be verified to an assurance level
commensurate with the certificate assurance level being requested.
Acceptable methods for performing this authentication and integrity
checking include, but are not limited to:

-   Verification of digitally signed messages sent from the sponsor
    (using certificates of equivalent or greater assurance than that
    being requested).

-   In person registration by the sponsor, with the identity of the
    sponsor confirmed in accordance with the requirements of Section
    3.2.3.1.

### Non-verified Subscriber Information

Except for the rudimentary assurance level, information that is not
verified shall not be included in certificates.

### Validation of Authority

For cross-certification, the FPKI Management Authority shall validate
the representative's authorization to act in the name of the
organization.

### Criteria for Interoperation

The FPKIPA shall determine the criteria for cross-certification with the
FBCA. See also Section 1.1.5 and the U.S. Government Public Key
Infrastructure Cross-Certification Methodology and Criteria. (see
http://www.cio.gov/fbca)

## Identification and authentication for re-key requests

### Identification and Authentication for Routine Re-key

In the event that a Principal CA re-key is required, a new certificate
will be issued to Principal CAs by the FBCA. Before issuance, the
Principal CA shall identify itself through use of its current signature
key or the initial registration process. If it has been more than three
years since a Principal CA was identified as required in Section 3.2,
identity shall be re-established through the initial registration
process.

Subscribers of Entity CAs shall identify themselves for the purpose of
re-keying as required in table below.

+-----------+----------------------------------------------------------+
| **        | **Routine Re-key Identity Requirements for Subscriber    |
| Assurance | Signature and Encryption Certificates**                  |
| Level**   |                                                          |
+===========+==========================================================+
| Ru        | Identity may be established through use of current       |
| dimentary | signature key.                                           |
+-----------+----------------------------------------------------------+
| Basic     | Identity may be established through use of current       |
|           | signature key, except that identity shall be             |
|           | reestablished through initial registration process at    |
|           | least once every 15 years from the time of initial       |
|           | registration.                                            |
+-----------+----------------------------------------------------------+
| Medium    | Identity may be established through use of current       |
|           | signature key, except that identity shall be established |
| (all      | through initial registration process at least once every |
| policies) | nine years from the time of initial registration.        |
+-----------+----------------------------------------------------------+
| High      | Identity may be established through use of current       |
|           | signature key, except that identity shall be established |
|           | through initial registration process at least once every |
|           | three years from the time of initial registration.       |
+-----------+----------------------------------------------------------+

### Identification and Authentication for Re-key after Revocation

After a certificate has been revoked other than during a renewal or
update action, the subscriber is required to go through the initial
registration process described in Section 3.2 to obtain a new
certificate. (This applies to all certificates issued by both Entity CAs
and the FBCA.)

## Identification and authentication for revocation request

Revocation requests must be authenticated. Requests to revoke a
certificate may be authenticated using that certificate\'s public key,
regardless of whether or not the associated private key has been
compromised.

# Certificate Life-Cycle

## Application

This section specifies requirements for initial application for
certificate issuance.

Entities seeking to cross-certify with the FBCA shall fulfill the
application requirements as specified in the U.S. Government Public Key
Infrastructure Cross-Certification Criteria and Methodology. The Federal
PKI Policy Authority shall act on the application and, upon making a
determination to issue a certificate and entering into the MOA with the
Entity, shall authorize the FPKI Management Authority to issue the
cross-certificate to the Entity.

The FBCA may issue end-entity certificates to trusted personnel where
necessary for the internal operations of the FBCA. The FBCA will not
issue end-entity certificates for any other reasons.

### Submission of Certificate Application

For the FBCA, the certificate application shall be submitted to the
FPKIPA by an authorized representative of the Entity CA.

For Entity CAs, this CP makes no stipulations regarding submission of
certificate applications.

### Enrollment Process and Responsibilities

Entities applying for cross-certification are responsible for providing
accurate information on their certificate applications. Upon issuance,
each certificate issued by the FBCA shall be manually checked to ensure
each field and extension is properly populated with the correct
information before the certificate is delivered to the Entity.

For Entity CAs, all communications among PKI authorities supporting the
certificate application and issuance process shall be authenticated and
protected from modification.

## Certificate Application Processing

Information in certificate applications must be verified as accurate
before certificates are issued. Entity CPs shall specify procedures to
verify information in certificate applications.

### Performing Identification and Authentication Functions

For the FBCA, the identification and authentication of the applicant
shall be performed by the FPKI Management Authority.

For Entity CAs, the identification and authentication of the Subscriber
must meet the requirements specified for Subscriber authentication as
specified in Sections 3.2 and 3.3 of this CP. The Entity CP must
identify the components of the Entity PKI (e.g., CA or RA) that are
responsible for authenticating the Subscriber's identity in each case.

### Approval or Rejection of Certificate Applications

For the FBCA, the FPKIPA may approve or reject a certificate
application. See Section 1.1.5.

This CP makes no stipulation regarding Approval or Rejection of
Certificate Applications in Entity PKIs.

### Time to Process Certificate Applications

No stipulation.

## Issuance

### CA Actions during Certificate Issuance

The FPKI Management Authority verifies the source of a certificate
request before issuance. CA certificates created by the FBCA shall be
checked to ensure that all fields and extensions are properly populated.
After generation and verification, the FPKI Management Authority shall
post CA certificates in the FBCA directory system.

Entity CAs shall verify the source of a certificate request before
issuance.

### Notification to Subscriber of Certificate Issuance 

The FBCA process for subscriber notification is defined in the U.S.
Government Public Key Infrastructure Cross-Certification Criteria and
Methodology. (See <http://www.cio.gov/fbca/tech_requirements.htm>)

For Entity CAs, no stipulation.

## CERTIFICATE Acceptance

Before a subscriber can make effective use of its private key, a PKI
Authority shall convey to the subscriber its responsibilities as defined
in Section 9.6.3.

### Conduct constituting certificate acceptance

For the FBCA, failure to object to the certificate or its contents
constitutes acceptance of the certificate.

### Publication of the Certificate by the CA

As specified in 2.2.1, all CA certificates shall be published in FBCA or
Entity repositories.

This specification makes no stipulation regarding publication of
Subscriber certificates.

### Notification of Certificate Issuance by the CA to other entities

For the FBCA, notification of certificate issuance will be provided to
all cross-certified entities.

For Entity CAs, the FPKI PA shall be notified upon issuance of new
inter-organizational CA cross-certificates.

## key pair and certificate Usage

### Subscriber Private Key and Certificate Usage

For High, Medium Hardware, Medium, and Basic Assurance, subscribers
shall protect their private keys from access by other parties. For
Rudimentary assurance, no stipulation.

Restrictions in the intended scope of usage for a private key are
specified through certificate extensions, including the key usage and
extended key usage extensions, in the associated certificate.

### Relying Party Public key and Certificate Usage

FBCA-issued certificates specify restrictions on use through critical
certificate extensions, including the basic constraints and key usage
extensions. The FBCA issues CRLs specifying the current status of all
unexpired FBCA certificates. It is recommended that relying parties
process and comply with this information whenever using FBCA issued
certificates in a transaction.

## Certificate Renewal

Certificate renewal consists of issuing a new certificate with a new
validity period and serial number while retaining all other information
in the original certificate including the public key. Frequent renewal
of certificates may assist in reducing the size of CRLs.

After certificate renewal, the old certificate may or may not be
revoked, but must not be further re-keyed, renewed, or modified.

### Circumstance for Certificate Renewal

A certificate may be renewed if the public key has not reached the end
of its validity period, the associated private key has not been
compromised, and the Subscriber name and attributes are unchanged. In
addition, the validity period of the certificate must meet the
requirements specified in Section 6.3.2.

Certificates may also be renewed when a CA re-keys.

### Who may request Renewal

For the FBCA, the Entity or FPKI Management Authority may request
renewal of an Entity CA's cross-certificate.

For Entity CAs that support renewal, such requests shall only be
accepted from certificate subjects, PKI sponsors or RAs. Additionally, a
CA may perform renewal of its subscriber certificates without a
corresponding request, such as when the CA re-keys.

### Processing Certificate Renewal Requests

For the FBCA, certificate renewal for reasons other than re-key of the
FBCA shall be approved by the FPKIPA.

For Entity CAs, no stipulation.

### Notification of new certificate issuance to Subscriber

The FPKI Management Authority shall notify Entity CAs upon issuance of
new certificates.

For Entity CAs, no stipulation.

### Conduct constituting acceptance of a Renewal certificate 

Failure to object to a FBCA-issued certificate constitutes acceptance of
the certificate.

For Entity CAs, no stipulation.

### Publication of the Renewal certificate by the CA

As specified in 2.2.1, all CA certificates shall be published in the
FBCA or Entity repositories.

### Notification of Certificate Issuance by the CA to other entities

The FPKI Management Authority shall inform the FPKIPA of any certificate
issuance.

For Entity CAs, no stipulation.

## Certificate Re-Key

Re-keying a certificate consists of creating new certificates with a
different public key (and serial number) while retaining the remaining
contents of the old certificate that describe the subject. The new
certificate may be assigned a different validity period, key
identifiers, specify a different CRL distribution point, and/or be
signed with a different key.

Subscribers of Entity CAs shall identify themselves for the purpose of
re-keying as required in Section 3.3.1.

After certificate rekey, the old certificate may or may not be revoked,
but must not be further re-keyed, renewed, or modified.

### Circumstance for Certificate Re-key

The FBCA will issue new cross-certificates to Principal CAs when a
currently recognized Principal CA has generated a new key pair and a
valid and unexpired MOA exists between the FPKIPA and the Entity PKI.

For Entity CAs, no stipulation.

### Who may request certification of a new public key

The FPKI Management Authority may request certification of a new public
key for currently cross-certified Entity Principal CAs.

For Entity CAs that support re-key, such requests shall only be accepted
from the subject of the certificate or PKI sponsors. Additionally, CAs
and RAs may initiate re-key of a subscriber's certificates without a
corresponding request.

### Processing certificate Re-keying requests

Before performing re-key, the FPKI Management Authority shall identify
and authenticate Principal CAs by performing the identification
processes defined in Section 3.2 or Section 3.3.

The validity period associated with the new certificate must not extend
beyond the period of the MOA.

For Entity CAs, see Sections 3.2 and 3.3.

### Notification of new certificate issuance to Subscriber

The FPKI Management Authority shall notify Entity CAs upon issuance of
new certificates.

For Entity CAs, no stipulation.

### Conduct constituting acceptance of a Re-keyed certificate

For the FBCA, failure to object to the certificate or its contents
constitutes acceptance of the certificate.

For Entity CAs, no stipulation.

### Publication of the Re-keyed certificate by the CA

As specified in 2.2.1, all CA certificates shall be published in the
FBCA or Entity repositories.

### Notification of certificate issuance by the CA to other Entities

The FPKI Management Authority shall inform the FPKIPA of any certificate
issuance.

For Entity CAs, no stipulation.

## Modification

Certificate modification consists of creating new certificates with
subject information (e.g., a name or email address) that differs from
the old certificate. For example, an Entity CA may perform certificate
modification for a Subscriber whose characteristics have changed (e.g.,
has just received a medical degree). The new certificate may have the
same or different subject public key.

After certificate modification, the old certificate may or may not be
revoked, but must not be further re-keyed, renewed, or modified.

### Circumstance for Certificate Modification

For the FBCA, certificate modification is performed if the Entity CA
changes its name.

For Entity CAs, no stipulation.

### Who may request Certificate Modification

The FPKI Management Authority or the Entity Principal CA may request
certificate modification for currently cross-certified Entity Principal
CAs.

For Entity CAs, no stipulation.

### Processing Certificate Modification Requests

The FPKI Management Authority shall perform certificate modification at
the direction of the FPKI PA. The FPKI Management Authority may also
perform certificate modification at the request of the Entity CA for the
following reasons:

-   Modification of SIA extension; or

-   Minor name changes (e.g., change CA1 to CA2) as part of key rollover
    procedures.

The validity period associated with the new certificate must not extend
beyond the period of the MOA.

For Entity CAs, proof of all subject information changes must be
provided to the RA or other designated agent and verified before the
modified certificate is issued.

### Notification of new certificate issuance to Subscriber

The FPKI Management Authority shall notify Entity CAs upon issuance of
new certificates.

For Entity CAs, no stipulation.

### Conduct constituting acceptance of modified certificate

For the FBCA, failure to object to the certificate or its contents
constitutes acceptance of the certificate.

For Entity CAs, no stipulation.

### Publication of the modified certificate by the CA

As specified in 2.2.1, all CA certificates shall be published in the
FBCA or Entity repositories.

### Notification of certificate issuance by the CA to other Entities

The FPKI Management Authority shall inform the FPKIPA of any certificate
issuance.

For Entity CAs, no stipulation.

## Certificate Revocation & Suspension

#### Revocation requests must be authenticated. Requests to revoke a certificate may be authenticated using that certificate\'s associated private key, regardless of whether or not the private key has been compromised. {#revocation-requests-must-be-authenticated.-requests-to-revoke-a-certificate-may-be-authenticated-using-that-certificates-associated-private-key-regardless-of-whether-or-not-the-private-key-has-been-compromised. .unnumbered}

For High, Medium Hardware, Medium, and Basic Assurance, all CAs shall
publish CRLs.

### Circumstances for Revocation 

For the FBCA and Entity CAs, a certificate shall be revoked when the
binding between the subject and the subject's public key defined within
a certificate is no longer considered valid. There are three
circumstances under which certificates issued by the FBCA will be
revoked:

-   The first circumstance is when the Federal PKI Policy Authority
    requests an FBCA-issued certificate be revoked. This will be the
    normal mechanism for revocation in cases where the Federal PKI
    Policy Authority determines that an Entity PKI does not meet the
    Federal PKI policy requirements or certification of the Entity PKI
    is no longer in the best interests of the Federal Government.

-   The second circumstance is when the Management Authority receives an
    authenticated request from a previously designated official of the
    Entity responsible for the Principal CA.

-   The third circumstance is when the FBCA Operational personnel
    determine that an emergency has occurred that may impact the
    integrity of the certificates issued by the FBCA. Under such
    circumstances, the following individuals may authorize immediate
    certificate revocation:

```{=html}
<!-- -->
```
-   Chair, Federal PKI Policy Authority, or

-   Other personnel as designated by the Chair, Federal PKI Policy
    Authority.

The Federal PKI Policy Authority shall meet as soon as practicable to
review the emergency revocation.

Entity CAs that implement certificate revocation shall, at a minimum,
revoke certificates

for the reason of key compromise upon receipt of an authenticated
request from an

appropriate entity.

Whenever any of the above circumstances occur, the associated
certificate shall be revoked and placed on the CRL. Revoked certificates
shall be included on all new publications of the certificate status
information until the certificates expire.

### Who Can Request Revocation 

An FBCA certificate may be revoked upon direction of the Federal PKI
Policy Authority or upon an authenticated request by a designated
official of the Entity responsible for the Principal CA (such official
or officials shall be identified in the MOA as authorized to make such a
request).

Entity CAs that implement certificate revocation shall, at a minimum,
accept revocation requests from subscribers. Requests for certificate
revocation from other parties may be supported by Entity CAs. Note that
an Entity Principal CA may always revoke the certificate it has issued
to the FBCA without any Federal PKI Policy Authority action.

### Procedure for Revocation Request

Upon receipt of a revocation request involving an FBCA-issued
certificate, the FPKI Management Authority shall authenticate the
request and apprise the Federal PKI Policy Authority. The Federal PKI
Policy Authority may, at its discretion, take whatever measures it deems
appropriate to verify the need for revocation. If the revocation request
appears to be valid, the Federal PKI Policy Authority shall direct the
FPKI Management Authority to revoke the certificate. The FPKI Management
Authority shall give prompt oral or electronic notification to
previously designated officials in all entities having a Principal CA
with which the FBCA interoperates.

Entity CAs that implement certificate revocation shall revoke
certificates upon receipt of sufficient evidence of compromise or loss
of the subscriber's corresponding private key. A request to revoke a
certificate shall identify the certificate to be revoked, explain the
reason for revocation, and allow the request to be authenticated (e.g.,
digitally or manually signed). Where subscribers use hardware tokens,
revocation is optional if all the following conditions are met:

-   the revocation request was not for key compromise;

-   the hardware token does not permit the user to export the signature
    private key;

-   the Subscriber surrendered the token to the PKI;

-   the token was zeroized or destroyed promptly upon surrender;

-   the token has been protected from malicious use between surrender
    and zeroization or destruction.

> In all other cases, revocation of the certificates is mandatory. Even
> where all the above conditions have been met, revocation of the
> associated certificates is recommended.

### Revocation Request Grace Period

The revocation request grace period is the time available to the
subscriber within which the subscriber must make a revocation request
after reasons for revocation have been identified.

In the case of key compromise, FBCA subscribers (e.g., Entity CAs) are
required to request revocation within one hour. For all other reasons,
FBCA subscribers are required to request revocation within 24 hours.

For Entity CAs, see Section 9.6.3.

### Time within which CA must Process the Revocation Request

The FBCA and Entity CAs will revoke certificates as quickly as practical
upon receipt of a proper revocation request. Revocation requests shall
be processed before the next CRL is published, excepting those requests
validated within two hours of CRL issuance. Revocation requests
validated within two hours of CRL issuance shall be processed before the
following CRL is published.

### Revocation Checking Requirements for Relying Parties

No stipulation.

### CRL Issuance Frequency

For this CP, CRL issuance encompasses both CRL generation and
publication.

For the FBCA, the interval between CRLs shall not exceed 24 hours.

For Entity CAs, see the table below for issuing frequency of routine
CRLs. CRLs may be issued more frequently than specified below.

Table 1 Entity CA CRL issuance Frequency

  -----------------------------------------------------------------------
  **Assurance Level**    **Maximum Interval for Routine CRL Issuance**
  ---------------------- ------------------------------------------------
  Rudimentary            No stipulation

  Basic                  24 hours

  Medium (all policies)  24 hours

  High                   24 hours
  -----------------------------------------------------------------------

For Entity Principal CAs that are operated in an off-line manner,
routine CRLs may be issued less frequently than specified above if the
CA only issues:

-   CA certificates

-   (optionally) CSS certificates, and

-   (optionally) end user certificates solely for the administration of
    the principal CA.

However, the interval between routine CRL issuance shall not exceed 31
days. Such CAs must meet the requirements specified in section 4.9.12
for issuing Emergency CRLs. (Note: such CAs will also be required to
notify the FPKI Management Authority upon Emergency CRL issuance. This
requirement will be included in the MOA between the FPKIPA and the
Entity.)

### Maximum Latency of CRLs

CRLs shall be published within 4 hours of generation. Furthermore, each
CRL shall be published no later than the time specified in the
nextUpdate field of the previously issued CRL for same scope.

### On-line Revocation/Status Checking Availability

If on-line revocation/status checking is supported by an Entity CA, the
latency of certificate status information distributed on-line by Entity
CAs or their delegated status responders must meet or exceed the
requirements for CRL issuance stated in 4.9.7.

### On-line Revocation Checking Requirements

No stipulation.

### Other Forms of Revocation Advertisements Available

A CA may also use other methods to publicize the certificates it has
revoked. Any alternative method must meet the following requirements:

-   The alternative method must be described in the CA's approved CPS.

-   The alternative method must provide authentication and integrity
    services commensurate with the assurance level of the certificate
    being verified.

-   The alternative method must meet the issuance and latency
    requirements for CRLs stated in Sections 4.9.7 and 4.9.8.

###  Special Requirements Related To Key Compromise

In the event of an Entity Principal CA private key compromise or loss,
the cross-certificate shall be revoked and a CRL shall be published at
the earliest feasible time by the FPKI Management Authority.

For Entity CAs, when a CA certificate is revoked or subscriber
certificate is revoked because of compromise, or suspected compromise,
of a private key, a CRL must be issued as specified below:

  -----------------------------------------------------------------------
  **Assurance Level**    **Maximum Latency for Emergency CRL Issuance**
  ---------------------- ------------------------------------------------
  Rudimentary            No stipulation

  Basic                  24 hours after notification

  Medium (all policies)  18 hours after notification

  High                   Six hours after notification
  -----------------------------------------------------------------------

###  Circumstances for Suspension

Suspension shall not be used by the FBCA.

For Entity CAs, no stipulation.

###  Who can Request Suspension

For Entity CAs, no stipulation.

### Procedure for Suspension Request

For Entity CAs, no stipulation.

###  Limits on Suspension Period

For Entity CAs, no stipulation.

## Certificate Status Services

No stipulation.

### Operational Characteristics

No stipulation.

###  Service Availability

No stipulation.

###  Optional Features

No stipulation.

## End Of Subscription

No stipulation.

## Key Escrow & Recovery

The FBCA shall not perform any encryption key recovery functions
involving Entity CAs, and shall not store any information encrypted by
the FBCA public key that may require key recovery capabilities. However,
if encryption key pairs need to be issued by the FBCA covering
repository system access or for other purposes, the FPKIPA shall publish
applicable requirements for that purpose.

###  Key Escrow and Recovery Policy and Practices

CA private keys are never escrowed.

Subscriber key management keys may be escrowed to provide key recovery.
CAs that support private key escrow for key management keys shall
document their key recovery practices.

Under no circumstances will a subscriber signature key be held in trust
by a third party.

###  Session Key Encapsulation and Recovery Policy and Practices

For the FBCA, no stipulation.

Entity CAs that support session key encapsulation and recovery shall
identify the document describing the practices in the applicable CP.

# Facility Management & Operations Controls

## Physical Controls

All CA equipment including CA cryptographic modules shall be protected
from unauthorized access at all times.

All the physical control requirements specified below apply equally to
the FBCA and Entity CAs.

### Site Location & Construction

The location and construction of the facility housing the FBCA and
Entity CA equipment shall be consistent with facilities used to house
high value, sensitive information. The site location and construction,
when combined with other physical security protection mechanisms such as
guards and intrusion sensors, shall provide robust protection against
unauthorized access to the FBCA and Entity CA equipment and records.

### Physical Access

#### Physical Access for CA Equipment

The FBCA and Entity CA equipment shall always be protected from
unauthorized access. The security mechanisms shall be commensurate with
the level of threat in the equipment environment. Since the FBCA must
plan to issue certificates at all levels of assurance, it shall be
operated and controlled on the presumption that it will be issuing at
least one High Assurance certificate.

The physical security requirements pertaining to CAs that issue Basic
Assurance certificates are:

-   Ensure no unauthorized access to the hardware is permitted

-   Ensure all removable media and paper containing sensitive plain-text
    information is stored in secure containers

In addition to those requirements, the following requirements shall
apply to CAs that issue Medium, Medium Hardware, or High assurance
certificates:

-   Ensure manual or electronic monitoring for unauthorized intrusion at
    all times

-   Ensure an access log is maintained and inspected periodically

-   Require two person physical access control to both the cryptographic
    module and computer system

Removable cryptographic modules, activation information used to access
or enable cryptographic modules, and other sensitive CA equipment shall
be placed in secure containers when not in use. Activation data shall
either be memorized, or recorded and stored in a manner commensurate
with the security afforded the cryptographic module, and shall not be
stored with the cryptographic module.

A security check of the facility housing the FBCA or Entity CA equipment
(operating at the Basic Assurance level or higher) shall occur if the
facility is to be left unattended. At a minimum, the check shall verify
the following:

-   The equipment is in a state appropriate to the current mode of
    operation (e.g., that cryptographic modules are in place when
    "open", and secured when "closed"; and for the FBCA, that all
    equipment other than the repository is shut down);

-   Any security containers are properly secured;

-   Physical security systems (e.g., door locks, vent covers) are
    functioning properly; and

-   The area is secured against unauthorized access.

A person or group of persons shall be made explicitly responsible for
making such checks. When a group of persons is responsible, a log
identifying the person performing a check at each instance shall be
maintained. If the facility is not continuously attended, the last
person to depart shall initial a sign-out sheet that indicates the date
and time, and asserts that all necessary physical protection mechanisms
are in place and activated.

#### Physical Access for RA Equipment

RA equipment shall be protected from unauthorized access while the
cryptographic module is installed and activated. The RA shall implement
physical access controls to reduce the risk of equipment tampering even
when the cryptographic module is not installed and activated. These
security mechanisms shall be commensurate with the level of threat in
the RA equipment environment.

#### Physical Access for CSS Equipment

Physical access control requirements for CSS equipment (if implemented),
shall meet the CA physical access requirements specified in 5.1.2.1.

### Power and Air Conditioning

The FBCA and Entity CAs (operating at the Basic Assurance level or
higher) shall have backup capability sufficient to automatically lock
out input, finish any pending actions, and record the state of the
equipment before lack of power or air conditioning causes a shutdown. In
addition, the FBCA directories (containing FBCA issued certificates and
CRLs) shall be provided with Uninterrupted Power sufficient for a
minimum of six hours operation in the absence of commercial power.
Entity CAs shall employ appropriate mechanisms to ensure availability of
repositories as specified in Section 2.2.1.

### Water Exposures

CA equipment shall be installed such that it is not in danger of
exposure to water (e.g., on tables or elevated floors).

Water exposure from fire prevention and protection measures (e.g.
sprinkler systems) are excluded from this requirement.

### Fire Prevention & Protection

No stipulation.

### Media Storage

FBCA and Entity CA media shall be stored so as to protect it from
accidental damage (water, fire, electromagnetic). Sensitive FBCA and
Entity CA media shall be stored so as to protect it from unauthorized
physical access.

### Waste Disposal

Sensitive media and documentation that are no longer needed for
operations shall be destroyed in a secure manner. For example, sensitive
paper documentation shall be shredded, burned, or otherwise rendered
unrecoverable.

### Off-Site backup

For the FBCA and Entity CAs operating at the Basic Assurance level or
higher, full system backups sufficient to recover from system failure
shall be made on a periodic schedule. Backups are to be performed and
stored off-site not less than once per week. At least one full backup
copy shall be stored at an off-site location separate from the FBCA or
Entity CA equipment. Only the latest full backup need be retained. The
backup shall be stored at a site with physical and procedural controls
commensurate to that of the operational FBCA or Entity CA.

## Procedural Controls

Unless stated otherwise, the requirements in this section apply equally
to the FBCA and Entity CAs.

### Trusted Roles

A trusted role is one whose incumbent performs functions that can
introduce security problems if not carried out properly, whether
accidentally or maliciously. The people selected to fill these roles
must be extraordinarily responsible or the integrity of the CA is
weakened. The functions performed in these roles form the basis of trust
for all uses of the FBCA or an Entity CA. Two approaches are taken to
increase the likelihood that these roles can be successfully carried
out. The first ensures that the person filling the role is trustworthy
and properly trained. The second distributes the functions among more
than one person, so that any malicious activity would require collusion.

The requirements of this policy are defined in terms of four roles.
(Note: the information derives from the Certificate Issuing and
Management Components (CIMC) Protection Profile.)

1.  *Administrator* -- authorized to install, configure, and maintain
    the CA; establish and maintain user accounts; configure profiles and
    audit parameters; and generate component keys.

2.  *Officer* -- authorized to request or approve certificates or
    certificate revocations.

3.  *Auditor* -- authorized to maintain audit logs.

4.  *Operator* -- authorized to perform system backup and recovery.

Some roles may be combined. The roles required for each level of
assurance are identified in Section 5.2.4.

The following subsections provide a detailed description of the
responsibilities for each role.

#### Administrator

The administrator role is responsible for:

-   Installation, configuration, and maintenance of the CA;

-   Establishing and maintaining CA system accounts;

-   Configuring certificate profiles or templates and audit parameters,
    and;

-   Generating and backing up CA keys.

Administrators do not issue certificates to subscribers.

#### Officer

The officer role is responsible for issuing certificates, that is:

-   Registering new subscribers and requesting the issuance of
    certificates;

-   Verifying the identity of subscribers and accuracy of information
    included in certificates;

-   Approving and executing the issuance of certificates, and;

-   Requesting, approving and executing the revocation of certificates.

#### Auditor

The auditor role is responsible for:

-   Reviewing, maintaining, and archiving audit logs;

-   Performing or overseeing internal compliance audits to ensure that
    the FBCA or Entity CA is operating in accordance with its CPS;

#### Operator

The operator role is responsible for the routine operation of the CA
equipment and operations such as system backups and recovery or changing
recording media.

### Number of Persons Required per Task

Only one person is required per task for CAs operating at the
Rudimentary and Basic Levels of Assurance.

Two or more persons are required for CAs operating at the Medium, Medium
Hardware, or High Levels of Assurance for the following tasks:

-   CA key generation;

-   CA signing key activation;

-   CA private key backup.

Where multiparty control for logical access is required, at least one of
the participants shall be an Administrator. All participants must serve
in a trusted role as defined in Section 5.2.1. Multiparty control for
logical access shall not be achieved using personnel that serve in the
Auditor Trusted Role.

Physical access to the CAs does not constitute a task as defined in this
section. Therefore, two-person physical access control may be attained
as required in Section 5.1.2.1.

### Identification and Authentication for Each Role

At all assurance levels other than Rudimentary, an individual shall
identify and authenticate him/herself before being permitted to perform
any actions set forth above for that role or identity.

### Separation of Roles

Role separation, when required as set forth below, may be enforced
either by the CA equipment, or procedurally, or by both means.

Requirements for the separation of roles, and limitations on use of
procedural mechanisms to implement role separation, are described below
for each level of assurance:

+---------------+------------------------------------------------------+
| **Assurance   | **Role Separation Rules**                            |
| Level**       |                                                      |
+---------------+------------------------------------------------------+
| Rudimentary   | No stipulation.                                      |
+---------------+------------------------------------------------------+
| Basic         | Individual personnel shall be specifically           |
|               | designated to the four roles defined in Section      |
|               | 5.2.1 above. Individuals may assume more than one    |
|               | role; however, no one individual shall assume both   |
|               | the Officer and Administrator roles. This may be     |
|               | enforced procedurally. No individual shall be        |
|               | assigned more than one identity.                     |
+---------------+------------------------------------------------------+
| Medium        | Individual personnel shall be specifically           |
|               | designated to the four roles defined in Section      |
| (all          | 5.2.1 above. Individuals may only assume one of the  |
| policies)     | Officer, Administrator, and Auditor roles, but any   |
|               | individual may assume the Operator role. The CA and  |
|               | RA software and hardware shall identify and          |
|               | authenticate its users and shall ensure that no user |
|               | identity can assume both an Administrator and an     |
|               | Officer role, assume both the Administrator and      |
|               | Auditor roles, and assume both the Auditor and       |
|               | Officer roles. No individual shall have more than    |
|               | one identity.                                        |
+---------------+------------------------------------------------------+
| High          | Individual personnel shall be specifically           |
|               | designated to the four roles defined in Section      |
|               | 5.2.1 above. Individuals may assume only one of the  |
|               | Officer, Administrator and Auditor roles.            |
|               | Individuals designated as Officer or Administrator   |
|               | may also assume the Operator role. An auditor may    |
|               | not assume any other role. The CA and RA software    |
|               | and hardware shall identify and authenticate its     |
|               | users and shall enforce these roles. No individual   |
|               | shall have more than one identity.                   |
+---------------+------------------------------------------------------+

The FBCA shall operate at the High Assurance level.

## Personnel Controls

### Background, Qualifications, Experience, & Security Clearance Requirements

> Each Entity shall identify at least one individual or group
> responsible and accountable for the operation of each CA in that
> Entity. For the FBCA, these are the Federal PKI Policy Authority and
> the FPKI Management Authority.

All persons filling trusted roles shall be selected on the basis of
loyalty, trustworthiness, and integrity. For the FBCA and Federal Agency
PKIs, regardless of the assurance level, and for state and local
government PKIs operated in the U.S. at High Assurance, all trusted
roles are required to be held by U.S. citizens. For PKIs operated at
Medium Assurance and Medium Hardware, each person filling a trusted role
must satisfy at least one of the following:

-   The person shall be a citizen of the country where the CA is
    located; or

-   For PKIs operated on behalf of multinational governmental
    organizations, the person shall be a citizen of one of the member
    countries; or

-   For PKIs located within the European Union, the person shall be a
    citizen of one of the member States of the European Union; or

-   For PKIs other than the FBCA and Federal Agency PKIs, the person
    shall have a security clearance equivalent to U.S. Secret or higher
    issued by a NATO member nation or major non-NATO ally as defined by
    the International Traffic in Arms Regulation (ITAR) -- 22 CFR
    120.32; or

-   For RA personnel only, in addition to the above, the person may be a
    citizen of the country where the RA is located.

For PKIs, apart from the FBCA and Federal Agency PKIs, operated at
Rudimentary, Basic, Medium-CBP and Medium Hardware-CBP, there is no
citizenship requirement or security clearance specified.

FPKI Management Authority personnel acting in trusted roles shall hold
TOP SECRET security clearances.

### Background Check Procedures

FPKI Management Authority personnel acting in trusted roles shall, at a
minimum, undergo procedures necessary to be cleared at the TOP SECRET
level.

Entity CA personnel shall, at a minimum, pass a background investigation
covering the following areas:

-   Employment;

-   Education;

-   Place of residence;

-   Law Enforcement; and

-   References.

The period of investigation must cover at least the last five years for
each area, excepting the residence check which must cover at least the
last three years. Regardless of the date of award, the highest
educational degree shall be verified.

Adjudication of the background investigation shall be performed by a
competent adjudication authority using a process consistent with
Executive Order 12968 August 1995, or equivalent.

### Training Requirements

All personnel performing duties with respect to the operation of the
FBCA or Entity CA shall receive comprehensive training in all
operational duties they are expected to perform, including disaster
recovery and business continuity procedures.

In addition, personnel performing duties with respect to the operation
of the FBCA or Entity CA shall receive comprehensive training, or
demonstrate competence, in the following areas:

-   CA/RA security principles and mechanisms;

-   All PKI software versions in use on the CA system.

Documentation shall be maintained identifying all personnel who received
training and the level of training completed. Where competence was
demonstrated in lieu of training, supporting documentation shall be
maintained.

### Retraining Frequency & Requirements

Individuals responsible for PKI roles shall be aware of changes in the
FBCA and Entity CA operation. Any significant change to the operations
shall have a training (awareness) plan, and the execution of such plan
shall be documented. Examples of such changes are FBCA and Entity CA
software or hardware upgrade, changes in automated security systems, and
relocation of equipment.

Documentation shall be maintained identifying all personnel who received
training and the level of training completed.

### Job Rotation Frequency & Sequence

For the FBCA, any job rotation frequency and sequencing procedures shall
provide for continuity and integrity of the FBCA services.

For Entity CAs, no stipulation.

### Sanctions for Unauthorized Actions

The FPKI Management Authority shall take appropriate actions where
personnel have performed actions involving the FBCA or its repository
not authorized in this CP, the FBCA CPS, or other procedures published
by the FPKI Management Authority.

For Entity CAs, no stipulation.

### Independent Contractor Requirements

Contractor personnel employed to perform functions pertaining to the
FBCA or an Entity CA shall meet the personnel requirements set forth in
the FBCA CP or Entity CP, as applicable.

### Documentation Supplied To Personnel

For the FBCA and Entity CAs, documentation sufficient to define duties
and procedures for each trusted role shall be provided to the personnel
filling that role.

## Audit Logging Procedures

Audit log files shall be generated for all events relating to the
security of the FBCA or Entity CAs. Where possible, the security audit
logs shall be automatically collected. Where this is not possible, a
logbook, paper form, or other physical mechanism shall be used. All
security audit logs, both electronic and non-electronic, shall be
retained and made available during compliance audits.

### Types of Events Recorded

A message from any source received by the FBCA or Entity CA requesting
an action related to the operational state of the CA is an auditable
event. At a minimum, each audit record shall include the following
(either recorded automatically or manually for each auditable event):

-   The type of event,

-   The date and time the event occurred,

-   A success or failure indicator, where appropriate

-   The identity of the entity and/or operator (of the FBCA or Entity
    CA) that caused the event,

Detailed audit requirements are listed in the table below according to
the level of assurance. The FBCA shall record the events identified in
the table for High Assurance.

All security auditing capabilities of the FBCA or Entity CA operating
system and CA applications required by this CP shall be enabled. As a
result, most of the events identified in the table shall be
automatically recorded. Where events cannot be automatically recorded,
the CA shall implement manual procedures to satisfy this requirement.

+-------------------------------+-----------+------+-----------+-----+
| **Auditable Event**           | **Rudi    | *    | *         | **  |
|                               | mentary** | *Bas | *Medium** | Hig |
|                               |           | ic** |           | h** |
|                               |           |      | **(all    |     |
|                               |           |      | po        |     |
|                               |           |      | licies)** |     |
+===============================+===========+======+===========+=====+
| **SECURITY AUDIT**            |           |      |           |     |
+-------------------------------+-----------+------+-----------+-----+
| Any changes to the Audit      |           | X    | X         | X   |
| parameters, e.g., audit       |           |      |           |     |
| frequency, type of event      |           |      |           |     |
| audited                       |           |      |           |     |
+-------------------------------+-----------+------+-----------+-----+
| Any attempt to delete or      |           | X    | X         | X   |
| modify the Audit logs         |           |      |           |     |
+-------------------------------+-----------+------+-----------+-----+
| Obtaining a third-party       |           | X    | X         | X   |
| time-stamp                    |           |      |           |     |
+-------------------------------+-----------+------+-----------+-----+
| **IDENTIFICATION AND          |           |      |           |     |
| AUTHENTICATION**              |           |      |           |     |
+-------------------------------+-----------+------+-----------+-----+
| Successful and unsuccessful   |           | X    | X         | X   |
| attempts to assume a role     |           |      |           |     |
+-------------------------------+-----------+------+-----------+-----+
| The value of *maximum         |           | X    | X         | X   |
| authentication attempts* is   |           |      |           |     |
| changed                       |           |      |           |     |
+-------------------------------+-----------+------+-----------+-----+
| The number of unsuccessful    |           | X    | X         | X   |
| authentication attempts       |           |      |           |     |
| exceeds the *maximum          |           |      |           |     |
| authentication attempts*      |           |      |           |     |
| during user login             |           |      |           |     |
+-------------------------------+-----------+------+-----------+-----+
| An Administrator unlocks an   |           | X    | X         | X   |
| account that has been locked  |           |      |           |     |
| as a result of unsuccessful   |           |      |           |     |
| authentication attempts       |           |      |           |     |
+-------------------------------+-----------+------+-----------+-----+
| An Administrator changes the  |           | X    | X         | X   |
| type of authenticator, e.g.,  |           |      |           |     |
| from password to biometrics   |           |      |           |     |
+-------------------------------+-----------+------+-----------+-----+
| **LOCAL DATA ENTRY**          |           |      |           |     |
+-------------------------------+-----------+------+-----------+-----+
| All security-relevant data    |           | X    | X         | X   |
| that is entered in the system |           |      |           |     |
+-------------------------------+-----------+------+-----------+-----+
| **REMOTE DATA ENTRY**         |           |      |           |     |
+-------------------------------+-----------+------+-----------+-----+
| All security-relevant         |           | X    | X         | X   |
| messages that are received by |           |      |           |     |
| the system                    |           |      |           |     |
+-------------------------------+-----------+------+-----------+-----+
| **DATA EXPORT AND OUTPUT**    |           |      |           |     |
+-------------------------------+-----------+------+-----------+-----+
| All successful and            |           | X    | X         | X   |
| unsuccessful requests for     |           |      |           |     |
| confidential and              |           |      |           |     |
| security-relevant information |           |      |           |     |
+-------------------------------+-----------+------+-----------+-----+
| **KEY GENERATION**            |           |      |           |     |
+-------------------------------+-----------+------+-----------+-----+
| Whenever the CA generates a   | X         | X    | X         | X   |
| key. (Not mandatory for       |           |      |           |     |
| single session or one-time    |           |      |           |     |
| use symmetric keys)           |           |      |           |     |
+-------------------------------+-----------+------+-----------+-----+
| **PRIVATE KEY LOAD AND        |           |      |           |     |
| STORAGE**                     |           |      |           |     |
+-------------------------------+-----------+------+-----------+-----+
| The loading of Component      | X         | X    | X         | X   |
| private keys                  |           |      |           |     |
+-------------------------------+-----------+------+-----------+-----+
| All access to certificate     | X         | X    | X         | X   |
| subject private keys retained |           |      |           |     |
| within the CA for key         |           |      |           |     |
| recovery purposes             |           |      |           |     |
+-------------------------------+-----------+------+-----------+-----+
| **TRUSTED PUBLIC KEY ENTRY,   |           |      |           |     |
| DELETION AND STORAGE**        |           |      |           |     |
+-------------------------------+-----------+------+-----------+-----+
| All changes to the trusted    | X         | X    | X         | X   |
| public keys, including        |           |      |           |     |
| additions and deletions       |           |      |           |     |
+-------------------------------+-----------+------+-----------+-----+
| **SECRET KEY STORAGE**        |           |      |           |     |
+-------------------------------+-----------+------+-----------+-----+
| The manual entry of secret    |           |      | X         | X   |
| keys used for authentication  |           |      |           |     |
+-------------------------------+-----------+------+-----------+-----+
| **PRIVATE AND SECRET KEY      |           |      |           |     |
| EXPORT**                      |           |      |           |     |
+-------------------------------+-----------+------+-----------+-----+
| The export of private and     | X         | X    | X         | X   |
| secret keys (keys used for a  |           |      |           |     |
| single session or message are |           |      |           |     |
| excluded)                     |           |      |           |     |
+-------------------------------+-----------+------+-----------+-----+
| **CERTIFICATE REGISTRATION**  |           |      |           |     |
+-------------------------------+-----------+------+-----------+-----+
| All certificate requests      | X         | X    | X         | X   |
+-------------------------------+-----------+------+-----------+-----+
| **CERTIFICATE REVOCATION**    |           |      |           |     |
+-------------------------------+-----------+------+-----------+-----+
| All certificate revocation    |           | X    | X         | X   |
| requests                      |           |      |           |     |
+-------------------------------+-----------+------+-----------+-----+
| **CERTIFICATE STATUS CHANGE   |           |      |           |     |
| APPROVAL**                    |           |      |           |     |
+-------------------------------+-----------+------+-----------+-----+
| The approval or rejection of  |           | X    | X         | X   |
| a certificate status change   |           |      |           |     |
| request                       |           |      |           |     |
+-------------------------------+-----------+------+-----------+-----+
| **CA CONFIGURATION**          |           |      |           |     |
+-------------------------------+-----------+------+-----------+-----+
| Any security-relevant changes |           | X    | X         | X   |
| to the configuration of the   |           |      |           |     |
| CA                            |           |      |           |     |
+-------------------------------+-----------+------+-----------+-----+
|                               |           |      |           |     |
+-------------------------------+-----------+------+-----------+-----+
| **ACCOUNT ADMINISTRATION**    |           |      |           |     |
+-------------------------------+-----------+------+-----------+-----+
| Roles and users are added or  | X         | X    | X         | X   |
| deleted                       |           |      |           |     |
+-------------------------------+-----------+------+-----------+-----+
| The access control privileges | X         | X    | X         | X   |
| of a user account or a role   |           |      |           |     |
| are modified                  |           |      |           |     |
+-------------------------------+-----------+------+-----------+-----+
| **CERTIFICATE PROFILE         |           |      |           |     |
| MANAGEMENT**                  |           |      |           |     |
+-------------------------------+-----------+------+-----------+-----+
| All changes to the            | X         | X    | X         | X   |
| certificate profile           |           |      |           |     |
+-------------------------------+-----------+------+-----------+-----+
| **REVOCATION PROFILE          |           |      |           |     |
| MANAGEMENT**                  |           |      |           |     |
+-------------------------------+-----------+------+-----------+-----+
| All changes to the revocation |           | X    | X         | X   |
| profile                       |           |      |           |     |
+-------------------------------+-----------+------+-----------+-----+
| **CERTIFICATE REVOCATION LIST |           |      |           |     |
| PROFILE MANAGEMENT**          |           |      |           |     |
+-------------------------------+-----------+------+-----------+-----+
| All changes to the            |           | X    | X         | X   |
| certificate revocation list   |           |      |           |     |
| profile                       |           |      |           |     |
+-------------------------------+-----------+------+-----------+-----+
| **MISCELLANEOUS**             |           |      |           |     |
+-------------------------------+-----------+------+-----------+-----+
| Appointment of an individual  | X         | X    | X         | X   |
| to a Trusted Role             |           |      |           |     |
+-------------------------------+-----------+------+-----------+-----+
| Designation of personnel for  |           |      | X         | X   |
| multiparty control            |           |      |           |     |
+-------------------------------+-----------+------+-----------+-----+
| Installation of the Operating |           | X    | X         | X   |
| System                        |           |      |           |     |
+-------------------------------+-----------+------+-----------+-----+
| Installation of the CA        |           | X    | X         | X   |
+-------------------------------+-----------+------+-----------+-----+
| Installing hardware           |           |      | X         | X   |
| cryptographic modules         |           |      |           |     |
+-------------------------------+-----------+------+-----------+-----+
| Removing hardware             |           |      | X         | X   |
| cryptographic modules         |           |      |           |     |
+-------------------------------+-----------+------+-----------+-----+
| Destruction of cryptographic  |           | X    | X         | X   |
| modules                       |           |      |           |     |
+-------------------------------+-----------+------+-----------+-----+
| System Startup                |           | X    | X         | X   |
+-------------------------------+-----------+------+-----------+-----+
| Logon Attempts to CA          |           | X    | X         | X   |
| Applications                  |           |      |           |     |
+-------------------------------+-----------+------+-----------+-----+
| Receipt of Hardware/Software  |           |      | X         | X   |
+-------------------------------+-----------+------+-----------+-----+
| Attempts to set passwords     |           | X    | X         | X   |
+-------------------------------+-----------+------+-----------+-----+
| Attempts to modify passwords  |           | X    | X         | X   |
+-------------------------------+-----------+------+-----------+-----+
| Backing up CA internal        |           | X    | X         | X   |
| database                      |           |      |           |     |
+-------------------------------+-----------+------+-----------+-----+
| Restoring CA internal         |           | X    | X         | X   |
| database                      |           |      |           |     |
+-------------------------------+-----------+------+-----------+-----+
| File manipulation (e.g.,      |           |      | X         | X   |
| creation, renaming, moving)   |           |      |           |     |
+-------------------------------+-----------+------+-----------+-----+
| Posting of any material to a  |           |      | X         | X   |
| repository                    |           |      |           |     |
+-------------------------------+-----------+------+-----------+-----+
| Access to CA internal         |           |      | X         | X   |
| database                      |           |      |           |     |
+-------------------------------+-----------+------+-----------+-----+
| All certificate compromise    |           | X    | X         | X   |
| notification requests         |           |      |           |     |
+-------------------------------+-----------+------+-----------+-----+
| Loading tokens with           |           |      | X         | X   |
| certificates                  |           |      |           |     |
+-------------------------------+-----------+------+-----------+-----+
| Shipment of Tokens            |           |      | X         | X   |
+-------------------------------+-----------+------+-----------+-----+
| Zeroizing tokens              |           | X    | X         | X   |
+-------------------------------+-----------+------+-----------+-----+
| Re-key of the CA              | X         | X    | X         | X   |
+-------------------------------+-----------+------+-----------+-----+
| Configuration changes to the  |           |      |           |     |
| CA server involving:          |           |      |           |     |
+-------------------------------+-----------+------+-----------+-----+
| \- Hardware                   |           | X    | X         | X   |
+-------------------------------+-----------+------+-----------+-----+
| \- Software                   |           | X    | X         | X   |
+-------------------------------+-----------+------+-----------+-----+
| \- Operating System           |           | X    | X         | X   |
+-------------------------------+-----------+------+-----------+-----+
| \- Patches                    |           | X    | X         | X   |
+-------------------------------+-----------+------+-----------+-----+
| \- Security Profiles          |           |      | X         | X   |
+-------------------------------+-----------+------+-----------+-----+
| **PHYSICAL ACCESS / SITE      |           |      |           |     |
| SECURITY**                    |           |      |           |     |
+-------------------------------+-----------+------+-----------+-----+
| Personnel Access to room      |           |      | X         | X   |
| housing CA                    |           |      |           |     |
+-------------------------------+-----------+------+-----------+-----+
| Access to the CA server       |           |      | X         | X   |
+-------------------------------+-----------+------+-----------+-----+
| Known or suspected violations |           | X    | X         | X   |
| of physical security          |           |      |           |     |
+-------------------------------+-----------+------+-----------+-----+
| **ANOMALIES**                 |           |      |           |     |
+-------------------------------+-----------+------+-----------+-----+
| Software Error conditions     |           | X    | X         | X   |
+-------------------------------+-----------+------+-----------+-----+
| Software check integrity      |           | X    | X         | X   |
| failures                      |           |      |           |     |
+-------------------------------+-----------+------+-----------+-----+
| Receipt of improper messages  |           |      | X         | X   |
+-------------------------------+-----------+------+-----------+-----+
| Misrouted messages            |           |      | X         | X   |
+-------------------------------+-----------+------+-----------+-----+
| Network attacks (suspected or |           | X    | X         | X   |
| confirmed)                    |           |      |           |     |
+-------------------------------+-----------+------+-----------+-----+
| Equipment failure             | X         | X    | X         | X   |
+-------------------------------+-----------+------+-----------+-----+
| Electrical power outages      |           |      | X         | X   |
+-------------------------------+-----------+------+-----------+-----+
| Uninterruptible Power Supply  |           |      | X         | X   |
| (UPS) failure                 |           |      |           |     |
+-------------------------------+-----------+------+-----------+-----+
| Obvious and significant       |           |      | X         | X   |
| network service or access     |           |      |           |     |
| failures                      |           |      |           |     |
+-------------------------------+-----------+------+-----------+-----+
| Violations of Certificate     | X         | X    | X         | X   |
| Policy                        |           |      |           |     |
+-------------------------------+-----------+------+-----------+-----+
| Violations of Certification   | X         | X    | X         | X   |
| Practice Statement            |           |      |           |     |
+-------------------------------+-----------+------+-----------+-----+
| Resetting Operating System    |           | X    | X         | X   |
| clock                         |           |      |           |     |
+-------------------------------+-----------+------+-----------+-----+

### Frequency of Processing Log

Audit logs shall be reviewed in accordance to the table below. Such
reviews involve verifying that the log has not been tampered with, and
then briefly inspecting all log entries, with a more thorough
investigation of any alerts or irregularities in the log. Examples of
irregularities include discontinuities in the logs and loss of audit
data. Actions taken as a result of these reviews shall be documented.

For the FBCA, the FPKI Management Authority shall explain all
significant events in an audit log summary.

+-----------------+----------------------------------------------------+
| Assurance Level | Review Audit Log                                   |
+=================+====================================================+
| Rudimentary     | Only required for cause                            |
+-----------------+----------------------------------------------------+
| Basic           | Only required for cause                            |
+-----------------+----------------------------------------------------+
| Medium          | At least once every two months                     |
|                 |                                                    |
| (all policies)  | Statistically significant set of security audit    |
|                 | data generated by Entity CAs since the last review |
|                 | shall be examined (where the confidence intervals  |
|                 | for each category of security audit data are       |
|                 | determined by the security ramifications of the    |
|                 | category and the availability of tools to perform  |
|                 | such a review), as well as a reasonable search for |
|                 | any evidence of malicious activity                 |
+-----------------+----------------------------------------------------+
| High            | At least once per month                            |
|                 |                                                    |
|                 | Statistically significant set of security audit    |
|                 | data generated by Entity CAs since the last review |
|                 | shall be examined (where the confidence intervals  |
|                 | for each category of security audit data are       |
|                 | determined by the security ramifications of the    |
|                 | category and the availability of tools to perform  |
|                 | such a review), as well as a reasonable search for |
|                 | any evidence of malicious activity                 |
+-----------------+----------------------------------------------------+

For the FBCA, 100% of security audit data generated by the FBCA since
the last review shall be examined.

### Retention Period for Audit Logs

For Medium, Medium Hardware, and High Assurance, audit logs shall be
retained on-site until reviewed, as well as being retained in the manner
described below. For Rudimentary and Basic Assurance, audit logs shall
be retained on-site for at least two months or until reviewed, as well
as being retained in the manner described below. The individual who
removes audit logs from the FBCA or Entity CA system shall be an
official different from the individuals who, in combination, command the
FBCA or an Entity CA signature key.

### Protection of Audit Logs

FBCA (or Entity CA) system configuration and procedures must be
implemented together to ensure that:

-   Only personnel assigned to trusted roles have read access to the
    logs;

-   Only authorized people may archive audit logs; and,

-   Audit logs are not modified.

The entity performing audit log archive need not have modify access, but
procedures must be implemented to protect archived data from destruction
prior to the end of the audit log retention period (note that deletion
requires modification access).

The off-site storage location for audit logs shall be a safe, secure
location separate from the CA equipment.

### Audit Log Backup Procedures

Audit logs and audit summaries shall be backed up at least monthly. A
copy of the audit log shall be sent off-site on a monthly basis.

### Audit Collection System (internal vs. external)

The audit log collection system may or may not be external to the FBCA
or Entity CA system. Automated audit processes shall be invoked at
system (or application) startup, and cease only at system (or
application) shutdown. Should it become apparent that an automated audit
system has failed, and the integrity of the system or confidentiality of
the information protected by the system is at risk, then the FPKI
Management Authority Administrator (or comparable Entity authority)
shall determine whether to suspend FBCA operation (or Entity CA
operation respectively) until the problem is remedied.

### Notification to Event-Causing Subject

This CP imposes no requirement to provide notice that an event was
audited to the individual, organization, device, or application that
caused the event.

### Vulnerability Assessments

FBCA personnel shall routinely assess whether the CA system or its
components have been attacked or breached.

For Entity CAs, personnel shall perform routine assessments for evidence
of malicious activity.

## Records Archive

Executive branch agencies must follow either the General Records
Schedules established by the National Archives and Records
Administration or an agency-specific schedule as applicable. All other
entities shall comply with their respective records retention policies
in accordance with whatever laws apply to those entities.

FBCA or Entity CA archive records shall be sufficiently detailed as to
verify that the FBCA or Entity CA was properly operated as well as
verify the validity of any certificate (including those revoked or
expired) issued by the FBCA or Entity CA.

### Types of Events Archived

At a minimum, the following data shall be recorded for archive in
accordance with each assurance level:

+------------------------------+-------------+-----+-----------+------+
| **Data To Be Archived**      | **Ru        | **B | *         | **Hi |
|                              | dimentary** | asi | *Medium** | gh** |
|                              |             | c** |           |      |
|                              |             |     | **(all    |      |
|                              |             |     | po        |      |
|                              |             |     | licies)** |      |
+==============================+=============+=====+===========+======+
| CA accreditation (if         | X           | X   | X         | X    |
| applicable)                  |             |     |           |      |
+------------------------------+-------------+-----+-----------+------+
| Certificate Policy           | X           | X   | X         | X    |
+------------------------------+-------------+-----+-----------+------+
| Certification Practice       | X           | X   | X         | X    |
| Statement                    |             |     |           |      |
+------------------------------+-------------+-----+-----------+------+
| Contractual obligations      | X           | X   | X         | X    |
+------------------------------+-------------+-----+-----------+------+
| Other agreements concerning  | X           | X   | X         | X    |
| operations of the CA         |             |     |           |      |
+------------------------------+-------------+-----+-----------+------+
| System and equipment         | X           | X   | X         | X    |
| configuration                |             |     |           |      |
+------------------------------+-------------+-----+-----------+------+
| Modifications and updates to | X           | X   | X         | X    |
| system or configuration      |             |     |           |      |
+------------------------------+-------------+-----+-----------+------+
| Certificate requests         | X           | X   | X         | X    |
+------------------------------+-------------+-----+-----------+------+
| Revocation requests          |             | X   | X         | X    |
+------------------------------+-------------+-----+-----------+------+
| Subscriber identity          |             | X   | X         | X    |
| Authentication data as per   |             |     |           |      |
| Section 3.2.3                |             |     |           |      |
+------------------------------+-------------+-----+-----------+------+
| Documentation of receipt and |             | X   | X         | X    |
| acceptance of certificates   |             |     |           |      |
| (if applicable)              |             |     |           |      |
+------------------------------+-------------+-----+-----------+------+
| Subscriber Agreements        |             | X   | X         | X    |
+------------------------------+-------------+-----+-----------+------+
| Documentation of receipt of  |             | X   | X         | X    |
| tokens                       |             |     |           |      |
+------------------------------+-------------+-----+-----------+------+
| All certificates issued or   | X           | X   | X         | X    |
| published                    |             |     |           |      |
+------------------------------+-------------+-----+-----------+------+
| Record of CA Re-key          | X           | X   | X         | X    |
+------------------------------+-------------+-----+-----------+------+
| All CRLs issued and/or       |             | X   | X         | X    |
| published                    |             |     |           |      |
+------------------------------+-------------+-----+-----------+------+
| Other data or applications   |             | X   | X         | X    |
| to verify archive contents   |             |     |           |      |
+------------------------------+-------------+-----+-----------+------+
| Compliance Auditor reports   |             | X   | X         | X    |
+------------------------------+-------------+-----+-----------+------+
| Any changes to the Audit     |             | X   | X         | X    |
| parameters, e.g., audit      |             |     |           |      |
| frequency, type of event     |             |     |           |      |
| audited                      |             |     |           |      |
+------------------------------+-------------+-----+-----------+------+
| Any attempt to delete or     |             | X   | X         | X    |
| modify the Audit logs        |             |     |           |      |
+------------------------------+-------------+-----+-----------+------+
| Whenever the CA generates a  | X           | X   | X         | X    |
| key. (Not mandatory for      |             |     |           |      |
| single session or one-time   |             |     |           |      |
| use symmetric keys)          |             |     |           |      |
+------------------------------+-------------+-----+-----------+------+
| All access to certificate    | X           | X   | X         | X    |
| subject private keys         |             |     |           |      |
| retained within the CA for   |             |     |           |      |
| key recovery purposes        |             |     |           |      |
+------------------------------+-------------+-----+-----------+------+
| All changes to the trusted   | X           | X   | X         | X    |
| public keys, including       |             |     |           |      |
| additions and deletions      |             |     |           |      |
+------------------------------+-------------+-----+-----------+------+
| The export of private and    | X           | X   | X         | X    |
| secret keys (keys used for a |             |     |           |      |
| single session or message    |             |     |           |      |
| are excluded)                |             |     |           |      |
+------------------------------+-------------+-----+-----------+------+
| The approval or rejection of |             | X   | X         | X    |
| a certificate status change  |             |     |           |      |
| request                      |             |     |           |      |
+------------------------------+-------------+-----+-----------+------+
| Appointment of an individual | X           | X   | X         | X    |
| to a Trusted Role            |             |     |           |      |
+------------------------------+-------------+-----+-----------+------+
| Destruction of cryptographic |             | X   | X         | X    |
| modules                      |             |     |           |      |
+------------------------------+-------------+-----+-----------+------+
| All certificate compromise   |             | X   | X         | X    |
| notifications                |             |     |           |      |
+------------------------------+-------------+-----+-----------+------+
| Remedial action taken as a   |             | X   | X         | X    |
| result of violations of      |             |     |           |      |
| physical security            |             |     |           |      |
+------------------------------+-------------+-----+-----------+------+
| Violations of Certificate    | X           | X   | X         | X    |
| Policy                       |             |     |           |      |
+------------------------------+-------------+-----+-----------+------+
| Violations of Certification  | X           | X   | X         | X    |
| Practice Statement           |             |     |           |      |
+------------------------------+-------------+-----+-----------+------+

### Retention Period for Archive

The minimum retention periods for archive data are identified below.
Executive branch agencies must follow either the General Records
Schedule established by the National Archives and Records Administration
or an agency-specific schedule as applicable. All other entities shall
comply with their respective records retention policies in accordance
with whatever laws apply to those entities.

This minimum retention period for these records is intended only to
facilitate the operation of the FBCA and the entities' CAs.

+------------------------+---------------------------------------------+
| **Assurance Level**    | **Minimum Retention Period**                |
+========================+=============================================+
| Rudimentary            | 7 Years & 6 Months                          |
+------------------------+---------------------------------------------+
| Basic                  | 7 Years & 6 Months                          |
+------------------------+---------------------------------------------+
| Medium                 | 10 Years & 6 Months                         |
|                        |                                             |
| (all policies)         |                                             |
+------------------------+---------------------------------------------+
| High                   | 20 Years & 6 Months                         |
+------------------------+---------------------------------------------+

### Protection of Archive

No unauthorized user shall be permitted to write to or delete the
archive. For the FBCA, archived records may be moved to another medium
when authorized by the FPKI Management Authority Administrator. The
contents of the archive shall not be released except in accordance with
Sections 9.3 & 9.4. Records of individual transactions may be released
upon request of any subscribers involved in the transaction or their
legally recognized agents. Archive media shall be stored in a safe,
secure storage facility separate from the FBCA or Entity CA itself.

If the original media cannot retain the data for the required period, a
mechanism to periodically transfer the archived data to new media shall
be defined by the archive site.

Alternatively, an Entity may retain data using whatever procedures have
been approved by NARA for that category of documents. Applications
required to process the archive data shall also be maintained for a
period determined by the Federal PKI Policy Authority for the FBCA (or
Entity for the Entity CA).

Prior to the end of the archive retention period, the FPKI Management
Authority shall provide archived data and the applications necessary to
read the archives to a Federal PKI Policy Authority approved archival
facility, which shall retain the applications necessary to read this
archived data.

### Archive Backup Procedures

If a cross-certified entity chooses to back up its archive records, the
CPS or a referenced document shall describe how the records are backed
up and managed.

### Requirements for Time-Stamping of Records

CA archive records shall be automatically time-stamped as they are
created. The CPS shall describe how system clocks used for time-stamping
are maintained in synchrony with an authoritative time standard.

### Archive Collection System (internal or external)

No stipulation.

### Procedures to Obtain & Verify Archive Information

Procedures detailing how to create, verify, package, transmit, and store
archive information shall be published in the applicable CP or CPS.

The contents of the archive shall not be released except as determined
by the Federal PKI Policy Authority for the FBCA (or Entity for the
Entity CA) or as required by law. Records of individual transactions may
be released upon request of any subscribers involved in the transaction
or their legally recognized agents.

## Key Changeover

To minimize risk from compromise of a CA's private signing key, that key
may be changed often; from that time on, only the new key will be used
for certificate signing purposes. The older, but still valid, public key
will be available to verify old signatures until all of the certificates
signed using the associated private key have also expired. If the old
private key is used to sign CRLs that cover certificates signed with
that key, then the old key must be retained and protected.

For the FBCA, key changeover procedures will establish key rollover
certificates where a certificate containing the old public key will be
signed by the new private key, and a certificate containing the new
public key will be signed by the old private key.

Entity CAs either must establish key rollover certificates as described
above or must obtain a new CA certificate for the new public key from
the issuers of their current certificates.

## Compromise & Disaster Recovery

### Incident and Compromise Handling Procedures

The members of the Federal PKI Policy Authority shall be notified if any
of the following cases occur:

-   suspected or detected compromise of the FBCA systems;

-   physical or electronic attempts to penetrate FBCA systems;

-   denial of service attacks on FBCA components;

-   any incident preventing the FBCA from issuing a CRL within 24 hours
    of the time specified in the next update field of its currently
    valid CRL.

This will allow member entities to protect their interests as Relying
Parties.

The FPKI Management Authority shall reestablish operational capabilities
as quickly as possible in accordance with procedures set forth in the
FBCA CPS.

Entity CAs shall provide notice as required by the applicable MOA.

### Computing Resources, Software, and/Or Data Are Corrupted

When computing resources, software, and/or data are corrupted, the FBCA
and Entity CAs shall respond as follows:

-   Before returning to operation, ensure that the system's integrity
    has been restored

-   If the CA signature keys are not destroyed**,** CA operation shall
    be reestablished, giving priority to the ability to generate
    certificate status information within the CRL issuance schedule
    specified in 4.9.7, Table 1.

-   If the CA signature keys are destroyed**,** CA operation shall be
    reestablished as quickly as possible, giving priority to the
    generation of a new CA key pair.

### Entity (CA) Private Key Compromise Procedures

If the FBCA or Entity CA signature keys are compromised or lost (such
that compromise is possible even though not certain):

-   The Federal PKI Policy Authority and all of its member entities
    shall be notified so that entities may issue CRLs revoking any
    cross-certificates issued to the compromised CA;

-   A new FBCA or Entity CA key pair shall be generated by the FBCA or
    Entity CA in accordance with procedures set forth in the FBCA or
    Entity CPS; and

-   New FBCA or Entity CA certificates shall be issued to Entities also
    in accordance with the FBCA or Entity CPS.

If the CA distributes its key in a self-signed certificate, the new
self-signed certificate shall be distributed as specified in Section
6.1.4.

The FPKI Management Authority or Entity CA governing body shall also
investigate and report to the Federal PKI Policy Authority what caused
the compromise or loss, and what measures have been taken to preclude
recurrence.

### Business Continuity Capabilities after a Disaster

The FBCA directory system shall be deployed so as to provide 24 hour,
365 day per year availability. The FPKI Management Authority shall
implement features to provide high levels of directory reliability.

The FPKI Management Authority shall operate a hot backup site, whose
purpose is to ensure continuity of operations in the event of failure of
the primary site. The FBCA operations shall be designed to restore full
service within six (6) hours of primary system failure.

The FPKI Management Authority or Entity Principal CA shall at the
earliest feasible time securely advise the Federal PKI Policy Authority
and all of its member entities in the event of a disaster where the FBCA
or Entity Principal CA installation is physically damaged and all copies
of the FBCA or Entity Principal CA signature keys are destroyed.

Relying Parties may decide of their own volition whether to continue to
use certificates signed with the destroyed private key pending
reestablishment of FBCA operation with new certificates.

## CA & RA Termination

In the event of termination of the FBCA operation, certificates signed
by the FBCA shall be revoked and the Federal PKI Policy Authority shall
advise entities that have entered into MOAs with the Federal PKI Policy
Authority that FBCA operation has terminated so they may revoke
certificates they have issued to the FBCA. Prior to FBCA termination,
the FPKI Management Authority shall provide all archived data to an
archival facility.

Entities will be given as much advance notice as circumstances permit,
and attempts to provide alternative sources of interoperation will be
sought in the event the FBCA is terminated.

In the event that an Entity CA terminates operation, the Entity shall
provide notice to the FBCA prior to termination.

# Technical Security Controls

## Key Pair Generation & Installation

### Key Pair Generation

#### CA Key Pair Generation

Cryptographic keying material used to sign certificates, CRLs or status
information by the FBCA shall be generated in FIPS 140 validated
cryptographic modules. Cryptographic keying material used to sign
certificates, CRLs or status information by Entity CAs shall be
generated in FIPS 140 validated cryptographic modules or modules
validated under equivalent international standards.

For the FBCA, the modules shall meet or exceed Security Level 3. For
Entity CAs, the modules shall meet or exceed Security Level 1 (for
Rudimentary), Security Level 2 (for Basic, Medium, or Medium Hardware),
or Security Level 3 (for High). Multiparty control is required for CA
key pair generation for the FBCA and for Entity CAs operating at the
Medium, Medium Hardware, or High levels of assurance, as specified in
Section 5.2.2.

CA key pair generation must create a verifiable audit trail that the
security requirements for procedures were followed. For all levels of
assurance, the documentation of the procedure must be detailed enough to
show that appropriate role separation was used.

For High, Medium Hardware, and Medium Assurance, an independent third
party shall validate the execution of the key generation procedures
either by witnessing the key generation or by examining the signed and
documented record of the key generation.

#### Subscriber Key Pair Generation

Subscriber key pair generation may be performed by the subscriber, CA,
or RA. If the CA or RA generates subscriber key pairs, the requirements
for key pair delivery specified in Section 6.1.2 must also be met.

Key generation shall be performed using a FIPS approved method or
equivalent international standard.

At the High and Medium Hardware assurance levels, subscriber key
generation shall be performed using a validated hardware cryptographic
module. For Medium and Basic assurance, either validated software or
validated hardware cryptographic modules shall be used for key
generation.

### Private Key Delivery to Subscriber

If subscribers generate their own key pairs, then there is no need to
deliver private keys, and this section does not apply.

When CAs or RAs generate keys on behalf of the Subscriber, then the
private key must be delivered securely to the Subscriber. Private keys
may be delivered electronically or may be delivered on a hardware
cryptographic module. In all cases, the following requirements must be
met:

-   Anyone who generates a private signing key for a Subscriber shall
    not retain any copy of the key after delivery of the private key to
    the Subscriber.

-   The private key must be protected from activation, compromise, or
    modification during the delivery process.

-   The Subscriber shall acknowledge receipt of the private key(s).

-   Delivery shall be accomplished in a way that ensures that the
    correct tokens and activation data are provided to the correct
    Subscribers.

    -   For hardware modules, accountability for the location and state
        of the module must be maintained until the Subscriber accepts
        possession of it.

    -   For electronic delivery of private keys, the key material shall
        be encrypted using a cryptographic algorithm and key size at
        least as strong as the private key. Activation data shall be
        delivered using a separate secure channel.

    -   For shared key applications, organizational identities, and
        network devices, see also Section 3.2.

The FBCA (or Entity CA) must maintain a record of the subscriber
acknowledgement of receipt of the token.

### Public Key Delivery to Certificate Issuer

For CAs operating at the Basic, Medium, Medium Hardware, or High level
of assurance, the following requirements apply:

-   Where key pairs are generated by the Subscriber or RA, the public
    key and the Subscriber's identity must be delivered securely to the
    CA for certificate issuance.

-   The delivery mechanism shall bind the Subscriber's verified identity
    to the public key. If cryptography is used to achieve this binding,
    it must be at least as strong as the CA keys used to sign the
    certificate.

For Rudimentary Assurance, no stipulation.

### CA Public Key Delivery to Relying Parties

When a CA updates its signature key pair, the CA shall distribute the
new public key in a secure fashion. The new public key may be
distributed in a self-signed certificate, in a key rollover certificate,
or in a new CA (e.g., cross-) certificate obtained from the issuer(s) of
the current CA certificate(s).

Self-signed certificates shall be conveyed to relying parties in a
secure fashion to preclude substitution attacks.

Key rollover certificates are signed with the CA's current private key,
so secure distribution is not required.

CA Certificates are signed with the issuing CA's current private key, so
secure distribution is not required.

### Key Sizes

All FIPS-approved signature algorithms shall be considered acceptable;
additional restrictions on key sizes are detailed below.

For CAs that distribute self-signed certificates to relying parties, the
CA's subject public keys in such certificates shall be at least 2048
bits for RSA, or at least 224 bits for ECDSA. Those CAs that distribute
self-signed certificates and whose key pairs were generated before
September 13, 2005 may be 1024 bits for RSA.

CAs that generate certificates and CRLs under this policy shall use
signature keys of at least 1024 bits for RSA or DSA, and at least 160
bits for ECDSA. Beginning 01/01/2011, all valid certificates shall be
signed with keys of at least 2048 bits for RSA or at least 224 bits for
ECDSA.

CAs that generate certificates and CRLs under this policy shall use
SHA-1, SHA-224, SHA-256, SHA-384, or SHA-512 hash algorithm when
generating digital signatures. Signatures on certificates and CRLs that
are issued after 12/31/2010 shall be generated using, at a minimum,
SHA-224.

Where implemented, CSSes shall sign responses using the same signature
algorithm, key size, and hash algorithm used by the CA to sign CRLs.

End-entity certificates shall contain public keys that are at least 1024
bit for RSA, DSA, or Diffie-Hellman, or 160 bits for elliptic curve
algorithms. The following special conditions also apply:

-   End-entity certificates that include a keyUsage extension that only
    asserts the *digitalSignature* bit that expire on or after
    12/31/2013 shall contain public keys that are at least 2048 bits for
    RSA or DSA, or 224 bits for elliptic curve algorithms.

-   Beginning 01/01/2011, all valid end-entity certificates that include
    a keyUsage extension that asserts the *nonRepudiation*,
    *keyEncipherment*, *dataEncipherment*, or *keyAgreement* bit shall
    contain public keys that are at least 2048 bits for RSA, DSA, or
    Diffie-Hellman, or 224 bits for elliptic curve algorithms.

-   Beginning 01/01/2011, all valid end-entity certificates that do not
    include a keyUsage extension shall contain public keys that are at
    least 2048 bits for RSA, DSA, or Diffie-Hellman, or 224 bits for
    elliptic curve algorithms.

The FBCA shall not issue a cross-certificate with a validity period
extending beyond 12/31/2010 to any Entity Principal CA unless all of the
following conditions apply:

-   Certificates that expire after 12/31/2010 are signed with keys of at
    least 2048 bits for RSA or at least 224 bits for ECDSA.

-   End-entity certificates that include a keyUsage extension that
    asserts the *nonRepudiation*, *keyEncipherment*, *dataEncipherment*,
    or *keyAgreement* bit that expire on or after 12/31/2010 contain
    public keys that are at least 2048 bits for RSA, DSA, or
    Diffie-Hellman, or 224 bits for elliptic curve algorithms.

-   End-entity certificates that do not include a keyUsage extension
    that expire on or after 12/31/2010 contain public keys that are at
    least 2048 bits for RSA, DSA, or Diffie-Hellman, or 224 bits for
    elliptic curve algorithms.

Use of TLS or another protocol providing similar security to accomplish
any of the requirements of this CP shall require at a minimum triple-DES
or equivalent for the symmetric key, and at least 1024 bit RSA or
equivalent for the asymmetric keys through 12/31/2010. Use of TLS or
another protocol providing similar security to accomplish any of the
requirements of this CP shall require at a minimum AES (128 bits) or
equivalent for the symmetric key, and at least 2048 bit RSA or
equivalent for the asymmetric keys after 12/31/2010.

### Public Key Parameters Generation and Quality Checking

Public key parameters for signature algorithms defined in the Digital
Signature Standard (DSS) shall be generated in accordance with FIPS 186.

Parameter quality checking (including primality testing for prime
numbers) shall be performed in accordance with FIPS 186; additional
tests may be specified by the Federal PKI Policy Authority.

### Key Usage Purposes (as per X.509 v3 key usage field)

Public keys that are bound into certificates shall be certified for use
in signing or encrypting, but not both, except as specified below. The
use of a specific key is determined by the key usage extension in the
X.509 certificate.

FBCA issued certificates and CA certificates issued by Entity CAs shall
set two key usage bits: *cRLSign* and/or *keyCertSign*. Where the
subject signs OCSP responses, the certificate may also set the
*digitalSignature* and/or *nonRepudiation* bits.

Subscriber certificates shall assert key usages based on the intended
application of the key pair. In particular, certificates to be used for
digital signatures (including authentication) shall set the
*digitalSignature* and/or *nonRepudiation* bits. Certificates to be used
for key or data encryption shall set the *keyEncipherment* and/or
*dataEncipherment* bits. Certificates to be used for key agreement shall
set the *keyAgreement* bit.

Rudimentary, Basic, and Medium Assurance Level certificates may include
a single key for use with encryption and signature in support of legacy
applications. Such dual-use certificates shall be generated and managed
in accordance with their respective signature certificate requirements,
except where otherwise noted in this CP. Such dual-use certificates
shall never assert the non-repudiation key usage bit, and shall not be
used for authenticating data that will be verified on the basis of the
dual-use certificate at a future time. Entities are encouraged at all
levels of assurance to issue Subscribers two key pairs, one for key
management and one for digital signature and authentication.

## Private Key Protection & CryptoGraphic Module Engineering Controls

### Cryptographic Module Standards & Controls

The relevant standard for cryptographic modules is FIPS PUB 140,
*Security Requirements for Cryptographic Modules*.

Cryptographic modules shall be validated to the FIPS 140 level
identified in this section. Additionally, the Federal PKI Policy
Authority reserves the right to review technical documentation
associated with any cryptographic modules under consideration for use by
the FBCA.

The table below summarizes the minimum requirements for cryptographic
modules; higher levels may be used.

+-------------+---------------------+-----------+----------------------+
| **Assurance | **CA & CSS**        | **Sub     | **RA**               |
| Level**     |                     | scriber** |                      |
+-------------+---------------------+-----------+----------------------+
| Rudimentary | Level 1             | N/A       | Level 1 (Hardware or |
|             |                     |           | Software)            |
|             | (Hardware or        |           |                      |
|             | Software)           |           |                      |
+-------------+---------------------+-----------+----------------------+
| **Basic**   | Level 2 (Hardware   | Level 1   | Level 1 (Hardware or |
|             | or Software)        |           | Software)            |
+-------------+---------------------+-----------+----------------------+
| **Medium**  | Level 2 (Hardware)  | Level 1   | Level 2 (Hardware)   |
+-------------+---------------------+-----------+----------------------+
| **Medium    | Level 2 (Hardware)  | Level 2   | Level 2 (Hardware)   |
| Hardware**  |                     | (         |                      |
|             |                     | Hardware) |                      |
+-------------+---------------------+-----------+----------------------+
| **High**    | Level 3 (Hardware)  | Level 2   | Level 2 (Hardware)   |
|             |                     | (         |                      |
|             |                     | Hardware) |                      |
+-------------+---------------------+-----------+----------------------+

### Private Key Multi-Person Control

Use of the FBCA private signing key shall require action by multiple
persons as set forth in Section 5.2.2 of this CP.

Use of the Entity CA private signing key shall require action by
multiple persons at Medium, Medium Hardware, and High Assurance as set
forth in Section 5.2.2 of this CP.

### Private Key Escrow 

#### Escrow of FBCA and Entity CA private signature key

Under no circumstances shall an FBCA or Entity CA signature key used to
sign certificates or CRLs be escrowed.

#### Escrow of CA encryption keys

The FBCA shall not perform any encryption key recovery functions
involving encryption keys issued to Entity CAs. However, if encryption
key pairs need to be issued by the

FBCA covering repository system access or for other purposes, the
Federal PKI Policy

Authority shall publish applicable requirements for that purpose.

For Entities, no stipulation.

#### Escrow of Subscriber private signature keys

Subscriber private signature keys shall not be escrowed.

#### Escrow of Subscriber private encryption and dual use keys

Subscriber private dual use keys shall not be escrowed.

No stipulation with respect to escrow of subscriber private encryption
keys.

### Private Key Backup

#### Backup of FBCA & Entity CA Private Signature Key

FBCA private signature keys shall be backed up under multi-person
control, as specified in Section 5.2.2.

Backup of Entity CA private signature keys is required to facilitate
disaster recovery. Where required by Section 5.2.2, Entity CA private
signature keys shall be backed up under multi-person control.

At least one copy of the FBCA or Entity CA private signature key shall
be stored off site. All copies of the CA private signature key shall be
accounted for and protected in the same manner as the original.

***6.2.4.2 Backup of subscriber private signature key***

At the Medium Hardware and High assurance levels, Subscriber private
signature keys may not be backed up or copied.

At the Rudimentary, Basic, or Medium levels of assurance, Subscriber
private signature keys may be backed up or copied, but must be held in
the Subscriber's control.

Backed up subscriber private signature keys shall not be stored in plain
text form outside the cryptographic module. Storage must ensure security
controls consistent with the protection provided by the subscriber's
cryptographic module.

***6.2.4.3 Backup of Subscriber Key Management Private Keys***

Backed up subscriber private key management keys shall not be stored in
plain text form outside the cryptographic module. Storage must ensure
security controls consistent with the protection provided by the
subscriber's cryptographic module.

***6.2.4.4 Backup of CSS Private Key***

CSS private keys may be backed up. If backed up, all copies shall be
accounted for and protected in the same manner as the original.

### Private Key Archival

Private signature keys shall not be archived.

For private encryption keys (key management or key transport), no
stipulation.

### Private Key Transfer into or from a Cryptographic Module

FBCA and Entity CA private keys may be exported from the cryptographic
module only to perform CA key backup procedures as described in Section
6.2.4.1. At no time shall the CA private key exist in plain text outside
the cryptographic module.

All other keys shall be generated by and in a cryptographic module. In
the event that a private key is to be transported from one cryptographic
module to another, the private key must be encrypted during transport;
private keys must never exist in plaintext form outside the
cryptographic module boundary.

Private or symmetric keys used to encrypt other private keys for
transport must be protected from disclosure.

### Private Key Storage on Cryptographic Module

No stipulation beyond that specified in FIPS-140.

### Method of Activating Private Keys

For the FBCA and Entity CAs that operate at the Medium, Medium Hardware,
or High level of assurance, CA signing key activation requires
multiparty control as specified in Section 5.2.2.

The Subscriber must be authenticated to the cryptographic module before
the activation of any private key(s). Acceptable means of authentication
include but are not limited to pass-phrases, PINs or biometrics. Entry
of activation data shall be protected from disclosure (i.e., the data
should not be displayed while it is entered).

### Methods of Deactivating Private Keys

Cryptographic modules that have been activated shall not be available to
unauthorized access. After use, the cryptographic module shall be
deactivated, e.g., via a manual logout procedure, or automatically after
a period of inactivity as defined in the applicable CPS. CA Hardware
cryptographic modules shall be removed and stored in a secure container
when not in use.

### Method of Destroying Private Keys

Individuals in trusted roles shall destroy CA, RA and status server
(e.g., OCSP server) private signature keys when they are no longer
needed. Subscriber private signature keys shall be destroyed when they
are no longer needed, or when the certificates to which they correspond
expire or are revoked. For software cryptographic modules, this can be
overwriting the data. For hardware cryptographic modules, this will
likely be executing a "zeroize" command. Physical destruction of
hardware is not required.

### Cryptographic Module Rating

See Section 6.2.1.

## Other Aspects Of Key Management

### Public Key Archival

The public key is archived as part of the certificate archival.

### Certificate Operational Periods/Key Usage Periods 

The FBCA shall limit the use of its private keys to a maximum of three
years for certificate signing and six years for CRL signing. CAs that
distribute their self-signed certificates for use as trust anchors shall
limit the use of the associated private key to a maximum of 20 years;
the self-signed certificates shall have a lifetime not to exceed 37
years. For all other CAs, the CA shall limit the use of its private keys
to a maximum of six years for subscriber certificates and ten years for
CRL signing and OCSP responder certificates. Code and content signers
may use their private keys for three years; the lifetime of the
associated public keys shall not exceed eight years. Subscribers'
signature private keys and certificates have a maximum lifetime of three
years. Subscriber key management certificates have a maximum lifetime of
3 years; use of subscriber key management private keys is unrestricted.

CAs must not issue subscriber certificates that extend beyond the
expiration date of their own certificates and public keys.

The validity period of the subscriber certificate must not exceed the
routine re-key Identity Requirements as specified in section 3.3.1.

## Activation Data

### Activation Data Generation & Installation

The activation data used to unlock FBCA, Entity CA or subscriber private
keys, in conjunction with any other access control, shall have an
appropriate level of strength for the keys or data to be protected. If
the activation data must be transmitted, it shall be via an
appropriately protected channel, and distinct in time and place from the
associated cryptographic module. Where the FBCA or an Entity CA uses
passwords as activation data for the CA signing key, at a minimum the
activation data shall be changed upon CA re-key.

### Activation Data Protection

Data used to unlock private keys shall be protected from disclosure by a
combination of cryptographic and physical access control mechanisms.
Activation data shall be:

-   memorized

-   biometric in nature, or

-   recorded and secured at the level of assurance associated with the
    activation of the cryptographic module, and shall not be stored with
    the cryptographic module.

The protection mechanism shall include a facility to temporarily lock
the account, or terminate the application, after a predetermined number
of failed login attempts as set forth in the respective CP or CPS.

### Other Aspects of Activation Data

No stipulation.

## Computer Security Controls

### Specific Computer Security Technical Requirements

For the FBCA, the computer security functions listed below are required.
These functions may be provided by the operating system, or through a
combination of operating system, software, and physical safeguards. The
FBCA and its ancillary parts shall include the following functionality:

-   Require authenticated logins

-   Provide Discretionary Access Control

-   Provide a security audit capability

-   Restrict access control to FBCA services and PKI roles

-   Enforce separation of duties for PKI roles

-   Require identification and authentication of PKI roles and
    associated identities

-   Prohibit object re-use or require separation for FBCA random access
    memory

-   Require use of cryptography for session communication and database
    security

-   Archive FBCA history and audit data

-   Require self-test security related FBCA services

-   Require a trusted path for identification of PKI roles and
    associated identities

-   Require a recovery mechanisms for keys and the FBCA system

-   Enforce domain integrity boundaries for security critical processes

For Entity CAs, the computer security functions listed below are
required. These functions may be provided by the operating system, or
through a combination of operating system, software, and physical
safeguards. The Entity CA and its ancillary parts shall include the
following functionality:

-   authenticate the identity of users before permitting access to the
    system or applications;

-   manage privileges of users to limit users to their assigned roles;

-   generate and archive audit records for all transactions; (see
    Section 5.4)

-   enforce domain integrity boundaries for security critical processes;
    and

-   support recovery from key or system failure.

For Certificate Status Servers, the computer security functions listed
below are required:

-   authenticate the identity of users before permitting access to the
    system or applications;

-   manage privileges of users to limit users to their assigned roles;

-   enforce domain integrity boundaries for security critical processes;
    and

-   support recovery from key or system failure.

### Computer Security Rating

No Stipulation.

## Life-Cycle Security Controls

### System Development Controls

The System Development Controls for the FBCA and Entity CAs at the Basic
Assurance level and above are as follows:

-   For commercial off-the-shelf software, the software shall be
    designed and developed under a formal, documented development
    methodology.

-   For hardware and software developed specifically for a particular
    CA, the applicant shall demonstrate that security requirements were
    achieved through a combination of software verification &
    validation, structured development approach, and controlled
    development environment.

-   Where open source software has been utilized, the applicant shall
    demonstrate that security requirements were achieved through
    software verification & validation and structured
    development/life-cycle management.

-   Hardware and software procured to operate the CA shall be purchased
    and shipped in a fashion to reduce the likelihood that any
    particular component was tampered with (e.g., by ensuring the
    equipment was randomly selected at time of purchase).

-   The CA hardware and software shall be dedicated to performing one
    task: the CA. There shall be no other applications; hardware
    devices, network connections, or component software installed which
    are not part of the CA operation.

-   Proper care shall be taken to prevent malicious software from being
    loaded onto the CA equipment. Hardware and software shall be scanned
    for malicious code on first use and periodically thereafter.

-   Hardware and software updates shall be purchased or developed in the
    same manner as original equipment, and be installed by trusted and
    trained personnel in a defined manner.

### Security Management Controls

The configuration of the FBCA or Entity CA system as well as any
modifications and upgrades shall be documented and controlled. There
shall be a mechanism for detecting unauthorized modification to the FBCA
or Entity CA software or configuration. A formal configuration
management methodology shall be used for installation and ongoing
maintenance of the FBCA or Entity CA system. The FBCA or Entity CA
software, when first loaded, shall be verified as being that supplied
from the vendor, with no modifications, and be the version intended for
use. For the FBCA, the integrity of the software shall be verified by
the FPKI Management Authority at least weekly (e.g., in conjunction with
CRL publication).

### Life Cycle Security Ratings

No stipulation.

## Network Security Controls

Network security controls shall be employed to protect the FBCA and the
FBCA Internal Directory. Networking equipment shall turn off unused
network ports and services. Any network software installed on the FBCA
equipment shall be necessary to the functioning of the FBCA.

The FBCA Border Directory shall be connected to the Internet and provide
continuous service (except, when necessary, for brief periods of
maintenance or backup).

Any boundary control devices used to protect the Border directory or
FBCA local area network shall deny all but the necessary services to the
PKI equipment even if those services are enabled for other devices on
the network.

Entity CAs, RAs, directories, and certificate status servers shall
employ appropriate network security controls. Networking equipment shall
turn off unused network ports and services. Any network software present
shall be necessary to the functioning of the equipment.

## Time Stamping

Asserted times shall be accurate to within three minutes. Electronic or
manual procedures may be used to maintain system time. Clock adjustments
are auditable events, see Section 5.4.1.

# Certificate, CARL/CRL, And ocsp profiles Format

## Certificate Profile

### Version Numbers

The FBCA and Entity CAs shall issue X.509 v3 certificates (populate
version field with integer \"2\").

### Certificate Extensions

For all CAs, use of standard certificate extensions shall comply with
\[RFC 3280\].

Certificates issued by the FBCA shall comply with *Federal Public Key
Infrastructure X.509 Certificate and CRL Extensions Profile*
\[FPKI-Prof\]. Certificates issued by Federal Entity CAs operating at
High, Medium Hardware, and/or Medium Assurance shall comply with
\[FPKI-Prof\].

Certificates issued by the FBCA shall not include critical private
extensions.

CA certificates issued by Entity PKIs shall not include critical private
extensions. Subscriber certificates issued by Entity PKIs may include
critical private extensions so long as interoperability within the
community of use is not impaired.

### Algorithm Object Identifiers

Certificates issued by the FBCA and Entity CAs shall identify the
signature algorithm using one of the following OIDs:

  ------------------------- ----------------------------------------------
  id-dsa-with-sha1          { iso(1) member-body(2) us(840) x9-57(10040)
                            x9cm(4) 3 }

  sha-1WithRSAEncryption    { iso(1) member-body(2) us(840) rsadsi(113549)
                            pkcs(1) pkcs-1(1) 5 }

  sha256WithRSAEncryption   { iso(1) member-body(2) us(840) rsadsi(113549)
                            pkcs(1) pkcs-1(1) 11 }

  id-RSASSA-PSS             { iso(1) member-body(2) us(840) rsadsi(113549)
                            pkcs(1) pkcs-1(1) 10 }

  ecdsa-with-SHA1           { iso(1) member-body(2) us(840)
                            ansi-X9-62(10045) signatures(4) 1 }

  ecdsa-with-SHA224         { iso(1) member-body(2) us(840)
                            ansi-X9-62(10045) signatures(4)
                            ecdsa-with-SHA2(3) 1 }

  ecdsa-with-SHA256         { iso(1) member-body(2) us(840)
                            ansi-X9-62(10045) signatures(4)
                            ecdsa-with-SHA2 (3) 2 }

  ecdsa-with-SHA384         { iso(1) member-body(2) us(840)
                            ansi-X9-62(10045) signatures(4)
                            ecdsa-with-SHA2(3) 3 }

  ecdsa-with-SHA512         { iso(1) member-body(2) us(840)
                            ansi-X9-62(10045) signatures(4)
                            ecdsa-with-SHA2(3) 4 }
  ------------------------- ----------------------------------------------

Where certificates are signed using RSA with PSS padding, the OID is
independent of the hash algorithm; the hash algorithm is specified as a
parameter. RSA signatures with PSS padding may be used with the hash
algorithms and OIDs specified below:

  ------------------------ ----------------------------------------------
  id-sha256                { joint-iso-itu-t(2) country(16) us(840)
                           organization(1) gov(101) csor(3)
                           nistalgorithm(4) hashalgs(2) 1 }

  id-sha512                { joint-iso-itu-t(2) country(16) us(840)
                           organization(1) gov(101) csor(3)
                           nistalgorithm(4) hashalgs(2) 3 }
  ------------------------ ----------------------------------------------

Certificates issued by the FBCA and Entity CAs shall identify the
cryptographic algorithm associated with the subject public key using one
of the following OIDs:

  ------------------------ ----------------------------------------------
  id-dsa                   { iso(1) member-body(2) us(840) x9-57(10040)
                           x9cm(4) 1 }

  RsaEncryption            { iso(1) member-body(2) us(840) rsadsi(113549)
                           pkcs(1) pkcs-1(1) 1 }

  Dhpublicnumber           { iso(1) member-body(2) us(840)
                           ansi-x942(10046) number-type(2) 1 }

  id-ecPublicKey           { iso(1) member-body(2) us(840)
                           ansi-X9-62(10045) id-publicKeyType(2) 1 }
  ------------------------ ----------------------------------------------

Where non-CA certificates issued on behalf of federal agencies contain
an elliptic curve public key, the parameters shall be specified as one
of the following named curves:

  ----------------- -----------------------------------------------------
  ansip192r1        { iso(1) member-body(2) us(840) 10045 curves(3)
                    prime(1) 1 }

  ansit163k1        { iso(1) identified-organization(3) certicom(132)
                    curve(0) 1 }

  ansit163r2        { iso(1) identified-organization(3) certicom(132)
                    curve(0) 15 }

  ansip224r1        { iso(1) identified-organization(3) certicom(132)
                    curve(0) 33 }

  ansit233k1        { iso(1) identified-organization(3) certicom(132)
                    curve(0) 26 }

  ansit233r1        { iso(1) identified-organization(3) certicom(132)
                    curve(0) 27 }

  ansip256r1        { iso(1) member-body(2) us(840) 10045 curves(3)
                    prime(1) 7 }

  ansit283k1        { iso(1) identified-organization(3) certicom(132)
                    curve(0) 16 }

  ansit283r1        { iso(1) identified-organization(3) certicom(132)
                    curve(0) 17 }

  ansip384r1        { iso(1) identified-organization(3) certicom(132)
                    curve(0) 34 }

  ansit409k1        { iso(1) identified-organization(3) certicom(132)
                    curve(0) 36 }

  ansit409r1        { iso(1) identified-organization(3) certicom(132)
                    curve(0) 37 }

  ansip521r1        { iso(1) identified-organization(3) certicom(132)
                    curve(0) 35 }

  ansit571k1        { iso(1) identified-organization(3) certicom(132)
                    curve(0) 38 }

  ansit571r1        { iso(1) identified-organization(3) certicom(132)
                    curve(0) 39 }
  ----------------- -----------------------------------------------------

### Name Forms

Where required as set forth in Section 3.1.1, the subject and issuer
fields of the base certificate shall be populated with an X.500
Distinguished Name. Distinguished names shall be composed of standard
attribute types, such as those identified in \[RFC3280\].

### Name Constraints

All CA certificates issued by the FBCA at the Medium, Medium Hardware,
or High Assurance levels shall have name constraints asserted that limit
the name space of the Principal CAs to that appropriate for their
domains. Additionally, the Federal PKI Policy Authority may require that
the FPKI Management Authority include such constraints for the FBCA
certificates issued at the Basic or Rudimentary levels if it deems
appropriate.

For Entity CAs, no stipulation.

### Certificate Policy Object Identifier

All certificates issued by the FBCA shall include a certificate policies
extension asserting the OID(s) appropriate to the level of assurance
with which it was issued. See Section 1.2 for specific OIDs.

For Entity CAs, no stipulation.

### Usage of Policy Constraints Extension

The CAs may assert policy constraints in CA certificates.

### Policy Qualifiers Syntax & Semantics

Certificates issued by the FBCA shall not contain policy qualifiers.
Certificates issued by Entity PKIs may contain policy qualifiers
identified in \[RFC 3280\].

### Processing Semantics for the Critical Certificate Policy Extension

Not applicable; certificates issued by the FBCA do not include a
critical certificate policies extension.

## CRL Profile

### Version Numbers

The FBCA shall issue X.509 version two (2) CRLs.

Entity CAs operating at Basic, Medium, Medium Hardware, or High
Assurance shall issue X.509 version 1 or version 2 CRLs.

### CRL Entry Extensions

For the FBCA, CRL extensions shall conform to \[FPKI-PROF\].

## OCSP Profile

If implemented, Certificate Status Servers (CSS) shall sign responses
using algorithms designated for CRL signing.

# Compliance Audit & Other Assessments

The FPKI Management Authority shall have a compliance audit mechanism in
place to ensure that the requirements of this CP and the FBCA CPS are
being implemented and enforced.

Entity CAs shall have a compliance audit mechanism in place to ensure
that the requirements of their CP/CPS are being implemented and
enforced.

This specification does not impose a requirement for any particular
assessment methodology.

## Frequency Of Audit Or Assessments

The FBCA, Entity Principal CAs and RAs and their subordinate CAs and RAs
shall be subject to a periodic compliance audit at least once per year
for High, Medium Hardware, and Medium Assurance, and at least once every
two years for Basic Assurance. Where a status server is specified in
certificates issued by a CA, the status server shall be subject to the
same periodic compliance audit requirements as the corresponding CA. For
example, if an OCSP server is specified in the authority information
access extension in certificates issued by a CA, that server must be
reviewed as part of that CA's compliance audit.

For entity PKIs operated by federal agencies and entity PKIs operated
under federal contract, alternative reviews may be substituted for full
compliance audits under exceptional circumstances. The conditions that
permit an alternative review are as follows:

(1) If no changes to policies, procedures, or operations have occurred
    during the previous year, an assertion to that effect, signed by the
    cognizant executive (CIO or equivalent), is acceptable in lieu of a
    full compliance audit.

(2) If no significant changes to policies, procedures, or operations
    have occurred during the previous year, a delta compliance audit is
    acceptable in lieu of a full compliance audit.

(3) However, a full compliance audit (see section 8.4) must be completed
    every third year regardless.

There is no audit requirement for CAs and RAs operating at the
Rudimentary level of assurance.

The FBCA and Entity Principal CAs have the right to require periodic and
aperiodic compliance audits or inspections of subordinate CA or RA
operations to validate that the subordinate entities are operating in
accordance with the security practices and procedures described in their
respective CPS. Further, the Federal PKI Policy Authority has the right
to require aperiodic compliance audits of Entity Principal CAs (and,
when needed, their subordinate CAs) that interoperate with the FBCA
under this CP. The Federal PKI Policy Authority shall state the reason
for any aperiodic compliance audit.

## Identity & Qualifications Of Assessor

The auditor must demonstrate competence in the field of compliance
audits. At the time of the audit, the FBCA compliance auditor must be
thoroughly familiar with requirements which the Federal PKI Policy
Authority imposes on the issuance and management of FBCA certificates.
Likewise, the Entity CA compliance auditor must be thoroughly familiar
with the requirements which Entities impose on the issuance and
management of their certificates. The compliance auditor must perform
such compliance audits as a regular ongoing business activity.

For the FBCA, in addition to the previous requirements, the auditor must
be a Certified Information System Auditor (CISA), IT security
specialist, and a PKI subject matter specialist who can offer input
regarding acceptable risks, mitigation strategies, and industry best
practices. The FPKI Management Authority shall identify the compliance
auditor for the FBCA.

## Assessor's Relationship To Assessed Entity

For both the FBCA and Entity CAs, the compliance auditor either shall be
a private firm, that is independent from the entity being audited, or it
shall be sufficiently organizationally separated from that entity to
provide an unbiased, independent evaluation. An example of the latter
situation may be an Agency inspector general. To insure independence and
objectivity, the compliance auditor may not have served the entity in
developing or maintaining the entity's CA Facility or certificate
practices statement.

The Federal PKI Policy Authority shall determine whether a compliance
auditor meets this requirement.

## Topics Covered By Assessment

The compliance audit of the FBCA shall verify that the FPKI Management
Authority is implementing all provisions of a CPS approved by the FPKI
Policy Authority consistent with this CP. The audit shall also verify
that the FPKI Management Authority is implementing the relevant
provisions of the MOAs between the FPKI Policy Authority and each Entity
PKI.

The purpose of a compliance audit of an Entity PKI shall be to verify
that an entity subject to the requirements of an Entity CP is complying
with the requirements of those documents, as well as any MOAs between
the Entity PKI and any other PKI.

A full compliance audit for the FBCA or an Entity PKI covers all aspects
within the scope identified above.

Where permitted by section 8.1, the FBCA or Entity PKI may perform a
delta compliance audit in lieu of the full compliance audit. A delta
compliance audit covers all changes to policies, procedures, or
operations that have occurred during the previous year. The following
topics must be addressed in a delta compliance audit even if no changes
have occurred since the last full compliance audit:

(1) Personnel controls;

(2) Separation of Duties;

(3) Audit review frequency and scope;

(4) Types of events recorded in physical and electronic audit logs;

(5) Protection of physical and electronic audit data;

(6) Physical security controls; and

(7) Backup and Archive generation and storage.

## Actions Taken As A Result Of Deficiency

When the compliance auditor finds a discrepancy between how the FBCA is
designed or is being operated or maintained, and the requirements of
this CP, the MOAs, or the applicable CPS, the following actions shall be
performed:

-   Τhe compliance auditor shall document the discrepancy and provide a
    copy to the FPKI Management Authority;

-   The FPKI Management Authority will provide a copy of the discrepancy
    documentation to the Federal PKI Policy Authority Chair;

-   The FPKI Management Authority will report findings and corrective
    action to the Federal PKI Policy Authority;

-   The FPKI Management Authority shall determine what further
    notifications or actions are necessary to meet the requirements of
    this CP and the MOAs, and then proceed to make such notifications
    and take such actions without delay.

-   Depending upon the nature and severity of the discrepancy, and how
    quickly it can be corrected, the Federal PKI Policy Authority may
    direct the FPKI Management Authority to take additional actions as
    appropriate, including temporarily halting operation of the FBCA.

When the Entity compliance auditor finds a discrepancy between how the
Entity CA is designed or is being operated or maintained, and the
requirements of the Entity CP, any applicable MOAs, or the applicable
CPS, the following actions shall be performed:

-   The compliance auditor shall document the discrepancy;

-   The compliance auditor shall notify the responsible party promptly;

-   The Entity PKI shall determine what further notifications or actions
    are necessary to meet the requirements of the Entity CP, CPS, and
    any relevant MOA provisions. The Entity PKI shall proceed to make
    such notifications and take such actions without delay.

When the Federal PKI Policy Authority receives a report of audit
deficiency from an Entity PKI, the Federal PKI Policy Authority may
direct the FPKI Management Authority to take additional actions to
protect the level of trust in the infrastructure.

## Communication Of Results

Upon completion, an Audit Compliance Report letter shall be provided to
the Federal PKI Policy Authority. The report shall identify the versions
of the CP and CPS used in the assessment. Additionally, where necessary,
the results shall be communicated as set forth in Section 8.5 above.

# Other Business & Legal Matters

## Fees

The Federal PKI Policy Authority reserves the right to charge a fee to
each Entity in order to support operations of the FBCA.

### Certificate Issuance/Renewal Fees

No Stipulation.

### Certificate Access Fees

No Stipulation.

### Revocation or Status Information Access Fee

No Stipulation.

### Fees for other Services

No Stipulation.

### Refund Policy

No Stipulation.

## Financial Responsibility

This CP contains no limits on the use of any certificates issued by the
FBCA or by Entity CAs. Rather, entities acting as Relying Parties shall
determine what financial limits, if any, they wish to impose for
certificates used to complete a transaction.

### Insurance Coverage

No stipulation.

### Other Assets

No stipulation.

### Insurance/warranty Coverage for End-Entities

No stipulation.

## Confidentiality Of Business Information

FBCA information not requiring protection shall be made publicly
available. Federal PKI Policy Authority access to Entity information
will be addressed in the MOA with that Entity. Public access to Entity
information shall be determined by the respective Entity.

### Scope of Confidential Information

No stipulation.

### Information not within the scope of Confidential Information

No stipulation.

### Responsibility to Protect Confidential Information

No stipulation.

## Privacy Of Personal Information

### Privacy Plan

The FPKI Management Authority shall conduct a Privacy Impact Assessment.
If deemed necessary, the FPKI Management Authority shall have a Privacy
Plan to protect personally identifying information from unauthorized
disclosure. The Federal PKI Policy Authority shall approve the Privacy
Plan.

For Entity CAs, no stipulation.

### Information treated as Private

The FBCA shall protect all subscriber personally identifying information
from unauthorized disclosure. The FBCA shall also protect personally
identifying information for Entity personnel collected to support
cross-certification and MOA requirements from unauthorized disclosure.
The contents of the archives maintained by the FPKI MA shall not be
released except as required by law.

For Entity CAs, no stipulation.

### Information not deemed Private

Information included in FBCA certificates is not subject to protections
outlined in Section 9.4.2.

### Responsibility to Protect Private Information

Sensitive information must be stored securely, and may be released only
in accordance with other stipulations in Section 9.4.

### Notice and Consent to use Private Information

The FPKI Management Authority is not required to provide any notice or
obtain the consent of the Subscriber or Entity personnel in order to
release private information in accordance with the stipulations of
Section 9.4.

### Disclosure Pursuant to Judicial/Administrative Process

The FPKI Management Authority shall not disclose private information to
any third party unless authorized by this Policy, required by law,
government rule or regulation, or order of a court of competent
jurisdiction. Any request for release of information shall be processed
according to 41 CFR 105-60.605.

### Other Information Disclosure Circumstances

None.

## Intellectual Property Rights

The FPKI Management Authority will not knowingly violate intellectual
property rights held by others.

## Representations & Warranties

The obligations described below pertain to the FBCA (and, by
implication, the FPKI Management Authority), and to Principal or other
CAs, which either interoperate with the FBCA or are in a trust chain up
to a Principal CA that interoperates with the FBCA. The obligations
applying to Principal or other CAs pertain to their activities as
issuers of certificates. Further, the obligations focus on Entity CA
obligations affecting interoperability with the FBCA. Thus, where the
obligations include, for example, a review (or audit) by the Federal PKI
Policy Authority or some other body of an Entity's

CA operation, the purpose of that review pertains to interoperability
using the FBCA, and whether the Entity is complying with the MOA.

### CA Representations and Warranties

FBCA certificates are issued and revoked at the sole discretion of the
Federal PKI Policy Authority. When the FBCA issues a cross-certificate
to a non-federal entity, it does so for the convenience of the U.S.
Federal Government. Any review by the Federal PKI Policy Authority of a
non-federal entity's certificate policy is for the use of the Federal
PKI Policy Authority in determining whether or not interoperability is
possible, and if possible, to what extent the non-federal entity's
certificate policy maps to the FBCA policy.

A non-federal entity must determine whether that entity's certificate
policy meets its legal and policy requirements. Review of a non-federal
entity's certificate policy by the Federal PKI Policy Authority is not a
substitute for due care and mapping of certificate policies by the
non-federal entity.

### RA Representations and Warranties

No stipulation.

### Subscriber Representations and Warranties

For Medium, Medium Hardware, and High Assurance levels, a Subscriber
shall be required to sign a document containing the requirements the
Subscriber shall meet respecting protection of the private key and use
of the certificate before being issued the certificate. For Basic
Assurance level, the Subscriber shall be required to acknowledge his or
her obligations respecting protection of the private key and use of the
certificate before being issued the certificate.

Subscribers of Entity CAs at Basic, Medium, and High Assurance Levels
shall agree to the following:

-   Accurately represent themselves in all communications with the PKI
    authorities.

-   Protect their private keys at all times, in accordance with this
    policy, as stipulated in their certificate acceptance agreements and
    local procedures.

-   Promptly notify the appropriate CA upon suspicion of loss or
    compromise of their private keys. Such notification shall be made
    directly or indirectly through mechanisms consistent with the CA's
    CPS.

-   Abide by all the terms, conditions, and restrictions levied on the
    use of their private keys and certificates.

### Relying Parties Representations and Warranties

None.

### Representations and Warranties of other Participants

None.

## Disclaimers Of Warranties

The FPKI MA may not disclaim any responsibilities described in this CP.

## Limitations of Liability

The U.S. Government shall not be liable to any party, except as
determined pursuant to the Federal Tort Claims Act (FTCA), 28 U.S.C.
2671-2680, or as determined through a valid express written contract
between the Government and another party.

For Entity CAs, no stipulation.

## Indemnities

No stipulation.

## Term & Termination

### Term

This CP becomes effective when approved by the FPKI Policy Authority.
This CP has no specified term.

### Termination

Termination of this CP is at the discretion of the FPKI Policy
Authority.

###  Effect of Termination and Survival

The requirements of this CP remain in effect through the end of the
archive period for the last certificate issued.

## Individual Notices & Communications With participants

The Federal PKI PA shall establish appropriate procedures for
communications with Entity CAs via contracts or memoranda of agreement
as applicable.

For all other communications, no stipulation.

## Amendments

### Procedure for Amendment

The Federal PKI Policy Authority shall review this CP at least once
every year. Corrections, updates, or suggested changes to this CP shall
be communicated to every Entity Principal CA. Such communication must
include a description of the change, a change justification, and contact
information for the person requesting the change.

###  Notification Mechanism and Period

Proposed changes to this CP shall be distributed electronically to
Policy Authority members and observers in accordance with the Charter
and By-laws.

### Circumstances under which OID must be changed

OIDs will be changed if the FPKI Policy Authority determines that a
change in the CP reduces the level of assurance provided.

## Dispute Resolution Provisions

Any dispute arising with respect to this policy or certificates issued
under this policy shall be resolved by the Parties.

## Governing Law

The construction, validity, performance and effect of certificates
issued under this CP for all purposes shall be governed by United States
Federal law (statute, case law or regulation).

For Entity CAs, the construction, validity, performance and effect of
certificates issued under the Entity CP for all purposes shall be
governed by law (statute, case law or regulation) under which the Entity
operates.

Where an inter-governmental dispute occurs, resolution will be according
to the terms of the MOA.

## Compliance With Applicable Law

The FBCA and Entity CAs are required to comply with applicable law.

## Miscellaneous Provisions

### Entire agreement

No stipulation.

###  Assignment

No stipulation.

###  Severability

Should it be determined that one section of this CP is incorrect or
invalid, the other sections of this CP shall remain in effect until the
CP is updated. The process for updating this CP is described in section
9.12.

###  Enforcement (Attorney Fees/Waiver of Rights)

No stipulation.

### Force Majeure

No stipulation.

## Other Provisions

No stipulation.

# BIBLIOGRAPHY

The following documents were used in part to develop this CP:

  ----------- --------------------------------------------------------------------------------------------------------------------------------------------------
  ABADSG      Digital Signature Guidelines, 1996-08-01. [http://www.abanet.org/scitech/ec/isc/dsgfree.html]{.underline}.

  CIMC        Certificate Issuing and Management Components Family of Protection Profiles, version 1.0, October 31, 2001.

  FIPS 140-2  Security Requirements for Cryptographic Modules May 25, 2001. http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf

  FIPS 186-2  Digital Signature Standard, January 27, 2000. http://csrc.nist.gov/publications/fips/fips186-2/fips186-2-change1.pdf

  FOIACT      5 U.S.C. 552, Freedom of Information Act. [Http://www4.law.cornell.edu/uscode/5/552.html](http://www4.law.cornell.edu/uscode/5/552.html)

  FPKI-E      Federal PKI Version 1 Technical Specifications: Part E-X.509 Certificate and CRL Extensions Profile, 7 July 1997
              <http://csrs.nist.gov/pki/FPKI7-10.DOC>

  FPKI-Prof   Federal PKI X.509 Certificate and CRL Extensions Profile

  ISO9594-8   Information Technology-Open Systems Interconnection-The Directory: Authentication Framework, 1997.

  ITMRA       40 U.S.C. 1452, Information Technology Management Reform Act of 1996.
              [Http://www4.law.cornell.edu/uscode/40/1452.html](http://www4.law.cornell.edu/uscode/40/1452.html)

  NAG69C      Information System Security Policy and Certification Practice Statement for Certification Authorities, rev C, November 1999.

  NSD42       National Policy for the Security of National Security Telecom and Information Systems, 5 Jul 1990.
              [Http://snyside.sunnyside.com/cpsr/privacy/computer_security/nsd_42.txt](http://snyside.sunnyside.com/cpsr/privacy/computer_security/nsd_42.txt)
              (redacted version)

  NS4005      NSTISSI 4005, Safeguarding COMSEC Facilities and Material, August 1997.

  NS4009      NSTISSI 4009, National Information Systems Security Glossary, January 1999.

  PKCS#12     Personal Information Exchange Syntax Standard, April 1997. ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-12/pkcs-12v1.pdf

  RFC 2510    Certificate Management Protocol, Adams and Farrell, March 1999.

  RFC 3647    Certificate Policy and Certification Practices Framework, Chokhani and Ford, Sabett, Merrill, and Wu, November 2003.
  ----------- --------------------------------------------------------------------------------------------------------------------------------------------------

# ACRONYMS & ABBREVIATIONS

  ----------- -----------------------------------------------------------
  CA          Certification Authority

  CARL        Certificate Authority Revocation List

  COMSEC      Communications Security

  CP          Certificate Policy

  CPS         Certification Practice Statement

  CRL         Certificate Revocation List

  CSOR        Computer Security Object Registry

  DN          Distinguished Name

  DSA         Digital Signature Algorithm

  DSS         Digital Signature Standard

  ERC         Enhanced Reliability Check

  FAR         Federal Acquisition Regulations

  FBCA        Federal Bridge Certification Authority

  FPKI MA     Federal Public Key Infrastructure Management Authority

  FED-STD     Federal Standard

  FIPS PUB    (US) Federal Information Processing Standard Publication

  FPKI        Federal Public Key Infrastructure

  FPKI-E      Federal PKI Version 1 Technical Specifications: Part E --
              X.509 Certificate and CRL Extensions Profile

  FPKISC      Federal PKI Steering Committee

  FPKIPA      Federal PKI Policy Authority

  GPEA        Government Paperwork Elimination Act of 1998

  IETF        Internet Engineering Task Force

  ISO         International Organization for Standardization

  ISSO        Information Systems Security Officer

  ITU         International Telecommunications Union

  ITU-T       International Telecommunications Union --
              Telecommunications Sector

  ITU-TSS     International Telecommunications Union --
              Telecommunications System Sector

  MOA         Memorandum of Agreement (as used in the context of this CP,
              between an Entity and the FPKIPA allowing interoperation
              between the FBCA and Entity Principal CA)

  NIST        National Institute of Standards and Technology

  NSA         National Security Agency

  NSTISSI     National Security Telecommunications and Information
              Systems Security Instruction

  OID         Object Identifier

  PIN         Personal Identification Number

  PKCS        Public Key Certificate Standard

  PKI         Public Key Infrastructure

  PKIX        Public Key Infrastructure X.509

  RA          Registration Authority

  RFC         Request For Comments

  RSA         Rivest-Shamir-Adleman (encryption algorithm)

  SHA-1       Secure Hash Algorithm, Version 1

  S/MIME      Secure Multipurpose Internet Mail Extension

  SSL         Secure Sockets Layer

  TSDM        Trusted Software Development Methodology

  UPS         Uninterrupted Power Supply

  URL         Uniform Resource Locator

  U.S.C.      United States Code

  WWW         World Wide Web
  ----------- -----------------------------------------------------------

# GLOSSARY

  --------------------- -------------------------------------------------
  Access                Ability to make use of any information system
                        (IS) resource. \[NS4009\]

  Access Control        Process of granting access to information system
                        resources only to authorized users, programs,
                        processes, or other systems. \[NS4009\]

  Accreditation         Formal declaration by a Designated Approving
                        Authority that an Information System is approved
                        to operate in a particular security mode using a
                        prescribed set of safeguards at an acceptable
                        level of risk. \[NS4009\]

  Activation Data       Private data, other than keys, that are required
                        to access cryptographic modules (i.e., unlock
                        private keys for signing or decryption events).

  Applicant             The subscriber is sometimes also called an
                        \"applicant\" after applying to a certification
                        authority for a certificate, but before the
                        certificate issuance procedure is completed.
                        \[ABADSG footnote 32\]

  Archive               Long-term, physically separate storage.

  Attribute Authority   An entity, recognized by the FPKIPA or comparable
                        Entity body as having the authority to verify the
                        association of attributes to an identity.

  Audit                 Independent review and examination of records and
                        activities to assess the adequacy of system
                        controls, to ensure compliance with established
                        policies and operational procedures, and to
                        recommend necessary changes in controls,
                        policies, or procedures. \[NS4009\]

  Audit Data            Chronological record of system activities to
                        enable the reconstruction and examination of the
                        sequence of events and changes in an event.
                        \[NS4009, \"audit trail\"\]

  Authenticate          To confirm the identity of an entity when that
                        identity is presented.

  Authentication        Security measure designed to establish the
                        validity of a transmission, message, or
                        originator, or a means of verifying an
                        individual\'s authorization to receive specific
                        categories of information. \[NS4009\]

  Backup                Copy of files and programs made to facilitate
                        recovery if necessary. \[NS4009\]

  Binding               Process of associating two related elements of
                        information. \[NS4009\]

  Biometric             A physical or behavioral characteristic of a
                        human being.

  Certificate           A digital representation of information which at
                        least (1) identifies the certification authority
                        issuing it, (2) names or identifies its
                        subscriber, (3) contains the subscriber\'s public
                        key, (4) identifies its operational period, and
                        (5) is digitally signed by the certification
                        authority issuing it. \[ABADSG\]. As used in this
                        CP, the term "Certificate" refers to certificates
                        that expressly reference the OID of this CP in
                        the "Certificate Policies" field of an X.509 v.3
                        certificate.

  Certification         An authority trusted by one or more users to
  Authority (CA)        issue and manage X.509 Public Key Certificates
                        and CARLs or CRLs.

  Certification         A signed, time-stamped list of serial numbers of
  Authority Revocation  CA public key certificates, including
  List (CARL)           cross-certificates, that have been revoked.

  CA Facility           The collection of equipment, personnel,
                        procedures and structures that are used by a
                        Certification Authority to perform certificate
                        issuance and revocation.

  Certificate           A digital representation of information which at
                        least (1) identifies the certification authority
                        issuing it, (2) names or identifies it's
                        Subscriber, (3) contains the Subscriber's public
                        key, (4) identifies it's operational period, and
                        (5) is digitally signed by the certification
                        authority issuing it. \[ABADSG\]

  Certificate           A Certification Authority or a Registration
  Management Authority  Authority.
  (CMA)                 

  Certification         Key Management and cryptographic software used to
  Authority Software    manage certificates issued to subscribers.

  Certificate Policy    A Certificate Policy is a specialized form of
  (CP)                  administrative policy tuned to electronic
                        transactions performed during certificate
                        management. A Certificate Policy addresses all
                        aspects associated with the generation,
                        production, distribution, accounting, compromise
                        recovery and administration of digital
                        certificates. Indirectly, a certificate policy
                        can also govern the transactions conducted using
                        a communications system protected by a
                        certificate-based security system. By controlling
                        critical certificate extensions, such policies
                        and associated enforcement technology can support
                        provision of the security services required by
                        particular applications.
  --------------------- -------------------------------------------------

  --------------------- -------------------------------------------------
  Certification         A statement of the practices that a CA employs in
  Practice Statement    issuing, suspending, revoking and renewing
  (CPS)                 certificates and providing access to them, in
                        accordance with specific requirements (i.e.,
                        requirements specified in this CP, or
                        requirements specified in a contract for
                        services).

  Certificate-Related   Information, such as a subscriber\'s postal
  Information           address, that is not included in a certificate.
                        May be used by a CA managing certificates.

  Certificate           A list maintained by a Certification Authority of
  Revocation List (CRL) the certificates which it has issued that are
                        revoked prior to their stated expiration date.

  Certificate Status    A trusted entity that provides on-line
  Authority             verification to a Relying Party of a subject
                        certificate\'s trustworthiness, and may also
                        provide additional attribute information for the
                        subject certificate.

  Client (application)  A system entity, usually a computer process
                        acting on behalf of a human user, that makes use
                        of a service provided by a server.

  Common Criteria       A set of internationally accepted semantic tools
                        and constructs for describing the security needs
                        of customers and the security attributes of
                        products.

  Compromise            Disclosure of information to unauthorized
                        persons, or a violation of the security policy of
                        a system in which unauthorized intentional or
                        unintentional disclosure, modification,
                        destruction, or loss of an object may have
                        occurred. \[NS4009\]

  Computer Security     Computer Security Objects Registry operated by
  Objects Registry      the National Institute of Standards and
  (CSOR)                Technology.

  Confidentiality       Assurance that information is not disclosed to
                        unauthorized entities or processes. \[NS4009\]

  Cross-Certificate     A certificate used to establish a trust
                        relationship between two Certification
                        Authorities.

  Cryptographic Module  The set of hardware, software, firmware, or some
                        combination thereof that implements cryptographic
                        logic or processes, including cryptographic
                        algorithms, and is contained within the
                        cryptographic boundary of the module.
                        \[FIPS1401\]

  Cryptoperiod          Time span during which each key setting remains
                        in effect. \[NS4009\]

  Data Integrity        Assurance that the data are unchanged from
                        creation to reception.

  Digital Signature     The result of a transformation of a message by
                        means of a cryptographic system using keys such
                        that a Relying Party can determine: (1) whether
                        the transformation was created using the private
                        key that corresponds to the public key in the
                        signer's digital certificate; and (2) whether the
                        message has been altered since the transformation
                        was made.

  Dual Use Certificate  A certificate that is intended for use with both
                        digital signature and data encryption services.

  Duration              A field within a certificate which is composed of
                        two subfields; "date of issue" and "date of next
                        issue".

  E-commerce            The use of network technology (especially the
                        internet) to buy or sell goods and services.

  Encrypted Network     A network that is protected from outside access
                        by NSA approved high-grade (Type I) cryptography.
                        Examples are SIPRNET and TOP SECRET networks.

  Encryption            A certificate containing a public key that is
  Certificate           used to encrypt electronic messages, files,
                        documents, or data transmissions, or to establish
                        or exchange a session key for these same
                        purposes.

  End-entity            Relying Parties and Subscribers.

  Entity                For the purposes of this document, "Entity"
                        refers to an organization, corporation, community
                        of interest, or government agency with
                        operational control of a CA.

  Entity CA             A CA that acts on behalf of an Entity, and is
                        under the operational control of an Entity. The
                        Entity may be an organization, corporation, or
                        community of interest. For the Federal
                        Government, an Entity may be any department,
                        subordinate element of a department, or
                        independent organizational entity that is
                        statutorily or constitutionally recognized as
                        being part of the Federal Government.

  FBCA Management       The Federal Public Key Infrastructure Management
  Authority (FPKI MA)   Authority is the organization selected by the
                        Federal Public Key Infrastructure Policy
                        Authority to be responsible for operating the
                        Federal Bridge Certification Authority.

  Federal Public Key    The FPKIPA is a federal government body
  Infrastructure Policy responsible for setting, implementing, and
  Authority (FPKI PA)   administering policy decisions regarding
                        interEntity PKI interoperability that uses the
                        FBCA.

  Firewall              Gateway that limits access between networks in
                        accordance with local security policy. \[NS4009\]

  High Assurance Guard  An enclave boundary protection device that
  (HAG)                 controls access between a local area network that
                        an enterprise system has a requirement to
                        protect, and an external network that is outside
                        the control of the enterprise system, with a high
                        degree of assurance.

  Information System    Person responsible to the designated approving
  Security Officer      authority for ensuring the security of an
  (ISSO)                information system throughout its lifecycle, from
                        design through disposal. \[NS4009\]

  Inside threat         An entity with authorized access that has the
                        potential to harm an information system through
                        destruction, disclosure, modification of data,
                        and/or denial of service.

  Integrity             Protection against unauthorized modification or
                        destruction of information. \[NS4009\]. A state
                        in which information has remained unaltered from
                        the point it was produced by a source, during
                        transmission, storage, and eventual receipt by
                        the destination.

  Intellectual Property Useful artistic, technical, and/or industrial
                        information, knowledge or ideas that convey
                        ownership and control of tangible or virtual
                        usage and/or representation.

  Intermediate CA       A CA that is subordinate to another CA, and has a
                        CA subordinate to itself.

  Key Escrow            A deposit of the private key of a subscriber and
                        other pertinent information pursuant to an escrow
                        agreement or similar contract binding upon the
                        subscriber, the terms of which require one or
                        more agents to hold the subscriber\'s private key
                        for the benefit of the subscriber, an employer,
                        or other party, upon provisions set forth in the
                        agreement. \[adapted from ABADSG, \"Commercial
                        key escrow service\"\]

  Key Exchange          The process of exchanging public keys in order to
                        establish secure communications.

  Key Generation        Random numbers, pseudo-random numbers, and
  Material              cryptographic parameters used in generating
                        cryptographic keys.

  Key Pair              Two mathematically related keys having the
                        properties that (1) one key can be used to
                        encrypt a message that can only be decrypted
                        using the other key, and (ii) even knowing one
                        key, it is computationally infeasible to discover
                        the other key.

  Local Registration    A Registration Authority with responsibility for
  Authority (LRA)       a local community.

  Memorandum of         Agreement between the FPKIPA and an Entity
  Agreement (MOA)       allowing interoperability between the Entity
                        Principal CA and the FBCA.

  Mission Support       Information that is important to the support of
  Information           deployed and contingency forces.

  Mutual Authentication Occurs when parties at both ends of a
                        communication activity authenticate each other
                        (see authentication).

  Naming Authority      An organizational entity responsible for
                        assigning distinguished names (DNs) and for
                        assuring that each DN is meaningful and unique
                        within its domain.

  National Security     Any telecommunications or information system
  System                operated by the United States Government, the
                        function, operation, or use of which involves
                        intelligence activities; involves cryptologic
                        activities related to national security; involves
                        command and control of military forces; involves
                        equipment that is an integral part of a weapon or
                        weapons system; or is critical to the direct
                        fulfillment of military or intelligence missions,
                        but does not include a system that is to be used
                        for routine administrative and business
                        applications (including payroll, finance,
                        logistics, and personnel management
                        applications). \[ITMRA\]

  Non-Repudiation       Assurance that the sender is provided with proof
                        of delivery and that the recipient is provided
                        with proof of the sender\'s identity so that
                        neither can later deny having processed the data.
                        \[NS4009\] Technical non-repudiation refers to
                        the assurance a Relying Party has that if a
                        public key is used to validate a digital
                        signature, that signature had to have been made
                        by the corresponding private signature key. Legal
                        non-repudiation refers to how well possession or
                        control of the private signature key can be
                        established.

  Object Identifier     A specialized formatted number that is registered
  (OID)                 with an internationally recognized standards
                        organization. The unique alphanumeric/numeric
                        identifier registered under the ISO registration
                        standard to reference a specific object or object
                        class. In the federal government PKI they are
                        used to uniquely identify each of the seven
                        policies and cryptographic algorithms supported.

  Out-of-Band           Communication between parties utilizing a means
                        or method that differs from the current method of
                        communication (e.g., one party uses U.S. Postal
                        Service mail to communicate with another party
                        where current communication is occurring online).

  Outside Threat        An unauthorized entity from outside the domain
                        perimeter that has the potential to harm an
                        Information System through destruction,
                        disclosure, modification of data, and/or denial
                        of service.

  Physically Isolated   A network that is not connected to entities or
  Network               systems outside a physically controlled space.

  PKI Sponsor           Fills the role of a Subscriber for non-human
                        system components that are named as public key
                        certificate subjects, and is responsible for
                        meeting the obligations of Subscribers as defined
                        throughout this CP.

  Policy Management     Body established to oversee the creation and
  Authority (PMA)       update of Certificate Policies, review
                        Certification Practice Statements, review the
                        results of CA audits for policy compliance,
                        evaluate non-domain policies for acceptance
                        within the domain, and generally oversee and
                        manage the PKI certificate policies. For the
                        FBCA, the PMA is the FPKIPA.

  Principal CA          The Principal CA is a CA designated by an Entity
                        to interoperate with the FBCA. An Entity may
                        designate multiple Principal CAs to interoperate
                        with the FBCA.

  Privacy               Restricting access to subscriber or Relying Party
                        information in accordance with Federal law and
                        Entity policy.

  Private Key           \(1\) The key of a signature key pair used to
                        create a digital signature. (2) The key of an
                        encryption key pair that is used to decrypt
                        confidential information. In both cases, this key
                        must be kept secret.

  Public Key            \(1\) The key of a signature key pair used to
                        validate a digital signature. (2) The key of an
                        encryption key pair that is used to encrypt
                        confidential information. In both cases, this key
                        is made publicly available normally in the form
                        of a digital certificate.

  Public Key            A set of policies, processes, server platforms,
  Infrastructure (PKI)  software and workstations used for the purpose of
                        administering certificates and public-private key
                        pairs, including the ability to issue, maintain,
                        and revoke public key certificates.

  Registration          An entity that is responsible for identification
  Authority (RA)        and authentication of certificate subjects, but
                        that does not sign or issue certificates (i.e., a
                        Registration Authority is delegated certain tasks
                        on behalf of an authorized CA).

  Re-key (a             To change the value of a cryptographic key that
  certificate)          is being used in a cryptographic system
                        application; this normally entails issuing a new
                        certificate on the new public key.

  Relying Party         A person or Entity who has received information
                        that includes a certificate and a digital
                        signature verifiable with reference to a public
                        key listed in the certificate, and is in a
                        position to rely on them.

  Renew (a certificate) The act or process of extending the validity of
                        the data binding asserted by a public key
                        certificate by issuing a new certificate.

  Repository            A database containing information and data
                        relating to certificates as specified in this CP;
                        may also be referred to as a directory.

  Responsible           A trustworthy person designated by a sponsoring
  Individual            organization to authenticate individual
                        applicants seeking certificates on the basis of
                        their affiliation with the sponsor.

  Revoke a Certificate  To prematurely end the operational period of a
                        certificate effective at a specific date and
                        time.

  Risk                  An expectation of loss expressed as the
                        probability that a particular threat will exploit
                        a particular vulnerability with a particular
                        harmful result.

  Risk Tolerance        The level of risk an entity is willing to assume
                        in order to achieve a potential desired result.

  Root CA               In a hierarchical PKI, the CA whose public key
                        serves as the most trusted datum (i.e., the
                        beginning of trust paths) for a security domain.

  Server                A system entity that provides a service in
                        response to requests from clients.

  Signature Certificate A public key certificate that contains a public
                        key intended for verifying digital signatures
                        rather than encrypting data or performing any
                        other cryptographic functions.

  Subordinate CA        In a hierarchical PKI, a CA whose certificate
                        signature key is certified by another CA, and
                        whose activities are constrained by that other
                        CA. (See superior CA).

  Subscriber            A Subscriber is an entity that (1) is the subject
                        named or identified in a certificate issued to
                        that entity, (2) holds a private key that
                        corresponds to the public key listed in the
                        certificate, and (3) does not itself issue
                        certificates to another party. This includes, but
                        is not limited to, an individual or network
                        device
  --------------------- -------------------------------------------------

  --------------------- -------------------------------------------------
  Superior CA           In a hierarchical PKI, a CA who has certified the
                        certificate signature key of another CA, and who
                        constrains the activities of that CA. (See
                        subordinate CA).

  System Equipment      A comprehensive accounting of all system hardware
  Configuration         and software types and settings.

  System High           The highest security level supported by an
                        information system. \[NS4009\]

  Technical             The contribution public key mechanisms to the
  non-repudiation       provision of technical evidence supporting a
                        non-repudiation security service.

  Threat                Any circumstance or event with the potential to
                        cause harm to an information system in the form
                        of destruction, disclosure, adverse modification
                        of data, and/or denial of service. \[NS4009\]

  Trust List            Collection of trusted certificates used by
                        Relying Parties to authenticate other
                        certificates.

  Trusted Agent         Entity authorized to act as a representative of
                        an Entity in confirming Subscriber identification
                        during the registration process. Trusted Agents
                        do not have automated interfaces with
                        Certification Authorities.

  Trusted Certificate   A certificate that is trusted by the Relying
                        Party on the basis of secure and authenticated
                        delivery. The public keys included in trusted
                        certificates are used to start certification
                        paths. Also known as a \"trust anchor\".

  Trusted Timestamp     A digitally signed assertion by a trusted
                        authority that a specific digital object existed
                        at a particular time.

  Trustworthy System    Computer hardware, software and procedures that:
                        (1) are reasonably secure from intrusion and
                        misuse; (2) provide a reasonable level of
                        availability, reliability, and correct operation;
                        (3) are reasonably suited to performing their
                        intended functions; and (4) adhere to generally
                        accepted security procedures.

  Two-Person Control    Continuous surveillance and control of positive
                        control material at all times by a minimum of two
                        authorized individuals, each capable of detecting
                        incorrect and/or unauthorized procedures with
                        respect to the task being performed, and each
                        familiar with established security and safety
                        requirements. \[NS4009\]

  Update (a             The act or process by which data items bound in
  certificate)          an existing public key certificate, especially
                        authorizations granted to the subject, are
                        changed by issuing a new certificate.

  Zeroize               A method of erasing electronically stored data by
                        altering the contents of the data storage so as
                        to prevent the recovery of the data. \[FIPS1401\]
  --------------------- -------------------------------------------------

# ACKNOWLEDGEMENTS

The Certificate Policy Working Group developed this CP based on RFC 3647
and the original FBCA Certificate Policy.