Public Key Infrastructure (PKI)\
Technical Specifications: Part A - Technical Concept of Operations

*Editor's Note: This is a draft of the CONOPS that incorporates
extensive changes. Sections 1 through 7 have been extensively revised. I
have run that much through the Word Grammar checker, and incorporated
comments received from others. Section 3.5 on attribute certificates has
been greatly expanded, and figure 4 added. However section 9.0 on
attribute authorities has not yet been revised. In section 4.2 I have
changed "Browser model" to "Trust List Model".*

*In section 6 "consistent certificate" has become "single algorithm
certificate" and "hybrid certificate" has become "mixed algorithm
certificate." I have attempted to state general rules for mixed
algorithm certificates but stopped short of specifying a specific
multiple algorithm architecture.*

*Section 7 has been extensively revised and incorporates new material on
polices, as well as some text from rich Guida's Notional Bridge CA
document. Section 7 accepts the 4 assurance levels proposed by the GOK.*

*Section 14 has been extensively revised, particularly the subsection
14.1 on repositories.*

*Please address comments to: william.burr@nist.gov*

Table of Contents

1\. Introduction

1.1 Purpose of the FPKI

1.2 Basic Concepts

2\. PKI Services

3\. PKI Data Structures

3.1 Nomenclature and Typographical Conventions

3.2 Certificates

3.3 Cross Certificates

3.4 Certificate Revocation Lists

3.4.1 CRL Data Structure

3.4.2 CRL Distribution Points and Indirect CRLs

3.5 Attribute Certificates and Subject Directory Attributes

3.5.1 Current Status

3.5.2 The Evolution of Attribute Certificates

4\. PKI Certification Path Architecture

4.1 Signatures and Certification Paths

4.2 Certification Path Architectures

4.2.1 Hierarchical Architecture

4.2.2 Mesh Certification Path Architecture

4.2.3 Trust-list Architecture

5\. Federal PKI Architecture

5.1 Architecture Components

5.2 Operational concept

5.2.1 Certificate Status

6\. Cryptographic Algorithms and Interoperability

6.1 Definitions

6.2 Parameter Inheritance

6.3 Algorithm Interoperability rules

7\. FPKI Management and Policies

7.1 Certificate Policies and Certification Practice Statements

7.1.1 Certificate Policies

7.1.2 Certification Practice Statement

7.1.3 Standardized Outline

7.1.4 Assurance Levels

7.1.5 Certificate Policy Field Contents

7.2 Policy Management Authorities

7.2.1 The Federal Policy Management Authority (FPMA)

7.2.2 Domain Policy Management Authorities

8\. Transition to an Integrated Federal FPKI

9\. Attribute Authorities

10\. Compromise Recovery

10.1 Compromise of User Keys

10.2 CA Key Compromise

10.2.1 Root CA Key Compromise

10.2.2 Subordinate CA Key Compromise

10.2.3 Peer CA Key Compromise

10.2.4 Bridge CA Key Compromise

10.3 RA Key Compromise

11\. Implementation Technologies

11.1 Clients

11.1.1 Software Implementation

11.1.2 Hardware Implementation

11.2 Authorities

12\. Interoperation

12.1 Interoperation with the Type 1 Infrastructure

12.2 Interoperation with non-Federal Users

12.2.1 Algorithms

12.2.2 Cross-Certification

12.2.3 Certificates Issued to non-Federal Users

13\. Records and Archives

13.1 Near term

13.2 Intermediate term

13.3 Archived Signatures

13.4 Responsibilites

14\. Servers and Agents

14.1 Repositories

14.2 Digital Notary Servers

14.3 Digital Recorder Servers and Archives

14.4 Digital Certified Delivery Servers

14.5 Ticket Granting Agents

14.6 Key Recovery Agents

Public Key Infrastructure (PKI) Technical Specifications: Part A -
Technical Concept of Operations

# Introduction

## Purpose of the FPKI

The Federal Public Key Infrastructure (PKI) will support secure Federal
Government use of information resources and the National Information
Infrastructure (NII). The Federal PKI will establish the facilities,
specifications, and policies needed by Federal departments and agencies
to use public key based certificates for:

-   information system security;

-   electronic commerce, and;

-   secure communications, including e-mail.

The Federal PKI will support secure communications and commerce between
Federal agencies as well as with entities of other branches of the
Federal Government, state, and local governments, business and the
public. The Federal PKI will facilitate secure communications and
information processing for unclassified but sensitive (UBS)
applications.

PKI support for secure communications with business, the general public,
other branches of the Federal Government and state and local governments
is vital. The Federal PKI does not focus inward to secure communications
and information systems only within a closed Government community.
Rather, its purpose is to provide Federal users secure information
access and communications with the entire nation and the rest of the
world, as well as to provide secure internal Federal Government
information access and communications.

The Federal PKI will not be a monolithic top down structure; it will be
created largely from the bottom up. Federal efforts to use public key
cryptography generally begin with individual applications within
agencies that provide immediate support for vital agency programs. These
PKI applications will yield an immediate return to the agency in terms
of either improved effectiveness, or cost savings, or both. These
implementations are paid for largely out of program funds, not funded as
a centralized government PKI. Yet great benefits can result from melding
together the separate systems that use certificates into a broader,
coherent Federal PKI, that is itself a part of a larger national or
global PKI. Communications networks become more useful as they encompass
more stations. So also will the "trust network" of a PKI be more useful
as it allows secure communications and networking with a broader, global
community.

The great challenge of the Federal PKI, therefore, is to meld the
individual agency projects that use PKI technology, from a variety of
commercial vendors, into a broadly interoperable trust network. When
this is done, the whole PKI will, in fact, be greater than the sum of
the parts.

## Basic Concepts

Digital signatures are based on the concept of a public-private key
pair. A signatory, Alice, has a private key that she must keep a secret,
and an associated public key, which she makes public. Given the public
key, it is infeasible to find the private key. Alice signs a digital
document (a message or file) with her private key. A *relying party,*
Bob, may verify the signature with Alice's public key. Digital
signatures can provide three important security services:

-   *integrity*: any change to a signed document will cause the
    signature verification to fail;

-   *source non-repudiation*: since only Alice knows her private key,
    only she can sign a document with it;

-   *authentication*: Bob, can authenticate Alice's identity, if he
    knows her public key, by sending her a challenge. Alice typically
    chooses some additional information to add to the challenge (this
    prevents certain attacks) and signs that plus the challenge. If Bob
    can validate the signature with Alice's public key, he knows it was
    signed by Alice. If it contains his challenge, Bob knows that the
    message was freshly signed.

In addition, public key technology can provide confidentiality to Bob
and Alice:

-   Bob can encrypt a message with Alice's public key, which only she
    can decrypt (with her private key), or:

-   Bob can encrypt a traffic key in Alice's encryption public key and
    send it to her. She can then decrypt the session key with her
    private key, and Bob and Alice can then use that session key with a
    symmetric key encryption algorithm to encrypt a message between
    them. Symmetric key cryptography is commonly used to encrypt bulk
    data because it is generally much faster than public key encryption.

Public key certificates are digital documents that, at a minimum,
contain the name and public key of a user, and are digitally signed by a
certification authority (CA). The purpose of a certificate is to
reliably associate a user\'s name and public key. Bob, trusting the CA
and knowing its public key, may reliably authenticate Alice's public key
from her certificate by verifying the signature on the certificate.

In addition there are registration authorities, certificate status
responders, and management authorities in the federal PKI. A
*registration authority (RA)*, does not itself issue certificates, but
registers or vouches for the identity of end entities (users) to a CA
that then issues certificates. *Certificate status responders* are
trusted online servers that act for the CA to provide authenticated
certificate status information to relying parties. A *Policy Management
Authority (PMA)* approves or coordinates the policies used to operate
CAs and RAs and to issue certificates.

Figure 1 shows a "PKI-centric" view of certificate-based security
services. The security services enabled by a PKI are shown as circles
around the periphery of the PKI and the underlying information, security
servers that support them. At the center is the core PKI, which is
concerned with issuing and managing certificates. The first ring is the
PKI clients that use the certificates, and the next ring shows various
security specific servers and agents that provide or facilitate various
security services. An incomplete outer ring of general information and
communications services is shown at the bottom, to highlight some
general services that, while not specifically security related, are
important to the security services. The outermost ring of "bubbles"
represent services that can be realized through the core PKI, the
clients and the agents and servers.

The core Federal PKI consists of CAs, RAs, certificate status
responders, and management authorities that manage public key
certificates used by Federal departments and agencies for unclassified,
sensitive applications. The core Federal PKI will:

1.  issue public key certificates;

2.  revoke public key certificates when required;

3.  establish the policies that govern the issuance and revocation of
    certificates;

4.  archive the information needed to validate certificates at a later
    date.

PKI clients will use the public key certificates issued and managed by
the PKI to provide security services to Federal users. PKI clients
perform four primitive functions with and for certificates:

1.  public-private key pair generation;

2.  digital signature generation;

3.  digital signature verification;

4.  confidentiality key management (i.e., agreement or distribution of a
    session or message key to be used with a symmetric key algorithm for
    confidentiality).

The first function, key pair generation, can also be performed by CAs or
RAs. However, generation of digital signature key pairs by the clients
helps to maintain the integrity of the system and preserve
nonrepudiation, since only the client then ever possesses the private
key used for digital signatures. The last three functions enable a
variety of public key based security protocols and services by direct
client-to-client protocols. These services include authentication,
access control based on an authenticated identity or role,
nonrepudiation services, and confidentiality.

A number of servers and agents support the infrastructure and clients
may obtain security services from these servers and agents. The full
range of services is not fully understood, and is still evolving, but
they may include:

-   *digital notaries*: A digital notary provides a service analogous to
    a notary public. A notary may provide a trusted date and time stamp
    for a document, that proves that it existed at a point in time and
    may also verify the signatures on a signed document;

-   *key recovery agents*: CAs may require that copies of private keys,
    used for confidentiality key management, be turned over to a key
    recovery agent (KRA) as a condition for issuing a key management
    certificate. Alternatively, a client that sends an encrypted
    message, may include the encryption session key encrypted in the
    public key of the KRA, with the message. The purpose of the KRA is
    to allow decryption of encrypted data when keys are lost, or for
    management supervision or law enforcement purposes.\
    \
    It may be useful to separate the CA and key recovery functions.
    While the only secret a CA inherently needs to protect or access is
    its own private key, a key recovery agent may need to store,
    protect, and provide carefully controlled access to a large number
    of client private keys. KRAs may provide for split control of the
    user private keys it holds, so that the cooperation of two or more
    agents is required to access the keys. This applies only to key
    management key pairs; private keys used for digital signatures
    should ordinarily never be divulged by certificate holders to any
    other party;

-   *certified delivery agents*: These servers provide a destination
    non-repudiation service, analogous to certified mail or process
    servers. The service proves that a message was received by a
    possibly uncooperative recipient, or that a good faith attempt was
    made to deliver the message;

-   *ticket granting agents*: These agents provide cryptographic digital
    "tickets" that can be used for access to systems or data. They can
    use either public key or symmetric key cryptography, and provide a
    means for centralizing and managing access control in distributed
    systems.

Three general information and network services are of particular
significance to the PKI:

-   *repositories:* A repository is an on-line, publicly accessible
    system for storing and retrieving certificates and other information
    relevant to certificates, such as revocation information. In effect,
    a certificate is published by putting it in a repository.
    Repositories also contain Certification Practice Statements (see 7.1
    below). In the Federal PKI the expected normal repository is a
    directory that uses the "lightweight" directory access protocol
    (LDAP) \[RFC1777\]. However, other forms of repositories may be
    used, including X.500 directories (that use the DAP directory access
    protocols) and HTTP or anonymous FTP servers;

-   *data archives*: Archives provide a long term storage of CA files
    and records. The life time of CAs may be relatively short. But it
    may be important to verify the validity of signatures on very old
    documents. CAs must make provision to store the information needed
    to verify the signatures of its users, in archives that will be able
    to make the data available at a much later date, perhaps several
    decades later;

-   *naming and registration*: in a distributed environment, many
    objects must have unique names. This is true for security objects,
    for example certificate subjects and issuers, must have unique
    names.

# PKI Services

The PKI will provide the services and facilities needed for unclassified
secure Federal information processing and use of the NII, including:

-   digital signatures for:

```{=html}
<!-- -->
```
-   authentication;

-   integrity;

-   nonrepudiation.

```{=html}
<!-- -->
```
-   management of symmetric keys for UBS level confidentiality for:

```{=html}
<!-- -->
```
-   communications sessions;

