National Institute of Standards and Technology

PILOT ROOT CERTIFICATION AUTHORITY

**POLICY**

For The

KEY RECOVERY DEMONSTRATION PROJECT

VERSION 1.0

February 23, 1998

TABLE OF CONTENTS

**1. INTRODUCTION**

1.1 OVERVIEW

1.2 IDENTIFICATION

1.3 COMMUNITY AND APPLICABILITY

1.3.1 Certification Authorities

1.3.2 Registration Authorities

1.3.3 End Entities

1.3.4 Applicability

1.4 CONTACT DETAILS

1.4.1 Specification Administration Organization

1.4.2 Contact Person

1.4.3 Person Determining policy Suitability for the Policy

2\. GENERAL PROVISIONS

2.1 LIABILITY

2.1.1 CA Liability

2.1.2 RA Liability

2.2 OBLIGATIONS

2.2.1 CA Obligations

2.2.2 RA Obligations

2.2.3 Subscriber Obligations

2.2.4 Relying Party Obligations

2.2.5 Repository Obligations

2.3 FINANCIAL RESPONSIBILITY

2.3.1 Indemnification by Relying Parties

2.3.2 Fiduciary Relationships (Trust)

2.3.3 Administrative Processes

2.4 INTERPRETATION AND ENFORCEMENT

2.4.1 Governing Law

2.4.2 Severability, Survival, Merger, Notice

2.4.3 Dispute Resolution Procedures

2.5 FEES

2.5.1 Certificate Issuance or Renewal Fees

2.5.2 Certificate Access Fees

2.5.3 Revocation or Status Information Access Fees

2.5.4 Fees for Other Services such as Policy Information

2.5.5 Refund Policy

2.6 PUBLICATION AND REPOSITORIES

2.6.1 Publication of CA Information

2.6.2 Frequency of Publication

2.6.3 Access Controls

2.6.4 Repositories

2.7 COMPLIANCE AUDIT

2.7.1 Frequency of Entity Compliance Audit

2.7.2 Identity/Qualifications of Auditor

2.7.3 Auditors Relationship to Audited Party

2.7.4 Topics Covered by Audit

2.7.5 Actions Taken as a Result of Deficiency

2.7.6 Communication of Results

2.8 CONFIDENTIALITY (Information Disclosure)

2.8.1 Types of Information to be Kept Private

2.8.2 Types of Information Not Considered Private

2.8.3 Disclosure of Certificate Revocation/Suspension Information

2.8.4 Release to Law Enforcement Officials

2.8.5 Release as Part of Civil Discovery

2.8.6 Disclosure Upon Owner's Request

2.8.7 Other Information Release Circumstances

2.9 INTELLECTUAL PROPERTY RIGHTS (Property Rights)

3\. IDENTIFICATION AND AUTHENTICATION

3.1 INITIAL REGISTRATION

3.1.1 Types of Names

3.1.2 Need for Names to be Meaningful

3.1.3 Rules for Interpreting Various Name Forms

3.1.4 Uniqueness of Names

3.1.5 Name Claim Dispute Resolution Procedure

3.1.6 Recognition, Authentication and Role of Trademarks

3.1.7 Method to Prove Possession of Private Key

3.1.8 Authentication of Organization Identity

3.1.9 Authentication of Individual Identity

3.2 ROUTINE REKEY

3.3 REKEY AFTER REVOCATION

3.4 REVOCATION REQUEST

4\. OPERATIONAL REQUIREMENTS

4.1 CERTIFICATE APPLICATION

4.2 CERTIFICATE ISSUANCE

4.3 CERTIFICATE ACCEPTANCE

4.4 CERTIFICATE SUSPENSION AND REVOCATION

4.4.1 Circumstances for Revocation

4.4.2 Who Can Request Revocation

4.4.3 Procedure for Revocation Request

4.4.4 Revocation Request Grace Period

4.4.5 Circumstances for Suspension

4.4.6 Who Can Request Suspension

4.4.7 Procedure for Suspension Request

4.4.8 Limits on Suspension Period

4.4.9 CRL Issuance Frequency

4.4.10 CRL Checking Requirements

4.4.11 On-line Revocation/Status Checking Availability

4.4.12 On-line Revocation Checking Requirements

4.4.13 Other Forms of Revocation Advertisements Available

4.4.14 Checking Requirements for Other Forms of Revocation
Advertisements

4.4.15 Special Requirements re Key Compromise

4.5 SECURITY AUDIT PROCEDURES

4.5.1 Types of Events Recorded

4.5.2 Frequency of Processing Log

4.5.3 Retention Period for Audit Log

4.5.4 Protection of Audit Log

4.5.5 Audit Log Backup Procedures

4.5.6 Audit Collection System (Internal vs. External)

4.5.7 Notification to Event-Causing Subject

4.5.8 Vulnerability Assessments

4.6 RECORDS ARCHIVAL

4.6.1 Types of Events Recorded

4.6.2 Retention Period for Archive

4.6.3 Protection of Archive

4.6.4 Archive Backup Procedures

4.6.5 Archive Collection System (Internal or External)

4.6.6 Procedures to Obtain and Verify Archive Information

4.7 KEY CHANGEOVER

4.8 COMPROMISE AND DISASTER RECOVERY

4.9 CA TERMINATION

