**NIST PILOT**

**ROOT CERTIFICATION PRACTICE STATEMENT**

**For The**

**KEY RECOVERY DEMONSTRATION PROJECT**

**VERSION 1.1**

**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 CPS 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 Confidential

2.8.2 Types of Information Not Considered Confidential

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 CONTROLS

5.1.1 Site Location and Construction

5.1.2 Physical Access

5.1.3 Power and Air Conditioning

5.1.4 Water Exposures

5.1.5 Fire Prevention and Protection

5.1.6 Media Storage

5.1.7 Waste Disposal

5.1.8 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.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 PROFILES

7.1.1 Version Number (s)

7.1.2 Certificate Extensions

7.1.3 Algorithm Object Identifiers

7.1.4 Name Forms

7.1.5 Name Constraints

7.1.6 Certificate Policy Object Identifier

7.1.7 Usage of Policy Constraints Extension

7.1.8 Policy Qualifiers Syntax and Semantics

7.1.9 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 CPS APPROVAL PROCEDURES

**Certification Practice Statement**

# 1. INTRODUCTION 

## 1.1 OVERVIEW

This Certification Practice Statement (CPS) describes the practices of
the Root Certification Authority (CA) for the Key Recovery Demonstration
Project (KRDP). The Root CA, here after referred to as the Root CA, is
operated by the National Institute of Standards and Technology (NIST).
This CPS is applicable to all subordinate CAs within the KRDP pilots for
the duration of the KRDP. This CPS provides a clear statement of the
practices and responsibilities of the Root CA, as well as the
responsibilities of each subordinate CA in dealing with the Root CA.

This CPS presents the practices for managing digital signature
certificates by the Root CA. It provides the details for the
certification process and the registering of subordinate CAs. This CPS
describes the issuing, managing, using, suspending, revoking, and
renewing of certificates. The scope of this document is limited to the
Root CA's use by the federal government KRDP pilots.

By reviewing this CPS, users should be able to determine the degree of
assurance and trust that they can have in the authenticity and integrity
of the public keys contained in certificates issued by the Root CA.

This CPS contains:

-   the mechanisms that will be used to authenticate the identity of all
    individuals that need to communicate information;

-   the methods used to ensure the integrity of all information that is
    communicated;

-   the format(s) of the input certification requests;

-   the format of the certificates generated by the Root CA;

-   the algorithm(s) used for signing the hashed content summary on
    certificates that are input to the Root CA and the algorithm used by
    the Root CA to sign the certificates that it generates;

-   the validation period of certificates issued by the Root CA and the
    procedure for renewing certificates;

-   the procedure for revoking certificates generated by the Root CA;

-   backup procedures that will ensure that all data is recoverable in
    case of catastrophic failure;

-   methods of protecting sensitive information from unauthorized
    access; and

-   methods of distributing and accessing the certificates generated by
    the Root CA.

The Root CA capabilities are implemented using Entrust 3.0 which
consists of Entrust Manager, Entrust Server, and a Certificate
Repository. These components are resident on Windows NT PCs.

## 1.2 IDENTIFICATION

This CPS is called the *NIST Root Certification Practice Statement 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 CPS reflects the practices for issuing certificates (for digital
signature only) in support of the federal agencies participating in the
KRDP pilots, their CAs and operators. Efforts will be made to make this
CPS applicable to future applications requiring digital signature
certificates.

### 1.3.1 Certification Authorities

NIST operates the Root CA for the KRDP. The Root CA will certify
subordinate CAs used by the KRDP pilots.

### 1.3.2 Registration Authorities

The Registration Authority (RA) function is a manual process performed
by the Root CA Registrar.

### 1.3.3 End Entities

The end entities are the KRDP subscribers of the following subordinate
CAs:

> Entrust 2.1 - Lawrence Livermore National Laboratory, SSA (Pitney
> Bowes)
>
> Entrust 3.0 - National Technical Information Services (NTIS)
>
> Netscape - Department of Transportation/NTIS
>
> VeriSign - Department of Energy, NTIS, FBI, PTO
>
> Xcert - Department of the Treasury

### 1.3.4 Applicability

This CPS applies to the Root CA and its agents to create certificates
for public keys used for digital signature verification only.

The practices described in this CPS apply to the issuance and use of
certificates and Certificate Revocation Lists (CRLs) for subordinate CAs
within the KRDP domain.

## 1.4 CONTACT DETAILS

### 1.4.1 Specification Administration Organization

The National Institute of Standards and Technology's, Information
Technology Laboratory, Computer Security Division, Security Technology
Group is the administering organization for the Root CA.

### 1.4.2 Contact Person

Questions regarding this CPS should be directed to the:

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 CPS Suitability for the Policy

The KRDP Project Manager determines the suitability of this CPS 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.2 RA Liability

N/A

## 2.2 OBLIGATIONS

### 2.2.1 CA Obligations

The Root CA is obliged to:

-   check that the subordinate CA policy and CPS is consistent with the
    Root CA's policy and CPS;

-   issue certificates to KRDP subordinate CAs in accordance with the
    practices described in this CPS;

-   revoke certificates which are issued by the Root CA, upon receipt of
    a valid request to do so from either the KRDP Project Manager or the
    subordinate CA itself, in accordance with the stipulations of the
    relevant certificate policy as well as those in Section 4.2 of this
    CPS;

-   issue and publish CRLs on a regular schedule as per Section 4.2 of
    this CPS;

-   notify subordinate CAs that certificates have been issued to them or
    that their digital signature verification certificate has been
    revoked;