-   e-mail messages.

When extended by Key Recovery Agents, the PKI will also provide key
recovery services for encrypted data.

The PKI will provide the services and facilities needed for secure
information access, communication, messaging and electronic commerce
with commercial and personal users employing common defacto and formal
security standards and using mainstream commercial security products.
The Federal PKI will be implemented primarily with ordinary COTS
security products.

# PKI Data Structures

Three basic data structures defined in the X.509 standard are used by
the Federal PKI are the : *certificate*, *cross certificate pair* and
*Certificate Revocation List (CRL)*.

## Nomenclature and Typographical Conventions

Certificates, cross-certificates and CRLs are all directory attributes
from the X.509 standard, and defined there using the ASN.1 syntax
\[X.509 97\]. Formal ASN.1 names are written without spaces and the
separate words in the names are indicated by capitalizing the first
letter of each word but the first. For example, the formal ASN.1 name of
a cross-certificate is "crossCertificatePair," while the formal name of
a certificate is "certificate." In this CONOPS, when it is useful to be
very specific that a word means a particular formal directory attribute,
as defined in X.509, it will be shown in its ASN.1 form, set in boldface
type (e.g., **certificate**, **crossCertificatePair,** and
**certificateRevocationList)**. However, frequent use of this convention
does not contribute to readability, so where it is not necessary to
stress the formalism, "plain English" names are used in normal roman
typeface.

## Certificates

The Federal PKI will use X.509 v3 certificates. The structure of the
X.509 v3 **certificate** is illustrated in Figure 2. In particular,
Figure 2 shows how the certificate may be extended with optional
extension fields. Table 1 gives more information about the use of
various certificate fields.

These certificates are digitally signed using the private key of the
issuing CA. Certificates issued for Federal users will be signed using
FIPS approved algorithms for digital signatures. There are a number of
standardized optional extension fields \[X.509 1997\]. In addition,
Federal specific extensions may be defined and incorporated into Federal
certificates. While certificates may be stored in hardware based tokens
or cryptographic modules, they generally need not be protected and can
be stored on any digital medium[^1]. The issuer's signature on the
certificate itself is created from a hash (for Federal use the FIPS
180-1 Secure Hash Algorithm) of the body of the certificate, and the
issuer's private key. In Table 1, the fields protected by the signature
are shown in the shaded area. Note that the algorithm identifier and
parameters fields of the signature itself are not protected.

The FIPS approved Digital Signature Algorithm requires the establishment
of three parameters. Syntactically there are three fields in the
certificate that could contain parameters. However, signatures should be
validated using the parameters contained in the parameters value of the
same subject public key info field as the public key used to validate
the signature. If the value of that parameters field is null, parameter
values are \"inherited\" from the parameters used for the previous
certificate validation in the certification path.

The optional extensions that have been defined for standardization
include extensions that:

-   identify the policies under which the certificate was issued;

-   map equivalent policies in different domains;

-   require subsequent certificates in a certification path to include
    specific policy identifiers, or inhibit policy mapping;

-   limit the subject name space for subsequent certificates in the
    certification path;

-   restrict key usage;

-   limit the number of subsequent certificates in a certification path;
    and,

-   distinguish between a CA certificate and an end-entity certificate.

Extensions may be labeled *critical*. A client must either be able to
process all critical extensions contained in a certificate, or it must
not validate that certificate. Most standardized extensions are
"optionally critical," and may be made critical or non-critical at the
discretion of the CA. A few are always non-critical or always critical,
and some must be critical in particular situations. The Federal PKI will
use these standardized extensions as needed and will require that
Federal certificates include certain extensions and that clients be
capable of processing certain extensions if they are present. Table 2
summarizes the standardized optional extensions to X.509 certificates
and their intended use in the FPKI. Additional material on certificate
extensions is contained in \[PROF 98\].

The primary purpose of an X.509 certificate is to associate the
subject's public key and name. Public keys may be used to verify
signatures, or to manage keys used with symmetric key algorithms for
confidentiality. Separate certificates will be used in the Federal PKI
for digital signatures and encryption.

## Cross Certificates

CAs may cross-certify each other, that is each issues the other a
certificate and combines the two certificates in a single directory
attribute called a **crossCertificatePair**. The attribute
**crossCertificatePair** supports chains of trust that run in both
directions. These pairs are needed for trust models that begin at the CA
which issued the users certificate, rather than trust models where trust
originates from a common "root" CA.

A **crossCertificatePair** includes two certificates, **forward** and
**reverse**. The subject of the forward certificate is the issuer of the
reverse certificate and vice-versa. When CA A cross certifies with CA B,
in A's **crossCertificatePair** attribute, A is the subject (and B is
the issuer) of **forward**, and B is the subject (and A the issuer) of
**reverse**. In B's **crossCertificatePair** attribute, A is the issuer
of **forward** and B is the issuer of **reverse**.

## Certificate Revocation Lists

It is at times necessary to revoke certificates, for example when the
certificate holder leaves the issuing organization or when the private
key is compromised. The mechanism defined in X.509 for revoking
certificates is the Certificate Revocation List (CRL). The X.509 v2 CRL
is illustrated in Table 3. Alternatively, some CAs may use the emerging
On Line Certificate Status Protocol (OCSP) \[OCSP 98\], with a
certificate status responder, to provide relying parties with current
certificate status information on individual certificates. OCSP is
further discussed in 5.2.1 below.

### CRL Data Structure

A CRL is a list, signed by a CA, of unexpired, revoked certificates. A
CRL contains the issuance time, and may contain the expected time at
which the next CRL will be issued. Therefore, a user can determine if a
copy of the CRL is still current. Federal CAs will issue CRLs for the
certificates they have issued at periodic intervals.

It is anticipated that all Federal CAs will issue CRLs as an archival
record, if for no other purpose. However, some Federal CAs may also
provide an on-line certificate status service, via the emerging Online
Certificate Status Protocol (OCSP) now being developed in the Internet
Engineering Task Force \[OCSP 98\]. On-line certificate status checks
provide a fresher check of certificate status than a CRL can, and may
also provide a mechanism for entering into a relationship or agreement
between the CA and a relying party.

Optional extensions are also defined for the X.509 CRL as a whole and
for each entry in the CRL. Table 4 summarizes the standardized
extensions for the CRL, while Table 5 summarizes the standardized
extensions for the CRL entries. In addition, certain of the optional
certificate extensions summarized in Table 2 (labeled " CRL
Identification" in the table) state information about CRLs, the issuer
of the CRL, and where to get a copy of the CRL.

### CRL Distribution Points and Indirect CRLs

If a CA issues a large number of certificates, and if certificates are
frequently revoked, perhaps because of personnel turnover, name changes,
or reorganizations, then CRLs could become quite large. A relying party,
then, needing to validate a single certificate, might be required to
download a large CRL, with much information he does not need. One way to
avoid this is with the **crlDistributionPoints** extension. This
certificate extension specifies where the CRL for the certificate may be
found, and allows the CA to partition the CRL space into smaller
segments. This reduces the amount of data that a relying party needs to
download to check the status of a particular certificate.

The default CRL issuer is the CA that issued the certificate. However,
the certificate and CRL extensions allow a certificate to identify a
second CA, other than the CA that issued the certificate, to be the CA
that will issue a CRL applicable to that certificate. This indirect CRL
may contain revocation information on certificates issued by many CAs.
Figure 3 illustrates the data structures for distribution points and
indirect CRLs.

The FPKI will use indirect CRLs to maintain an *Authority Revocation
List (ARL)*. An ARL is an indirect CRL that covers all the CA
certificates in the Federal PKI, but not end entity certificates. It
provides a single consolidated CRL for all CAs in the Federal PKI.

## Attribute Certificates and Subject Directory Attributes

Attribute certificates are an emerging concept, which is not yet fully
defined and understood.

### Current Status

Attribute certificates are defined in \[X9.45 97\] and \[X.509 1997\].
Table 6 summarizes the structure of an attribute certificate and its
fields. Attribute certificates might, for example, indicate credit
limits, authority to obligate the government, access privileges and so
on. An attribute certificate is a signed by an attribute authority (AA)
and is a digital document binding some attribute to either:

1.  a name (generally an X.550 distinguished name). An attribute
    verifier must verify that the claimant holds the name in the
    attribute certificate. The attribute claimant will generally present
    a signature certificate issued in that name and prove possession of
    the corresponding private key; or,

2.  a specific digital signature certificate, identified by issuer and
    serial number. The attribute verifier then must establish that the
    attribute claimant holds the private key for that specific
    certificate.

The relationship of attribute certificates to public key signature
certificates is illustrated in Figure 4.

Attribute certificates also allow the certification of attributes to be
made by the entity that is responsible for the attribute, rather than a
general CA. However, use of separate attribute certificates requires
that the certification paths of both the attribute certificate and the
subject's public key certificate be validated, which may significantly
increase overhead.

Alternatively, the **subjectDiractoryAttributes** extension can be used
to include in a certificate any desired directory attributes that have
been defined for the subject. If attributes included in a digital
signature certificate are changed, then it is necessary to revoke the
certificate and issue a new certificate, to update the certificate.
Therefore it is only appropriate to include subject attributes in a
digital signature certificate when:

-   the attribute is frequently needed when signatures are used; and,

-   the attribute is not expected to change frequently.

Several attributes have been defined for this purpose for the Multilevel
Information System Security Initiative (MISSI) \[SDN.706\]. Table 7
summarizes these attributes. They will be used in the Federal PKI
wherever it is necessary to include hierarchical classification levels
or citizenship information digital signature certificates and may be
used as appropriate for their uses as well.

Attribute certificates will probably become important in the Federal
PKI. Several standards committees are now attempting to standardize
attributes for various applications.

### The Evolution of Attribute Certificates

Work is progressing to elucidate and extend the use of attribute
certificates \[ISO WD 98\]. As this is evolving, this section can only
sketch the general outline of the work. The attribute certificate is
being extended to include an object digest as one of the choices for the
"owner" (formerly the "subject") of the certificate. The owner may
therefore be either a specified certificate, a name, or an object
digest. The object digest could be a digest of any object that can be
reduced to a message digest, but typically would be an executable
program. This is effectively a formalism for "code signing."

The model for the use of attribute certificates is being expanded to
include a *control model* where a *claimant* of a *privilege,*
encapsulated in an attribute certificate, requests a service. A
*verifier* compares the claimant's privileges to a *control policy* and
makes an access control decision.

A *delegation model* is also defined. A *Source of Authority* delegates
some privilege to a claimant as an attribute certificate. The claimant
may further delegate a privilege within the scope of his privilege to
another claimant, who may further delegate it, and so on. This forms a
*delegation path*, which is distinct from a certification path (see 4.1
below).. The verifier must then verify the entire delegation path,
ensuring that each successive delegation is within the scope of the
previous delegation. A number of extensions are proposed to control the
delegation of attributes.

# PKI Certification Path Architecture

A *certification path* is a chain of certificates. The chain starts from
the public key of a CA trusted by the verifier. Each certificate in the
certification path is signed by its predecessor\'s key. A relying party
verifies a signature by successively verifying the signatures on the
certificates in the path. The certification path is the essential
architectural construct of a PKI. There are different ways of arranging
certification paths, that have different consequences.

## Signatures and Certification Paths

Figure 5 depicts the relationship of a certificate and a signed
document. The signature of the signed document is validated with the
public key in the certificate. Note that the signature itself does not
identify the certificate for the public key used to sign the document.
Rather the relying party must either know *a priori* which certificate
to find the public key in, or must try all the keys of the certificates
held by the signer until he finds one that validates. If no public key
in any certificate validates the signature on the document, then the
signature cannot be validated.

A certificate is itself a signed document. Assume that Alice wishes to
validate the signature of a document signed by Bob. Alice has a CA that
she trusts, and whose public key she knows. In the usual case, Alice
knows this public key because she has been given a "self-signed"
certificate containing the key by some authenticated, but "out-of band"
process. Usually she gets it when she gets her own certificate. Bob
holds a certificate issued by a different CA, whose public key Alice
does not know. But that CA may itself have been issued a certificate by
the CA Alice trusts, or there may exist a chain of certificates leading
from the CA Alice trusts, to other CAs and ultimately to Bob's
certificate. Such a chain, illustrated in Figure 6, is called a
certification path, and Alice can start with the public key of CA1, that
she knows, and successively validate the signatures on each of the
certificates, until she reaches Bob's certificate.

Figure 6 shows a detailed view of the certification path, including the
keys and the signatures, and a simplified view, which depicts CA keys as
circles, end-entity keys as rectangles, and certificates as arrows from
the signing key to the certified key. It is convenient to use this
notation to draw a certification path topology for a PKI. But it is
important to understand that what we are illustrating in such figures is
really a trust topology by the certificates that CAs issued to other
CAs, and to end-entities. A certification path is not a communication
path. The fact that a node (really a key) is on many paths may indicate
that it is an important CA. However, it does not indicate that the CA
(which may not even be an on-line entity) is actively involved in the
validation of the certification paths, or that it represents any kind of
communications bottleneck.

## Certification Path Architectures

CAs can issue certificates to each other in a systematic and ordered way
or in a more flexible and less ordered way. In addition, current web
browser products implement only a simplified "flat" PKI that does not
make much use of certification path processing, in the general sense.
The systematic, ordered topology of certification paths that is a
hierarchy, while the more general topology is a mesh of cross-certified
CAs. The alternatives are illustrated in Figure 7 and described below:

-   *Hierarchical*: Authorities are arranged hierarchically under a
    "root" CA that issues certificates to subordinate CAs. These CAs may
    issue certificates to CAs below them in the hierarchy, or to users.
    In a hierarchical PKI, every relying party knows the public key of
    the root CA. Any certificate may be verified by verifying the
    certification path of certificates from the root CA. Alice verifies
    Bob's certificate, issued by CA 4, then CA 4's certificate, issued
    by CA 2, and then CA 2's certificate issued by CA 1, the root, whose
    public key she knows;

-   *Mesh*: Independent CA's cross certify each other (that is issue
    certificates to each other), resulting in a general mesh of trust
    relationships between peer CAs. Figure 7 (b) illustrates a mesh of
    authorities. A relying party knows the public key of a CA \"near\"
    himself, generally the one that issued his certificate. The relying
    party verifies certificate by verifying a certification path of
    certificates that leads from that trusted CA. CAs cross certify with
    each other, that is they issue certificates to each other, and
    combine the two in a **crossCertificatePair**. So, for example,
    Alice knows the public key of CA 3, while Bob knows the public key
    of CA 4. There are several certification paths that lead from Bob to
    Alice. The shortest requires Alice to verify Bob's certificate,
    issued by CA 4, then CA 4's certificate issued by CA 5 and finally
    CA 5's certificate, issued by CA 3. CA 3 is Alice's CA and she
    trusts CA 3 and knows its public key.