5\. PHYSICAL, PROCEDURAL, AND PERSONNEL SECURITY CONTROLS

5.1 PHYSICAL SECURITY CONTROLS

5.1.1 Site Location and Construction

5.1.2 Physical Access

5.1.3 Media Storage

5.1.4 Waste Disposal

5.1.5 Off-site Backup

5.2 PROCEDURAL CONTROLS

5.2.1 Trusted Roles

5.2.2 Number of Persons Required Per Task

5.2.3 Identification and Authentication for Each Role

5.3 PERSONNEL CONTROLS

5.3.1 Background, Qualifications, Experience, and Clearance Requirements

5.3.2 Background Check Procedures

5.3.3 Training Requirements

5.3.4 Retraining Frequency and Requirements

5.3.5 Job Rotation Frequency and Sequence

5.3.6 Sanctions for Unauthorized Actions

5.3.7 Contracting Personnel Requirements

5.3.8 Documentation Supplied to Personnel

6\. TECHNICAL SECURITY CONTROLS

6.1 KEY PAIR GENERATION AND INSTALLATION

6.1.1 Key Pair Generation

6.1.2 Private Key Delivery to Entity

6.1.3 Public Key Delivery to Certificate Issuer

6.1.4 CA Public Key Delivery to Users

6.1.5 Key Sizes

6.1.6 Public Key Parameters Generation

6.1.7 Parameter Quality Checking

6.1.8 Hardware/Software Key Generation

6.1.9 Key Usage Purposes (as per x.509 v3 key usage field)

6.2 PRIVATE KEY PROTECTION

6.2.1 Standards for Cryptographic Module

6.2.2 Private Key (n out of m) Multi-Person Control

6.2.3 Private Key Escrow

6.2.4 Private Key Backup

6.2.5 Private Key Archival

6.2.6 Private Key Entry Into Cryptographic Module

6.2.7 Method of Activating Private Key

6.2.8 Method of Deactivating Private Key

6.2.9 Method of Destroying Private Key

6.3 OTHER ASPECTS OF KEY PAIR MANAGEMENT

6.3.1 Public Key Archival

6.3.2 Usage Periods for the Public and Private Keys

6.4 ACTIVATION DATA

6.4.1 Activation Data Generation and Installation

6.4.2 Activation Data Protection

6.4.3 Other Aspects of Activation Data

6.5 COMPUTER SECURITY CONTROLS

6.5.1 Specific Computer Security Technical Requirements

6.5.2 Computer Security Rating

6.6. LIFE CYCLE SECURITY CONTROLS

6.6.1 System Development Controls

6.6.2 Security Management Controls

6.6.3 Life Cycle Security Ratings

6.7 NETWORK SECURITY CONTROLS

6.8 CRYPTOGRAPHIC MODULE ENGINEERING CONTROLS

7\. CERTIFICATE AND CRL PROFILES

7.1 CERTIFICATE FORMAT VERSIONS AND PROFILES

7.1.1 Certificate Extensions

7.1.2 Algorithm Object Identifiers

7.1.3 Name Forms

7.1.4 Name Constraints

7.1.5 Certificate Policy Object Identifier

7.1.6 Usage of Policy Constraints Extension

7.1.7 Policy Qualifiers Syntax and Semantics

7.1.8 Processing Semantics for the Critical Certificate Policy Extension

7.2 CRL PROFILE

7.2.1 Version number(s)

7.2.2 CRL and CRL entry extensions

8\. SPECIFICATION ADMINISTRATION

8.1 SPECIFICATION CHANGE PROCEDURES

8.2 PUBLICATION AND NOTIFICATION POLICIES

8.3 POLICY APPROVAL PROCEDURES

**Root Certification Authority Policy**

# 1. INTRODUCTION 

## 1.1 OVERVIEW

A certificate policy is a named set of rules that indicates the
applicability of a certificate to a particular community and/or class of
applications with common security requirements. The policy defined in
this document is tailored to the Pilot Root Certification Authority
(CA), hear after referred to as the Root CA, for the Federal Agency
pilots participating in the Key Recovery Demonstration Project (KRDP).

No requirement for confidentiality or key recovery was identified for
the Root CA. Therefore, this policy does not address requirements
specific to the support of confidentiality or key recovery services, or
address the certification of public keys by the Root CA except for
subordinate CAs.

This policy document and the associated Certificate Practice Statement
(CPS), which describes the practices of the Root CA, should be used to
determine the degree of assurance and trust that can be placed in the
authenticity and integrity of the public keys contained in certificates
issued by the Root CA.

## 1.2 IDENTIFICATION

This policy is called the *NIST Pilot Root Certification Authority
Policy for the Key Recovery Demonstration Project.* The Root CA issues
certificates for use in the verification of certificates issued by the
subordinate CAs.

## 1.3 COMMUNITY AND APPLICABILITY

This certificate policy reflects security requirements in support of the
KRDP Root CA and its subordinate CAs. The use of this policy shall be
approved by the appropriate authorities. The certificate policy and CPS
of any subordinate CA shall be consistent with those of the Root CA.

### *1.3.1 Certification Authorities*

The Root CA will certify subordinate CAs used by the KRDP pilots.
Subordinate CAs shall conform to the stipulations of this certificate
policy definition and publish a Certification Practice Statement that
supports and includes a reference to this certificate policy.
Subordinate CAs following this policy may certify subscriber CAs and end
users in a manner which is consistent with the Root CA requirements.