-   notify others (e.g., relying parties) of certificate
    issuance/revocation by provision of access to certificates and CRLs
    in the Root CA repository (See Section 2.6.4). Certificate and
    revocation information is listed in the repository; and

-   notify the subordinate CAs of their responsibilities.

### 2.2.2 RA Obligations

The RA Root CA functions are performed by the Registrar who is obliged
to verify the accuracy and authenticity of the information provided by
the subordinate CAs at the time of application for a certificate and
request for certificate revocation.

### 

### 2.2.3 Subscriber Obligations

Subordinate CAs are the subscribers of the Root CA. The subordinate CAs
are responsible for the following with regard to their relationship with
the Root CA:

-   accuracy of their certificate information;

-   protection of their private keys;

-   notification to the Root CA of a change to any information included
    in the subordinate CA's certificate or certificate application
    request;

-   notification to the Root CA of private key compromise in accordance
    with Section 4.4; and

-   ensuring that all applicable laws and regulations are followed. (See
    section 2.4.1).

In addition, the subordinate CAs are responsible for the following with
regard to their relationship with their subscribers:

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

-   checking the accuracy of the subscriber certificate information;

-   verifying the public signature keys of their subscribers;

-   revoking certificates which are issued by the subordinate CA in
    accordance with the subordinate CA policies and CPS;

-   issuing and publicizing CRLs on a regular schedule in accordance
    with the subordinate CA's CPS;

-   notifying users that certificates have been issued to them or that
    their digital signature verification certificate has been revoked;

-   notifying users of certificate issuance/revocation by provision of
    access to certificates and CRLs;

-   notifying the users of their responsibilities; and

-   ensuring that all applicable laws and regulations are followed. (See
    section 2.4.1).

### 2.2.4 Relying Party Obligations 

Relying parties are KRDP subscribers of the KRDP subordinate CAs. The
relying parties are responsible for checking the purpose for which a
certificate is used, verifying certificates, and checking revocation
lists.

### 2.2.5 Repository Obligations

The repository is the vehicle for distributing timely information
regarding certificates and revocation lists. The Root CA Administrator
is obliged to create a CRL and insert that CRL 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 should be in accordance with applicable statutes.

### 2.3.2 Fiduciary Relationships (Trust)

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

### 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, will apply, depending upon the jurisdiction(s) in which
certificates are issued and used. It is the responsibility of the
subordinate CAs and their users to ensure that all applicable laws and
regulations are followed.

### 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 will publish this CPS on the NIST web site. The home page
address is "csrc.ncsl.nist.gov" under programs.

The certificates and CRLs associated with the subordinate CAs are
available in the Root CA Repository on the NIST web site
"csrc.ncsl.nist.gov" under programs.

### 2.6.2 Frequency of Publication

This CPS is re-issued and published in accordance with Section 8 of this
CPS. Certificates are published in the Root CA Repository as they are
issued.

CRLs are published in the Root CA Repository as they are issued. The
frequency of CRL issuance is discussed in Section 4.4 of this CPS.

### 2.6.3 Access Controls

This CPS is publicly available on the NIST Web site at
"csrc.ncls.nist.gov" under programs. Only the NIST administrators have
permission to modify, replace or remove this CPS from its web site.

With respect to the KRDP domain information published in the repository,
the Root CA Administrators and Security Officers have sufficient access
permissions on entries to allow them to modify information published in
the repository.

### 2.6.4 Repositories

The repository contains certificates and CRLs issued by the Root CA. The
protocol used to access the repository is the Lightweight Directory
Access Protocol (LDAP) version 2, as specified in Internet RFC 1777. No
access control is imposed on information retrieval. The Repository is
available on the NIST Web site at "csrc.ncsl.nist.gov" under programs.

The LDAP requests and results are encoded using string representations
similar to the syntax **Undefined** from Section 2.1 of RFC 1778: values
of these attributes are encoded as if they were values of type **OCTET
STRING**, with the string value of the encoding being the DER-encoding
of the value itself.

## 2.7 COMPLIANCE AUDIT

Audits will not be performed for this project.

### 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 by the KRDP Project Manager or
the KRDP to be public domain information is to be kept confidential.
Some specifics are addressed in the subsections below.

### 2.8.1 Types of Information to be Kept Confidential

Types of information to be kept confidential include, but are not
limited to, the following:

-   all secret and private keys (e.g., the private signing key and the
    storage encryption key) of the Root CA;

-   information held in audit trails;

-   security measures and system vulnerabilities of the Root CA;

-   authentication information (e.g., Passwords, Pass Phrases); and

-   information covered by the Privacy Act.

### 2.8.2 Types of Information Not Considered Confidential

Types of information not considered confidential include, but are not
limited to, the following:

-   information included in certificates and CRLs issued by the Root CA;

-   information in the certificate policies supported by this Root CA;

-   this CPS itself; and

-   information in the Root CA repository.

### 2.8.3 Disclosure of Certificate Revocation/Suspension Information

When a certificate is revoked by the Root CA, a revocation reason is
included in the CRL entry for the revoked certificate. This revocation
reason code is not considered confidential. However, no other details
concerning the revocation shall be disclosed.

### 2.8.4 Release to Law Enforcement Officials

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

### 2.8.5 Release as Part of Civil Discovery 

If any private key is exposed, all keys and related certificates will be
revoked and re-issued.

### 2.8.6 Disclosure Upon Owner's Request

A subordinate CA may request any information concerning that CA.

### 2.8.7 Other Information Release Circumstances

All information collected will remain confidential; however, for
reporting purposes, some information may be used for statistical
analysis, for example.