```{=html}
<!-- -->
```
-   *Trust List*: Current web browser and server products are the most
    widely used PKI clients, however they lack a well-developed
    certification path processing capability. Browsers contain a file of
    trusted self-signed certificates. In most cases, clients will
    validate a certificate only if it is directly signed by one of the
    keys contained in the file of trusted CA certificates. This is
    illustrated in Figure 7 (c). This approach can be effective for
    local applications, and might be workable on a broader scale if all
    other certificates were issued by one of a handful of "national"
    CAs. However, it does not appear to be sufficient to implement a
    broad Federal or national PKI.

Table 8 summarizes the characteristics of the three architectures.

### Hierarchical Architecture

In the hierarchical architecture all relying parties base their trust on
the key of a single root CA. The root\'s public key must be distributed
in some authenticated fashion to all relying parties, to "bootstrap"
trust in the PKI. Trust paths descend from the root through subordinate
CAs. The hierarchical certification path architecture has some
advantages:

-   The organizational management structure of many organizations such
    as the government is largely hierarchical. Trust relationships are
    frequently aligned with organizational structure, so it is natural
    to align the certification path with the organizational structure;

-   The hierarchy may be aligned with hierarchical directory names;

-   The strategy for searching for a certification path is
    straightforward;

-   Important existing Federal PKI components are designed
    hierarchically;

-   Each user has a certification path back to the root. The user can
    provide his path to any other user and any user can verify the path,
    since all users know the root's public key.

A strictly hierarchical certification path architecture also has some
disadvantages:

-   It is improbable that there will be a single root CA for the world
    PKI;

-   Commercial and business trust relationships are not necessarily
    hierarchical;

-   Compromise of the root private key is catastrophic and recovery
    requires the secure distribution of the new public key to every
    user.

Early attempts to design PKIs, such as the Internet Privacy Enhanced
Mail (PEM) standard \[RFC 1421, RFC 1422, RFC 1423\], generally featured
a hierarchical structure. The principal reason for this was to
facilitate the management of security policies and trust relationships:
branches of the tree were aligned with security policies. The X.509 v3
certificate structure, however, introduces several extensions that allow
the management of policies and trust relationships in a non-hierarchical
PKI, and this rationale for a hierarchical PKI is no longer compelling.

### Mesh Certification Path Architecture

In the mesh architecture, each relying party relies on the public key of
one of the CAs in the PKI, generally the one that issued the relying
party's certificate. Rather than superior-subordinate relationships
between CAs, trust relationships are peer-to-peer: CAs exchange
certificates to form cross certificate pairs. The mesh certification
path architecture has some advantages:

-   It is flexible, facilitates ad hoc associations and trusted
    relationships, and reflects the bilateral trust relationships of
    business;

-   A user must trust at least the CA that issued its own certificate in
    any PKI, and it is reasonable to make this the foundation of all
    trust relationships;

-   CAs that are organizationally remote, but whose users work together
    with a high degree of trust, can be directly cross-certified under a
    high trust policy that is not extended to other CAs and is higher
    than would be practical through a long, hierarchical chain of
    certificates;

-   It allows direct cross-certification of CAs whose users communicate
    frequently, reducing certification path processing load;

-   Recovery from the compromise of any CA's private key requires only
    that the new public key (and certificates signed with the
    corresponding new private key) be securely distributed to the
    holders of certificates from that CA.

The mesh PKI also has at least two disadvantages:

-   Certification path search strategies can be more complex;

-   A user cannot provide a single certification path that is guaranteed
    to enable verification of his signatures by all other users of the
    PKI.

### Trust-list Architecture

The trust-list PKI is, in terms of the number users with clients that
support it, undoubtedly the most widely implemented architecture. The
two nearly ubiquitous leading browser products implement the trust-list
approach, as do many server products. Each browser user has a local file
of trusted self-signed "root" certificates. The browsers normally are
distributed with an initial set of root certificates. Control of that
file may be managed by the individual user, or organizations may have
provision for loading or managing it from a central network management
serve. Users can add to this set or delete certificates from it.

The certificate path processing capability of these products is
currently quite limited. For some applications, browsers can process an
ordered certificate list leading from the sender of a message back to a
certificate signed under one of the self-signed certificates in the
trusted certificate file. The browsers have a limited capability to
retrieve a certificate from an LDAP directory, as requested by the user,
but no capability to automatically find an ordered, complete multi-step
certification path. A few standardized extensions, including Key Usage
and Basic Constraints are supported. Some private extensions for code
signing and SSL may also be supported. The X.509 name constraints,
certificate policy and policy constraints extensions are not supported.
The concept of cross-certificates is not directly supported.

The browsers can use certificates to sign, verify, encrypt and decrypt
S/MIME email messages. They can use certificates to establish Secure
Socket Layer (SSL) sessions. SSL is a transport level session encryption
and authentication protocol that is being adopted by the IETF as the
Transport Security Protocol (TSP). In an SSL session, users can, for
example, submit forms to a server or receive information from a server
in an encrypted, authenticated transport session. Browsers can also
verify the signatures on signed code.

SSL is a client-server transport level protocol. Web server products
from the browser vendors and other server vendors, then implement the
SSL server functionality. A number of Certification Authority (that is
certificate server) products are available that can issue client
certificates to browsers and SSL server certificates to web servers.
Several commercial CAs also offer certificates to browsers and servers
over the Internet. LDAP products and some browser configuration
management products complete the suite of currently available PKI tools
for these systems.

Since browsers do not support certificate policies, each CA must issue
certificates under a single policy. If a CA wants to distinguish between
high, medium and low assurance certificates, then three separate CAs
with separate CA keys are needed, and the appropriate self-signed CA
certificates must be loaded into the browser trusted certificate files.
This, however, is at best an awkward solution, since the browsers have
no particular tools to manage separate trusted certificate files, and
select one, depending on the type of transaction being evaluated.
Multiple users are supported for each browser, so one might create
several browser users, each with a different set of trusted
certificates. Perhaps, then, some rough equivelent to the X.509 initial
policy set might be achieved.

These tools, however, suffice to build useful single-enterprise scale
applications, where all the users have certificates from a single CA,
and where all certificates\' subjects can be equally trusted. They can
also allow some limited hierarchical structure, if all S/MIME users
provide a certificate list back to a root CA, and all browsers are
initialized to accept that CA. It is far from clear, however, that they
are adequate for an "open" national or international PKI. The absence of
direct support for cross certification and certificate policies limits
the use of browsers for large-scale open PKI applications, as does their
inability to automatically find certification paths.

The initialization and management of a file of possibly numerous
"trusted CA certificates" is a somewhat questionable proposition for
every workstation in a large organization, as a way to manage enterprise
trust relationships. It is not clear that there is any practical way to
prevent either users, or others with access to their workstations, from
making unauthorized alterations to this file. Certainly, the process of
distributing an initial file of such self-signed certificates with
browser products that are routinely downloaded over the Internet, is not
a secure way to initialize the trusted keys. Moreover, with only two
browser products of commercial consequence, the initial distribution
certificate choices by browser vendors will distort the market for open
PKI services. In effect, the browser vendor\'s choice of which
self-signed certificates to include with their "out of the box" product
may establish a kind of defacto CA accreditation.

The browser-oriented PKI architecture has several advantages:

-   It is simple, straightforward and comparatively easy to implement;

-   The end user has total control of the contents of the file of CAs he
    trusts;

-   It would work well with a simple On-line Certificate Status Protocol
    (OCSP), since there is not a complex certification path to validate,
    rather the status request is addressed only to the CA in the trusted
    certificate file. (Note that browsers do not now implement such a
    protocol);

-   Certification paths are generally simple, which should speed
    processing.

-   

The browser-oriented PKI architecture has several disadvantages:

-   The browser user has total control of the contents of the file of
    CAs he trusts. It is hard to see how organizations can reliably
    manage this as organizations and prevent individual users from
    altering these files;

-   The inclusion of a default list of trusted CA's in browsers as they
    come, out of the box, is hardly an authenticated process for
    initializing the known public keys upon which all else rests;

-   The careful management of the potentially large file of trusted CA
    certificates may be too tedious and difficult for most end users;

-   Little support is provided for finding certification paths;

-   There is no direct support for cross-certificate pairs, limiting the
    role of CAs in managing trust;

-   Certificate Policies are not supported, requiring that a
    Certification Authority entity operate several CAs, if it is to
    support different certificate policies and assurance levels. This in
    turn ads more Certificates to the browser's trusted certificate
    file;

-   Browsers now support no automated method of verifying the status of
    certificates, nor of revoking them.

The most important advantage of the trust-list oriented PKI is not
inherent in the architecture: support for S/MIME and SSL is available
out of the box, in current browser products. These browser clients are
now ubiquitous. The World Wide Web and browsers are the dominant network
client technology today, and the main platform for implementing
distributed applications. Web servers also support the browser-oriented
PKI model. Any PKI application, that hopes to reach the public at large,
must find this existing ubiquitous capability compelling. Moreover, web
technology is now the platform of choice for many intranet applications
as well. Whatever the abstract merits of the PKI architecture
implemented by browsers, the reality of their pervasive availability,
and their key position, makes this an important architecture.

# Federal PKI Architecture

There are now many more or less independent efforts in Federal agencies
to set up independent CAs to support individual applications. In most
cases, the cost of setting up and operating the CA is born by some
application that supports the agency mission, such as purchasing,
grants, or travel, etc. and the use of public key technology must be
justified in terms of its direct benefit to that agency application. In
other cases the government will use commercial CA service providers to
issue certificates to the public, to facilitate delivering services to
the public, and the cost will be born by the various agency projects
that rely upon those certificates. Relatively little thought has
generally been given to broader government-wide PKI needs, and the
systems that are set up do not generally facilitate interagency
operation, or the creation of a broader national PKI.

"Metcalfe's Law," that a network becomes more valuable as it reaches
more users, must surely also apply to a PKI. It is apparent that there
are great benefits to a system that propagates trust not just in the
local environment, but throughout the entire Federal Government, the
nation, and the world. Trust in a PKI propagates through certification
paths. The main issue for the Federal PKI is: Given that many, often
quite different, systems that use certificates are now being implemented
by agencies, how do we create certification paths between them, in a
sufficiently consistent and coherent fashion, to allow reasonably
reliable and broad propagation of trust?