### *1.3.2 Registration Authorities*

Any registration authority (RA) may operate within this certificate
policy provided they conform to the stipulations of this certificate
policy definition and register with, and obtain the approval of, the
Root CA as described in 1.3.1. An RA may employ agents, in which case
each agent shall be directly accountable for the transactions that he or
she performs on behalf of the RA.

### *1.3.3 End Entities*

The end entities are the subscribers of the subordinate CAs
participating in the KRDP, and includes only those subscribers
associated with the KRDP in cases where the subordinate CA has non- KRDP
subscribers. The subscribers to be certified under this policy shall be
associated with a Federal Agency participating in the KRDP.

### *1.3.4 Applicability*

This policy is for use in the generation of certificates which bind
public keys to their owners. In the case of the Root CA, the
certificates shall bind digital signature public keys to the appropriate
subordinate CA; no other certificates shall be issued by the Root CA.
This policy applies to the Root CA and its agents, the Root CA, RA and
its agents, the subordinate CAs and their agents, the certificate and
certificate revocation list (CRL) repositories of the Root and
subordinate CAs, and to the end entities of the KRDP Federal Agency
pilots.

## 1.4 CONTACT DETAILS

### *1.4.1 Specification Administration Organization*

The National Institute of Standards and Technology's (NIST), Information
Technology Laboratory, Computer Security Division, Security Technology
Group is the administering organization for this certificate policy.

### *1.4.2 Contact Person*

Questions regarding this policy should be directed to the:

Pilot Root CA Registrar

National Institute of Standards and Technology

Computer Security Division

Security Technology Group

Bldg. 820, Room 426

Gaithersburg, MD 20899

> krdp@nist.gov

### *1.4.3 Person Determining policy Suitability for the Policy*

The KRDP Project Manager determines the suitability of this policy for
the KRDP.

# 2. GENERAL PROVISIONS

## 2.1 LIABILITY

The Subordinate CAs agree that NIST is not liable for the disclosure or
information designated as Proprietary which, after notice to and
consultation with the Subordinate CAs, NIST determines may not lawfully
be withheld or which a court of competent jurisdiction requires
disclosed.

### 2.1.1 CA Liability

N/A

### 2.1.1.1 Warranties and Limitations on Warranties

Under this policy, the Root CA warrants and promises to:

-   provide certification and repository services consistent with this
    certificate policy;

-   provide the controls required by this certificate policy definition;

-   perform the authentication procedures as set forth in Section 3 of
    this certificate policy definition;

-   issue certificates in accordance with this certificate policy
    definition and honor the various representations to subscribers and
    to relying parties presented in any published CPS;

-   publish certificates in a repository that is generally available to
    the user community;

-   support the rights of the subscribers and relying parties who use
    certificates in accordance with applicable laws and regulations;

-   revoke certificates and issue CRLs in accordance with Section 4 of
    this certificate policy definition;

-   provide for the renewal of certificates on expiration; and

-   comply with all provisions in Section 2 of this certificate policy
    definition and any legal provisions in a published CPS.

Subordinate CAs may make warranties beyond those stated above.

### 2.1.2 RA Liability

N/A

#### 2.1.2.1 Warranties and Limitations on Warranties

Subordinate CAs warrant and promise to:

-   provide the controls required under Sections 4 through 6 of this
    certificate policy definition;

-   perform the authentication procedures as set forth in Section 3 of
    this certificate policy definition;

-   perform the obligations of an RA and support the rights of the
    relying parties who use certificates in accordance with applicable
    federal, state, and provincial laws and regulations; and

-   comply with all provisions in Section 2 of this certificate policy
    definition and any legal provisions in a published CPS.

RAs may make warranties beyond those stated above.

## 2.2 OBLIGATIONS

### 2.2.1 CA Obligations

The KRDP Root CA shall:

-   check that the subordinate CA policies are consistent with that of
    the Root CA policy;

-   sign certificates only after verifying the identity of the
    certificate subject in accordance with Section 3 of this policy, and
    that the subject holds the private key corresponding to the public
    key in the certificate;

-   post certificates in a public repository;

-   revoke certificates and provide a notice of invocation in accordance
    with Section 4.4 of this policy;

-   protect the private signing key of the Root CA in accordance with
    Section 6 of this policy;

-   use the private signing key only when issuing certificates and CRLs
    which conform to this policy; and

-   follow all applicable laws and regulations.

### 2.2.2 RA Obligations

The RA shall:

-   verify the identity of the certificate subject in accordance with
    Section 3 of this policy, and that the subject holds the private key
    corresponding to the public key in the certificate;

-   protect any private key in accordance with Section 6 of this
    certificate policy definition; and

-   not use any private key associated with the RA function for any
    other purpose.

### 2.2.3 Subscriber Obligations

Subordinate CAs are the subscribers of the Root CA. At the time of
certificate acceptance and throughout the operational period of the
certificate, a subscriber shall certify and agree that:

-   no unauthorized person has ever had access to the subordinate CA's
    private key;

-   the subordinate CA's private signing key shall be protected in
    accordance with Section 6 of this policy, taking reasonable
    precautions to prevent the loss, disclosure to any other party,
    modification, or unauthorized use of that key;