## 2.9 INTELLECTUAL PROPERTY RIGHTS (Property Rights)

Property interests of the following materials and data are regarded as
the property of the parties listed below:

-   This CPS is the property of NIST.

-   The Relative Distinguished Name (RDN) of the KRDP Root CA is the
    property of NIST.

-   Certificates are the property of the issuer for whom the certificate
    is issued.

-   The Distinguished Names (DNs) used to represent the subordinate CAs
    within the KRDP Root CA domain and in certificates issued to those
    CAs by the Root CA are the property of each subordinate CA.

-   Secret keys and public/private key pairs used by the Root CA are the
    property of NIST.

-   Private and public keys are the property of the subject for whom the
    certificate is created.

# 3. IDENTIFICATION AND AUTHENTICATION

To identify and authenticate a certificate applicant, written procedures
address initial registration, routine rekey, rekey after revocation, and
revocation requests.

## 3.1 INITIAL REGISTRATION

Subordinate CAs will need to fill out a registration form. The form is
available on the NIST web site at "csrc.ncsl.nist.gov" under programs.
Subordinate CAs must provide their policy and CPS documentation in order
for the Root CA Registrar to verify consistency with the Root CA's
policy and CPS.

### 3.1.1 Types of Names

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

Subordinate CAs may optionally have additional name forms such as an
e-mail address; however the 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 is 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

Should more than one subordinate CA claim the same DN, the Registrar
will attempt to resolve the name claim dispute. In the case that the
name claim dispute cannot be resolved, the Root CA will report the
duplication to the KRDP Project Manager.

### 3.1.6 Recognition, Authentication and Role of Trademarks

Names in any certificate issued under this CPS 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

For signature public keys, the certificate request shall be signed by
the corresponding private key. Verification of the signature using the
public key in the request shall serve as proof of possession of the
private key.

NOTE: Encryption key pairs are centrally generated by the Root CA
system. The encryption private is protected by the Secure Exchange
Protocol (SEP) during transmission to the user.

### 3.1.8 Authentication of Organization Identity

For authentication purposes, the KRDP Project Manager provides the Root
CA Registrar with each subordinate CA contact's name, and a "pass
phrase" provided by the subordinate CA contact for subsequent
verification.

### 3.1.9 Authentication of Individual Identity

Each subordinate CA contact must provide their name, and "pass phrase",
which will be verified by the Root CA Registrar. In addition, if the
contact is appearing in person, he/she must show an appropriate ID.

## 3.2 ROUTINE REKEY

No automatic key update process will be used. 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.

(See 3.2 above).

## 3.4 REVOCATION REQUEST

Requests to revoke a subordinate CA's certificate require one of the
following identification and authentication mechanisms prior to any
possible on-line request:

-   digitally signed e-mail sent from the subordinate CA to the Root
    Certificate Registrar;

-   telephone the Root Certificate Registrar and provide the appropriate
    identification information as specified in Section 3.1.8; or

-   revocation requests by the KRDP Project Manager as specified in
    Section 4.4.2.

# 4. OPERATIONAL REQUIREMENTS

Operational requirements are those requirements imposed upon the Root CA
with respect to various operational activities.

## 4.1 CERTIFICATE APPLICATION

The subordinate CA contact is required to complete a registration form
when applying for a certificate. (See the NIST web site at
"csrd.ncsl.nist.gov" under programs).

Prior to certificate issuance, a directory entry is created for the
subordinate CA using the subordinate CAs DN. Certification proceeds as
follows:

-   If the subordinate CA uses an Entrust system, the Root CA Security
    Officers will begin the "cross-certification" process. *\[NOTE: If
    Entrust 2.1 is used, the following might not be true\]* A password
    is created which will be provided to the subordinate CA Security
    Officer(s) via certified mail or in person (after the appropriate
    authentication procedure as defined in Section 3.1.8) along with the
    Root CA DN, TCP/IP address and port number. The subordinate CAs
    Security Officer(s) complete the "cross-certification" process at
    their site.

```{=html}
<!-- -->
```
-   If the subordinate CA uses a non-Entrust system, the subordinate CA
    contact must provide a self-signed X.509 v3 certificate containing
    the subordinate CAs verification public key to the Root CA
    Registrar via diskette.

## 4.2 CERTIFICATE ISSUANCE

Entrust CAs: Certificates are automatically issued to the subordinate
CAs during the "cross- certification" process identified in Section 4.1.

Non-Entrust CAs: Upon receipt of the self-signed certificate, the Root
CA System Administrators issue a signature verification public key
certificate for that subordinate CA. The newly signed certificate is
returned to the subordinate CA contact on a diskette along with the Root
CAs self-signed signature verification certificate.

In both cases, the subordinate CA's certificate is placed in the Root CA
repository on the NIST Web site at "csrc.ncsl.nist.gov" under programs.

## 4.3 CERTIFICATE ACCEPTANCE

Successful completion of the certification, as defined in Section 4.2
above, constitutes 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 must be
revoked when the certificate is no longer trusted for any reason or if
the relationship is no longer required. Some of the specific reasons for
revocation of certificates include, but are not limited to:

-   compromise or suspected compromise of private keys;

-   failure of the subordinate CA to meet their obligations (NOTE:
    responsibilities) as stated in Section 2.2.3;

-   changes to the relationship between the KRDP Root CA and the
    subordinate CAs;

-   a key becoming untrustworthy for any reason; or

-   when information (e.g., DN) in the certificate changes or the
    subordinate CA requests revocation for any reason.

### 4.4.2 Who Can Request Revocation

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