This CONOPS uses a *Bridge CA (BCA)* that provides systematic
certification paths between CAs in agencies, and outside the government.
Federal CAs that meet certain standards and requirements will be
eligible to cross-certify with the BCA, thereby gaining the
certification paths needed for broad trust interoperation in the larger
Federal and national PKI. While the certification path processing
limitations of some less functional clients may confound
interoperability at times, the existence of these certification paths is
a necessary precondition for broad trust interoperation.

## Architecture Components

The certification path elements of the proposed architecture are
illustrated in Figure 8. The complete architecture is composed of the
following components:

-   ***Federal Policy Management Authority (FPMA)***: this management
    authority sets the overall policies of the Federal PKI, and approves
    the policies and procedures of trust domains within the federal PKI.
    It operates a Federal Bridge CA, and repository;

-   ***Trust Domains***: In the Federal context a trust domain is a
    portion of the Federal PKI that operates under the management of a
    single *policy management authority*. One or more Certification
    Authorities exist within the trust domain. Each trust domain has a
    single *principal CA*, but may have many other CAs. Each trust
    domain has a domain repository. In the non-Federal Context, trust
    domains, may be more loosely organized, but consist at a minimum of
    a group of CAs that share trust and operate under consistent
    policies.

-   ***Domain Policy Management Authorities (DPMA)***: a policy
    management authority approves the certification practice statements
    of the CAs within a trust domain, and monitors their operation. The
    DPMAs operate or supervise a domain repository. In the non-federal
    context, a DPMA may be an association of CAs that share trust and
    use consistent or comparable CA policies;

-   ***Certification Authorities (CA)***:

```{=html}
<!-- -->
```
-   ***Bridge CA (BCA)***: the Federal Bridge CA is operated by the
    Federal Policy Management Authority. Its purpose is to be a bridge
    of trust that provide trust paths between the various trust domains
    of the Federal PKI, as well as between the Federal PKI and
    non-federal trust domains. FPMA approved trust domains designate a
    principal CA that is eligible to cross-certify with the Federal BCA.
    Note that the BCA is not a *root CA*, since it does not ordinarily
    begin certification paths. When the BCA cross certifies with CAs it
    may include **nameConstraints**, **pathLengthConstraints** or
    **policyConstraints** that limit the propagation of trust to other,
    cross-certified domains. The BCA also issues a consolidated Federal
    ARL;

-   ***Principal CA***: A CA within a trust domain that cross-certifies
    with the Federal BCA. Each trust domain has one principal CA. In the
    case of a domain with hierarchical certification paths it will be
    the root CA of the domain. In a mesh organized domain, the principal
    CA may be any CA in the domain. However it will normally be one
    operated by, or associated with, the domain policy management
    authority;

-   ***Peer CA***: A CA in a mesh domain, that has a self-signed
    certificate which is distributed to its certificate holders, and
    which is used by them to start certification paths. Peer CAs
    cross-certify with other CAs in their trust domain;

-   ***Root CA***: In a hierarchical trust domain, the CA that starts
    all trust paths. In the hierarchical domain, certificate holders and
    relying parties are given the self-signed root CA certificate, by
    some authenticated, out-of-band means, and start all trust paths
    from that point. For hierarchical trust domains the root CA is also
    the principle CA for that domain;

-   ***Subordinate CA***: A CA in a hierarchical domain that does not
    begin trust paths; rather trust starts from some root CA. In a
    hierarchical trust domain, a subordinate CA receives a certificate
    from it's superior CA, and may also have subordinate CAs of its own,
    to which it issues certificates;

```{=html}
<!-- -->
```
-   ***Repositories*:** Repositories are on-line facilities that provide
    certificates and certificate status information. Repositories in the
    Federal PKI will provide information via the LDAP protocol and they
    may also provide information in other ways. The FPMA will maintain
    an open LDAP repository for CA certificates and revocations.
    Repositories that contain end-entity certificates and CRLs for
    end-entity certificates, or other certificate status responders, are
    a policy matter for individual trust domains. Some domains may
    choose to make end entity certificates available in open
    repositories, and other domains may restrict access to end-entity
    certificates. Similarly some domains may implement CRL based
    certificate revocation while others may choose to implement OCSP
    responders. Some domains may elect to make certificates and
    certificate status information available only to relying parties
    that have entered into an agreement with the CA or domain management
    authority;

-   ***BCA Repository***: The BCA repository will be open to Internet
    access by anyone, and will make the following available:

```{=html}
<!-- -->
```
-   All certificates issued by the BCA;

-   All certificates held by the BCA;

-   All cross certificate pairs containing certificates held or issued
    by the BCA;

-   All CA certificates issued by CAs within the overall Federal PKI;

-   All cross certificate pairs between CAs in the Federal PKI;

-   A consolidated Federal ARL, that covers all CAs in the Federal PKI.
    This implies a requirement to include appropriate CRL Issuer and CRL
    Distribution Point extensions in all CA Certificates issued by CAs
    within the Federal PKI;

-   Other certificates and CRLs as determined by the FPMA;

```{=html}
<!-- -->
```
-   ***Certificate Status Responders (CSR)***: CSRs will use the
    emerging Internet Online Certificate Status protocol \[OCSP 98\] to
    give relying parties an online, real time response to the simple
    question: "Has this end entity certificate been revoked or
    suspended?" CAs that use OCSP responders rather than (or in addition
    to CRLs) will specify the address of the OCSP responder in those
    certificates, and issue a certificate to the responder. CSRs will
    only be used for end-entity certificates, which will be the vast
    number of certificates in the Federal PKI and which will be changed
    and revoked much more often than CA certificates.

## Operational concept

The *Federal Bridge CA (BCA)* will be the unifying element to link
otherwise unconnected agency CAs into a systematic overall Federal PKI.
The BCA is not a root CA. It does not start certification paths, it
simply connects *trust domains* through cross certificate pairs to
designated "principal CAs.\" It is a "bridge of trust." A Federal Policy
Management Authority (FPMA) will supervise BCA operation and establish
the requirements for cross certifying with the BCA. These trust domains
may be within the government or outside the government.

Those Federal (or non-Federal) CAs that operate in trust domains that
meet the requirements established by the FPMA will be eligible to cross
certify with the BCA. This will then connect them to the overall trust
network of the Federal PKI, and provide relying parties and certificate
holders in their trust domains with connectivity to the larger Federal
PKI. This will be simpler and more effective than trying to manage an ad
hoc collection of many cross certifications with CAs in other trust
domains.

The BCA will maintain a repository that focuses on CA certificates, and
the BCA will issue an *Authority Revocation List (ARL)*, an indirect CRL
that covers all the CAs in the Federal PKI. The ARL will also cover the
certificates of the certificate status responders associated with any
Federal CAs. This will be an aid to efficient certification path
creation and validation. The total number of certificates issued by the
BCA will be modest, since the total number of CA certificates not large,
and the repository database will not be large.

The Federal PKI will embrace as many PKI approaches as can be made to
work together (hierarchical, mesh, and large scale web oriented
commercial CA oriented approaches), as well as can be arranged. Given
the limitations of current PKI clients, the existence of certification
paths does not guarantee trust interoperability, but it is a necessary
precondition.

To provide maximum flexibility to Federal agencies and not intrude upon
their prerogatives:

-   Agencies will not be required to adopt the BCA's policies. Rather,
    agencies will retain the option to use other policies defined by
    their own within-agency PMAs, or by commercial certificate service
    providers. See Section 7 below for more discussion of policy
    management.

-   Agencies will not be required to use the BCA to interoperate within
    or outside the Federal government -- they may go directly to the
    party with which they are seeking to interoperate and develop a
    one-to-one relationship for that purpose.

### Certificate Status

An important part of certification path processing is confirming that
certificates have not been revoked or suspended. Certificates may be
revoked for a number of reasons. These include changes in the name of
individuals, reorganizations that change organizational names, because
the subject has left the organization or changed his job, because any
attributes bound to the subject in the certificate has changed, or
because of a known or suspected key compromise. Two standardized
mechanisms are available for determining current status, CRLs and OCSP
responders.

A CRL is a signed list of certificates that have been revoked or
suspended. A revoked certificate is removed from a CRL after the
expiration date of the certificate. A CRL is normally signed by the CA
that issued the certificates, however there is a mechanism that includes
a pointer in a certificate to an applicable "indirect CRL" issued to
another CA. The indirect CRL is illustrated in Figure 3.

CRLs have several useful properties. Since they are validated by the
signature on the CRL, it does not matter where CRLs are obtained, and
they can be made available at many locations and cached. They contain an
issuance date and an expected date when the next CRL will be issued.
These can be used as an aid to managing a cache of CRLs, and it is
reasonable to adopt a CRL cache management scheme that continues to use
a cached CRL until the date of the next CRL. Provided that revocation
rates are not very high, CRLs make an efficient, scaleable mechanism.
Moreover, they can be partitioned and certificate lifetimes managed to
keep CRL sizes reasonable even in the face of large CAs with significant
revocation rates.

But there are several limitations to CRLs:

-   CRLs are periodic, and therefore may not have the freshest possible
    information about certificate status. But if the CRL period is very
    short, and therefore the information always very fresh, then caching
    doesn't work well, and the CRLs will be inefficient. A relying party
    will have to download a new CRL nearly every time, and will get much
    information he won't ever need;

-   If revocations are frequent, then CRLs get big. This can be
    ameliorated by adjusting certificate validity periods (so that
    expired certificates are removed from CRLs) and partitioning CRLs
    into pieces with distribution points (see Figure 3);

-   Since it doesn't matter where a CRL is obtained, and since they are
    designed to be cached, mirrored and shadowed, it will be very hard
    to charge relying parties for access to CRLs, limiting this possible
    revenue source to fund PKI operation;

-   Similarly, it will be difficult to use the CRL as a mechanism to
    bind relying parties to CAs for the purpose of contractual privity;

-   CRLs (particularly indirect CRLs) are complex structures that add a
    good deal of complexity to clients for relying parties, including
    the ability to access the CRLs from repositories.

In consequence, a proposal for an Online Certificate Status Protocol
(OCSP) has been introduced to the IETF. With OCSP a relying party will
send a (possibly signed) request identifying a certificate to an on-line
certificate status responder. The responder will reply with a signed
message stating something about the status of the certificate.

This on-line approach has several advantages:

-   the information can potentially be very fresh, that is each response
    can potentially be generated from the most current information a CA
    has for each certificate;

-   for any one certificate check, much less response information is
    required than would be with CRLs;

-   the subject certificate and the signed OCSP response provide a
    relatively compact (compared to a certificate and a CRL) set of
    information to store with a signed document to facilitate later
    revalidation of the signature;

-   the code needed in clients to implement OCSP is probably less than
    the code needed to process CRLs;

-   it is comparatively straightforward to bill relying parties on a per
    status request basis;

-   it provides an opportunity to enter into a "click-wrap" contract of
    some sort between the CA, (or at least the responder as the agent of
    the CA), and the relying party. This contract could, for example,
    define the CA's potential liability.

Despite these advantages there are also some issues and uncertainties
with the OCSP approach. These include:

-   The responder is a trusted on-line server with high availability
    requirements, which is replacing a repository that did not need to
    be trusted. In addition, the repository is still needed (to find
    certificates in the first place);

-   The responder is not easily mirrored or shadowed and it potentially
    becomes a centralized performance bottleneck or point of failure, in
    a system that hitherto had none, moreover:

```{=html}
<!-- -->
```
-   on-line transaction systems will have sharp load peaks that are much
    greater then average loads;

-   it is a bottleneck that must generate a high peak volumes of
    signatures, and, possibly (if requests must be validated) validate a
    high volume of signatures as well;

```{=html}
<!-- -->
```
-   some of the fixes for the performance issues (precomputing
    responses) also reduce freshness;

The actual model, the trust relationships supported or assumed and the
actual question answered by the OCSP responder are not yet entirely
clear.

Several considerations apply to the use of CRLs in the Federal PKI:

-   CRLs are periodically "pulled" from repositories by verifiers. This
    results in some potential delay in notifications of suspected key
    compromises. "Push" models have been used for distributing a
    Compromised Key List (CKL). However, for a large Federal PKI a CKL
    might become unworkably large for push type distribution, and it is
    unclear to whom the CKL should be pushed. A possible solution is an
    indirect compromised key CRL, that consolidated key compromise
    information and is frequently updated.

-   For a large Federal PKI, the communications needed to access CRLs
    could become quite large and the cost of distributing CRLs is also
    potentially large \[MITRE 94\]. Several approaches are available to
    minimize this:

```{=html}
<!-- -->
```
-   delta CRLs (which include only new revocations since some base CRL)
    and CRL distribution points (which include only revocations for a
    particular arc of the name-space) may be used to minimize the amount
    of information needed to validate a single certificate;

-   certificate validity periods can be adjusted to keep CRLs short.
    When revoked certificates expire they are removed from the CRL;

-   relatively coarse names will minimize revocations due to name
    changes;

-   applications where certificate "churn" is high are good candidates
    for OCSP status validation rather than CRLs.

In the Federal PKI, CAs may use OCSP responders, or CRLs to make end
entity certificate status available. Since end entity certificates may
exhibit significant volatility and the total number of end entity
certificates will be large, OCSP certificate status validation may both
be more efficient and provide more timely revocation information than
would be possible with the CRL status mechanism. It may also facilitate
cost recovery mechanisms where relying parties (e.g., government web
servers) are charged for each status validation. However, CRL
publication of end-entity revocations places a smaller burden on the
PKI, since it avoids the expense of a trusted real-time responder, and
can be both effective and efficient.

Although CA certificates should be validated frequently during
certification path processing, the database is not large and does not
change rapidly. CA certificates and ARLs are ideal data structures for
local cache memory: get them once and use them many times. Therefore the
Federal PKI will rely on the ARL as a "one stop" mechanism for
validating the current status of all CAs in the Federal PKI. The BCA
will issue an ARL, an indirect CRL that covers all CA and OSCP responder
certificates in the Federal PKI. CA certificates will not be nearly as
volatile as end-entity certificates (although their validity periods
will be larger), so the ARL should remain fairly small. The BCA
repository will then be a key resource for creating and validating
certification paths, and will have high availability requirements,
medium bandwidth requirements, and low storage requirements. The CA
certificates and the ARL will be available on the BCA repository, and
may readily be shadowed or replicated in other repositories.

The Federal PKI will normally follow the "pull" distribution model for
CRLs, that is verifiers will request CRLs from repositories on an as
needed basis. Local hard disk storage is relatively inexpensive, and
CRLs need not be stored in trusted memory. Therefore, a CRL, once
retrieved by a client verifier, will normally be retained in a local
cache memory until the date of the next update (which is stated in the
CRL), to reduce communications costs. The period for CRLs will be a
compromise, balancing the delay in distributing revocation notices to
verifiers against the communications costs of frequent updates.

# Cryptographic Algorithms and Interoperability

Only the FIPS 186-1 Digital Signature Algorithm (DSA) is now approved
for Federal use. However, NIST expects to extend Federal Information
Processing Standard (FIPS) 186, the Digital Signature Standard \[FIPS
186\], to specify additional public-key based digital signature
algorithms. The Rivest-Shamir-Adelman (RSA) algorithm \[X9.31\] and the
Elliptic Curve Digital Signature Algorithm (ECDSA) \[X9.62\] are strong
candidates for inclusion in an expanded FIPS 186. This would allow
Federal users to choose the present Digital Signature Algorithm, the RSA
algorithm, or the ECDSA algorithm.

## Definitions

The X.509 standard specifically allows a key for one algorithm to be
certified in a certificate signed by another algorithm. For the
discussion in this section the following terms are defined:

-   *single algorithm certificate*: a certificate that uses the same
    algorithm to sign the certificate as the algorithm for the public
    key certified in the certificate;

-   *mixed algorithm certificate*: A certificate where the subject's
    algorithm for the certified key is different from the algorithm used
    by the issuing CA to sign the certificate;

-   *self-signed certificate*: A certificate signed with the key it
    certifies. CA uses a self-signed certificate to state (but not
    authenticate) its public key and any associated parameters.
    Self-signed certificates are transmitted to relying parties by some
    out-of-band, authenticated mechanism.

## Parameter Inheritance

Some algorithms (DSA and ECDSA) require that parameters be specified.
Parameters are public constants, needed for the algorithms, that can be
common to all the certificates issued by a CA, to a group of
certificates, or to a large domain of the PKI. The algorithm identifier
field can (optionally) state the parameters used. The only secure place
to find either the public key used to sign a message (including a
certificate) and the associated parameters, is in the subject public key
field of the signer's certificate \[CHOK\]. Parameters are often large
numbers. In the case of the DSA, two of the parameters, p and g, are the
same size as the public key, between 512 and 1024 bits. In this case, it
is desirable to omit parameters, wherever it is possible to reduce the
size of the certificates. Therefore, a set of "parameter inheritance"
rules have been developed. These rules allow parameters to be inherited.
Those rules have been incorporated in some draft standards \[WD 15782\],
and are summarized as follows:

-   parameters should be obtained from the same authenticated source as
    the public key, the subject public key field of the signer's
    certificate;

```{=html}
<!-- -->
```
-   if the parameters in the subject key field of the signer's
    certificate are null (for those algorithms requiring parameters),
    then the parameters are "inherited" from the preceding step in the
    certification path;

-   parameter inheritance does not apply to multiple algorithm
    certificates, that is a multiple algorithm certificate must contain
    the parameters in the subject public key field, if parameters are
    used for the subject algorithm.

Parameter inheritance is illustrated in Figure 9. In this case CA2
inherits its parameters from the certificate of CA1, but Bob has
different parameters that must be stated explicitly in his certificate.

## Algorithm Interoperability rules

To maximize efficiency and minimize algorithm interoperability problems,
the Federal PKI should be designed so that two end-entities who use the
same signature algorithm, should be able to find a certification path
that does not require use of a second algorithm. It is therefore
desirable, in the interest of local interoperability, for individual
trust domains to use a single signature algorithm. This will minimize
the number of certificates that need to explicitly state parameters in
the certificates, and minimize the chances for algorithm induced
interoperability problems within a trust domain. It will also be
desirable for there to be single algorithm certification paths between
domains that use the same algorithm.

Similarly, whenever two trust domains use different signature
algorithms, there should be a certification path between the two that
does not require use of a third signature algorithm. This will maximize
the chance that end entities in the two domains can validate the trust
paths between them.

It is relatively simple to implement signature verification for several
algorithms, but much more burdensome to sign with different algorithms,
since this implies that users must have more keys and certificates to
manage. So most end-entities will prefer to use as few signature keys as
possible and sign with a single algorithm. Accordingly, the major burden
for multi-algorithm interoperability in the federal PKI falls on
end-entity client software, that should be capable of verifying
signatures for all the algorithms supported by the Federal PKI.

If the CA Alice trusts signs with algorithm "white" and Bob's key is for
algorithm "gray," then, if Alice is to verify Bob's signature, there
must exist a mixed algorithm certificate for a gray algorithm key,
signed with a white algorithm key, somewhere in the certification path
between them. The principle that local trust domains should minimize the
use of multiple algorithms within the domain implies that the needed
mixed algorithm certificates should be associated with the BCA that
connects trust domains. That is, the mixed algorithm certificates that
are needed to provide trust paths between users of different algorithms
are properly either issued by or to the BCA.

The following rules will simplify interoperability in a Federal PKI that
uses several digital signature algorithms:

-   end-entity certificates will be single algorithm certificates;

-   if the end-entity needs to interoperate with end-entities who use
    other algorithms, then his client should be able to verify
    signatures for other algorithms (but not necessarily to sign with
    multiple algorithms);

-   a CA (other than the BCA) will sign certificates with only one
    algorithm;

-   Each trust domain will use a single signature algorithm;

-   the BCA may support multiple signing algorithms, and have keys for
    different algorithms;

-   mixed algorithm certificates will be used only between the BCA and
    PCAs;

-   all self-signed certificates for algorithms that use parameters will
    include the parameters in the subject public key field;

-   other Certificates will only include parameters if, and only if:

```{=html}
<!-- -->
```
-   the certificate is a mixed algorithm certificate, or;

-   the parameters are different from the parameters of the issuing CA.

```{=html}
<!-- -->
```
-   Federal users will be encouraged to use client systems that can
    verify all Federally approved digital signature algorithms.

-   the end-entity normally signs with a single algorithm, minimizing
    the number of keys and certificates he is required to hold and
    manage;

A Federal PKI which follows these rules will have certain desirable
properties. Two end-entities who use the same signature algorithm will
not require the use of additional algorithms to verify certification
paths. In most cases, mixed algorithm certificates, if they occur in a
certification path will occur only once, and the number of mixed
algorithm certificates, which may require that parameters be included in
the certificates, will be minimized.

The precise definition of how the BCA handles multiple algorithms and
mixed algorithm certificates is under consideration at this time.
Several apparently workable approaches have been identified
\[TWG-98-44\]. The BCA may be a single logical CA (that is, have a
single name), even though it signs with several different algorithms.

# FPKI Management and Policies

Certificate Policies and Certification Practice Statements are key
elements in the management of the Federal PKI. The management body for
the Federal PKI will be the Federal Policy Management Authority.
Similarly domain Policy Management Authorities will manage the polices
for the CAs within individual trust domains.

## Certificate Policies and Certification Practice Statements

The terms Certificate Policy (CP) and Certification Practice Statement
(CPS) are often confused. The following sections describe their use in
the Federal PKI.

### Certificate Policies

The term certificate policy effectively has an evolving legal meaning
and a more or less mechanical instantiation as a field in a certificate.
However, the processing of certificate policies extension has two
different modes, depending on the critical bit in the extension.

X.509 defines a CP as \"a named set of rules that indicates the
applicability of a certificate to a particular community and/or class of
application with common security requirements\"\[X.509 97\]. An X.509 v3
certificate may state one or more certificate policies in the
**certificatePolicy** extension. A **certificatePolicy** extension
contains one or more **policyIdentifier'**s. A **policyIdentifier** is a
unique, registered Object IDentifiers (OID) that represent a certificate
policy in a certificate. Relying parties may use these policies to
decide whether or not to trust a certificate for a particular purpose.
The registration process follows the procedures specified in ISO/IEC and
ITU standards. The party that registers the OID also publishes a textual
specification of the certificate policy, for examination by certificate
users and other parties.

The Model Federal Certificate Policy \[POLA 98\] takes the position that
a certificate policy is essentially a relying party document. A relying
party or an organization of relying parties typically writes a CP that
states the conditions under which a certificate is acceptable to the
relying party for some stated purpose. By including particular policy
OID in the a **certificatePolicy** extension of a certificate, the CA
that issues a certificate represents that it has met the conditions of
that CP in the issuance of the certificate.

In a more CA-centric view of certificate policies, the CA may define any
CP it wishes use to identify the procedures it uses to issue various
certificates. Relying parties may then evaluate these policies to
determine if they meet their requirements.

Mechanically, the processing of the certificate policies field depends
upon whether it is flagged critical or noncritical. When the extension
is flagged noncritical, it simply provides information to a relying
party, to use in making a decision about accepting the certificate. In
the noncritical case, a relying party verifying a certification path
supplies an "initial set" of acceptable certificate policies to his
certification path processing client (he may also choose to accept any
policy). At each step in the certification path processing, the
certificate must contain the OID of one of the policies in the initial
set (or an equivelent policy that has been "mapped" to a policy in the
initial set) or the path verification fails.

When the certificate policies extension is flagged critical, then the
relying party must understand the meaning of at least one of the CP OIDs
in the field, and act in accordance with it. For example, a critical
policy might require that the certificate be accepted only for purchases
shipped to a particular address for amounts of less than \$1,000. There
is no formal language for defining the meaning of a CP. Therefore,
flagging an extension critical will generally limit its use to a
particular application and application specific client software that *a
priori* knows the meaning of the policy.

In the Federal PKI the certificate policies extension will be flagged
noncritical.

### Certification Practice Statement

A Certification Practice Statement (CPS) \[ABA 96\] is a statement of
the practices that a particular CA employs in issuing certificates. A
CPS describes the details of the system used and the practices employed
by a CA to issue certificates. A CPS details the procedures used to
implement the policies identified in the certificates issued by a CA,
including the means used to identify certificate subjects. It also
states the means used to protect the public key of the CA, and the other
operational practices followed by the CA to ensure security. Each
Federal CAs will post its CPS in the BCA Repository, and also post the
CPS in any repository associated with the CA.

### Standardized Outline

There is a standardized outline and list of factors to be considered in
writing a CPS or CP \[PKIX4 98\]. The basic list of topics to be covered
are the same for both a certificate policy and a CPS. The outline
addresses the following major subject areas:

1.  *Introduction:* Identifies who operates and manages the CA (or the
    certificate policy), the users it serves and how to contact it.

2.  *General Provisions:* covers liability, fiscal responsibility,
    governing law, fees and similar considerations

