> ![](media/image1.png){width="1.1770833333333333in"
> height="1.1770833333333333in"} **Federal Bridge CA Certificate Policy
> Change Proposal Change Number:** ***2005-02***

**To:** Federal PKI Policy Authority

**From:** FPKI Certificate Policy Working Group

**Subjects:** Measuring TLI; Recognizing E-Auth Level 4

**Date:** 6 June 2005

**\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--**

**Scope:** Establish concrete requirements for the determination of
trust, loyalty, and integrity (TLI) of persons holding trusted roles for
the existing FBCA policies. Add a new certificate policy *medium-cbp*
for external PKIs whose personnel security rules do not address
citizenship but are otherwise operated at the Medium Level of Assurance;
Add two new certificate policies that require FIPS 140-2 Level 2
hardware cryptographic modules for subscribers but are otherwise
identical to the FBCA-medium and medium-cbp policies.

## Version and Date of Certificate Policy Requested to be changed:  {#version-and-date-of-certificate-policy-requested-to-be-changed .sub-heading}

X.509 Certificate Policy for the Federal Bridge Certification Authority
(FBCA), dated 26 April 2005.

**Change Advocates' Contact Information:**

Name: **Tim Polk** Name:

Organization: **NIST** Organization:

Telephone number: **(301) 975-3348** Telephone number:

E-mail address: [**tim.polk@nist.gov**](mailto:tim.polk@nist.gov) E-mail
address:

**Organization requesting change**:

Certificate Policy Working Group, E-Authentication program, Ad hoc
working group on Trust, Loyalty, and Integrity, and U.S. Government
Trade Policy Experts (ad hoc group)

##  {#section .sub-heading}

**Change summary**:

This change proposal incorporates the following amendments to the FBCA
Certificate Policy:

(1) Concrete metrics for trust, loyalty, and integrity of personnel
    holding trusted roles are established for the existing High, Medium,
    Basic, and Rudimentary Assurance certificate policies.

(2) The current language fails to clearly identify the RA as a trusted
    role, although the responsibilities overlap with the definition of
    the Officer trusted role.

(3) A new FBCA Medium Hardware policy is established. This certificate
    policy corresponds to PKIs operated at the Medium Level of
    Assurance, but requiring FIPS 140-2 Level 2 hardware cryptographic
    modules for subscribers.

(4) A new Commercial Best Practice policy is established. This
    certificate policy corresponds to external PKIs operated at the
    Medium Level of Assurance, but omitting the citizenship requirement.

(5) A new Commercial Best Practice Hardware (CBP-HW) policy is
    established. This certificate policy corresponds to external PKIs
    operated at the Medium Hardware Level of Assurance, but omitting the
    citizenship requirement.

**Background**:

(1) The existing FBCA CP mandates a Top Secret clearance for all persons
    holding a trusted role in the FBCA operations, but is silent
    regarding personnel holding trusted roles in entity PKIs. Concrete
    requirements for entity PKIs must be established to ensure that
    policies with the same mapping provide a consistent level of
    assurance.

(2) The FBCA text must be clarified to ensure that RA personnel are
    considered to hold trusted roles when their duties match those
    specified for the Officer role.

(3) NIST Special Publication 800-63 \[800-63\] establishes requirements
    for implementation of the E-Authentication Levels defined by the
    Office of Management and Budget in \[04-04\]. Level 4 authentication
    requirements may be satisfied by PKIs that meet the FBCA Medium
    Level of Assurance if they meet one additional policy requirement:
    subscribers must use hardware cryptographic modules validated at
    FIPS 140-2 Level 2. By adding a new policy, the FBCA can preserve
    this information through policy mapping.

(4) U.S. Government personnel security requirements typically include a
    U.S. citizenship requirement, providing an additional indication of
    loyalty. This requirement is inappropriate as stated for foreign
    PKIs, but has merit when modified to indicate that trusted personnel
    should be "citizens of that nation", or "citizens of a member
    nation" for multinational entities (e.g., NATO).

(5) Personnel security requirements employed by commercial or
    non-governmental entities do not typically include citizenship
    requirements. Citizenship is not related to loyalty to commercial or
    non-governmental entities, especially where these entities are
    themselves multinational. In addition, citizenship requirements may
    not be a legal requirement for employment in some cases or
    locations. Entity PKIs whose personnel security rules are silent
    with respect to citizenship should be recognized but differentiated
    to support the full range of agency security requirements.

**Specific Changes:**

Specific changes are recommended in Sections 1.2, 1.3.1.8, 5.3.1 and
6.2.1. Inserted text is displayed as ***bold italics***; deleted text
appears as **~~bold with strikethrough~~**.

1\) [Section 1.2 (Identification):]{.underline}

***These Certificate Policy specifies eight distinct policies which are
defined in its*** **~~There are five levels of assurance in this
Certificate Policy which are defined in~~** subsequent sections. Each
**~~level of assurance~~** ***of the eight policies*** has an Object
Identifier (OID), to be asserted in certificates issued by the FBCA. The
OIDs are registered under the id-infosec arc 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-medium-CBP***          ***::= fbca-policies 14***

  ***id-fpki-certpcy-mediumHW***            ***::= fbca-policies 12***

  ***id-fpki-certpcy-mediumHW-CBP***        ***::= fbca-policies 15***

  id-fpki-certpcy-highAssurance             ::= fbca-policies 4

  id-fpki-certpcy-testAssurance             ::= fbca-policies 5
  ----------------------------------------- -----------------------------