### 4.4.3 Procedure for Revocation Request

The subordinate CA contact, after proper authentication (see Section
3.1.8), may request the revocation of the subordinate CAs certificate
by presenting a letter to the Root CA Registrar. The request shall
contain, at a minimum, the subordinate CA name, serial number,
revocation reason, date and time. This action can be performed by
personal delivery, postal delivery, or e-mail. If accomplished by
personal or postal delivery, the letter shall be hand signed by the
subordinate CA contact. If accomplished by e-mail, the letter shall be
digitally signed using the subordinate CA contacts private signature
key.

### 4.4.4 Revocation Request Grace Period

When a key compromise is detected or when risk warrants revocation, the
revocation request must be placed immediately. Requests for other
revocation reasons must be placed within 24 hours of the decision to
revoke a certificate.

### 4.4.5 Circumstances for Suspension

The KRDP Root CA does 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 will be issued every 48 hours (routine) and immediately when a
subordinate CA key is revoked or compromised.

### 4.4.10 CRL Checking Requirements

Each certificate issued by the KRDP Root CA includes the full DN of the
CRL Distribution Point to be checked during the verification of the
certificate. Relying parties, when working in an online mode, should
check the current CRL identified by the DN in the certificate\'s
**cRLDistributionPoints** extension field, along with any other CRLs
required in the certificate chain processing prior to trusting the
certificate.

### 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 Root CA
Registrar will alert all other subordinate CA contacts and the KRDP
Program Manager by e-mail.

### 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 must be filed with the Root CA
Registrar indicating the circumstances under which the compromise
occurred. The Root CA Registrar will report the compromise to the KRDP
Project Manager who will initiate an investigation for potential action.

If the compromise is determined to be accidental on the part of the
subordinate CA, no further action is required.

After revocation, the subordinate CA may request issuance of a new
certificate as specified in Section 4.1.

## 4.5 SECURITY AUDIT PROCEDURES

### 4.5.1 Types of Events Recorded 

All significant security events are automatically time stamped and
recorded in audit trail files. These include such events as:

-   successful and failed attempts to initialize subordinate CAs, and
    remove, enable, disable, and update their keys and certificates;

-   successful and failed attempts to create, remove, log in, set, reset
    and change passwords; revoke privileges of Root CA personnel, and
    create and update keys;

-   failed interactions with the directory, including successful and
    failed connection attempts, and read and write operations by the
    Root CA;

-   posting of certificates and CRLs to the repository; and

-   all events related to certificate creation and revocation, security
    policy modification and validation, Root CA software startup and
    stop, database backup, cross-certification, certificate validation,
    user upgrade, DN change, database and audit trail management,
    certificate life-cycle management and other miscellaneous events.

### 4.5.2 Frequency of Processing Log

The logs are audited, verified, and consolidated weekly by the Security
Officers.

### 4.5.3 Retention Period for Audit Log

The KRDP Root CA audit logs are retained for one year.

### 4.5.4 Protection of Audit Log

The audit trail is stored in regular operating system flat files. Each
audit trail file consists of an audit header which contains information
about the audits in the file and list of events. A Message
Authentication Code (MAC) is created for each of the audit events and
the audit header. Each audit trail file has a different audit key used
to generate the MAC. The master key for the KRDP Root CA is used to
protect the audit key which is stored in the audit header.

### 4.5.5 Audit Log Backup Procedures

Audit trail files are backed up by the System Administrators on a weekly
basis. All files including the latest audit trail file are stored in a
locked cabinet.

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

The audit collection system is internal to the Root CA system.

### 4.5.7 Notification to Event-Causing Subject

Security Officers and System Administrators causing audit events receive
notification, as appropriate, via the administrator interface.

### 4.5.8 Vulnerability Assessments

A vulnerability assessment will not be performed for the KRDP Root CA.

## 4.6 RECORDS ARCHIVAL 

The Root CA database, repository database and audit trails for both are
archived. The Root CA database includes:

-   information about Root CA subscribers (subordinate CAs),

-   validity periods for all subscriber certificates,

-   the audit trail,

-   the CA signing key pair, and

-   Security Officer and System Administrator information.

The repository database includes 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

The types of events recorded in the Root CA database include:

-   creation of the Root CA signing key pair;

-   addition and removal of subordinate CAs from the system;

-   changes to the verification public key history for all subordinate
    CAs, including certificate issuance and revocation events;

-   changes to the DN of subordinate CAs;

-   addition/changes/removal of System Administrator and Security
    Officer privileges;

-   changes to some aspects of policy such as certificate validity
    period; and

-   creation and revocation of subordinate CA certificates.

See Section 4.5.1 for recorded audit events for the Root CA. Audit
events for the repository include records of the addition and deletion
of subscribers, certificates and CRLs to the database.

### 4.6.2 Retention Period for Archive

The archive of the Root CA database is retained for at least 1 year. The
archives of audit trail files are retained for at least one year.

### 4.6.3 Protection of Archive

The Root CA database is encrypted and protected by master keys.
Protection of the audit trail is described in Section 4.5.4 of this CPS.

The archive media is protected by physical security by means of a
restricted access facility to which only NIST KRDP Root CA personnel
have access. Archive records may be moved to another facility if deemed
necessary by the system administrators.

### 4.6.4 Archive Backup Procedures

Archive files are created and backed up weekly. Originals are stored
on-site and housed with the Root CA System. Backup files are stored at a
secure and separate geographic location.

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

The archive collection system (backup facility) for the Root CA database
is internal to the system.

The archive collection system (backup facility) for the audit trail
files is described in Section 4.5.5 of this CPS.