-   any compromise of the subordinate CA's private signing key shall be
    immediately reported to the Root CA;

-   all representations made by the subordinate CA to the Root CA or RA
    regarding the information in the certificate are true;

-   the certificate is being used exclusively for authorized and legal
    purposes, consistent with this certificate policy; and

-   all applicable laws and regulations shall be followed.

In addition, the subordinate CAs shall agree to the following with
regard to their relationship with their subscribers:

-   the policy of any lower level CA is consistent with that of the
    subordinate and Root CA policies; and

-   the verification, generation and revocation of certificates for the
    subscribers of the subordinate CAs shall be consistent with the Root
    CA's policy as defined in this document.

### 2.2.4 Relying Party Obligations 

Relying parties are KRDP subscribers of the KRDP subordinate CAs. All
relying parties shall operate in a manner which is consistent with the
policies of their subordinate CA and the Root CA.

### 

### 2.2.5 Repository Obligations

The Root CA repository shall be the vehicle for distributing timely
information regarding certificates and revocation lists. The Root CA
Administrator shall create certificates for the subordinate CAs and
place them in the repository. CRLs shall be created and inserted into
the repository immediately upon the receipt of a Certificate Revocation
Request.

## 2.3 FINANCIAL RESPONSIBILITY

### 2.3.1 Indemnification by Relying Parties

End entity liability shall be in accordance with applicable statutes.

### 2.3.2 Fiduciary Relationships (Trust)

Issuance of certificates in accordance with this policy shall not make
the Root CA an agent, fiduciary, trustee, or other representative of the
subordinate CAs or their subscribers.

Assisting in the issuance of certificates in accordance with this policy
shall not make the RA an agent, fiduciary, trustee, or other
representative of the subordinate CAs or their subscribers.

### 2.3.3 Administrative Processes

N/A

## 2.4 INTERPRETATION AND ENFORCEMENT

### 2.4.1 Governing Law

Various laws and regulations, including the Privacy Act and the Computer
Security Act, shall apply, depending upon the jurisdiction(s) in which
certificates are issued and used.

### 2.4.2 Severability, Survival, Merger, Notice

No stipulation

### 2.4.3 Dispute Resolution Procedures

Disputes within the KRDP Root CA domain shall be resolved by the KRDP
Project Manager.

## 2.5 FEES

### 2.5.1 Certificate Issuance or Renewal Fees

N/A

### 2.5.2 Certificate Access Fees

N/A

### 2.5.3 Revocation or Status Information Access Fees

N/A

### 2.5.4 Fees for Other Services such as Policy Information

N/A

### 2.5.5 Refund Policy

N/A

## 2.6 PUBLICATION AND REPOSITORIES

### 2.6.1 Publication of CA Information

The Root CA shall make this policy publicly available.

The certificates and CRLs associated with the subordinate CAs shall be
made publicaly available in the Root CA Repository.

### 2.6.2 Frequency of Publication

This policy shall be re-issued and published in accordance with Section
8. Certificates shall be published in the Root CA Repository as they are
issued.

CRLs shall be published in the Root CA Repository as they are issued.

### 2.6.3 Access Controls

There shall be no access controls on the reading of this certificate
policy definition or the KRDP Root CA CPS. This policy and the CPS shall
be made publicly available. There shall be appropriate access controls
controlling who can write or modify policies, certificates, certificate
status or CRLs. There shall be physical access controls to the Root CA
and RA equipment. Operating system controls shall be implemented by the
Root CA system to protect access to system resources. All personal
information maintained by the Root CA and RA shall be protected from
unauthorized disclosure.

### 2.6.4 Repositories

A repository holding the information identified in Error: Reference
source not found shall be used by the Root CA and every subordinate CA.
Each repository may be operated by the CA or by a separate organization.
There shall be no access controls imposed on information retrieval.

## 2.7 COMPLIANCE AUDIT

Audits will not be performed for the Root CA for this project. Audits
may be conducted for the subordinate CAs.

### 2.7.1 Frequency of Entity Compliance Audit

N/A

### 2.7.2 Identity/Qualifications of Auditor

N/A

### 2.7.3 Auditors Relationship to Audited Party

N/A

### 2.7.4 Topics Covered by Audit

N/A

### 2.7.5 Actions Taken as a Result of Deficiency

N/A

### 2.7.6 Communication of Results

N/A

## 2.8 CONFIDENTIALITY (Information Disclosure)

All information which is not considered to be public domain information
shall not be disclosed.

### 2.8.1 Types of Information to be Kept Private

Types of information that shall be kept private include, but are not
limited to, the following:

-   all secret and private keys of the Root CA;

-   audit trail information as a whole; however, records of individual
    transactions may be released to the entity involved;

-   security measures and system vulnerabilities of the Root CA;

-   authentication information;

-   subscriber information not appearing in a certificate or CRL; and

-   Privacy Act Information.

### 2.8.2 Types of Information Not Considered Private

Identification information or other information appearing on
certificates shall be considered public.

### 2.8.3 Disclosure of Certificate Revocation/Suspension Information

Identification information or other information including revocation
reason shall be considered public.

### 2.8.4 Release to Law Enforcement Officials

The Root CA shall release information to Law Enforcement Officials
provided that the appropriate order is issued by a court of law.