***The High Assurance policy is reserved for government (federal, state,
and local) use.***

***The requirements associated with the 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 CBP-HW policy are identical to
those defined for the Medium Hardware Assurance policy, with the
exception of personnel security requirements (see Section 5.3.1).***

2\) [Section 1.3.1.8 Registration Authority (RA)]{.underline}

### 

The RA is the entity that collects and verifies each Subscriber's
identity and information that are to be entered into his or her public
key certificate. ***The RA is by definition functioning as the Officer
trusted role of the CA as defined at 5.2.1.2.*** The **~~FBCA~~ *FPKI
***Operational Authority acts as the RA for the FBCA, and performs its
function in accordance with a CPS approved by the Federal PKI Policy
Authority. The requirements for RAs in Entity PKIs are set forth in the
sections below.

3\) [Section 5.3.1 Background, qualifications, experience, and security
clearance requirements]{.underline}

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 **~~FBCA~~
*FPKI ***Operational Authority.

All persons filling trusted roles shall be selected on the basis of
loyalty, trustworthiness, and integrity. **~~, and must be U.S.
citizens.~~ *For the FBCA and Federal Agency PKIs, regardless of the
assurance level, and for 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 or MediumHW Assurance, all trusted roles
must be held by citizens of the country where the CA is located. For
PKIs operated at Medium-CBP or MediumHW-CBP, there is no citizenship
requirements specified. ***

***\[Practice Note: For PKIs operated at Medium Assurance or MediumHW
Assurance, on behalf of multinational governmental organizations, all
trusted roles must be held by citizens of the member countries.\]***

***Where an entity PKI operated at High Assurance or Medium Assurance is
affiliated with RAs operated overseas, RA personnel holding trusted
roles may be local citizens of the country where the RA is located or of
the country where the CA is located.***

**~~The requirements governing the qualifications, selection and
oversight of individuals who operate, manage, oversee, and audit the CA
shall be set forth in the Entity CA CPS.~~**

**~~FBCA~~ *FPKI ***Operational Authority personnel shall hold TOP
SECRET security clearances. Entity CA personnel **~~may hold security
clearances if deemed appropriate by their respective Entity.~~ *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. \[Practice Note for federal agencies:
A successfully adjudicated National Agency Check with Written Inquires
(NACI) or National Agency Check with Law Enforcement Check (NACLC) on
record are deemed to meet the minimum standards specified above.\]
\[Practice Note for nongovernmental partners: The qualifications of the
adjudication authority and procedures utilized to satisfy these
requirements must be demonstrated before cross certification with the
FBCA.\]***

4\) [Section 6.2.1 (Standards for Cryptographic Modules):]{.underline}

The relevant standard for cryptographic modules is FIPS PUB 140‑1,
*Security Requirements for Cryptographic Modules*. The Federal PKI
Policy Authority may determine that other comparable validation,
certification, or verification standards are sufficient. These standards
will be published by the Federal PKI Policy Authority. Cryptographic
modules shall be validated to the FIPS 140‑1 level identified in this
section, or validated, certified, or verified to requirements published
by the Federal PKI Policy Authority. Additionally, the Federal PKI
Policy Authority reserves the right to review technical documentation
associated with any cryptomodules under consideration for use by the
FBCA.

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

  ---------------- ---------------- --------------- ----------------- ---------------- ----------------
  **Assurance      **Latest version **Federal       **Certification   **Subscriber**   **Registration
  Level**          of FIPS 140      Bridge          Authority**                        Authority**
                   series**         Certification                                      
                                    Authority**                                        

  Test             MOA              MOA             MOA               MOA              MOA

  Rudimentary      N/A              Level 3         Level 1 (Hardware N/A              Level 1
                                    (Hardware)      or Software)                       (Hardware or
                                                                                       Software)

  **Basic**        Required         Level 3         Level 2 (Hardware Level 1          Level 1
                                    (Hardware)      or Software)      (Hardware or     (Hardware or
                                                                      Software)        Software)

  **Medium**       Required         Level 3         Level 2           Level 1          Level 2
                                    (Hardware)      (Hardware)        (Hardware or     (Hardware)
                                                                      Software)        

  ***MediumHW***   ***Required***   ***Level 3      ***Level 2        ***Level 2       ***Level 2
                                    (Hardware)***   (Hardware)***     (Hardware)***    (Hardware)***

  **High**         Required         Level 3         Level 3           Level 2          Level 2
                                    (Hardware)      (Hardware)        (Hardware)       (Hardware)
  ---------------- ---------------- --------------- ----------------- ---------------- ----------------

## \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-- {#section-2 .sub-heading}

**Estimated Cost:**

There is minimal cost associated with implementing this change at the
FBCA itself. Upon approval of mapping by the Policy Authority, some
current cross certificates will require re-issuance to update the policy
OIDs and policy mappings.

**Implementation Date:**

This change will be implemented immediately in all policy mappings.

**Prerequisites for Adoption:**

There are no prerequisites.

**Plan to Meet Prerequisites:**

There are no prerequisites.

**Approval and Coordination Dates:**

Date presented to CPWG: various dates, May 2004 through June 2005

Date CPWG recommended approval: June 6, 2005

Date Presented to FPKI PA: June 14, 2005

Date of approval by FPKI PA: June 14, 2005