The archiving of the Root CA database and audit trail files onto
separate media and the secure storage of that media is external to the
system.

### 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.
(See Section 3.1)

## 4.8 COMPROMISE AND DISASTER RECOVERY

In the event of a disaster or serious compromise, the following steps,
as a minimum, are taken to recover the Root CA system:

-   All passwords will be changed for all KRDP Root CA personnel.

-   Depending on the nature of the disaster, some or all certificates
    may be revoked.

-   The repository data and CRLs are restored if the repository becomes
    unusable and must be restored from backup, or if the repository is
    suspected of being corrupted.

-   Should a Security Officer\'s profile need recovery, the profile can
    be recovered by two other Security Officers. If there are not enough
    Security Officers with valid Security Officer privileges available
    to recover a Security Officer profile, the Master Users recover this
    through the Root CA Control system.

-   In the case of Root CA key compromise, the Root CA will revoke all
    certificates, door locks will be re-programmed, new key pairs
    generated, and all Root CA and subordinate CA certificates reissued.

-   In the case of a natural disaster whereby the Root CA is physically
    damaged and becomes inoperative, the Root CA will be reloaded from
    backups using an alternate system, if necessary.

## 4.9 CA TERMINATION

The KRDP Project Manager has the authority to terminate the Root CA
and/or subordinate CAs. This will be done via an official letter to the
Root CA Registrar.

In the event that the KRDP Root CA ceases operation, all subordinate CAs
will be informed via certified mail with return receipt, and subordinate
CA certificates will be revoked.

An archive of the Root CA database is retained by NIST for a minimum of
1 year.

# 5. PHYSICAL, PROCEDURAL, AND PERSONNEL SECURITY CONTROLS

Physical, procedural, and personnel security controls are non-technical
controls used by the issuing CA to

perform the secure functions of key generation, authentication,
certificate issuance, certificate revocation and audit.

## 

## 

## 5.1 PHYSICAL CONTROLS

### 5.1.1 Site Location and Construction

The KRDP Root CA system is located at NIST North, building 820, room
652.

### 5.1.2 Physical Access

The KRDP Root CA facility has a combination lock on the door. An access
control list is posted at the door to the room containing the Root CA
system. Anyone not on the access control list must be escorted by a
person on the list. There is a guard at the main entrance to the
building during normal working hours. During non-working hours the
electronic doors are locked. Admittance to the building must be obtained
from the NIST security office on the main campus. A security guard will
check the facility once every 24 hours.

### 5.1.3 Power and Air Conditioning

The NIST North building provides power and air conditioning.

### 5.1.4 Water Exposures

The KRDP Root CA facility has an overhead sprinkler system.

### 5.1.5 Fire Prevention and Protection

Fire alarms are present throughout the NIST campus and NIST North. NIST
provides fire fighting services for the main campus, and the city of
Gaithersburg provides fire fighting services for NIST North.

### 5.1.6 Media Storage

The primary media is stored in locked cabinets and housed in the Root CA
facility (building 820, room 652).

### 5.1.7 Waste Disposal

A wipe utility is used to clean the system, and a shredder is used to
shred paper material.

### 5.1.8 Off-site Backup

Off-site system backup for the Root CA is provided in building 101, room
C27, NIST main campus. Media for the backup system is stored in locked
cabinets.

## 5.2 PROCEDURAL CONTROLS

### 5.2.1 Trusted Roles

The Root CA Master Users maintain the Root CA System. The Master User
passwords are documented and stored in a dual combination safe.

The Master Users have the authority to:

-   maintain Root CA services (consisting of the System Administration
    Service, Key Management Service, and Directory Service) plus the
    Root CA database;

-   recover Security Officer profiles in the event that Security
    Officers have forgotten their passwords;

-   recover the System Administration service in the event that
    administration profiles become damaged; and

-   backup, re-encrypt and restore the Root CA database from backup, as
    necessary.

The Security Officers have the authority to:

-   set and alter the security policy for the Root CA;

-   authorize sensitive operations, such as adding and deleting Security
    Officers, System Administrators, and subordinate CAs;

-   manage, issue, update and revoke subordinate CA certificates; and

-   process audit logs.

System Administrators have the privilege and authority to:

-   issue, update and revoke subordinate CA certificates;

-   process audit logs;

-   use all System Administrator privileges;

-   add and delete subordinate CAs (but not Security Officers or other
    System Administrators); and

-   change subordinate CA Distinguished Names (DNs).

### 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) has been configured for the Root CA system and is
required during all Root CA operations.

### 5.2.3 Identification and Authentication for Each Role

Passwords are used for identification and authentication for each role.

## 5.3 PERSONNEL CONTROLS

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

All KRDP Root CA personnel are cleared to at least the secret level. All
other personnel will be escorted. No single individual will be assigned
the same role simultaneously.

### 5.3.2 Background Check Procedures

Normal government practice is used for background checks for secret
level clearances.

### 5.3.3 Training Requirements

All KRDP Root CA personnel have been 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

Any Root CA official will be removed from system access.

### 5.3.7 Contracting Personnel Requirements

N/A

### 5.3.8 Documentation Supplied to Personnel

Procedures and system manuals are 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 is created during the initial start up of
the Root CA application and is protected by the Root CA master key.

The software key generation process is designed to comply with FIPS
140-1, level 1.

### 6.1.2 Private Key Delivery to Entity

No private keys will be exchanged between the Root CA and the
subordinate CAs.

### 6.1.3 Public Key Delivery to Certificate Issuer