### 2.8.5 Release as Part of Civil Discovery 

All keys and related certificates shall be revoked and re-issued if any
private key is exposed.

### 2.8.6 Disclosure Upon Owner's Request

The Root CA shall release any requested information to a subordinate CA
concerning that CA.

### 2.8.7 Other Information Release Circumstances

Some information collected may be released for statistical analysis.

## 2.9 INTELLECTUAL PROPERTY RIGHTS (Property Rights)

Private and public keys are the property of the subject for whom the
certificate is created. Certificates issued by the Root CA are the
property of that CA.

# 3. IDENTIFICATION AND AUTHENTICATION

This section contains the practices that shall be followed in
identifying and authenticating individuals and organizations involved in
the certification process.

## 3.1 INITIAL REGISTRATION

Subordinate CAs shall provide their CPS and policy documentation to the
Root CA during initial registration as well as complying with the
following subsections.

### 3.1.1 Types of Names

For the purpose of this project, the Root CA and the subordinate CAs may
use names of their choosing.

NOTE: Subordinate CAs may optionally have additional name forms such as
an e-mail address; however the distinguished name (DN) is the primary
name and the one used to populate the subject fields of certificates and
CRLs.

### 3.1.2 Need for Names to be Meaningful

There shall be no overall requirement for names to be meaningful,
although the certificate applicant may be required to demonstrate
rightful use of a name.

### 3.1.3 Rules for Interpreting Various Name Forms

See 3.1.2

### 3.1.4 Uniqueness of Names

Names shall be unambiguously defined for each subordinate CA.

### 3.1.5 Name Claim Dispute Resolution Procedure

Name claim disputes shall be resolved at the root CA, if possible. In
the case that no resolution is possible at the root CA, the dispute
shall ultimately be resolved by the KRDP Project Manager.

### 3.1.6 Recognition, Authentication and Role of Trademarks

Names in any certificate issued under this policy shall be of the
subordinate CA's choosing. The Root CA or its agents may refuse to
accept a name known to be a trademark of someone else, or deemed
inappropriate for use in the certificate.

### 3.1.7 Method to Prove Possession of Private Key

The registration process shall involve a stage in which the applicant
demonstrates possession of the private key.

### 3.1.8 Authentication of Organization Identity

Under this policy, certificates shall only be issued to subordinate CAs.

### 3.1.9 Authentication of Individual Identity

Each subordinate CA contact shall provide appropriate identification
information to the Root CA. The Root CA shall then verify that
information.

## 3.2 ROUTINE REKEY

No automatic key update process will be used during the lifetime of the
KRDP.

NOTE: If the KRDP Project Manager determines that the project is to
extend beyond the original period, a new certificate will be issued. The
same identification and authentication process used for initial
certification applies to the issuance of new certificates.

## 3.3 REKEY AFTER REVOCATION

Rekey or certificate renewal following revocation may be authorized
depending upon the reason for the revocation. Renewal within a period of
time deemed reasonable by the Root CA following a non-compromise
revocation, may be authenticated on the basis of a digital signature
using the old key pair if no information about the certificate holder is
modified. In a compromise situation, or if any information about the
certificate holder is modified, authentication will be effected as for
initial registration.

## 3.4 REVOCATION REQUEST

A revocation request shall be authenticated and may be initiated by the
certificate holder or the KRDP Project Manager to the Root CA.
Notification of the revocation of a certificate, including the reason
and originator of the request, shall be provided to the requester.

# 4. OPERATIONAL REQUIREMENTS

Operational requirements are those requirements imposed by this policy
on the Root CA, RA and its subscribers with respect to various
operational activities.

## 4.1 CERTIFICATE APPLICATION

Each applicant shall generate a key pair and demonstrate to the Root CA
they hold a functioning key pair; protect the private key of this key
pair from compromise; and submit a certificate application. The
applicants for Root CA certificates are representatives of the
subordinate CAs. The applicant shall agree to the terms and conditions
contained in this certificate policy definition and the applicable CPS.

## 4.2 CERTIFICATE ISSUANCE

The issuance of a certificate by the Root CA shall indicate a complete
and final approval of the certificate application.

## 4.3 CERTIFICATE ACCEPTANCE

Successful completion of the certification, as defined in Section 4.2
above, shall constitute acceptance of the certificate by the subordinate
CA.

## 4.4 CERTIFICATE SUSPENSION AND REVOCATION

### 4.4.1 Circumstances for Revocation

Any certificate issued by the KRDP Root CA to a subordinate CA shall be
revoked when the certificate is no longer trusted for any reason or if
the relationship is no longer required.

### 4.4.2 Who Can Request Revocation

The subordinate CA or the KRDP Project Manager may request the
revocation of a subordinate CAs certificate.

### 4.4.3 Procedure for Revocation Request

### The revocation requester shall provide proper authentication and all appropriate information to the Root CA. Revoked certificates shall be identified in CRLs which are posted to the Root CA repository.

### 4.4.4 Revocation Request Grace Period

When a key compromise is detected or when risk warrants revocation, the
revocation request shall be placed immediately. Requests for other
revocation reasons shall be placed within a reasonable amount of time.

### 4.4.5 Circumstances for Suspension

The KRDP Root CA shall not support the suspension of certificates.

### 4.4.6 Who Can Request Suspension

N/A