3.  *Identification and Authentication*: deals with how names are
    assigned and identities proofed.

4.  *Operational Requirements*: describes the process for issuing and
    revoking certificates, the records that are kept the audits that are
    performed, and CA compromise, disaster recovery and termination
    provisions;

5.  *Physical, Procedural and Personnel Security Controls*: describes
    the physical facilities, the trusted roles in operating the CA and
    issuing certificates, and the personnel controls on CA/RA personnel;

6.  *Technical Security Controls*: covers cryptographic issues, key pair
    generation, the algorithms used, how private keys are activated,
    protected, and managed, and the technical security considerations
    for CA, RA and end entity systems;

7.  *Certificate and CRRL Profile*: states the rules for the use of
    certificate and CRL extensions;

8.  *Specification Administration*: states how the CP or CPS is
    administered and maintained.

### Assurance Levels

The X.509 standard does not associate certificate policies with
particular assurance levels. However a Government of Canada (GOC)
proposal \[GOC 98\] defines four certificate policies ordered by their
assurance level, for use by the Canadian government. This proposal has
been circulated as a strawman for standardized policies. The GOC
proposes four ordered levels of assurance:

-   *Rudimentary Assurance*

-   *Basic Assurance*

-   *Medium-level Assurance*

-   *High Assurance*

In order to promote interoperability, and the appropriate use of
certificate policies, the Federal PKI will adopt the principle of four
levels of assurance. The Federal PKI will cooperate to establish
consistent standards for these levels to facilitate trustworthy
cross-certification with non-Federal CAs. Ultimately, a broad system of
accreditation for CAs may evolve to enable a national trust framework..
This may occur thorough the actions of an industry association.

Certificates issued within the Federal PKI will contain at least one of
the standard assurance level policy IDs in the certificate policies
extension. Certificates issued by Federal CAs may also contain other,
application specific, policy identifiers.

### Certificate Policy Field Contents

The **certificatePolicies** extension in Federal PKI certificates will
identify the policies that apply to a certificate. The
**certificatePolicies** field will contain the identifier of an
assurance level policy, that states the highest level of trust supported
by this certificate, as determined by the issuing CA and its policy
management authority. The **certificatePolicy\'s** extension will also
contain the OIDs of all the lower assurance levels that the certificate
also satisfies. For example, a certificate issued under a medium
assurance policy will also contain the policy identifiers for the low,
and rudimentary assurance policies, because the medium assurance
certificate should meet the requirements of lower assurance policies.
The certificate would then be acceptable to a relying party who
specified *rudimentary* assurance, *low* assurance, or *medium*
assurance, but not to a relying party who specified only *hig*h
assurance. The **certificatePolicies** extension may also contain other
specific policy identifiers that also apply to the certificate.

*\[Editor's note: the alternative is to include only the highest
assurance level supported by the certificate in the certificate and
expect the relying party to use an initial set with all the higher
assurance levels he would accept. For example a relying party who would
accept a low assurance certificate could use an initial set of low,
medium and high\]*

## Policy Management Authorities

Policy management authorities have purview over the operation of Federal
CAs within a trust domain. Every CA operates under the control of a PMA.
Management authorities approve CA certification practice statements and
certificate policies. Efforts are under way to develop formal criteria
for accrediting CAs. As an accepted framework for CA accreditation
evolves, many or all of the CAs in the Federal PKI may become
accredited.

### The Federal Policy Management Authority (FPMA)

The FPMA is the overall management body for the Federal PKI. When a PMA
wishes to cross certify it's PCA with the Federal BCA, the FPMA will
examine the certification practice statements and certificate policies
used in that trust domain and make a decision about cross certification.
In particular, the FPMA will decide which certificate policies and
policy mappings to include in the certificate issued by the BCA to the
PCA.

The Federal PMA will:

a.  Draft, approve, and maintain (through a change management process)
    Certificate Policies (CPs) and Certificate Practice Statements
    (CPSs) for the BCA (described below). This will support
    interoperability between the BCA and agency CAs and, hence,
    interoperability among the agency CAs. The CPs will support
    interoperability for four levels of assurance (high, medium, basic,
    and rudimentary).

b.  Determine the assurance level(s) at which a Federal agency CA(s) may
    join the interoperable FPKI through the BCA, by comparing the CPs,
    CPSs, and other material submitted by that agency against the
    criteria used to develop the BCA's CPs and CPSs. This comparison
    will consider all relevant objective and subjective elements to
    arrive at an overall conclusion, and will not simply attempt to map
    one set of requirements onto another such that an inability to
    accomplish such mapping equates to non-equivalency.

c.  To the maximum extent practical, attend to the unique operating
    circumstances and needs of Federal agencies, such as those whose
    role is primarily regulatory in nature, or those who focus on law
    enforcement, to ensure that each agency has the greatest opportunity
    to interoperate through the BCA regardless of its principal mission.
    This includes helping to define how those operating circumstances
    and needs may affect the design, operating requirements and
    operating practices of the BCA.

d.  Provide additional support, advice, and assistance to Federal
    agencies in the management of their internal agency PKIs, when
    requested.

### Domain Policy Management Authorities

The CAs in each trust domain will operate under the supervision of a
domain PMA. The domain PMA will approve the certification practice
statements of the CAs within the domain, and the certificate policies
used to issue certificates.

# Transition to an Integrated Federal FPKI

Many Federal CAs will initially be stand alone certificate management
systems that support a particular application. It will be desirable to
use the existing CA for other purposes that require trust paths to other
CAs and their certificate holders. Agencies will not find it cost
effective to operate dozens or hundreds of CAs, each dedicated to a
particular application. Moreover, such isolated CAs can not create a
framework for broad secure interoperation between agencies, or with
state and local governments, business and the public.

A PMA supervises a trust domain of one or more CAs. When the domain
wishes to join the overall Federal PKI, its PMA submits the certificate
policies used in the trust domain and the certification practice
statements of its CAs to the FPMA. The FPMA reviews the material, and
decides if the applicant trust domain qualifies to join the FPKI. It
determines the assurance level certificate policies, and policy mappings
included in the certificate issued by the Federal BCA to the applicant
PCA. The Federal BCA then cross certifies with the PCA.

However there are many possible obstacles to incorporating an existing,
isolated CA and its certificate holders into the FPKI. If the isolated
CA does not use FIPS approved algorithms, then it cannot be incorporated
into the FPKI. It may be necessary for the formerly isolated CA to issue
new certificates to its certificate holders that contain the extensions
required in FPKI certificates (in particular, a **certificatePolicy**
extension containing a PMA approved CP). Certificates that do not use
distinguished names as the subject name may not fit well into the FPKI,
and it may be necessary to reissue certificates with distinguished names
before joining the FPKI. If CAs issue certificates with critical
extensions that are not supported by most federal clients, then this may
create a barrier to effective participation in the Federal PKI. A CA
that expects to participate in the FPKI should support or use a
repository that provides LDAP access. Federal CAs should also use
cryptographic modules validated under FIPS 140-1. The FPMA may also
require other administrative CA operational policy requirements, such as
split knowledge dual control activation of the CA private key.

The FPMA will develop model assurance level certificate policies.
Adoption of the FPMA model certificate policies will facilitate
incorporation of new trust domains into the FPKI, since this will
simplify the evaluation and mapping of certificate policies.

Perhaps more fundamental and difficult to deal with, however, may be
inconsistencies in clients. Clients that cannot process certain critical
extensions identified in the Certificate Profile \[PROF 98\] will not be
interoperable in the FPKI.. FPKI clients should implement the rules for
parameter inheritance discussed briefly in section 3.2 above. Clients
must adequately protect private keys, in accordance with rules to be
established for each Federal Assurance Level, and use FIPS 140-1
validated cryptographic modules.

# Attribute Authorities

An Attribute Authority (AA) issues attribute or attribute delegation
certificates. While attribute authorities may be operated in conjunction
with a CA, they may be entirely separate. Attribute authorities are
associated with privileges, roles and access controls. A CA issues an
attribute authority a signature certificate.

Attributes can be bound in signature certificates. However, when
attributes are bound in signature certificates, then a change in the
attribute requires that the signature certificate be revoked and
reissued. If many attributes are bound in signature certificates, then
revocation rates are likely to be quite high. But reissuing a signature
certificate is comparatively expensive, because it will ordinarily
require the generation of a new key pair. If an individual changes
signature certificates frequently, then finding the right certificate to
verify an old signature, may become problematic. Attribute certificates
allow attributes to be certified independently of digital signature
certificates. They are discussed in Section 3.5 above.

The AA that properly "speaks for" an attribute may be quite unrelated to
the CA that issued the attribute holder's signature certificate. If so,
then a relying party may need to verify two independent certification
paths, one for the signature certificate and one for the attribute
certificate. Verification of attribute certification paths will be more
efficient when the same CA issues certificates to both the AA and the
attribute holder..

The structure and use of attribute certificates are evolving. While it
is likely that AAs will come to play an important role in the FPKI, the
role of attribute authorities and attribute certificates in the FPKI is
a subject for further study.

# Compromise Recovery

Compromise recovery is a significant concern in the PKI. Provisions are
needed to recover from compromises of private keys. This section
summarizes the principles of compromise recovery.

## Compromise of User Keys

Recovery from compromised user keys is the responsibility of the CA that
issued the certificate for the compromised key. The compromised
certificate is added to the next CRL issued by the CA, and to any
indirect consolidated CRL for compromised keys. The client may be issued
a new certificate by the authority if appropriate.

A user may sign a message to the CA that issued his certificate, stating
that the private key has been compromised and requesting that the
certificate be revoked, using the compromised private key. RAs may also
request that CAs revoke certificates issued through their registration
process, if a key compromise is detected.

## CA Key Compromise

Compromise of the private key of a CA invalidates all the certificates
issued by that authority, since it results in the possibility of
certificates forged with the compromised private key. In general,
recovery from the compromise of a CA private key requires:

-   the generation of a new CA public-private key pair;

-   the revocation of all CA certificates for the compromised key;

-   the issuance of new CA certificates for the new key from those CAs
    that have issued certificates to the compromised CA;

-   the issuance of new certificates, signed with the new CA private
    key, to replace the certificates issued with the compromised key;

-   secure distribution of the new public key to all relying parties who
    use this key to start certification paths. Note that this must be a
    "out-of-band" process, since the old, compromised key cannot be used
    to validate the new key.

Since compromise of the CA private key does not itself compromise the
private keys of its subordinates (although it may allow the forgery of
new certificates), it is not, in general necessary to replace the
subordinate public-private key pairs, and the new certificates may
retain the old user public key. However, it is necessary to provide all
subjects of certificates signed with the compromised key with new
certificates and the public key of the CA, by a secure process.

### Root CA Key Compromise

Whenever a CA's public key is used to start certification paths, a
compromised public key requires that all relying parties which begin
their certification paths with that key, must be given the new public
key by some authenticated, but out-of-band process. Therefore, when a
root CA private key in a hierarchical domain is compromised it is
necessary to:

-   revoke all CA certificates for the compromised key;

-   generate a new key;

-   reissue all the certificates issued by the CA under the compromised
    key;

-   obtain new CA certificates to replace the revoked CA certificates;

-   notify all relying parties within the hierarchical domain, including
    certificate holders of certificates from subordinate CAs whose keys
    have not been compromised, of the compromise and distribute the new
    public key in an authenticated manner..

### Subordinate CA Key Compromise

Since the keys of subordinate CAs in hierarchical domains are not used
to start certification paths, recovery from key compromise is
comparatively straightforward. To recover it is necessary to:

-   revoke all CA certificates for the compromised key;

-   generate a new key;

-   reissue all the certificates issued by the CA under the compromised
    key;

-   obtain new CA certificates to replace the revoked CA certificates.

### Peer CA Key Compromise

In a mesh domain, relying parties will generally start certification
paths with the public key of the CA that issued them their certificate.
If the key of a peer CA in a mesh domain is compromised, then it is
necessary to:

-   revoke all CA certificates for the compromised key;

-   generate a new key;

-   reissue all the certificates issued by the CA under the compromised
    key;

-   obtain new CA certificates to replace the revoked CA certificates;

-   notify all certificatholders of the key compromise and securely
    distribute the new CA public key to all certificateholders.

### Bridge CA Key Compromise

Although the BCA key is particularly important to the overall operation
of the FPKI, in some ways the compromise of its key is easier to recover
from than other CAs, since the BCA key is not used to start
certification paths, and does not issue end-entity certificates.
Therefore there is no need for authenticated out-of-band distribution
the new key to a large community of relying parties. However, since the
BCA will hold a certificate from every PCA in the FPKI, there will be a
comparatively large number of CA certificates issued by the various PCAs
to the BCA that must be revoked and reissued To recover from BCA key
compromise the BCA must:

-   notify all PCAs of the compromise and they must revoke all
    certificates they have issued for the compromised key;

-   generate a new key;

-   reissue all the PCA certificates issued by the BCA under the
    compromised key;

-   obtain new CA certificates from the PCAs for the new BCA key.

## RA Key Compromise

If an RA key is compromised, it is possible that user certificates may
have been issued to fictitious users, or with incorrect attributes.
Recovery requires revocation of all certificates issued through the
compromised RA using the compromised key. If the compromise date is
known, then it is only necessary to revoke certificates issued after the
compromise occurred. If the RA has retained complete, uncompromised
records of the users who applied for certificates through the RA, then
new certificates may be automatically issued to users whose certificates
have been revoked. Otherwise, users whose certificates are revoked, must
reapply to the RA to be issued a new certificate.

# Implementation Technologies

## Clients

Availability of PKI client functionality to every Federal information
system and every Federal user is needed. Some users require the
assurance that is best provided by personal hardware cryptographic
tokens. Other users and applications cannot justify the additional
expense of cryptographic hardware and tokens for every client (i.e.,
every PC, every data terminal, every workstation). Entirely software
based solutions are appropriate for many clients and their applications.
Hardware and software based clients must be capable of secure
interoperation.

### Software Implementation

To provide government users with the availability of an affordable suite
of security services (i.e., signature based authentication, integrity,
and confidentiality key exchange, as well as confidentiality for
communications sessions or messaging), the PKI, in combination with
clients that use its certificates, will:

-   provide the following security services:

```{=html}
<!-- -->
```
-   public key digital signatures for:

```{=html}
<!-- -->
```
-   authentication;

-   integrity.

```{=html}
<!-- -->
```
-   certificate or public key based symmetric key exchange/agreement
    for:

```{=html}
<!-- -->
```
-   messaging confidentiality;

-   communications session confidentiality;

```{=html}
<!-- -->
```
-   provide confidentiality using symmetric key encryption.

```{=html}
<!-- -->
```
-   allow clients to be implemented entirely in software;

-   use publicly disclosed algorithms that need not be protected;

-   be able to operate on single user computer systems that have not
    been validated to conform to any trust criteria.

Technical policies for implementing PKI client software cryptographic
modules and storing private keys are stated in ???. The implementation
of client cryptographic modules affects the level of assurance accorded
to certificates and signatures. Accordingly some high assurance policies
for issuing certificates will require hardware cryptographic tokens.

### Hardware Implementation

Alternatively, user keying material may be retained in trusted hardware
cryptographic modules and signatures or session keys generated in that
trusted module. Such modules will not export user signature private
keys. Access to the cryptographic functionality of the module may be
protected by passwords, or possibly by other means such as biometrics.

The PKI may also support algorithms that are not publicly disclosed and
for which software implementations are not authorized. Such algorithms
will be implemented in trusted cryptographic modules.

Some high assurance policies for issuing certificates will require use
of hardware cryptographic tokens.

## Authorities

The systems used by CAs to sign certificates will require a high level
of assurance. Technical policies governing the assurance required in the
implementation of CAs will be stated in ????.

# Interoperation

The PKI will support secure communications with business, other branches
of the Federal Government, the public, and state and local governments,
as well as between Federal departments and agencies. Interoperation may
also be required with Federal users of Type 1 cryptography (cryptography
used to protect classified National Security information). The Federal
PKI will therefore support and interoperate with a broad range of
technologies, as appropriate, including commonly used technologies that
are not approved for use to protect UBS communications between Federal
users. \[INT 95\] contains a more detailed treatment of interoperation
issues.

## Interoperation with the Type 1 Infrastructure

The primary burden for interoperation between Type 1 users and the
Federal PKI rests with the Type 1 users:

-   Type 1 Certificate Authorities may also issue PKI certificates;

-   Type 1 tokens and modules may also support PKI certificates and
    algorithms;

-   the impact of the PKI design on the ability of the existing Type 1
    infrastructure to support the PKI will be considered in the design
    of the PKI.

## Interoperation with non-Federal Users

### Algorithms

The digital signature algorithms that are in wide commercial use will
also usually be "FIPS-approved" for use by Federal agencies. The basic
principle of the FPKI for interoperation between users of different
algorithms is the "end system" approach. It is explained in more detail
in Section 6.3 above. The basic principles of interoperation with
non-Federal users are:

-   The Federal PKI supports only certificates that use FIPS approved
    algorithms. Federal users who require signature capability using a
    non-approved algorithm must waive the FIPS;

-   Non-Federal users are expected to be able to verify signatures using
    FIPS approved algorithms;

-   Federal PKI users may verify signatures of non-Federal parties, in
    accordance with their security policy. If the algorithms used are
    not FIPS approved, a FIPS waiver may be required;

-   In general, it is the algorithm used in the key management
    certificate of the destination of an encrypted message that
    determines the key management algorithm used to establish the key
    the message encryption key.

### Cross-Certification

The Federal PMA will approve BCAcross-certification with non-Federal
CAs. The optional policy mapping, path length constraint, and subtrees
constraint extension fields of the X.509 v3 certificates may be used by
CAs to constrain the use of cross certification links with non-federal
CAs and infrastructures.

### Certificates Issued to non-Federal Users

Federal CAs may issue end-entity certificates to non-Federal users in
accordance with their CPS. Name space constraints in the BCA
certificates may, however, limit propagation of trust to certificates
issued to subjects with non-Federal names.

# Records and Archives

While the validation of digital signatures, and the certification paths
that support them is comparatively straightforward at the time the
signatures are executed, later validation becomes increasingly
problematic. Validation of digital signatures can be broken down into
three distinct problems, or regimes, depending upon the time that has
elapsed since the signatures were executed:

1.  *near term*: validation while all the certificates and CRLs required
    to validate the signatures are current and generally available;

2.  *intermediate term*: validation after expiration of one or more of
    the certificates required to validate the signature, but while the
    cryptography used in the signatures is still secure;

3.  *archival:* validation indefinitely, and in particular after the
    time when the cryptography used is no longer secure; that is
    validation after the time when it would be practical to derive
    private keys from public keys, or to generate hash collisions.

## Near term 

It is the responsibility of CAs to make available in repositories all
current certificates and the current CRL. This will provide the
information needed to validate any current signature, before any of the
certificates in its certification path have been revoked or expired.

## Intermediate term

The intermediate term begins when one or more of the certificates needed
to validate a signature expires, and lasts until the cryptography used
for the signatures is no longer secure. Since the cryptography is still
considered secure, then a strong validation of the signature is still
possible if the needed certificates and CRLs can be obtained. If the
signatures are valid and the certification paths of the signatories were
valid at the time the signature was executed, then the signature is
verified.

Digital signatures, however, do not reliably date a signed document.
Therefore it is easy for signatories to predate and sign a document,
just as it is with handwritten signatures. If the actual date of a
digitally signed document is at issue, then this must be established by
some other means. One such means would be a dated signature by a trusted
third party, (a trusted time stamp). The trusted time stamp may be
applied to a hash of the signed document; it is not necessary for the
time stamp service to see the document itself. Nor, in principle, is it
necessary for the service to record the time stamp transaction. Other
approaches to the proof of the age of documents would be to publish the
hash of the document in some publication of record (e.g., the Commerce
Business Daily, the New York Times, etc.), or to enter a copy of the
document in some archive that would take custody of the document, and be
able to attest to the time at which the document was entered into the
archive.

However, in the intermediate term, a straightforward automatic
validation of the certification paths will not occur, since one or more
of the needed certificates has expired. Human intervention may be needed
to determine the date of the signature. The support that will be
provided by certification path processing software for retrospective
validations is unclear, but it may be necessary, for example, for the
human user to override the path processor to tell it to accept expired
certificates. Ideally, certification path processing logic would include
a way to set a "signature date" parameter, and evaluate the validity of
signatures and the certification path supplied as of that date, to
support retrospective signature validations.

A trusted digital notary might be used to simplify the process of later
validating signatures. Such a notary would examine a signed document (it
is not necessary for the notary to see the document text itself, but the
notary must see the document hash and all the signatures) and validate
all the signatures, then "notarize" the document by signing the document
hash and signatures, plus a time stamp and a notice attesting that the
signatures had been validated. This might simplify the records that need
be retained to allow later validation (particularly documents with
multiple signatures) if the notary undertook to maintain and make
available a trustworthy long term record of its own certificates.

## Archived Signatures

Archival storage is indefinite, and may extend long past the time when
the cryptography used to sign documents is still secure. All the issues
about validation that apply to intermediate term signature validation
apply to the archival case. Moreover, future advances in computing are
likely to make it practical to generate private keys from public keys or
hash collisions for current digital signature and hashing algorithms,
where this is infeasible today. Therefore validation of archived
signatures cannot rely solely on the cryptography, even when complete
certification paths are available.

The approaches to archival validation require that the signed document
be turned over to a trusted archive that can be trusted to keep a true
copy of signed document[^2], while the cryptography remains secure.
There are several variations:

-   The document is entered into the archive with all the necessary CRLs
    and certificates needed to validate the signatures. Since the
    archive is trusted to maintain a true copy, any forgery must have
    occurred before entry into the archive. But if a forgery were
    impractical at the time of entry into the archive, and the
    signatures are valid, then the signatures can be judged valid.

-   The document is first notarized as described above, then entered
    into the archive. Records to substantiate the public key of the
    notary must also be archived;

-   The archive itself validates the signatures and acts as a notary at
    the time the document is entered into the archive; In this case a
    simple unsigned notation that the signatures had been validated by
    the archive would suffice, since the archive is already a trusted
    custodian for the document.

Notary and suitable validated archival services for digitally signed
documents are not yet available.

## Responsibilites

Federal CAs will make their certificates and CRLs available through
repositories while they are current. They will maintain publicly
available records of the certificates issued and CRLs for a period of
TBD years after their expiration. The Bridge CA will make authentic
copies of the public keys they use to issue certificates available
indefinitely However, CAs are not necessarily permanent institutions and
the long term responsibility for preserving the records needed to
validate signatures indefinitely rests with signatories or relying
parties, who may retain or archive the certification paths needed to
substantiate signatures, or to have signed documents timestamped or
notarized as required.

# Servers and Agents

The FPKI infrastructure will be augmented by a variety of
security-related servers and agents. Some security related servers and
agents may be operated by the Federal PKI, or be used by the Federal
PKI. The important services that have been identified are described in
some detail below. The following list is not exhaustive, and a need for
additional kinds of security servers and agents may be identified. These
servers or agents will generally be trusted users with certificates
issued by some appropriate authority. They will support the needs of
users, or, in some cases, of the Federal PKI hierarchy itself. In this
section these servers are described in terms, such as digital notary and
document recorder that approximate services now available for paper
documents. The sections below describe some of the services that may be
provided. This aspect of the infrastructure is not well understood, and
the actual digital servers that emerge may be combined in other ways and
given other names.

## Repositories

The PKI will use repositories to make certificates and CRLs available.
Repositories are on-line entities that may have high availability
requirements, however they conceptually are not trusted entities. It is
the signature of a CA or an AA on the data held in repositories that
validates the data, not the fact that the repository held the data.

In many cases repositories will be directories that provide access
through the Lightweight Directory Access Protocol (LDAP) \[RFC1777\],
however other World Wide Web oriented alternatives may also be
supported. Repositories may be operated by a CA, or may be a part of a
separate directory that serves broader purposes than just supporting the
PKI.

The LDAP standard is being extended and many repository general issues
remain unresolved. It is unclear whether a broadly based X.500 based
directory service will ever exist on a national scale, so that directory
servers use the Directory Service Protocol (DSP) to resolve queries. An
alternative, supported by LDAP is referrals, where a directory server
that is unable to satisfy a query, refers the user agent to another
directory server. Another general issue is the extent to which directory
access is available to parties outside the organization that operates
the directory. In many cases firewalls may not pass directory queries,
and directories may contain information that is proprietary to the
organization. Therefore some organizations may have an internal
directory and a "boundary directory" that contains only nonproprietary
information located outside firewalls.

Repositories contain several PKI related attributes:

-   End-entity certificates - these may or may not be proprietary; some
    organizations and agencies may not wish to make the names of some or
    most employees openly available;

-   CA certificates - these should never be proprietary, and should be
    made as widely available as possible in directories;