For non-Entrust subordinate CAs, each subordinate CA contact shall
provide their public digital signature key to the KRDP Root CA in a
self-signed certificate on a diskette.

For Entrust subordinate CAs, the procedure specified in Section 4.1 will
result in the subordinate CA's public verification key being supplied to
the Root CA.

### 6.1.4 CA Public Key Delivery to Users

The Root CA distributes its public key, in a self-signed certificate, by
placing the certificate in the repository and mailing or physically
transferring a diskette to each subordinate CA via certified mail or in
person.

### 6.1.5 Key Sizes

The Root CA signing key pair is1024 bit RSA.

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

The responsibility lies with each subordinate CA to check the quality of
their digital signature key pairs.

### 6.1.8 Hardware/Software Key Generation

The Root CA digital signature keys are generated in software.

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

Certificates issued by the KRDP Root CA contain the **keyUsage**
certificate extension restricting the purpose to which the certificate
can be applied.

The digital signature key pair is used to provide authentication,
integrity and support for non-repudiation services.

The KRDP Root CA signing key is used to sign certificates and CRLs
issued by the Root CA.

## 6.2 PRIVATE KEY PROTECTION

### 6.2.1 Standards for Cryptographic Module

A FIPS 140-1, level 1 module is used to generate the keys in the Root
CA.

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

Two Person Integrity is required for all Root CA activities.

### 6.2.3 Private Key Escrow

N/A

### 6.2.4 Private Key Backup

The KRDP Root CA's private keys are backed up in the Root CA database.
The database, which stores the Root CA's public and private keys, is
encrypted and their integrity is protected by SHA-1. The Root CA
database is 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 pairs are generated in software
within the cryptographic module. The private keys are stored encrypted
in the cryptographic module and are decrypted only at the time at which
they are actually being used.

### 6.2.7 Method of Activating Private Key 

The private signing key is activated at the time log in occurs.

### 6.2.8 Method of Deactivating Private Key

The Master User's private signing key becomes inactive when the Master
Users log off the system or it there is a ten minute period of
non-activity.

### 6.2.9 Method of Destroying Private Key

All sensitive keys in memory are overwritten with zeros when no longer
used. The permanent destruction of private keys is achieved with secure
delete operations.

## 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
certificates are backed up in the Root CA database.

The complete verification public key history for all subordinate CAs,
including a history of status changes such as revocation date and
reason, are also archived in this database.

The Root CA database is archived according to the procedures described
in Section 4.6 of this CPS.

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

For the purpose of this KRDP, the public and private keys will have a
four-month usage period.

## 6.4 ACTIVATION DATA

### 6.4.1 Activation Data Generation and Installation

Passwords are required by all entities logging on to the KRDP Root CA.
The Root CA system enforces a stringent set of rules for each password
to ensure that the system is secure. Some of the rules on password
selection are listed below:

-   It must have at least eight characters.

-   It must have at least one upper-case letter or digit.

-   It must have at least one lower-case letter.

-   It must not contain many occurrences of the same character.

-   It must not be the same as the entity\'s profile name.

-   It must not contain a long substring of the entity\'s profile name.

### 6.4.2 Activation Data Protection

The password is protected by a one way hash function. The plain text
password is not stored.

### 6.4.3 Other Aspects of Activation Data

System Administrator and Security Officer user-names and password check
values are stored in the Root CA database.

## 6.5 COMPUTER SECURITY CONTROLS

### 6.5.1 Specific Computer Security Technical Requirements

The operating system enforces the identification and authentication of
all users.

### 6.5.2 Computer Security Rating

N/A

## 6.6. LIFE CYCLE SECURITY CONTROLS

### 6.6.1 System Development Controls

There are no system development controls since commercial-off-the-shelf
products are used.

### 6.6.2 Security Management Controls

Audit logs are generated weekly.

### 6.6.3 Life Cycle Security Ratings

N/A

## 6.7 NETWORK SECURITY CONTROLS

For Entrust subordinate CAs, remote access to the Root CA via the System
Administration interface is secured using the security features of the
SEP protocol. No other remote access is permitted, and features
including inbound ftp are disabled.

## 6.8 CRYPTOGRAPHIC MODULE ENGINEERING CONTROLS

The Entrust software cryptographic module is designed to comply with
FIPS 140-1, level 1.

# 7. CERTIFICATE AND CRL PROFILES

## 7.1 CERTIFICATE PROFILES

The following fields of the X.509 version 3 certificate format are used
by the KRDP Root CA:

-   version: version field is set to v3

-   serial number: when a new certificate is created, a unique serial
    number within the Root CA

-   security domain is generated by the Root CA

-   signature: identifier for the algorithm used by the Root CA to sign
    the certificate

-   issuer: Root CA Distinguished Name

-   validity: certificate validity period - **notAfter** date is
    specified

-   subject: Distinguished Name of the CA that owns the public key
    (e.g., Root CA, subordinate CA)

-   subject public key information: algorithm identifier (RSA or DSA
    with SHA-1), and public key

-   extensions: see Section 7.1.2 below

The following fields of the X.509 version 3 certificate format are not
used in this PKI:

-   issuer unique identifier

-   subject unique identifier

### 7.1.1 Version Number (s)

The Root CA issues X.509v3 certificates.

### 7.1.2 Certificate Extensions

A number of X.509 version 3 certificate extensions are included in
certificates issued by this Root CA, as well as one private extension
defined by Entrust Technologies. The X.509 version 3 certificate
extensions, which are never present in certificates issued by this CA,
are indicated below.

The following certificate extensions are used in this PKI:

+-----------------+----------+----------+-----------------------------+
| **X.509 v3      | **Crit   | **Op     | **Notes**                   |
| Certificate     | ical/Non | tional** |                             |
| Extension**     | Cr       |          |                             |
|                 | itical** |          |                             |
+-----------------+----------+----------+-----------------------------+
| **s             | Non      | Optional |  **GeneralName** - only    |
| ubjectAltName** | critical |          | choices \[0=other name\],   |
|                 |          |          | \[3=x400 address\] and      |
|                 |          |          | \[5=EDI party name\] are    |
|                 |          |          | implemented.                |
|                 |          |          |                             |
|                 |          |          |  A user\'s **rfc822Name**  |
|                 |          |          | or **iPAddress** with an    |
|                 |          |          | optional e-mail address     |
+-----------------+----------+----------+-----------------------------+
| **privateK      | Non      | Not      |  **notAfter** is always    |
| eyUsagePeriod** | critical | optional | used                        |
|                 |          |          |                             |
|                 |          |          |  **notBefore** is never    |
|                 |          |          | used                        |
+-----------------+----------+----------+-----------------------------+
| **authority     | Non      | Not      |  only element **\[0\]**    |
| KeyIdentifier** | critical | optional | (                           |
|                 |          |          | **authorityKeyIdentifier**) |
|                 |          |          | is filled in                |
|                 |          |          |                             |
|                 |          |          |  contains a 20 byte hash   |
|                 |          |          | of the                      |
|                 |          |          | **subjectPublicKeyInfo** in |
|                 |          |          | the CA certificate          |
+-----------------+----------+----------+-----------------------------+
| **subject       | Non      | Not      |  contains a 20 byte hash   |
| KeyIdentifier** | critical | optional | of the                      |
|                 |          |          | **subjectPublicKeyInfo** in |
|                 |          |          | the certificate             |
+-----------------+----------+----------+-----------------------------+
| **bas           | Non      | Not      |  only the **cA**           |
| icConstraints** | critical | optional | **Boolean** is used         |
+-----------------+----------+----------+-----------------------------+
| **cRLDistr      | ***t     | Not      | *** set to               |
| ibutionPoints** | .b.s.*** | optional | non-critical***             |
|                 |          |          |                             |
|                 |          |          |  only 1 distribution point |
|                 |          |          | name is included in each    |
|                 |          |          | certificate                 |
|                 |          |          |                             |
|                 |          |          | ****** only element        |
|                 |          |          | **\[0\]**                   |
|                 |          |          | (**distributionPoint**) is  |
|                 |          |          | used and includes the full  |
|                 |          |          | DN                          |
+-----------------+----------+----------+-----------------------------+
| **keyUsage**    | Non      | Not      | only                        |
|                 | critical | optional |                             |
|                 |          |          | -   digitalSignature,       |
|                 |          |          |                             |
|                 |          |          | -   nonRepudiation,         |
|                 |          |          |                             |
|                 |          |          | -   keyCertSign, and/or     |
|                 |          |          |                             |
|                 |          |          | -   cRLSign.                |
+-----------------+----------+----------+-----------------------------+
| -               | Non      | Not      |  only **policyIdentifier** |
|                 | critical | optional | element is supported with   |
| **Certif        |          |          | up to 10 **OIDs**           |
| icatePolicies** |          |          |                             |
|                 |          |          |  **policyQualifiers** not  |
|                 |          |          | supported                   |
+-----------------+----------+----------+-----------------------------+

In addition, the following private extensions are present in all
certificates:

**entrustVersInfo EXTENSION ::= {**

> **SYNTAX EntrustVersInfoSyntax,**
>
> **IDENTIFIED BY {id-entrust 0}}**

**EntrustVersInfoSyntax ::= SEQUENCE {**

> **entrustVers GeneralString,**
>
> **entrustInfoFlags EntrustInfoFlags }**

**EntrustInfoFlags::= BIT STRING {**

**keyUpdateAllowed**

**newExtensions (1), \--** not used

**pKIXCertificate (2) } \--** certificate created by pkix

These extensions are non critical and not optional. The **entrustVers**
is set to 3.0.

The value of **id-nsn-ext-entrustVersInfo**, the OID for
**entrustVersInfo** is **1 2 840 113533 7 65 0**.

The following X.509 version 3 certificate extensions are not used in
this Root CA:

-   policy mappings

-   name constraints

-   policy constraints

-   issuer alternative name

-   subject directory attributes

### 7.1.3 Algorithm Object Identifiers

  ----------------------- ----------------------- -----------------------
  **Algorithm**           **Object Identifier**   **Issuing Authority**

  dsa-with-sha1           1 3 14 3 2 27           OIW Security SIG

  sha1WithRSAEncryption   1 2 840 113549 1 1 5    RSADSI

  DES-EDE3-CBC            1 2 840 113549 3 7      RSADSI

  cast3CBC                1 2 840 113533 7 66 3   Entrust Technologies

  cast3MAC                1 2 840 113533 7 66 4   Entrust Technologies

  cast5CBC                1 2 840 113533 7 66 10  Entrust Technologies

  cast5MAC                1 2 840 113533 7 66 11  Entrust Technologies

  3DESMAC                 1 2 840 113533 7 66 14  Entrust Technologies
  ----------------------- ----------------------- -----------------------

### 7.1.4 Name Forms

In a certificate, the issuer DN and subject DN fields contain the full
X.500 Distinguished Name of the Root CA and subject CA respectively. If
the **subjectAltName** extension is present in a certificate, the
subject CAs **rfc822Name** or **iPAddress** with an optional e-mail
address is used.