### 4.4.7 Procedure for Suspension Request

N/A

### 4.4.8 Limits on Suspension Period

N/A

### 4.4.9 CRL Issuance Frequency

CRLs containing a newly revoked key which has been compromised shall be
issued immediately. In all other cases, CRLs shall be issued on a
routine periodic basis.

### 4.4.10 CRL Checking Requirements

CRLs should be checked by relying parties.

### 4.4.11 On-line Revocation/Status Checking Availability

N/A

### 4.4.12 On-line Revocation Checking Requirements

N/A

### 4.4.13 Other Forms of Revocation Advertisements Available

Upon the revocation of a subordinate CA's certificate, the KRDP Project
manager and all subordinate CAs shall be notified.

### 4.4.14 Checking Requirements for Other Forms of Revocation Advertisements

N/A

### 4.4.15 Special Requirements re Key Compromise

In any key compromise situation, a report shall be created for the KRDP
Project Manager.

## 4.5 SECURITY AUDIT PROCEDURES

### 4.5.1 Types of Events Recorded 

For audit purposes, the Root CA shall log, as a minimum, the following:

-   the creation and revocation of certificates,

-   the installation of new software or software updates,

-   the time and date and other descriptive information about all
    backups, shutdowns and restarts of the system, and

-   the time and date of all hardware upgrades, audit log dumps, and
    transaction archive dumps.

### 4.5.2 Frequency of Processing Log

Audit logs shall be periodically verified and consolidated.

### 4.5.3 Retention Period for Audit Log

The KRDP Root CA audit logs shall be retained for at least one year.

### 4.5.4 Protection of Audit Log

The audit logs shall be time-stamped, protected against modification,
and backed up by a CA administrator. All entries shall be individually
time stamped. At least two people in security administrator or
information system security officer roles shall be present for such
verification and consolidation.

### 4.5.5 Audit Log Backup Procedures

Audit trail files shall be backed up at least weekly. Two copies of the
consolidated log shall be made and stored in separate physically-secured
locations.

### 4.5.6 Audit Collection System (Internal vs. External)

N/A

### 4.5.7 Notification to Event-Causing Subject

Root CA personnel causing audit events shall receive notification, as
appropriate.

### 4.5.8 Vulnerability Assessments

N/A

## 4.6 RECORDS ARCHIVAL 

The Root CA shall archive, and make available upon authorized request,
the documentation of the Root CA's compliance with the Root CPS and the
documentation of actions and information that is material to each
certificate application, issuance, or revocation.

The repository database shall include information about the Root CA
subscribers and the certificates of those subscribers, as well as CRLs
issued by the Root CA.

### 4.6.1 Types of Events Recorded

For each certificate, the records shall include information regarding
creation, issuance, use, suspension, revocation, expiration, and renewal
activities. In addition, the records shall include information regarding
the Root CA key creation and handling, personnel activity, system policy
administration and audit record handling.

### 4.6.2 Retention Period for Archive

Archives shall be retained and protected against modification or
destruction for a period as specified in the CPS which in no case may be
less than one year.

### 4.6.3 Protection of Archive

The contents of the archives shall not be released as a whole, except as
required by law. Records of individual transactions may be released upon
request of any of the entities involved in the transaction, their
recognized representatives, authorized procurement officials, and the
courts. The Root CA shall ensure availability of the archive even if the
Root CA's operations are interrupted or suspended.

### 4.6.4 Archive Backup Procedures

Archive files shall be created and backed up at least weekly. Two copies
of the archive shall be made and stored in separate physically-secured
locations

### 4.6.5 Archive Collection System (Internal or External)

The archive collection system for the audit trail files shall be
described in the CPS.

### 4.6.6 Procedures to Obtain and Verify Archive Information

N/A

## 4.7 KEY CHANGEOVER

Keys shall be changed following the procedures for initial registration.

## 4.8 COMPROMISE AND DISASTER RECOVERY

Backup/recovery procedures for the Root CA shall be outlined in the CPS.
These procedures shall outline contingencies for password changes,
certificate revocation, key compromise, new key generation, re-issuance
of certificates, and other events.

## 4.9 CA TERMINATION

Termination of service by the Root CA and/or subordinate CAs shall occur
by authority of the KRDP Project Manager.

# 5. PHYSICAL, PROCEDURAL, AND PERSONNEL SECURITY CONTROLS

This section describes the physical, procedural, and personnel security
controls used by the Root CA to

protect its operations.

## 5.1 PHYSICAL SECURITY CONTROLS

### 5.1.1 Site Location and Construction

The site location and construction shall be documented in the Root CA
CPS.

### 5.1.2 Physical Access

Physical security controls shall be implemented to control access to the
KRDP Root CA hardware and software.

The CA\'s facility shall also store 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. Backup media shall also be
replicated at a separate location to permit restoration in the event of
a natural disaster to the primary facility. A security check to the
facility housing the CA\'s workstation shall be made at least once every
24 hours.

### 5.1.3 Media Storage

Media shall be stored in at least two physically separate locations
which are protected against unauthorized access.

### 5.1.4 Waste Disposal

Waste material shall be handled in a manner which protects the
confidentiality of the information residing on that material.

### 5.1.5 Off-site Backup

Off-site system backup for the Root CA shall be provided at a separate
location to permit restoration in the event of a natural disaster to the
primary facility. Media for the backup system shall be stored securely.

