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

Certificate Policy CP-1 for FMS Public Key Certificates in Unclassified
Environments

Prepared by

Draft 0.2 -- 13 November 2023

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

# **TABLE OF CONTENTS** {#table-of-contents .unnumbered}

Section Page

TABLE OF CONTENTS [i](#table-of-contents)

ACKNOWLDEGEMENTS [v](#acknowldegements)

DEFINITIONS [vi](#definitions)

ABBREVIATIONS [ix](#abbreviations)

1\. INTRODUCTION [1](#introduction)

1.1 OVERVIEW [1](#overview)

1.2 CERTIFICATE POLICY IDENTIFICATION
[1](#certificate-policy-identification)

1.2.1 Certificate Policy Name [1](#certificate-policy-name)

1.2.2 Object Identifier: {to be supplied}
[2](#object-identifier-to-be-supplied)

1.2.3 Certificate References to This Policy
[2](#certificate-references-to-this-policy)

1.3 CERTIFICATE TYPES AND INTENDED USE
[2](#certificate-types-and-intended-use)

1.3.1 Identity Certificates [2](#identity-certificates)

1.3.2 Separation of Certificates and Keys by Intended Use
[2](#separation-of-certificates-and-keys-by-intended-use)

1.4 COMMUNITY AND APPLICABILITY [3](#community-and-applicability)

1.4.1 Community [3](#community)

1.4.2 Applicability [3](#applicability)

1.4.3 Registration of CA Names 4

1.5 INTERSITE TRUST AGREEMENTS AND CROSS-CERTIFICATION 4

1.5.1 Intersite Trust Agreements 4

1.5.2 Intra-organization Cross-Certification 4

1.5.3 Conditions for Use of Certificates by Cross-Certified CAs 4

2\. GENERAL PROVISIONS [5](#general-provisions)

2.1 LIABILITY, OWNERSHIP, AND DISCLAIMERS
[5](#__RefHeading___Toc464035350)

2.2 ROLES AND OBLIGATIONS [5](#__RefHeading___Toc464035351)

2.2.1 Certification Authority (CA)
[5](#certification-authority-administrator-caa)

2.2.2 Registration Authority [6](#registration-authority)

2.2.3 Subscriber 7

2.2.4 Sponsor 8

2.2.5 Relying Party 9

2.3 PUBLICATION AND REPOSITORIES 9

2.3.1 Publication of CA Information 9

2.3.2 Method of Publication [9](#method-of-publication)

2.3.3 Frequency of Publication [9](#frequency-of-publication)

2.3.4 Access Controls 10

2.4 COMPLIANCE AUDIT 10

2.5 CONFIDENTIALITY 10

2.5.1 Normal Operation 10

2.5.2 Exceptions for Encrypted Data Recovery
[10](#__RefHeading___Toc464035365)

2.5.3 Exceptions for Conveying Private Keys to End Entities
[10](#exceptions-for-conveying-private-keys-to-end-entities)

2.5.4 Exceptions for Diagnosing and Troubleshooting Problems
[10](#exceptions-for-diagnosing-and-troubleshooting-problems)

3\. IDENTIFICATION AND AUTHENTICATION 12

3.1 INITIAL REGISTRATION 12

3.1.1 Subject Naming in Certificates 12

3.1.2 Uniqueness of Subject Names 13

3.1.3 Method to Prove Possession of Private
Key.....................................................................13

3.1.4 Authentication of Individual Identity 13

3.1.5 Authentication of Organization Identity 13

3.1.6 Authentication of Computers and Machines as End Entities 13

3.2 ROUTINE RE-KEY 13

4\. OPERATIONAL REQUIREMENTS 15

4.1 CERTIFICATE APPLICATION AND ISSUANCE 15

4.2 CERTIFICATE ACCEPTANCE 15

4.3 CERTIFICATE SUSPENSION AND REVOCATION 15

4.3.1 Reasons for Revocation 15

4.3.2 Revocation Requests 15

4.3.3 Certificate Suspension 16

4.3.4 Certificate Verification 16

4.4 SECURITY AUDIT PROCEDURES 17

4.5 RECORDS ARCHIVAL 17

4.6 KEY LIFETIMES AND CHANGEOVERS 17

4.6.1 CA Keys 17

4.6.2 End Entity Keys 17

4.7 CA COMPROMISE AND DISASTER RECOVERY 18

4.8 CA TERMINATION 18

5\. PHYSICAL, PROCEDURAL, AND PERSONNEL SECURITY CONTROLS
[18](#physical-procedural-and-personnel-security-controls)

5.1 Physical SECURITY Controls 19

5.1.1 Physical Security Controls for Certification Authorities 20

5.1.2 Physical Security Controls for Registration Authorities 20

5.1.3 Physical Security Controls for End entities 20

5.2 PROCEDURAL CONTROLS 20

5.2.1 Trusted Roles 20

5.2.2 Number of Persons Required per Task 21

5.2.3 Identification and Authentication for Each Role 22

5.3 PERSONNEL SECURITY CONTROLS 22

5.3.1 Personnel Security Controls for Certification Authorities 22

5.3.2 Personnel Security Controls for Registration Authorities 22

5.3.3 Personnel Security Controls for End Entities 22

6\. TECHNICAL SECURITY CONTROLS 23

6.1 KEY PAIR GENERATION AND INSTALLATION 23

6.1.1 Key Pair Generation 23

6.1.2 Private Key Delivery to Entity 23

6.1.3 Public Key Delivery to Certificate Issuer 23

6.1.4 CA Public Key Delivery to Users
[22](#ca-public-key-delivery-to-users)

6.1.5 Key Parameters 24

6.1.6 Key Usage 24

6.2 PRIVATE KEY PROTECTION 24

6.2.1 Standards for Cryptographic Modules 24

6.2.2 Private Key Multi-Person Control 24

6.2.3 Private Key, Backup, and Archival 25

6.2.4 Private Key Activation and Entry into Hardware Cryptographic
Modules 25

6.2.5 Method of Deactivating and Destroying Private Key 25

6.3 ACTIVATION DATA (PASSWORDS) 25

6.4 COMPUTER SECURITY CONTROLS 26

6.5 NETWORK SECURITY CONTROLS 26

6.6 CRYPTO ENGINEERING CONTROLS 26

6.7 LIFE CYCLE TECHNICAL CONTROLS 26

6.7.1 System Development Controls 26

6.7.2 Security Management Controls 27

6.7.3 Life Cycle Security Assurance 27

7\. CERTIFICATE AND CRL PROFILES 28

7.1 CERTIFICATE FORMAT VERSIONS AND PROFILES 28

7.2 POLICY OBJECT IDENTIFIER 28

7.3 SIGNATURE ALGORITHM OBJECT IDENTIFIERS 28

7.4 USE OF NAME FIELDS 28

7.5 NAME CONSTRAINTS AND NAME FORMS FOR NAME CONSTRAINTS 28

7.6 CERTIFICATE EXTENSIONS POPULATED AND THEIR CRITICALITY 28

7.7 USE OF POLICY CONSTRAINTS 29

7.8 POLICY QUALIFIERS 29

7.9 CRL AND CRL ENTRY EXTENSIONS POPULATED AND THEIR CRITICALITY 29

8\. CERTIFICATE POLICY ADMINISTRATION AND CHANGE CONTROL 30

8.1 CERTIFICATE POLICY CHANGE PROCEDURES 30

8.2 ADMINISTRATIVE POINTS OF CONTACT 30

REFERENCES 31

This page intentionally left blank.

# ACKNOWLDEGEMENTS {#acknowldegements .unnumbered}

# DEFINITIONS {#definitions .unnumbered}

[Activation data]{.underline}: Data (other than keys) required for
operating hardware or software cryptographic modules. Examples include
personal identification numbers (PINs), passwords, and pass phrases.

[Authentication]{.underline}: The process of establishing identity based
on the possession of a trusted credential.

[Authority Revocation List (ARL)]{.underline}: A list of
cross-certificates previously issued by the subject CA that have been
subsequently compromised or otherwise invalidated.

[Certificate]{.underline}: A public key certificate

[Certification Authority]{.underline}:

[Certification Authority Administrator (CAA)]{.underline}: An entity
responsible for issuing, signing (certifying), and managing public key
certificates (sometimes referred to as a certificate authority.)

[Certificate Authority Workstation (CAW]{.underline}): The computer
system or systems that process certification authority software and/or
have access to the CA private keys, end entity keys, or end entity
public keys prior to certification.

[Certification path]{.underline}: \[TBD\]

[Certificate Policy (CP)]{.underline}: A "named set of rules that
indicates the applicability of a certificate to a particular community
and/or class of application with common security requirements" \[X509\].

[Certification Practices Statement (CPS)]{.underline}: A statement of
the practices that a CA employs for operating the CA in compliance with
a certificate policy.

[Certificate Revocation List (CRL)]{.underline}: A list of certificates
previously issued by the subject CA that have been subsequently
compromised or otherwise invalidated.

[Cross-certificate]{.underline}: A certificate issued by the subject CA
certifying the public key of another CA.

[Data integrity]{.underline}: Cryptographically secure assurance that no
change has occurred in a document, message, data file, or data
transmission.

[Decryption private key]{.underline}: A private key used to decrypt data
or session keys encrypted by the corresponding public key. In the
context of this document, the public key is presumed to be contained and
conveyed by an encryption certificate.

[Distinguished Name]{.underline}: *\[Use x.500 definition\]*

[FMS community]{.underline}: The US Department of Treasury, Financial
Management Service (FMS), or any person or organization operating under
the authority and direction of the FMS, either directly or through a
contractual relationship.

[Domain (of a CA)]{.underline}: The scope of authority of a CA,
generally limited to RAs and end entities registered with or certified
by the CA.

[Encryption certificate]{.underline}: A certificate containing and
conveying a public key used to encrypt electronic messages, files,
documents, data transmissions, etc., or to establish a session key for
those purposes.

[End Entity (EE)]{.underline}: A person computer system or a
communications device that is a subject or user of a certificate, but is
not a CA or RA. An end entity is a subscriber, a relying party, or both.

[Entity]{.underline}: A CA, RA, or end entity.

[Government information]{.underline}: Defined by Office of Management
and Budget (OMB) Circular A-130 as all information created, collected,
processed, disseminated, or disposed of by or for the Federal
government.

[Identity certificate]{.underline}: A certificate issued for the purpose
of binding the identity of the subject (as stated in the certificate) to
a public key issued to that subject. In X.509 certificates, the identity
of the subject is equivalent to the Distinguished Name of the subject.

[Intersite Trust Agreement]{.underline}: An agreement between sites for
allowing cross-site use of certificates.

[Key]{.underline}: A value supplied to a cryptographic algorithm to
encrypt or decrypt data.

[Key materials]{.underline}: A tangible representation of a key.
Examples include a key stored in computer memory, computer disk, smart
card, or other key carrier.

[PKI]{.underline}: See public key infrastructure.

[Policy Certification Authority (PCA)]{.underline}: A FMS entity that
formulates policy, and oversees the operation of public key
infrastructures within the FMS, as specified in the FMS
Telecommunications Manual, Chapter 9, *"Policy for the Use of Public Key
Cryptography and Key Management.*"

[Policy Management Authority (PMA)]{.underline}: *(This group needs to
be formed)* A FMS committee with representatives from organizations
operating CAs within the FMS, as specified in the FMS Telecommunications
Manual, Chapter ?, *"Policy for the Use of Public Key Cryptography and
Key Management.*"

[Private key]{.underline}: The portion of a public-private key pair
known only to the holder.

[Public key]{.underline}: The portion of a public-private key pair that
may be publicly known or distributed without reducing the security of
the cryptography system. In the context of this Policy, public keys
(after initial issuance) are always distributed through the use of
public key certificates.

[Public key certificate]{.underline}: The public key portion of a
public-private key pair, that has been digitally signed by a CA, thereby
certifying the validity and data integrity of the public key contained
in the certificate, in accordance with the applicable certificate
policy.

[Public key algorithm]{.underline}: A cryptographic algorithm in which
the encryption and decryption functions are divided between a pair of
mathematically related keys. In some common public key algorithms (e.g.,
RSA), the encryption/decryption functions are reciprocal, i.e., either
key of the pair can be used to encrypt or decrypt, with the other key
able to decrypt or encrypt respectively.

[Public key infrastructure (PKI)]{.underline}: A system for using public
key cryptography and providing a trusted mechanism for distributing and
managing public keys through the appropriate use of certificates.

[Registration Authority (RA)]{.underline}: A person or other entity
operating under the authority of a CA that is responsible for
identification and authentication of certificate subjects and other
duties as assigned in the site CPS.

[Relying party]{.underline}: Any user or recipient of a certificate that
acts in reliance on that certificate. In this document, the terms
"certificate user" and "relying party" are used interchangeably.

[Session key]{.underline}: A key, typically for a symmetric algorithm,
established between communicating parties for subsequent
encryption/decryption of electronic messages, files, documents, data
transmissions, etc. Its use is generally limited to that purpose and a
single transaction or session.

[Signature verification certificate]{.underline}: A certificate
containing and conveying a public key used to verify a digital signature
created by the associated signing private key. Also called a
verification certificate.

[Signing private key]{.underline}: A private key used to create digital
signatures.

[Sponsor]{.underline}: A person or organization with which the
subscriber is affiliated (e.g., as an employee, user of service, or
customer).

[Subject]{.underline}: An entity that has been issued a certificate by
the subject CA in compliance with this Policy, and whose public key and
distinguished name are certified in the certificate.

[Subject end entity]{.underline}: An end entity that is the subject of a
certificate.

[Subscriber]{.underline}: See *Subject.*

[Symmetric algorithm]{.underline}: An cryptographic algorithm in which
data is encrypted and decrypted using the same key.

# ABBREVIATIONS {#abbreviations .unnumbered}

ARL Authority Revocation List

CA Certification Authority

CAA Certification Authority Administrator

CAW Certificate Authority Workstation

CP

CPS Certification Practices Statement

CRL Certificate Revocation List

FMS US Department of Treasury, Financial Management Service

FIPS Federal Information Processing Standard

IEC International Electro-technical Commission

IETF Internet Engineering Task Force

IP Internet Protocol

ISO International Organization for Standardization

ISSO Information Systems Security Officer

ITU International Telecommunications Union

NIST National Institute of Standards and Technology

PCA Policy Certification Authority

PMA Policy Management Authority

PIN Personal Identification Number

PKI Public Key Infrastructure

PKIX Public Key Infrastructure - X.509 (IETF Working Group)

RA Registration Authority

RFC Request For Comments

RSA Rivest-Shamir-Adelman encryption algorithm

SA System Administrator

TCSEC Trusted Computer System Evaluation Criteria

# INTRODUCTION

## OVERVIEW

This document defines the requirements for issuance, management, and use
of public key certificates and associated cryptographic technology used
for authentication, confidentiality, data integrity, and non-repudiation
security services in FMS unclassified information processing
communities.

This document defines the requirements for issuance, management, and use
of public key certificates and associated cryptographic technology used
for authentication, confidentiality, data integrity, and non-repudiation
security services in FMS unclassified information processing
communities. Chapter 9 of FMS Manual 200.1-1, Public Key Cryptography
and Key Management, establishes the requirement for the development of
certificate policies.

This Policy is termed a *medium assurance* level policy with respect to
measures specified for assuring trust: identification and
authentication, key lengths, physical and computer security protections,
etc.

This Policy states the roles and obligations of Certificate Authority
Administrator's and other entities issuing, managing, and using
certificates and related cryptographic materials. It sets forth
requirements for identification and authentication of entities,
operation of Certificate Authority (CA) software and hardware, Intersite
Trust Agreements and cross-certifications with other CAs, and other
essential elements of certificate issuance, management, and use.

All sections of this Policy apply equally to certificates used for
digital signature applications and encryption/decryption applications
unless otherwise noted.

As stated in section 2.1.6, certificate users and relying parties must
assure themselves*,* by reviewing this document, the CPS, and any other
information they deem necessary, that any certificate issued or other
service provided by a CA under this Policy is suitable for the intended
use.

**All keys, key materials, and certificates issued under this policy are
the property of** **the Financial Management Service** **and the US
Government. Activities of the certification authority and other
entities, and all certificates issued and used under this CP, are
intended solely for the conduct of FMS business and must conform to
applicable FMS policies, Government regulations, and site policies.**

## CERTIFICATE POLICY IDENTIFICATION

### Certificate Policy Name

"Certificate Policy CP-1 for FMS Public Key Certificates in Unclassified
Environments"

### Object Identifier **{to be supplied}**

### Certificate References to This Policy

Persons or organizations within the FMS community operating a CA may
issue public key certificates that reference this CP (see 1.2.3),
provided that the CA conforms to the stipulations of this CP and
operates in compliance with all other applicable FMS policies and
regulations.

Certification Authorities issuing certificates that conform to the X.509
Version 3 standard shall include the Object Identifier (see 1.2.2) of
the CP in the policy extension field of the certificate.

CAs that do not support the CP, but conform in all other ways to this CP
may also issue certificates. Such CAs shall operate under this CP
exclusively, so that all certificates issued by the CA can be presumed
to be compliant with this CP. This shall be clearly stated in the
applicable Certification Practices Statement.

## CERTIFICATE TYPES AND INTENDED USE

### Identity Certificates

Certificates issued under this CP are identity certificates. They are
issued for the purpose of binding the identity of the subject's public
key to the subject and other information contained in the certificate.
They are *not* intended to convey information about the subject's role,
authority, clearance to access data, or authorization to perform
business functions. Even though authorization may be implicit in these
certificates simply because they exist in certain environments, it is
not recommended that these certificates be used in that manner.

### Separation of Certificates and Keys by Intended Use

Under this CP, certificates and related private keys used for creating
and verifying digital signatures and/or authentication shall be separate
from those used for encrypting and decrypting electronic messages,
files, data transmissions, etc. The CA may issue one or both certificate
types to an end entity.

#### Digital Signature and Authentication Use

Signing private keys and signature verification certificates may be used
for creating and verifying digital signatures. Through the use of
appropriate protocols, they may also be used as credentials for
authentication. Requirements elsewhere in this CP state that the signing
private keys shall never be made available to any party other than the
subject. This provides the basis for non-repudiation of digital
signatures and positive authentication, and also makes signing keys and
verification certificates unacceptable for encryption/decryption use
because of the conflicting requirement to archive decryption private
keys for possible data recovery use.

#### Encryption Use

Encryption certificates and decryption private keys may be used for
encrypting electronic messages, files, documents, data transmissions,
etc., or establishing session keys for that purpose. Requirements
elsewhere in this Policy state that decryption private keys shall be
archived by the CA, providing a mechanism for recovery of encrypted data
in emergency situations. Because private keys are potentially available
to more than one entity, they are not suitable for digital signature or
authentication use.

## COMMUNITY AND APPLICABILITY

### Community

Financial Management Service

The community applicable to this CP are certificate holders whose
certificates have been issued under this policy. These will most always
be affiliates of FMS whose certificates were issued by a FMS CA.

### Applicability

Certificates and keys issued in accordance with this CP are intended for
use in processing FMS Government information as stated below.

-   To permit public key encryption or session key establishment for the
    purpose of protecting all FMS unclassified information, including
    FMS sensitive and Unclassified from unauthorized disclosure. The use
    of any encryption including public key is subject to the
    requirements of FMS polices and Federal Information Processing
    Standard (FIPS) publications.

> ***Public key cryptographic systems described in this CP OR OPERATED
> UNDER THIS CP*** ***SHALL NOT be used to protect classified
> information.***

-   To verify the data integrity of electronic messages, files,
    documents, data transmissions, etc., through the use of digital
    signatures.

-   To verify the identity affiliation of the signer of electronic
    messages, files, documents, data transmissions, etc., through the
    use of digital signatures.

-   To verify the identity of client computers, servers, and other
    computer systems.

-   To verify the identity of recipients of FMS unclassified
    information, including FMS sensitive unclassified information ,
    whose authorization to receive such information has been
    pre-established.

### Registration of CA Names

> To ensure unambiguous assignment of CA names within the FMS community,
> CA names that appear as part of subject distinguished names in
> certificates shall be registered with the FMS Policy Certification
> Authority for exclusive use within the community (see 1.4.1) by the CA
> organization.

## CROSS-CERTIFICATION

Prior to using certificates issued by a cross-certified CA, it is the
responsibility of the subject CA to inspect the CP and CPS of the
cross-certified CA and determine what, if any, restrictions must be
placed on the use of certificates issued by that CA. The subject CA may
negotiate enhancements or assurances regarding operational procedures,
facility, operations, administration, restrictions on certificate usage,
certificate validity period, volume of transactions between subscribers,
liability issues, etc.

### RESERVED 

### RESERVED 

### RESERVED 

# GENERAL PROVISIONS

##  {#section .unnumbered}

[]{#__RefHeading___Toc464035350 .anchor}

## ROLES AND OBLIGATIONS

### Certification Authority Administrator (CAA)

Certification authorities are responsible for issuing and signing
(certifying) public key certificates. They are also responsible for many
aspects of managing these certificates, associated key materials, and
other PKI services as specified elsewhere in this CP.

#### Accuracy of Representations

By publishing a certificate that references this CP in a repository
accessible by members of the community, or otherwise conveying a
certificate to a relying party, the CA certifies to all who reasonably
rely on the information contained in the certificate that it has: issued
the certificate to the named subscriber in accordance with this CP, and
that the subscriber has accepted the certificate, and that the CA was
operating in compliance with this CP at the time the certificate was
issued and through the end of the validity period of all CRLs and ARLs
issued by the CA.

#### CA Discretion to Issue Certificates

> Certificates are issued at the discretion of the CA. The CA shall
> reject any certificate request that does not appear to comply with all
> the stipulations of this CP and/or applicable local CPS.

#### Protection of CA Private Keys

The CA shall protect its private keys in accordance with the provisions
of Section 6 of this CP.

#### CA Private Key Use

The CA's private key can be used for signing end entity certificates,
cross-certificates, CRLs, ARLs, other certificate types, and for CA
management functions such as signing response messages confirming that
requested actions have been accomplished. Requirement for approved
Certification Practices Statement

The CA shall operate under a Certification Practices Statement (CPS)
that specifies the practices through which this CP is implemented. The
CPS shall reference this CP by name or object identifier.

#### Separation of Signature and Encryption Certificates

The CA shall issue separate certificates for digital signature or
authentication functions and for encryption/decryption functions (see
1.3.2). The CA shall be capable of separating certain management
functions (e.g., key recovery, certificate revocation, expiration and
renewal) for each certificate type, as detailed elsewhere in this CP.

#### Revocation of Certificates

The CA shall provide a mechanism to insure that compromised or otherwise
invalidated certificates (see 4.3) are promptly revoked. The revocation
mechanism shall allow certificate users to obtain timely and unambiguous
knowledge of the revocation status of any certificate issued by the CA.
**The revocation mechanism shall be fully specified in the CPS.**

#### Key Recovery and Escrow

The CA shall archive the private decryption key associated with any
public encryption certificate issued by the CA, and maintain the
capability to recover that key. This doesnot apply to those issued for
digital signature and authentication use.

Archival and recovery practices, and the conditions under which key
recovery is authorized, shall be fully described in the CPS. Each
subscriber shall be informed of these practices at or prior to
certificate issuance (see 2.1.3.5)

Symmetric keys are not required to be escrowed.

### Registration Authority

The CA may delegate or employ one or more Registration Authorities (RAs)
for identification and authentication of certificate subjects,
forwarding authentication results to the CA, relaying CA key generation
passwords (not the keys themselves) to the user, conveying the CA's
public key certificate, and other administrative functions as detailed
in the CPS. The specific duties will be specified in the site CPS. RAs
shall conform to the stipulations of the site CPS.

#### Requirement for Written Approval from CA

Each RA operating within the domain of the subject CA shall have written
approval for operation from the CA. The CA shall maintain a list of
approved RAs.

#### Accuracy of Representations

By performing duties as a registration authority for the subject CA, the
RA certifies that he or she has accepted this responsibility and has
agreed to operate in compliance with this CP and applicable CPS.

#### Use of Private Keys for RA Functions

Persons operating as RAs may use their normal end entity private keys
for RA functions.

### Subscriber

A subscriber is an entity issued a certificate by the subject CA in
accordance with this CP, and whose public key and distinguished name are
certified in the certificate. Subscribers issued certificates under this
CP shall be associated with a sponsor recognized by the CA as specified
in section 2.1.4

The subscriber agrees to comply the stipulations in sections 2.1.3.1
through 2.1.3.5, and agrees to uphold these throughout the operational
period of the certificate.

The subscriber shall sign an agreement at or prior to the time of
issuance of the certificate as specified in sections 2.3.3.1 through
2.3.3.5. The CA shall retain a copy of the agreement.

#### Accuracy of Representations

The subscriber certifies that all representations made by the subscriber
to the sponsor, CA, or RA regarding the information in the certificate
are true.

#### Protection of End Entity Private Keys

The subscriber shall retain control of the subscriber's private keys and
key materials, and protect them in accordance with section 5.1.3 of this
CP. The subscriber shall take necessary precautions to prevent loss,
disclosure to any other party, modification, or unauthorized use. The
subscriber shall likewise protect activation data.

#### Restrictions on End Entity Private Key Use

Private keys are issued for the exclusive use of the key holder in the
conduct of FMS business, as stated in section 1.1.

#### Notification of Loss, Disclosure, or Compromise

The subscriber shall notify the CA or RA immediately upon any actual or
suspected loss, disclosure, or compromise of the subscriber\'s private
keys or activation data.

#### Decryption Key Recovery

The subscriber understands that the CA maintains the ability to recover
the subscriber's private decryption key. The CA may, as required by law
or authorized FMS officials, or under other circumstances specified in
the applicable CPS, recover the subscriber's private decryption key and
decrypt any data encrypted with the corresponding public key.

### Sponsor 

### The sponsor shall be a person or organization with which the subscriber is affiliated (e.g., as an employee, user of service, customer, etc.). The sponsor shall certify that the subscriber has a recognized relationship with the sponsoring organization and has a valid need and purpose for public key certificates issued by the subject CA. The requirements for sponsoring relationships shall be specified in the applicable CPS.

The sponsor may also certify a group of individuals, in which case each
member of the group is considered to be sponsored by the certifying
sponsor.

The sponsor agrees to comply with this CP and the stipulations in
sections 2.1.5.1 through 2.1.5.2, and agrees to uphold these throughout
the operational period of the certificate.

The sponsor shall sign an agreement to this effect at or prior to the
time of issuance of the certificate(s). The CA shall retain a copy of
the agreement.

#### Sponsor Representations

By sponsoring a subscriber, the sponsor certifies that at the time of
the sponsor\'s approval of the subscriber, and throughout the
operational period of the certificate unless the issuing CA or RA is
notified otherwise by the sponsor:

-   The subscriber has a valid affiliation with the sponsor (as an
    employee, user of service, customer, or other relationship
    documented in the subscription application provided to the CA).

-   All representations made by the sponsor to the CA or RA regarding
    subscriber information to be used for the issuance of certificates
    are true

-   The subscriber has a valid need and purpose for public key
    certificates issued by the CA

#### Notification of Termination of Sponsoring Relationship

The sponsor or sponsor's authorized agent shall notify the CA or RA
promptly upon termination of the sponsoring relationship with the
subscriber, or termination of the subscriber\'s valid need for the
certificates issued pursuant to that relationship.

### Relying Party is any recipient of a certificate who relies on a certificate in the conduct of business. In practice however, it is not practical for every certificate holder to ascertain if the certificate is in fact appropriate for business use. Within the FMS environment, it is expected that business process owners and data owners will make the determination as to the appropriateness of use of these certificates. When a process and/or data owner decides to use a certificate issued under this policy, they indemnify the holders of certificates when these certificates are properly used as specified by the business process and data owners.

## PUBLICATION AND REPOSITORIES 

### Publication

The CAA may publish its CP. The FMS CA Root will be maintained and
managed within the Information Resource Division.

The CAA shall make the following items available to subjects and relying
parties:

-   Copies of this CP and any CPS that references this CP

-   Copies of all Intersite Assurance Agreements, Intersite Trust
    Agreements, and cross-certification agreements entered into by the
    CA

-   Copies of public key certificates issued by the CA

-   Copies of all CRLs and ARLs issued by the CA.

### Repositories

### Method of Publication

CAs may publish the information specified in section 2.3.2 by conveying
the information to subjects, relying parties, or other entities
reasonably requiring the information, or by publishing the information
in a repository accessible by those entities. Such repositories may be
operated by the CA or by a separate organization (i.e., a third party).
In the latter case, the subject CA shall retain adequate control to
insure that the requirements of this CP are met. The CPS shall document
any such third-party repository relationship.

### Frequency of Publication

The CA shall publish certificates and other information promptly upon
issuance or acceptance by the CA.

### Access Controls

The CA shall insure that appropriate access controls are in place to
prevent unauthorized writing, modifying, or deleting certificates,
policy documents, CRLs, and other items placed in the repository.

## PUBLICATION AND REPOSITORIES 

The site PKI operating in accordance with this CP, including operational
CAAs and RAs, will be subject to periodic review and audit, as required.
Certification authorities operating under this CP shall be subject to
periodic review and audit as specified by applicable FMS and Treasury
Polices.

2.  **PUBLICATION OF CA INFORMATION**

**2.4 COMPLIANCE AUDIT**

**2.5 CONFIDENTIALITY**

### **2.5.1 Normal Operation** {#normal-operation .unnumbered}

In normal operation, CAAs shall not have access to the private keys of
entities they certify. RAs and end entities shall not have access to the
private keys of any other end entity. The previous statement is not
intended to exclude an individual from being the subject of more than
one entity certificate, in which case that individual would have access
to the private keys for each of those entities.
[]{#__RefHeading___Toc464035365 .anchor}2.5.2 Exceptions for Encrypted
Data Recovery

Exceptions to section 2.4.1 shall be made for cases in which the CAs
and/or RAs must have access to the private decryption keys of the
entities they certify or support for the purpose recovering encrypted
data as specified in Section 2.1.3.5. These keys shall be protected in
accordance with technical security provisions in Section 6, and shall
not be disclosed to any other party without the prior consent of the
subscriber or authorized agents, or as required by law. The procedures
and conditions under which private decryption key disclosure is
authorized shall be specified in the CPS.

### 2.5.3 Exceptions for Conveying Private Keys to End Entities {#exceptions-for-conveying-private-keys-to-end-entities .unnumbered}

Exceptions to section 2.4.1 may be made for cases in which it is
impossible or impractical to have the end entity generate their own
signing private keys as mandated in section 6.1.1. In such cases, the CA
or authorized CA representative may generate the end entity signing
private keys and other key material and convey them to the end entity.
These keys shall be protected in accordance with technical security
provisions in Section 6 and not disclosed to any other party.

The CA shall document all such exceptions for each occurrence. The
conditions under which this process may be utilized, and the
requirements for authorization, secure generation, and secure
conveyance, shall be fully specified in the applicable CPS.

###  2.5.4 Exceptions for Diagnosing and Troubleshooting Problems {#exceptions-for-diagnosing-and-troubleshooting-problems .unnumbered}

Exceptions to section 2.4.1 may be made for cases in which it is
impossible or impractical for a CA or RA to troubleshoot, diagnose, or
repair system or user problems without access to the private keys of an
end entity. In such cases, the entity may disclose their private keys or
activation data to the CA or authorized CA representative. These keys
shall be protected in accordance with technical security provisions in
Section 6 and not disclosed to any other party.

In all such cases, the end entity shall give informed, signed consent to
the disclosure of their private keys or activation data. As soon as the
problem is resolved, the CA shall take immediate measures to resume
secure operation (such as revoking and re-issuing end entity
certificates, requiring the end entity to change the activation data,
etc.).

The CA shall document all such exceptions for each occurrence, to
include the signed statement of the subject entity. The conditions under
which this process may be utilized, and the requirements for
authorization and continuity of secure operation, shall be fully
specified in the applicable CPS.

# IDENTIFICATION AND AUTHENTICATION OF END ENTITIES

## INITIAL REGISTRATION 

### Authentication of Individual Identity

#### Need to Present in Person

In normal operations, the applicant must personally appear before the RA
and be visually authenticated for the purpose of certificate issuance.

Exceptions to the above may be made for cases in which it is impossible
or impractical to have the end entity appear in person. In such cases,
the CA may issue a certificate based on the signed statement of a
sponsor affirming he or she personally knows the certificate subject and
accepting responsibility for compliance with this CP. The conditions
under which this process may be utilized, and the requirements for
authorization and approval of such requests, shall be fully specified in
the applicable CPS. See for additional requirements if the private
signing key cannot be generated by the end entity.

#### Minimum Credential(s) Required 

The CA or RA shall verify the applicant\'s identity by examination of an
official badge issued by the FMS or a FMS Integrated contractor, which
includes a photograph of the applicant.

If the applicant does not possess an official FMS badge, the CA or RA
may verify the applicant\'s identity based on two other forms of
identification, at least one of which shall be a photographic credential
issued by a branch of the US Government or a State Government. The forms
of identification required in this case and the methods used to
establish and verify identity shall be fully specified in the CPS.

The CPS shall specify the approval requirements and process for cases in
which the applicant does not appear in person.

#### Verification of Attributes or Privileges

Not applicable for identity certificates

### Subject Naming in Certificates

In an effort to insure clarity in subject names across FMS sites,
subject naming in certificates shall conform as closely as practical to
subject naming guidelines issued by the PCA or PMA.

If the end entity is a person, the form of the distinguished name shall
be officially recognized by the issuing entity. If that name differs
from the name which appears on the credential used by the CA or RA to
establish the subject\'s identity, the difference must be resolved by
the issuing official through consulting an officially authoritative
source (badge office, etc.). **The form of the name to be used and
methods for verification shall be outlined in the CPS.**

### Uniqueness of Subject Names

The CAA shall ensure that the distinguished name is unambiguous for all
subjects within the domain of the CA.

### Method to Prove Possession of Private Key

The registration process shall involve a stage in which the applicant
demonstrates possession of the private signing key. The process by which
this is accomplished shall be specified in the CPS.

The registration process shall involve a stage in which the applicant
demonstrates possession of the private decryption key. The process by
which this is accomplished shall be specified in the CPS.

### Authentication of Organization Identity

In a certificate issued to a named organization, the CPS shall specify
the manner in which the CA or RA shall confirm the business entity\'s
name, address, and other registration information.

### Authentication of Computers and Machines as End Entities

Certificates may be issued to named computer systems or machines
incorporating a computer system, provided that a person is designated as
the responsible party for assuring appropriate control and use of
private keys and certificates issued. The CA or RA shall document this
designation. The designated party shall be issued a certificate in
compliance with this CP, except that the identification information in
the certificate shall identify the subject computer system or machine.
It is the responsibility of the designated person to insure that the
keys and certificates are securely conveyed to the subject computer
system or machine.

The CPS shall specify the manner in which the CA or RA shall verify the
computer system\'s end entity name, address, and other registration
information and the method of conveying the keys and certificates. The
CA shall document the form(s) of identification used to verify this
information.

## ROUTINE RE-KEY

Certificates and associated private keys issued to end entities shall be
replaced at specified intervals and a new certificate issued (see
4.6.2). In the case of a forgotten password, authentication shall be
effected as for initial registration.

**3.3 RE-KEY AFTER REVOCATION**

Authentication of a subject for re-key following revocation depends upon
the revocation reason. With a non-compromise revocation, re-key may be
performed upon request. The CPS shall describe the conditions under
which this is allowed.

In an actual, suspected, or potential compromise situation,
authentication shall be effected as for initial registration.

**3.4 REVOCATION REQUEST**

A revocation request may be authenticated on the basis of a valid
digital signature recognized by the issuing CA or by a signed written
request. Revocations can be made at the request of the subject, the
sponsor, or other authorized persons as stated in the CPS.

# OPERATIONAL REQUIREMENTS

*This section describes the operating requirements imposed by this CP on
CAs, RAs, and end entities. It includes handling of certificate
revocations, audit logs, and transaction archives*

## CERTIFICATE APPLICATION AND ISSUANCE

The CPS shall specify the procedure for subscriber application for a
certificate. The issuance of a certificate by a CA indicates a complete
and final approval of the certificate application by the CA.

## CERTIFICATE ACCEPTANCE

The certificate issuance process shall include a step in which the
subscriber explicitly indicates acceptance of the certificate. The
mechanism for this shall be specified in the CPS. By accepting a
certificate containing the identifier of the subscriber in the
certificate, the subscriber agrees to the terms and conditions contained
in this CP and the applicable CPS.

## CERTIFICATE SUSPENSION AND REVOCATION

### Reasons for Revocation

#### Key Compromise

Certificates shall be revoked when the private key or activation data
associated with the certificate is compromised. Key compromise includes
unauthorized access to private keys or activation data, loss of private
keys or activation data, stolen keys, or destroyed keys, or reasonable
suspicion that any of these have occurred.

#### Subscriber Failure to Meet Obligations

A certificate may be revoked by a CA upon failure of the subscriber to
meet its obligations under this CP, the CPS, FMS or Federal regulations,
site policies, or any other agreement or regulation that may be in
force.

#### Termination of Need for Certificate

Subscriber certificates may be revoked when a valid need no longer
exists for the certificate.

### Revocation Requests

The CPS shall identify the entities that may request revocation of a
certificate. These may include:

-   the end entity/certificate holder or sponsor,

-   the issuing CA,

-   the RA, on behalf of the sponsor or the end entity,

-   authorized organizational elements such as the subject's Human
    Resources Department, or

-   other authorized persons including FMS and law enforcement
    officials.

    The CPS shall also specify the manner in which a revocation request
    may be generated, and how it is processed. All revocation requests,
    reasons for revocation, and the resulting actions taken by the CA
    shall be documented.

    Revocation requests shall be promptly forwarded to the CA or an RA
    following suspicion or detection of a compromise or any other event
    necessitating revocation.

### Certificate Suspension

Under this CP, CAs are required to support certificate revocation, but
suspension is optional. The CPS shall state any provisions regarding
suspension.

### Certificate Verification

#### Certificate Revocation List -Based Verification

Where CRLs are used as the basis of certificate verification, CAs shall
issue CRLs on a regular basis. CRLs for certificates issued under this
CP shall have a lifetime of no more than 25 hours. The CPS may specify a
shorter lifetime. The CRL validity period or expiration time shall be
stated within the body of the CRL.

An end entity that obtains a CRL from a repository (or other source)
shall verify the authenticity of the CRL by checking its digital
signature and the associated certification path. Certificates and CRLs
may be stored locally on a relying party\'s system but, before use, each
such certificate and CRL shall be validated to insure that it is still
in effect and has not expired.

A revoked certificate shall remain on the CRL until the certificate
validity period expires.

#### Time-of-Use Verification

Time-of-use ("on-line") certificate verification is not acceptable under
this CP at this time.

## SECURITY AUDIT PROCEDURES

The CA shall log or otherwise document for audit purposes the following
information relating to the CA Workstation(s):

-   Creation of operating system accounts (privileged or not)

-   Installation of new software or software updates

-   Time and date of backups, shutdowns, and restarts of the system

-   Hardware changes, repairs, or upgrades

-   Audit log dumps (resets)

-   Transaction archive dumps (resets)

    Audit logs shall be appropriately protected and time-stamped.
    Non-electronic audit records shall be signed and dated by
    appropriate personnel. The CPS shall specify procedures for
    reviewing, verifying, and storing audit logs and records.

## RECORDS ARCHIVAL

CAs shall archive, and make available on authorized request,
documentation of CA compliance with this CP and applicable CPS, as
specified in this CP and supporting CPS. For each certificate and CRL,
the records shall include the creation, issuance, use, suspension,
revocation, expiration, and renewal activities

Archives shall be retained and protected against modification or
destruction for a period as specified in the CPS, but no less than the
lifetime of end entity certificates. The CA shall ensure availability of
the archive even if the CA operations are interrupted, suspended or
terminated.

## KEY LIFETIMES AND CHANGEOVERS

### Certificate Authority Keys

CAs have a single signing key with which they do all CA signing
functions. CAs may not issue certificates that extend beyond the
expiration dates of their own certificates and public keys; therefore,
their certificate validity periods must be greater than those for users,
listed in section 3.2. To minimize risk to the CA through compromise of
an authority's key, those keys will be changed more frequently, and only
the new key will be used for authority signing purposes from that time.
The older, but still valid, certificate will be available to verify old
signatures until all of the user certificates signed under it have also
expired. For this medium assurance policy, CA signing keys shall have a
validity period of 20 years and a lifetime of 8 years.

### End Entity Keys

Prior to the expiration of the usage period of a key pair, a subscriber
may request issuance of a new certificate, provided the previous
certificate has not been revoked and a valid sponsor and requirement for
the certificate still exists. Up to two such renewals/re-keys may occur
on-line at intervals not to exceed 25 months, without the need for the
subject to reappear in person. The CPS shall specify the time period
during which such requests are permitted.

Revoked or expired certificates shall not be renewed.

## CA COMPROMISE AND DISASTER RECOVERY

In case of a CA key compromise, the CA's certificate shall be revoked
(if possible by the CA signing the compromised key). Subsequently, the
CA installation shall be re-established from the beginning by first
re-establishing the CA equipment and re-issuing the CA certificate, then
re-issuing all cross-certificates and all end user certificates.

The CPS shall specify the requirements and procedures for recovery of
the CA in the event of a disaster whereby a CA installation is
physically damaged and becomes inoperative. If, due to the disaster, the
CA keys or archived end entity keys are compromised, or there is
reasonable suspicion that compromise may have been possible during the
disaster or subsequent activities, then the CA shall be re-built as in
the case of key compromise, above.

All breaches or suspected breaches of CA integrity or security shall be
reported promptly to the PMA.

## CA TERMINATION

Operation of the CA may be terminated for convenience, contract
expiration, re-organization, or other non-security related reason. In
this case, the CA shall attempt to notify all certificate subjects and
relying parties of the termination. Certificates may continue to be
considered valid at the discretion of the relying party.

At or prior to termination, the CA must provide for disposition of
audit, archive, and data recovery material from the terminated CA. The
PMA must be notified immediately of the intent to terminate an operating
CA.

# PHYSICAL, PROCEDURAL, AND PERSONNEL SECURITY CONTROLS

*This section describes the physical, procedural, and personnel security
controls required of CAs, RAs, and end entities to protect their
operations.*

In the community covered by this CP (see 1.4.1), CA, RAs and end
entities operate in a FMS unclassified environment that may contain
sensitive unclassified information, therefore, in addition to the
requirements of this section, all FMS requirements for operation in a
sensitive unclassified information processing environment must also be
met. This shall be so stated in the supporting CPS.

In considering the CA, RA, and end entity security environment,
increased exposure of data through the use of cross-certificates (for
example, extending security services provided by the CA to users at
remote sites), whether intended or not, must be included.

Where security measures and controls required by this CP are already in
place as part of existing FMS policy, site security policy, computer
protection plans, or other applicable policy, these policies shall be
cited in the CPS.

## Physical SECURITY Controls

### Physical Security Controls for Certification Authorities

Physical security controls shall be implemented to control access to CA
hardware and software. This includes the CA workstation(s) (and
servers), and any external cryptographic hardware modules or tokens.

Physical access to the CA workstation(s) shall be limited to those
personnel performing one of the roles described in section 5.2.1. Access
control may be provided by keeping the CA workstation and related
equipment in a locked room or a locked equipment cabinet ("CA facility")
with access only available to those personnel.

Alternatively, the CA may be co-located in an area approved by FMS for
housing other equipment of equivalent security and trust implications
(e.g., a site's unclassified Kerberos key distribution center), with
access limited to appropriate personnel.

The CPS shall specify the type of facility or mechanism used for
controlling access to the CA.

Security checks for the CA facility shall be provided on a regular
basis. The procedure and interval shall be specified in the CPS. The
security check shall include visual verification that cryptographic
devices/tokens are securely stored if not in use, that the doors and
locks are properly secured, and that there have been no attempts at
forceful entry.

The CA facility shall also provide storage for backup and distribution
media in a manner sufficient to prevent loss, tampering, or unauthorized
use of the stored information. Backups shall be kept both for data
recovery and for the archival of important information. At least one
copy of backup material shall be stored at a location apart from the CA
workstation, with equivalent security, to permit restoration in the
event of a disaster to the primary facility. Backup media shall be
adequately protected from access by unauthorized personnel.

### Physical Security Controls for Registration Authorities

For RAs, the only mandatory physical security control is use of a
lockable file cabinet or other repository for storing records of end
entity registration requests.

### Physical Security Controls for End entities

End entity private keys, activation data, and hardware tokens (if used)
shall be protected in accordance with FMS or site policies for
protection of data of equivalent security and trust implications (e.g.,
Kerberos passwords for unclassified resources). The CPS shall specify
the protection mechanism or refer to other FMS or site policies for
protection of such information.

End entity private keys may be stored in encrypted form on a diskette,
computer hard drive, or other unsecured medium, provided that the
private key information is encrypted with an approved encryption
algorithm, protected by the subject's password or passphrase, and that
access to the end entity workstation is limited when the subject is not
present (e.g., through the use of boot-up passwords, locking screen
savers, etc.).

The PIN or password used to unlock the private key protection or
hardware cryptographic token shall never be stored in the same location
as the private key or token itself.

Preferably, PINs, passwords, etc., should be memorized and not written
down. If a PIN or password must be written down, it shall be protected
as above. The CPS may specify certain emergency roles and conditions for
storage, retrieval, and handling of this information by other persons.
The CA shall document the use of such emergency procedures for each
occurrence.

End entities shall not leave their workstations unattended when the
cryptography is in an unlocked state such that it could be utilized by
an unintended party.

## PROCEDURAL CONTROLS

### Trusted Roles

#### Trusted Roles for Certification Authorities

It is recommended that a CA supporting this CP recognize at least three
distinct roles, as outlined below. Different arrangements of separation
of duties may be acceptable, provided the resilience to insider attack
is at least as strong as with the recommended model and the roles are
fully described in the CPS.

The recommended roles are:

> [Information System Security Office (ISSO)]{.underline} --responsible
> for Platform security
>
> [Certification Authority Administrator (CAA)]{.underline}

The CAA role typically includes: certificate generation, programming and
secure distribution of subscriber cryptographic tokens (if any),
generating, distributing, and otherwise managing CRLs, and other
administrative functions associated with maintaining the CA database and
assisting in compromise investigations.

> [System Administrator (SA)]{.underline}

The SA role typically includes: initial configuration of the computer
and operating systems including secure boot start-up and shut down of
the CAW, initial setup of all system accounts, initial network
configuration, creating emergency system restart media to recover from
catastrophic system loss, recovering from unexpected system crashes or
other malfunctions, performing system backups, software upgrades and
recovery, including the secure storage and distribution of the backups
and upgrades to an off-site location, and changing of the host name
and/or network address.

[Platform Security Administrator (PSA)]{.underline}

The PSD role typically includes: assigning or changing operating system
security privileges and access controls of users, authorizing or
creating new system accounts, performing archive of required system
records, review and subsequent deletion of the audit log to detect CAA
compliance with system security policy, and conducting or supervising a
periodic inventory of the CA's records.

#### Trusted Roles for Registration Authorities

No special procedural controls are stipulated.

#### Trusted Roles for End Entities

No requirement stated.

### Number of Persons Required per Task

For the CA, at least two persons shall be present and actively aware of
the current operation when any of the following operations are
performed:

-   "Breaking in" or otherwise bypassing operating system protections,
    as in the case of unexpected system malfunctions,

-   Copying or replacement of hard drives or system media, other than
    backup media,

-   Restoration of the system from a backup,

-   CA key-pair generation *subsequent* to the initial installation of
    the CA, or

-   CA key-pair revocation.

    These persons shall be those assigned one of the roles listed in
    Section 5.2.1.1, or an authorized delegate. In any case, BOTH
    persons shall be sufficiently well trained in CA technology and
    security considerations to understand the security implications of
    the task they are performing or witnessing.

    It is also recommended that recovery of end entity private keys
    require two persons. The requirements and process for end entity key
    recovery shall be fully specified in the CPS (see 2.1.1.7).

    All such two-person accesses shall be documented by the CA,
    including the names of both persons.

### Identification and Authentication for Each Role

In accordance with usual practices for positions of this sensitivity.

## PERSONNEL SECURITY CONTROLS

### Personnel Security Controls for Certification Authorities

All CA personnel in sensitive positions, including, at least, the CAA
and ISSO positions, shall be appointed in writing by an approving
authority and have received proper training in the performance of their
duties. The CPS shall specify the persons or organizations responsible
for providing this training.

### Personnel Security Controls for Registration Authorities

The CA organization shall ensure that each individual performing RA
tasks has been trained in the operation of RA software and in the
registration policies and practices of this guide. The CPS shall specify
the persons or organizations responsible for providing this training.
All RA appointments shall be documented by the CA.

### Personnel Security Controls for End Entities

End entities shall be made aware of any additional security practices
they need to follow in the protection of their workstations and
cryptographic devices when accessing their private keys. The CPS shall
specify the persons or organizations responsible for providing this
training.

# TECHNICAL SECURITY CONTROLS

*This section contains provisions of the public/private key pair
management policy for CAs, RAs, and end entities, and the corresponding
technical controls.*

Under this CP the CA, RAs and end entities operate in a FMS unclassified
environment that may contain sensitive unclassified information,
therefore, in addition to the requirements of this section, all FMS
requirements for operation in a sensitive unclassified information
processing environment must also be met. This shall be so stated in the
supporting CPS.

In considering the CA, RA, and end entity security environment, any
possible exposure of data through the use of cross-certificates, whether
intended or not, must be included.

Where security measures and controls are already in place as part of
existing FMS policy, site security policy, computer protection plans, or
other applicable policy, these policies shall be cited in the CPS.

## KEY PAIR GENERATION AND INSTALLATION

### Key Pair Generation

Every entity shall generate its own signing key pair. An end entity may
generate its own encryption/decryption key pair, or its
encryption/decryption key pair may be generated by another entity,
including a CA, RA, or other trusted third party, provided that the
other requirements of this CP are met.

Exceptions to this, in which key pairs are generated by another entity,
may be granted by the CA as specified in Section for entities *other
than* CAs or RAs.

### Private Key Delivery to Entity

Signing: No delivery required (see 6.1.1).

Encryption: If an encryption/decryption key pair is generated by an
entity other than the subject entity, then the private key shall be
delivered in a secure manner, manually or via an encrypted on-line
exchange. The CPS shall specify the mechanism for delivery.

### Public Key Delivery to Certificate Issuer

Public keys shall be protected against modification or substitution
during delivery to the certificate issuer, manually or via a signed or
encrypted on-line exchange. The CPS shall specify the mechanism for
delivery.

### CA Public Key Delivery to Users

CA public keys shall be protected against modification or substitution
during delivery to the certificate user, manually or via a signed or
encrypted on-line exchange. The CPS shall specify the mechanism for
delivery.

### Key Parameters

Key sizes, key generation mechanisms, and other key parameters shall be
specified in the CPS. Key parameters and encryption algorithms must be
as required by FMS orders and policy for handling FMS sensitive
unclassified data .

### Key Usage

#### End Entity Signing and Verification

End entities will typically use their private signing keys either to
create digital signatures or as part of a challenge-response protocol
for authentication. End entity public verification keys will be used by
relying parties to verify digital signatures and challenge-responses.

#### End Entity Encryption and Decryption

End entities will typically use their private decryption keys to decrypt
messages encrypted with their public key encryption certificate. End
entity public encryption keys will be used by relying parties to encrypt
electronic messages, files, documents, data transmissions, etc., or to
establish a session key for those purposes

#### CA Signing and Verification

CAs will typically use their private signing keys in a digital Signature
algorithm to sign end entity certificates and CRLs. CA Public
verification keys will be used by relying parties to verify the CA's
digital signature.

## PRIVATE KEY PROTECTION

### Standards for Cryptographic Modules

CA keys shall be created and maintained in a cryptographic module
validated to at least FIPS 140-1 Level 1.

If RAs perform all cryptographic operations, the RA shall meet the same
requirements as the CA.

End entities shall protect private keys, when not in active use, by
storage in approved cryptographic hardware modules, or by using an
approved cryptographic algorithm to encrypt private key information
stored in non-volatile computer memory, disks, or other media.

If a hardware cryptographic module is not used, private key storage
media shall be protected, when not in use, by physical access control
(see 5.1.3), or by additional encryption of the media (or the portion
containing the private key information) with an approved encryption
product.

### Private Key Multi-Person Control

For CAs, two-person control is required for generation, changes, or
revocation of the CA private keys (except for first-time generation and
initialization) (see 5.2.2). For RAs and end entities, one person
control is permitted.

### Private Key, Backup, and Archival

Private signing keys shall not be stored or archived by any entity
except the entity to which the key was issued. An entity may optionally
back up its own private signing key. Backup copies shall be protected
(see 5.1.3).

Private decryption keys shall be stored or archived by the CA as stated
in 2.1.1.7. These keys shall be given the same protection as the CA
private keys, unless otherwise stated in the applicable CPS

### Private Key Activation and Entry into Hardware Cryptographic Modules

If a hardware cryptographic module is used, the private key is generated
in it and it remains there.

### Method of Deactivating and Destroying Private Key

Upon termination of use of a private signing key or private decryption
key, all copies of the private key shall be securely destroyed.

## ACTIVATION DATA (PASSWORDS)

No requirement stated.

## COMPUTER SECURITY CONTROLS

The certification authority workstation (CAW) shall provide sufficient
computer security controls for the separation of roles described in
section 5.2 to be enforced, and to prohibit access by unauthorized
users.

The CPS shall specify computer security controls for the CAW or
reference other approved site plans/policies for such controls. Computer
security controls for workstations used by RAs depend on the role
assigned to the RA. RAs that load certificates onto hardware tokens or
initialize such tokens shall meet the requirements imposed upon CAWs.
Workstations used by RAs who are simply information verifier/forwarders
do not need a formal TCSEC rating but must include reasonable support
for audit logs and access controls.

Computer security controls for repositories used by a CA shall be
sufficient to reasonably insure that certificates, policy documents, and
CRLs are available to users and relying parties, and are protected from
unauthorized writing, modifying or deleting (2.2.5).

## NETWORK SECURITY CONTROLS

The CPS shall specify network security controls for the CAW network
segment. A CAW network segment is defined as any network segment to
which components of the CA (such as servers and operators' workstations)
are connected. The CPS may reference other approved site plans/policies
for such controls. As a minimum, the CAW network segment(s) shall be
protected by a firewall (packet-filtering router and/or application
gateway) configured to allow only the minimum set of functions to pass
through.

Network security controls imposed on the workstation used by an RA
depend on the role assigned to the RA. RAs that load certificates onto
hardware tokens or initialize such tokens shall meet the requirements
imposed upon CAWs. Workstations used by RAs who are simply information
verifier/forwarders need no special network protections.

No specific network security controls are stipulated for the certificate
repository used by a CA.

## CRYPTO ENGINEERING CONTROLS

The cryptographic devices used by a CA and a RA shall meet at least
level 1 of FIPS 140-1.

## LIFE CYCLE TECHNICAL CONTROLS

### System Development Controls

One of the following approaches shall be used as protection against the
insertion of malicious logic into software that implements CA and RA
functionality:

a\. The software is developed in a controlled environment, such as one
that follows or is equivalent to the Trusted Software Development
Methodology level T2 or higher. \[TSDM\].

b\. The organization operating the CA or RA workstation obtains and
examines the source code that implements the application, or engages an
independent organization to do the examination, looking for logic that
might make extra copies of private keys, or improperly call or use
cryptographic functions. The organization that performs the examination
shall not be the same organization that developed or modified the
software.

c\. CAWs and RA workstations may be based on commercially-available
off-the-shelf products, provided that the software manufacturer is
regularly and customarily engaged in the business of providing such
software, and that the software is a standard, released product
available to the commercial market at-large.

d\. FMS must approve exceptions to the above requirements.

### Security Management Controls

See 5.2.1. These roles shall be implemented and enforced.

### Life Cycle Security Assurance

The executable code that makes up the CA application should be digitally
signed by the organization holding the master copy, if feasible. If a
digital signature is not available, then some other secure means should
be utilized to insure that the correct code is received and installed
from distributing organization. The CPS shall specify procedures for
validating the executable software against the known signature value
when available and alternative procedures for non signed code.

Installed code that is not expected to change by operating, should be
signed by a local authority and verified periodically for modification.
If code is found to be modified, then CA operations should cease until
the cause is found and corrected. The CPS will specify the procedures
for this.

Life-cycle assurance controls imposed on the workstation used by a RA
depend on the role assigned to the RA. RAs that load certificates onto
hardware tokens or initialize such tokens shall meet the requirements
imposed upon CAWs. There are no life-cycle security assurance
requirements imposed on the workstations used by RAs who are simply
"information verifier/forwarders".

# CERTIFICATE AND CRL PROFILES

*This section contains rules and guidelines regarding the use of
particular X.509 certificate and CRL fields and extensions.*

The CPS shall include a description of the certificates, CRLs and the
directory schema. This description should indicate which certificate and
CRL extensions are present, whether they are marked critical or
non-critical, which optional fields are included, what value ranges are
allowed, and what action is expected of verifiers in response to any
non-standard extensions. The location of these attributes in the
directory shall be described.

## CERTIFICATE FORMAT VERSIONS AND PROFILES

It is recommended that CAs issue X.509 Version 3 certificates, in
accordance with the IETF PKIX certificate profile definition. \[HOU\]

## POLICY OBJECT IDENTIFIER

The object identifier for this Policy shall be as specified in 1.2.2.

## SIGNATURE ALGORITHM OBJECT IDENTIFIERS

Certificates issued under this Policy shall be signed using a signature
algorithm approved for use within the FMS.

## USE OF NAME FIELDS

All CAs and RAs shall have a primary name in the Directory Name form,
and this name shall be used in the appropriate field in the base
certificate or CRL (not an extension field).

## NAME CONSTRAINTS AND NAME FORMS FOR NAME CONSTRAINTS

The issuing CA shall populate the name constraint field in certificates
with directory names only.

## CERTIFICATE EXTENSIONS POPULATED AND THEIR CRITICALITY

In accordance with the provisions of the IETF PKIX profile \[HOU\].

## USE OF POLICY CONSTRAINTS

At the option of the issuing CA.

## POLICY QUALIFIERS

The following policy qualifier types, as defined in the PKIX profile,
may be used with this Policy:

-   CPS Pointer

-   User Notice

## CRL AND CRL ENTRY EXTENSIONS POPULATED AND THEIR CRITICALITY

As specified in the CPS.

# CERTIFICATE POLICY ADMINISTRATION AND CHANGE CONTROL

## CERTIFICATE POLICY CHANGE PROCEDURES

Changes to this document must be approved in accordance with applicable
FMS policy. Notice shall be given within a reasonable time to all
relying parties and cross-certified CAs of changes to this document. The
notification mechanisms shall be specified in the CPS.

## ADMINISTRATIVE POINTS OF CONTACT

# REFERENCES {#references .unnumbered}

\[IETF\] Internet Engineering Task Force: Internet Public Key
Infrastructure

*Part IV: Certificate Policy and Certifications Practices Framework
(2000)* Available at:

[ftp.isi.edu]{.underline}

\[ABA\] American Bar Association, Section of Science & Technology,
*Digital Signature Guidelines* (1996)

\[FIPS\] U.S. Department of Commerce, *Security Requirements for
Cryptographic Modules*, Federal Information Processing Standards
Publication FIPS PUB 140-1, 1994. Available at: http://csrc.nist.gov.

\[CHO\] S. Chokhani and W. Ford, "Certificate Policy and Certification
Practices Statement Framework," Internet Draft
\<draft-ietf-pkix-ipki-part4-00.txt\>.

\[HOU\] R Housley, W. Ford, T. Polk, D. Solo, *Internet Public Key
Infrastructure Part I: X.509 Certificate and CRL Profile*, Internet
Draft: draft-ietf-pkix-ipki-part1-04.txt, 03/26/1997.

\[TCSEC\] U.S. Department of Defense, *Department of Defense Trusted
Computer System Evaluation Criteria*, DOD 5200.28-STD, National Computer
Security Center, Fort Meade, MD, December 1985. Available at:
http://www.disa.mil/MLS/info/orange/intro.html;
http://csrc.nist.gov/secpubs/rainbow/std001.txt.

\[TSDM\] U.S. Department of Defense, "Trusted Software Methodology,"
Volume 1, SDI-S-SD-91-000007, Department of Defense, Strategic Defense
Initiative Organization, 17 June 1992.

\[X509\] ISO/IEC 9594-8, *Information Technology---Open Systems
Interconnection---The Directory: Authentication Framework*. Also
published as ITU-T X.509 Recommendation. For X.509 v3 certificates, see
edition ITU-T Rec. X.509 (1993 E) or ISO/IEC 9594-8:1995 with Technical
Corrigendum 1 and Amendment 1 (Certificate Extensions) applied.

\[FORD\] "Strawman Certificate Policy Definitions: Mid-Level Policies
for Digital Signature and Encryption" Warwick Ford, 4/29/97