### 7.1.5 Name Constraints

Name constraints are not used by the KRDP Root CA.

### 7.1.6 Certificate Policy Object Identifier

N/A

### 7.1.7 Usage of Policy Constraints Extension

Policy constraints are not used by the KRDP Root CA.

### 7.1.8 Policy Qualifiers Syntax and Semantics

Policy qualifiers are not used in the KRDP Root CA.

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

The only certificate extension which may be identified as critical in
certificates issued by this Root CA is the **cRLDistributionPoints**
extension.

## 7.2 CRL PROFILE

The following fields of the X.509 version 2 CRL format are used in this
Root CA:

-   version: set to v2

-   signature: identifier of the algorithm used to sign the CRL

-   issuer: the full Distinguished Name of the Root CA issuing the CRL

-   this update: time of CRL issuance

-   next update: time of next expected CRL update

-   revoked certificates: list of revoked certificate information

### 7.2.1 Version number(s)

CRLs issued by the Root CA are X.509v2 CRLs.

### 7.2.2 CRL and CRL entry extensions

The following CRL and CRL entry extensions are used in this Root CA:

+-----------------+----------+----------+-----------------------------+
| **X.509 v2 CRL  | **Crit   | **Op     | **Notes**                   |
| Extension**     | ical/Non | tional** |                             |
|                 | Cr       |          |                             |
|                 | itical** |          |                             |
+-----------------+----------+----------+-----------------------------+
| **authority     | Non      | Not      |  only element **\[0\]**    |
| KeyIdentifier** | critical | optional | (                           |
|                 |          |          | **authorityKeyIdentifier**) |
|                 |          |          | is filled in                |
|                 |          |          |                             |
|                 |          |          |  contains a 20 byte hash   |
|                 |          |          | of the                      |
|                 |          |          | **subjectPublicKeyInfo** in |
|                 |          |          | the CA certificate          |
+-----------------+----------+----------+-----------------------------+
| **cRLNumber**   | Non      | Not      |  Incremented each time a   |
|                 | critical | optional | particular CRL/ARL is       |
|                 |          |          | changed                     |
+-----------------+----------+----------+-----------------------------+
| **reasonCode**  | Non      | Not      |  CRL entry extension -     |
|                 | critical | optional | only reason codes           |
|                 |          |          | **(0=unused), (1=key        |
|                 |          |          | compromise), (3=affiliation |
|                 |          |          | changed), (4=superseded)**  |
|                 |          |          | and **(5=cessation of       |
|                 |          |          | operations)** supported     |
+-----------------+----------+----------+-----------------------------+
| **issuingDist   | Critical | Not      |  element **\[0\]**         |
| ributionPoint** |          | optional | (**distributionPoint**)     |
|                 |          |          | includes the full DN of the |
|                 |          |          | distribution point          |
|                 |          |          |                             |
|                 |          |          |  element **\[1\]**         |
|                 |          |          | (**onlyContainsUserCerts**) |
|                 |          |          | is included for CRLs        |
|                 |          |          |                             |
|                 |          |          |  element **\[2\]**         |
|                 |          |          | (**onlyContainsCACerts**)   |
|                 |          |          | is inlcuded for ARLs        |
|                 |          |          |                             |
|                 |          |          |  element **\[1\]** and     |
|                 |          |          | **\[2\]** are never present |
|                 |          |          | together in the same        |
|                 |          |          | revocation list             |
|                 |          |          |                             |
|                 |          |          |  elements **\[3\]** and    |
|                 |          |          | **\[4\]** are not used      |
+-----------------+----------+----------+-----------------------------+

The following X.509 version 2 CRL extensions are not used in this Root
CA:

-   issuer alternative name

-   hold instruction code

-   invalidity date

-   certificate issuer

-   delta CRL indicator

# 8. SPECIFICATION ADMINISTRATION

## 8.1 SPECIFICATION CHANGE PROCEDURES

Changes to items within this CPS, which will have no/minimal impact on
the subordinate CA domains using certificates and CRLs issued by this
Root CA, may be made with no change to the CPS version number and no
notification to the subordinate CAs.

Changes to the certificates supported by this CPS as well as changes to
items within this CPS which may have significant impact on the
subordinate CA domains using certificates and CRLs issued by this Root
CA, may be made with 30 days notice to the user community, and the
version number of this CPS must be increased accordingly.

## 8.2 PUBLICATION AND NOTIFICATION POLICIES

Thirty days prior to major changes to this CPS, a notification of the
upcoming changes will be posted on the NIST web site at
"csrc.ncsl.nist.gov" under programs, and conveyed to subordinate CA
organizations via e-mail by the Root CA Registrar.

## 8.3 CPS APPROVAL PROCEDURES

The KRDP Project Manager approves this CPS and any subsequent changes.

**APPENDIX A**

**ACRONYMS**

**ACRONYMS**

CA Certification Authority

CPS Certification Practice Statement

CRL Certificate Revocation List

DN Distinguished Name

DSA Digital Signature Algorithm

KRDP Key Recovery Demonstration Project

MAC Message Authentication Code

NIST National Institute of Standards and Technology

RA Registration Authority

TPI Two Person Integrity

**APPENDIX B**

**REFERENCES**

**REFERENCES**

Draft - Boilerplate Certification Practice Statement for an Entrust 3.0
Based PKI - July 1997

Entrust Infrastructure User Guide - 1977

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

NIST Purchase Request System Certificate Policy (Digital Signatures
Only) - September 4, 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 Practice Statement (CPS: 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.