## 5.2 PROCEDURAL CONTROLS

### 5.2.1 Trusted Roles

To ensure the integrity of the Root CA System, responsibilities shall be
shared by multiple roles and individuals. Each account on the Root CA
system shall have limited capabilities, commensurate with the role of
the account holder. At least two distinct roles shall be used: Security
Officer and System Administrator. The Security Officer shall be
responsible for system security policy, the authorization of sensitive
operations and review of audit logs. The System Administrator shall be
responsible for routine Root CA operations.

### 5.2.2 Number of Persons Required Per Task

In order to minimize the risks associated with any one individual having
the ability to subvert the trustworthiness of the Root CA, Two Person
Integrity (TPI) shall be configured for the Root CA system and shall be
required during all Root CA operations.

### 5.2.3 Identification and Authentication for Each Role

Identification and authentication for each role shall be invoked. The
method shall be as specified in the Root CPS.

## 5.3 PERSONNEL CONTROLS

### 5.3.1 Background, Qualifications, Experience, and Clearance Requirements

Individuals assuming Root CA roles shall be of unquestionable loyalty,
trustworthiness and integrity, and shall have demonstrated a security
consciousness and awareness in their daily activities.

### 5.3.2 Background Check Procedures

Normal government practice shall be used for background checks for Root
CA personnel.

### 

### 5.3.3 Training Requirements

All KRDP Root CA personnel shall be provided the appropriate training
for their roles prior to enrollment on the Root CA system.

### 5.3.4 Retraining Frequency and Requirements

N/A

### 5.3.5 Job Rotation Frequency and Sequence

N/A

### 5.3.6 Sanctions for Unauthorized Actions

Sanctions for unauthorized actions shall result in any Root CA
official's removal from system access.

### 5.3.7 Contracting Personnel Requirements

N/A

### 5.3.8 Documentation Supplied to Personnel

Procedures and system manuals shall be available to all Root CA
personnel.

# 6. TECHNICAL SECURITY CONTROLS

## 6.1 KEY PAIR GENERATION AND INSTALLATION

### 6.1.1 Key Pair Generation

The Root CA signing key pair shall be created during the initial start
up of the Root CA application and shall be protected against
modification and disclosure. The Root CA key generation process shall be
designed to comply with FIPS 140-1, level 1, as a minimum. Subordinate
CAs shall generate and protect their own signature key pairs.

### 6.1.2 Private Key Delivery to Entity

Private keys shall not be exchanged between the Root CA and the
subordinate CAs.

### 6.1.3 Public Key Delivery to Certificate Issuer

The public digital signature key shall be provided to the Root CA in a
form such that the authenticity and of the public key can be verified.

### 6.1.4 CA Public Key Delivery to Users

The Root CA shall distribute its public key to each subordinate CA in a
manner in which thepublic key can be verified.

### 6.1.5 Key Sizes

The Root CA signing key pair shall have the equivalent of a 1024 bit
Digital Signature Algorithm (DSA) key.

### 6.1.6 Public Key Parameters Generation

Public key parameters shall be generated by each CA (i.e., Root CA and
subordinate CA).

### 6.1.7 Parameter Quality Checking

Subordinate CAs shall check the quality of their digital signature key
pairs.

### 6.1.8 Hardware/Software Key Generation

Digital signature keys may be generated in either hardware or software;
however, the generation process shall be FIPS 140-1 compliant.

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

Certificates issued by the KRDP Root CA shall contain the **keyUsage**
certificate extension restricting the purpose to which the certificate
can be applied. Certificates issued by the Root CA shall only be used
for certificate and CRL signing.

## 6.2 PRIVATE KEY PROTECTION

### 6.2.1 Standards for Cryptographic Module

A FIPS 140-1, level 1 module, at a minimum, shall be used to generate
the keys and sign certificates.

### 6.2.2 Private Key (n out of m) Multi-Person Control

Two Person Integrity shall be required for all Root CA activities.

### 6.2.3 Private Key Escrow

Encryption keys and certificates shall no be generated by the Root CA.

### 6.2.4 Private Key Backup

The KRDP Root CA's private keys shall be backed up, at a minimum, on a
weekly basis or whenever there are changes.

### 6.2.5 Private Key Archival

N/A

### 6.2.6 Private Key Entry Into Cryptographic Module

The KRDP Root CA's signing private key pair shall be generated and
handled by the Root CA cryptographic module in a manner which is
compliant with FIPS 140-1.

### 6.2.7 Method of Activating Private Key 

The private signing key shall be activated when Root CA personnel log on
to the system in accordance with Section 5.2.2.

### 6.2.8 Method of Deactivating Private Key

When the use of a private key for creating signatures is terminated, all
copies of the private key shall be securely destroyed.

### 6.2.9 Method of Destroying Private Key

The method for destroying the private key shall be defined in the CPS.

## 6.3 OTHER ASPECTS OF KEY PAIR MANAGEMENT

### 6.3.1 Public Key Archival

The KRDP Root CA's signing key pair and verification public key
certificate shall be backed up.

### 6.3.2 Usage Periods for the Public and Private Keys

The public and private keys shall be valid for the duration of the KRDP.

## 6.4 ACTIVATION DATA

### 6.4.1 Activation Data Generation and Installation