-   CRLs - these should generally be openly available in the Federal
    PKI, but there may be cost recovery PKI business models where
    repositories charge relying parties for access to CRLs. This should
    not normally be the case for access to the CRLs issued for Federal
    entities;

-   Certificate Policy definitions - in the Federal PKI certificate
    policy definitions should be freely available in repositories. This
    may not always be the case for the policies of commercial
    organizations, which may feel that they contain proprietary
    information. In these cases organizations that cross-certify may
    disclose their policies only to the policy management authorities of
    the cross certified domains.

-   Certification Practice Statements - in the Federal PKI CPS should be
    freely available in repositories. Again, this may not always be the
    case for nonfederal CAs.

The BCA directory will contain all the CA certificates and
cross-certificates issued to or issued by all the CAs in the Federal
PKI. The Bridge CA repository will also contain the ARL for all Federal
CA certificates. The bridge CA may also contain "shadow copies" of
certificates for end-entities and CRLs issued by Federal CAs. There will
be no restriction on access to the Bridge CA repository.

## Digital Notary Servers

The digital notary server provides a service roughly equivalent to a
notary public. Digital notaries operate on the message digests of
digital documents and the digital signatures that may be applied to
those documents, rather than the documents themselves.

The term "notarization" has peen traditionally applied to at least four
functions often lumped under the rubric of "notarization" \[BARASSI\]:

-   Administering oaths or declarations;

-   attesting to or acknowledging acts;

-   certifying facts;

-   authenticating the legality of acts.

A discussion of these functions in a legal sense is beyond the scope of
this CONOPS. However there are two services that a digital notary may
offer that are of technical interest to a PKI:

-   to add a time-date stamp to a message digest of a document and sign
    the message digest plus the time-date stamp. This time-date stamp
    provides proof that the document existed at a particular point in
    time and is the date-time stamp service of Figure 1;

-   to verify the signatures applied to a signed document and generate a
    signed, dated notarization statement that includes the message
    digest of the subject document and the names of each of the
    signatories. If signed documents that are so notarized, then it is
    sufficient to verify the only signature of the notary to verify the
    signatures of the signatories. This is particularly valuable when
    signed documents are to be saved in archives for long periods.

The certificates of notaries should be registered in a permanent
archive. The notary keeps a log of the notarizations but not copies of
the documents.

## Digital Recorder Servers and Archives

The digital recorder server provides the service of a document recorder,
that is a document archive where documents may be registered for
safekeeping and to make a permanent record. The digital recorder
permanently retains, under its sole control, a dated copy of digital
documents registered with it. The digital recorder will, upon request,
issue a signed copy of recorded documents, stating the date of
registration.

Among the uses of digital registries are the key (or certificate)
archiving service of Figure 1. They can provide a repository for expired
certificates, to allow the verification of signatures on old documents.
If digital documents are to replace paper documents, then it must be
possible to verify digital signatures long after the certificates used
to sign the documents have expired, and after the authorities that
issued the certificates have ceased to exist. To be useful for this
purpose, a digital registry must be a permanent archive, independent of
particular authorities.

The verification of the authenticity of signed digital documents, long
after they were signed, presents particular problems. The advantage of
digital documents in archives is that they can be copied as often as
needed without any alteration or degradation, which is generally
impossible with analog records. This allows a perfect copy to be
maintained through many generations of copies. The disadvantage of
digital documents for archival purposes is that, as a practical matter
digital storage media have a short useful life, and documents must be
copied frequently to maintain them \[Rothen 95\]. Therefore, the
physical forensic evidence that may help to authenticate original old
paper documents is not available for digital documents. Moreover, we
must assume that any presently secure digital signature technology may
eventually fall to advances in computer power and cryptanalysis.

Since any present digital signature technology may ultimately be
compromised by future progress in computing power and cryptanalysis, the
validity of recorded documents can not primarily depend on any digital
signature made by the recorder at the time of document registration.
Rather the validity of recorded documents depends on the physical
control of the registered copy of the document by the trusted recorder.
If a recorder has retained an accurate dated copy of a signed digital
document, if a true copy of the signer's certificate exists, and if it
were impractical to forge the signature at the time the document was
registered, then verification of the signature is meaningful even after
it becomes possible to forge the signature.

For truly long term verification of certificates and signatures, it is
not sufficient to register only the certificates of the authorities
themselves, because we must assume that it will eventually be possible
to derive the authority's private key for any current public key and
forge a certificate. Registering all certificates issued by an authority
would allow detection of certificates forged at a later date. Similarly,
signed digital documents, whose authenticity may be important at a much
later date, must registered contemporaneously with their signing. Then,
knowing from the registry:

1.  the contents and signature of a document that was registered on a
    given date, and,

2.  the complete certificate path supporting the signatures;

It is possible to verify the authenticity of the document at a later
time, even after it is practical to derive the private key from the
public key.

However, very long term (i.e., for centuries) digital archive services
are problematic, due to the rapid rate of change of digital media,
applications and file formats, and the uncertain storage lifetimes of
digital media \[Rothen 95\]. Any presently practical digital archive
must periodically copy data onto new media, for even where a storage
medium has a long lifetime, data readers for the storage medium will
become unavailable after newer media come into use. This means that a
requirement to maintain long term archives of large numbers of public
key certificates is potentially burdensome. Unless registries are funded
from public tax moneys, they will need to charge a registration fee
sufficient to maintain copies of the documents in perpetuity.

## Digital Certified Delivery Servers

Proper maintenance and design of the PKI makes it difficult for users to
repudiate their own signatures. While digital nonrepudiation can be
accomplished by cooperating parties without a trusted server,
cooperation is not always assured. Certified delivery servers provide
services analogous to those of process servers and certified or
registered mail. A digital nonrepudiation server provides a trusted
third party that can verify that a digital document was in fact
delivered to its intended recipient, or that a good faith, best effort
was made to deliver the document, even without the cooperation of the
intended recipient. The Federal Government may need nonrepudiation
servers, but they are not needed to support the operation of the PKI
itself.

## Ticket Granting Agents

Ticket granting agents issue tickets that grant limited-time access to
information resources. Although now widely used with symmetric key
rather than public key authentication systems, they can also be used
with public key technology to centralize management of access control.
In effect, a Registration Authority (RA) that does not issue
certificates itself, but vouches for the identity of prospective
certificate holders to a certification authority, is a ticket granting
agent.

## Key Recovery Agents

\[To be Supplied\]

**List of Acronyms**

AA Attribute Authority

ARL Authority Revocation List

BCA Bridge CA

CA Certification Authority

CKL Compromises Key List

CRL Certificate Revocation List

CSOR Computer Security Objects Register

FPMA Federal Policy Management Authority

FPKI Federal PKI

KMI Key Management Infrastructure

KRA Key Recovery Agent

LDAP Lightweight Directory Access Protocol

MISSI Multilevel Information Systems Security Initiative

OCSP Online Certificate Status Protocol

OID Object IDentifier

PCA Principal CA

PMA Policy Management Authority

RA Registration Authority

PMA Policy Management Authority

PKI Public Key Infrastructure

UBS Unclassified But Sensitive

**References**

\[ABA 96\] Information Security Committee Electronic Commerce and
Information Technology Division Section of Science and Technology
American Bar Association, *Digital Signature Guidelines*, August 1,
1996.

\[BARASSI\] Barassi, Theadore, "Public Key Registration and
Certification and Authentication of International Legal Transactions,"
http://www.abanet.org/scitech/ec/cn/cybernote.html

\[CHOK\] Chokhani, Santosh, *A Security Flaw in the X.509 Standard*, in
the Proceedings of the 19^th^ National Information Systems Security
Conference, Volume 2. October 22-25, 1996.

\[FIPS 46\] FIPS PUB 46-2, *Data Encryption Standard (DES)*, NIST, 1993.

\[FIPS 180\] FIPS PUB 180, *Secure Hash Standard*, NIST, 1993.

\[FIPS 140\] FIPS 140-1, *Security Requirements for Cryptographic
Modules*, NIST, 1994.

\[FIPS 185\] FIPS PUB 185, *Escrowed Encryption Standard (EES)*, NIST,
1994.

\[FIPS 186\] FIPS PUB 186, *Digital Signature Standard (DSS)*, NIST,
1994.

\[FR 97\] NIST, "Announcing Plans to Revise Federal Information
Processing Standard 186, Digital Signature Standard," *Federal
Register*, May 13, 1997 pp. 26293-26294.

\[Garf 95\] Simon Garfinkle, PGP: Pretty Good Privacy, O'Reilly &
Associates, Inc., 1995.

\[GOC 98\] Working Draft, *Digital Signature and Confidentiality
Certificate Policies for the Government of Canada Public Key
Infrastructure*, V2.0, August 1998.

\[ISO WD 98\] "Working Document on Amendments for Certificate
Extensions" from the Collaborative ITU and ISO/IEC meeting on the
Directory, Phoenix Arizona, 26-30 January 1998.

\[PKIX1 98\] Internet Draft, *Internet Public Key Infrastructure: X.509
Certificate and CRL Profile*, \<draft-ietf-pkix-ipki-part1-07.txt\>, R
Housley, W. Ford, W. Polk and D. Solo, July 28, 1998. Available at:
http://www.ietf.org/html.charters/pkix-charter.html

\[PKIX4 98\] Internet Draft, *Internet Public Key Infrastructure Part
IV: Certificate Policy and Certification Practices Framework*,
\<draft-ietf-pkix-ipki-part4-03.txt\>, S. Chokhani and W. Ford, April ,
1998. Available at: http://www.ietf.org/html.charters/pkix-charter.html

\[OCSP 98\] Internet Public key Infrastructure Online Certificate Status
Protocol - OSCP, OCSP \<draft-ietf-pkix-ocsp-05/txt\>, M. Myers, R.
Ankney, A. Malpani, S. Galperin, and C. Adams, August 1998, available
at:: http://www.ietf.org/html.charters/pkix-charter.html

\[POLA 98\] Model Certificate Policy, Part A - Introduction and
Approach, FPKI Legal/Policy Working group, Discussion Draft, March 25,
1998, revised July 8, 1998, available at
http://gits-sec.treas.gov/model_cert_policy_intro.htm

\[POLB 98\] Model Certificate Policy, Part B - The Model Certificate
Policy, FPKI Legal/Policy Working group, Discussion Draft, March 25,
1998, revised July 8, 1998, available at
http://gits-sec.treas.gov/model_cert_policy_cert.htm

\[PROF 98\] TWG-98-07, *Public Key Infrastructure (PKI) Federal X.509
Certificate Profile,* March 9, 1998, available at:
http://csrc.ncsl.nist.gov/pki/

\[RFC1777\] RFC 1777, *Lightweight Directory Access Protocol,* Ed
Yeoung, Howes, and Killie. March 1995.

\[RIV 78\] Rivest, Ronald L., Adi Shamir and Leonard L. Adleman, "A
Method for Obtaining Public Key Signatures and Public Key
Cryptosystems,*" Communications of the* *ACM,* 21 (1978).

\[Rothen 95\] Rothenberg, Jeff, *"Ensuring the Longevity of Digital
Documents,"* Scientific American*,* Vol. 72, no. 1, Jan 1995, pp.
42-47*.*

\[TWG-98-44\] Burr, W., "Multiple Algorithms and the Bridge CA Concept,"
24 July 1998.

\[X.500 93\] CCITT Recommendation X.500*, The Directory*, *1993.*

\[X.509 97\] CCITT Recommendation 509*, The Directory: Authentication
Framework*, *1997.*

\[X9.45 97\] Working draft, *X9.45-199x: Enhanced Management Controls
Using Digital Signatures and Attribute Certificates*, June 24, 1997.

\[X9.31\] Working Draft American National Standard X9.31-199x, Public
Key Cryptography for the Financial Services Industry: The Reversable
Digital Signature Algorithm,

\[X9.62\] Working Draft American National Standard X9.62-199x, Public
Key Cryptography for the Financial Services Industry: The Elliptic Curve
Digital Signature Algorithm, June 21, 1996

[^1]: One exception is the self-signed certificate of a trusted CA,
    which states its public key, and is distributed by some secure
    "out-of-band" mechanism. Since this public key is not protected by
    its own signature, and is used to validate all other signatures, it
    should have protection to ensure its integrity (although not its
    secrecy).

[^2]: While the TWG briefly discussed periodic resigning of documents as
    a technique for ensuring that a true copy had been kept, it came to
    the conclusion that the procedures that ensure that a true copy is
    kept could also be administrative and procedural, and that archives
    have long been trusted to maintain true copies of documents without
    any cryptographic means.