Passwords shall be required by all entities, at a minimum, logging on to
the KRDP Root CA system. The Root CA system shall enforce a stringent
set of rules for each password to ensure that the system is secure.
Rules on password selection shall be described in the CPS.

### 6.4.2 Activation Data Protection

The password shall be securely protected against modification and
disclosure. The plain text password shall not be retrievable.

### 6.4.3 Other Aspects of Activation Data

Root CA personnel user-names and passwords shall be securely stored.

## 6.5 COMPUTER SECURITY CONTROLS

### 6.5.1 Specific Computer Security Technical Requirements

The operating system shall enforce the identification, authentication,
and separation of roles of all users.

### 6.5.2 Computer Security Rating

N/A

## 6.6. LIFE CYCLE SECURITY CONTROLS

### 6.6.1 System Development Controls

Commercial-off-the-shelf products shall be used for the KRDP Root CA.

### 6.6.2 Security Management Controls

Section 5.2 describes security management controls, which shall be
enforced.

### 6.6.3 Life Cycle Security Ratings

N/A

## 6.7 NETWORK SECURITY CONTROLS

Remote access to the Root CA shall be protected.

## 6.8 CRYPTOGRAPHIC MODULE ENGINEERING CONTROLS

The Root CA cryptographic module shall be designed to comply with FIPS
140-1.

# 7. CERTIFICATE AND CRL PROFILES

## 7.1 CERTIFICATE FORMAT VERSIONS AND PROFILES 

The KRDP Root CA shall issue X.509 version 3 certificates.

### 7.1.1 Certificate Extensions

Certificate extensions shall include the extensions specified in the
Minimum Interoperability Specification for PKI Components (MISPC).

### 7.1.2 Algorithm Object Identifiers

Algorithm identifiers shall be specified in the Root CA CPS.

### 7.1.3 Name Forms

In a certificate, the issuer DN and subject DN fields shall contain the
full X.500 Distinguished Name of the Root CA and subordinate CA
respectively.

### 7.1.4 Name Constraints

N/A

### 7.1.5 Certificate Policy Object Identifier

N/A

### 7.1.6 Usage of Policy Constraints Extension

N/A

### 7.1.7 Policy Qualifiers Syntax and Semantics

N/A

### 7.1.8 Processing Semantics for the Critical Certificate Policy Extension

CAs issuing certificates under this policy shall mark the certificate
policy extension as critical. Certificates issued under this policy
shall include a pointer to the CPS for the issuing CA.

## 7.2 CRL PROFILE

### 7.2.1 Version number(s)

The KRDP Root CA shall issue X.509v2 CRLs.

### 7.2.2 CRL and CRL entry extensions

CRLs shall be issued in a format which is consistent with the MISPC.

# 8. SPECIFICATION ADMINISTRATION

## 8.1 SPECIFICATION CHANGE PROCEDURES

Only editorial changes or typographical corrections may be made to this
specification without notification. Items that could change throughout
the life of a certificate, such as specific contact information for
reporting revocations, should appear in the CPS whenever possible.

Any item in this certificate policy may be changed with 90 days notice.
Changes to items which will not materially impact a substantial majority
of the subordinate CAs or relying parties using this policy may be
changed with 30 days notice. The method of notification and subsequent
handling of the changes and comments shall be specified in the Root CA
CPS.

## 8.2 PUBLICATION AND NOTIFICATION POLICIES

Thirty days prior to major changes to this policy, a notification of the
upcoming changes shall be posted and conveyed to subordinate CA
organizations. The method of notification shall be specified in the Root
CA CPS.

## 8.3 POLICY APPROVAL PROCEDURES

The KRDP Project Manager shall approve this policy and any subsequent
changes.

**APPENDIX A**

**ACRONYMS**

**ACRONYMS**

CA Certification Authority

CRL Certificate Revocation List

DN Distinguished Name

DSA Digital Signature Algorithm

KRDP Key Recovery Demonstration Project

NIST National Institute of Standards and Technology

RA Registration Authority

TPI Two Person Integrity

**APPENDIX B**

**REFERENCES**

**REFERENCES**

NIST Pilot Root Certification Policy Statement for the Key Recovery
Demonstration Project - December 9, 1997

PKIX Working Group Internet Draft Certificate Policy and Certification
Policy Statement Framework - June 1997

NIST Purchase Request System Certificate Policy (Digital Signatures
Only) - September 4, 1997

NIST Special Publication 800-15, Minimum Interoperability Specification
for PKI Components - September 1997

**APPENDIX C**

**DEFINITIONS**

**DEFINITIONS**

Activation Data: Data values, other than keys, that are required to
operate cryptographic modules and that need to be protected (e.g., a
passwords).

Certification Policy Statement (policy: a statement of the practices
which a certification authority employs in issuing certificates.

End Entity: a person or a computer system 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: A CA, RA, end entity, or subordinate CA.

Registration Authority (RA): An entity that is responsible for
identification and authentication of certificate subjects, but that does
not sign or issue certificates (i.e., an RA is delegated certain tasks
on behalf of a CA).

Relying Party: A recipient of a certificate who acts in reliance on that
certificate and/or digital signatures verified using that certificate.

Subject: An entity whose public key is certified in a public key
certificate.

Subscriber: Users of the subordinate CAs.