**[Federal Agency Use of Public Key Technology]{.underline}**

**[for Digital Signatures and Authentication]{.underline}**

**1.0 [Purpose]{.underline}**

This document responds to direction by the Office of Management and
Budget \<cite FR\> for the Federal Public Key Infrastructure Steering
Committee to publish technical guidance on the use of public key
technology for digital signatures or authentication. (Note: the
distinction between the use of public key technology for digital
signatures and for authentication is drawn because the latter can be
done without the former. Standards such as X.509 provide for that
functionality. However, most applications which use public key
technology employ digital signatures for user authentication.)

The guidance in this document is intended to assist Federal agencies
considering the use of public key technology for digital signatures or
authentication over open networks such as the Internet. This includes
communications with other Federal or non-Federal entities, such as
members of the public, private firms, citizen groups, and state or local
governments. The document encourages the thoughtful use of public key
technology by Federal agencies as set forth in guidance published by the
Office of Management and Budget implementing the Government Paperwork
Elimination Act (GPEA) \<FR cite\>. It also amplifies upon principles
contained in the GPEA guidance and separately in *Access with Trust*
issued in September 1998 by the Office of Management and Budget, the
National Partnership for Reinventing Government, and the Government
Information Technology Services Board. Finally, it discusses briefly the
government-wide Public Key Infrastructure (PKI) which is developing to
enable applications programs to effectively use public key technology
across Federal agencies.

This document includes specific questions and issues which an agency
should consider to: (1) evaluate potential applications of public key
technology involving digital signatures or authentication, considering
whether the application warrants such use as set forth in the OMB GPEA
guidance; and (2) implement those applications selected. The questions
and issues address technical, business, policy and legal aspects, and
they are fashioned to inform all agency elements who play a part in
evaluating how public key technology may be applied to agency
operations. While many of the factors addressed also are relevant to
other (non-PKI) technologies used to support electronic transactions
(e.g., Personal Identification Numbers), the focus of this document is
the use of public key technology for digital signatures or
authentication over open networks.

**2.0 [Background]{.underline}**

Individuals (including Federal employees) or other entities interacting
with Federal agencies electronically have a right to expect that with
reasonable assurance, and when an application warrants it:

\(1\) the information sender and recipient both will be identified
uniquely so the parties know where the information is coming from and
where it is going (authentication);

> \(2\) the transmitted information was not altered deliberately or
> inadvertently (data integrity);
>
> \(3\) there is a way to establish that the sender's identity is
> inextricably bound to the information (technical non-repudiation); and
>
> \(4\) the information will be protected from unauthorized access
> (confidentiality or privacy). It should be noted that this
> functionality is recited simply for completeness since public key
> technology (and a Public Key Infrastructure) also provides it; it is
> not covered by this guidance.

In other words, two parties who may not know each other should be able
to communicate reliably through electronic means, with confidence that
their communication is protected and their identities established
(neither party is being impersonated) when appropriate, and with proper
assurance that their communication cannot be repudiated after it has
occurred.

Public key technology enables applications software (programs) to meet
these requirements. While a full description of the technology and how
it works is beyond the scope of this document, a brief description which
may be helpful can be found in *Access with Trust* (available at
http://gits-sec.treas.gov).

Public key technology has a firm theoretical underpinning and a growing
spectrum of applications, but its use represents unexplored territory
for many Federal agencies. Natural reluctance may exist until the "bugs
have been shaken out" by someone else. *Access with Trust* and a more
recent report, *The Evolving Federal Public Key Infrastructure* \<to be
published\>, describe how that "shaking out" process is well underway
and succeeding in making public key technology in general, and digital
signatures in particular, useful to Federal agencies today. Federal
agencies contemplating public key technology will benefit by proceeding
sooner than later, to participate in building the Federal portion of the
evolving world-wide PKI around their needs, rather than later having to
adjust those needs to however the framework evolves.

Even where an agency elects to postpone employing the technology in its
applications software, entities with which it interacts may begin using
the technology for their own applications. For example, this is
happening already in the automobile industry through the Automotive
Network Exchange (ANX) and the International Computer Security
Association (ICSA), in the financial sector through the National
Automated Clearing House Association and through multi-bank consortia
(one example is Identrus), and in the health care sector through
hospitals, insurers, pharmacists, and others. The best way for Federal
agencies to become full participants in the construction of the
framework is to apply public key technology *now* to substantive agency
work, just as companies in the industrial, financial, and health care
sectors are doing for their spheres of interest.

As with any investment in new technology, the agency needs an
appropriate business case linked to its mission and goals. An agency
must ask itself whether the function to be supported needs to be done,
whether it should be performed within the agency or through contractors
or outsourcing, and whether the processes to execute the function need
to be re-engineered. In many cases, the use of digital signatures may
require transforming agency business processes to a new service delivery
model, involving some degree of process re-engineering. Rarely can
digital signatures simply be "plugged in" or "switched on."

The public may harbor concerns about electronic transactions which this
technology may not initially alleviate. Those concerns may be amplified
because people are naturally uncomfortable with change, because public
key technology is not yet widely understood by the public at large, and
because it has not yet been perceived as having demonstrated
"trustworthiness." While this guidance explores how to deal with these
concerns, the best approach entails developing a public information plan
or some comparable instrument covering the agency\'s design,
implementation and presentation of the electronic application. The plan
would seek stakeholder input early in the process of developing
electronic transaction systems using public key technology, and it would
establish and communicate the strengths which the new approach brings to
ensure security and privacy, promote the availability of electronic
communications, and reduce risks associated with their use.

The Social Security Administration, which interacts with the public far
more than most Federal agencies, published a report on this subject in
September 1997 called \"Privacy and Customer Service in the Electronic
Age" (available on-line at http://www.ssa.gov). The report expands upon
the issues discussed above and can help agency officials better
understand how to deal with public concerns over electronic
interactions.

As cited earlier, public key technology and digital certificates (which
bind the identity of a party to his, her or its public key) can be used
to support authentication, encryption, non-repudiation, and data
integrity. A range of services are available through the use of a PKI,
for example:

-   A user can authenticate himself or herself to another party,
    typically a server, by digitally signing a challenge phrase
    (supplied by the server) with the user's private key. The server can
    use the public key in the user's digital certificate to validate the
    user's signature on the challenge phrase and thus authenticate the
    user.

```{=html}
<!-- -->
```
-   Web servers frequently have digital certificates issued to them
    which can be used to authenticate the server to a user and create an
    encrypted communications session that can be used to protect any
    shared secret information including Personal Identification Numbers
    (PINs) or passwords. Such an "encrypted session" prevents a
    malefactor from taking it over (sometimes called "hijacking") after
    the session has begun.

```{=html}
<!-- -->
```
-   When both web servers and clients have digital certificates, mutual
    strong authentication can be achieved -- each party can authenticate
    itself to the other.

```{=html}
<!-- -->
```
-   A document or file may be digitally signed using a party's private
    key, creating a "digital signature" that is stored with the
    document. At a later date, anyone else can validate the signature on
    the document using the public key from the digital certificate
    issued to the signer. Validating the digital signature not only
    confirms who signed it, but also ensures that there have been no
    alterations to the document since it was signed.

```{=html}
<!-- -->
```
-   In like fashion, an e-mail message may be digitally signed using
    commonly-available client software that implements an open standard
    for this purpose, such as Secure Multipurpose Internet Mail
    Extensions (S/MIME). Validating the signature on the e-mail can help
    the recipient know with confidence who sent it, and that it was not
    altered during transmission.

The X.509 Version 3 standard for digital certificates provides specific
bits which can be set in a certificate to ensure that the uses to which
the certificate should be put (signature, authentication, encryption)
are identified in the certificate. Whether an applications program
honors these bits and the X.509 standard in general should be
established prior to its purchase.

Finally, although this document focuses on the use of public key
technology for digital signatures and authentication, it is important to
note that once a PKI is established for those purposes, the same PKI can
be used to provide end-user to end-user confidentiality or privacy
through the use of encryption certificates. That is an example of the
extensible nature of public key technology.

**3.0 [Access Certificates For Electronic Services]{.underline}**

Agencies wishing to employ digital certificates should first consider
availing themselves of the capabilities provided by the Federal
Technology Service of the General Services Administration through
contracts under the Access Certificates for Electronic Services (ACES)
program. ACES is a very convenient contract vehicle for several
purposes: (a) obtaining PKI services (including certificate issuance
from a vendor PKI established especially for the purpose) for
transactions with the public or with agency trading partners; (b)
obtaining vendor services to set up a vendor or agency-run
special-purpose PKI covering agency employees, contractors, or the
public; and (c) obtaining vendor services to PKI-enable applications
programs to accept certificates regardless of source. In late 1999, the
ACES program placed three contracts with large consortia which included
leading PKI and IT firms, and which provided competitive prices for
digital certificate issuance and use. Agencies can make use of the ACES
contracts simply by entering into an interagency agreement with FTS/GSA,
and then let FTS manage the contract. Agencies are encouraged to
consider this alternative as they review the guidance contained in this
document, and especially inquire as to the costs associated with
enabling applications to use ACES, because the total costs associated
with employing ACES may be well below the agency threshold for saving
money through the use of electronic transactions requiring strong
authentication. Further information and points of contact can be found
at http://www.gsa.gov/aces.

**4.0 [Using This Document]{.underline}**

Federal agency officials need to determine if the use of public key
technology for digital signatures and authentication makes good business
sense. This determination often needs to be made on an application by
application basis, recognizing that once a PKI is in place, it can serve
multiple applications. This document contains questions which Federal
agency officials should ask themselves in evaluating a potential
application. The questions cover five main elements: (1) the benefits
derived from implementing and using digital signatures for an
application; (2) the costs; (3) the risks; (4) how to compare the
benefits, costs, and risks to arrive at a decision; and (5) what issues
to consider in implementing the decision. Associated with each question
is additional material (labeled "discussion") to help provide more
complete context. The questions implicate policy, technical, business
and legal elements which may be more relevant to an agency's technical
staff than to its senior policy or decision makers, or vice versa. Where
this is likely to be the case and it is not clear from the context, the
discussion material related to the question so indicates.

The questions (each of which starts on a new page) are presented in an
order that anticipates how an agency may evaluate a potential
application of public key technology involving digital signatures or
authentication to an existing electronic process. Since one size cannot
fit all, agencies certainly have the discretion to deal with the
questions in a different order. Moreover, there may be circumstances
where no electronic process currently exists but may be developed; in
that case, the questions should also help to provide insight in
evaluating the potential application of this technology as the
electronic process is designed. Finally, where the agency may be
considering the use of other mechanisms such as PINs to serve some of
the functionality public key technology could provide, the questions
should help in such a comparison.

**5.0 [Summary]{.underline}**

Many Federal agencies are implementing (or recognizing opportunities for
implementing) applications which use public key technology to improve
the delivery of services to outside parties and improve work processes
with existing business partners. Recognizing opportunities, and seizing
them in a disciplined, thoughtful way, can require a substantial leap
with significant risk. Fortunately, agencies wishing to seize such
opportunities are not alone. They may call upon the experience and
expertise represent by the many agencies that participate in the Federal
PKI Steering Committee, the activities of which are reported in *Access
with Trust* and *The Evolving Federal Public Key Infrastructure* and on
the Steering Committee web site, http://gits-sec.treas.gov. Several of
these agencies have already succeeded in applying the technology to a
wide spectrum of applications. It is hoped that this guidance document
will further support agencies considering when and how to implement
applications using public key technology for digital signatures and
authentication.

***Question 1**. What are the benefits, direct and indirect, financial
and non-financial, objective and subjective, of using digital signatures
for the proposed application?*

**D1.0 [Discussion]{.underline}**

The context of this question includes converting existing electronic
processes to use digital signatures; developing electronic processes
using digital signatures where the existing process is manual; and
considering external, inter- and intra-agency applications for the use
of digital signatures. Further, as the question implies, benefits come
in many forms. It is important for all of the benefits to be identified
so that a fair comparison of costs and risks, which are often more
immediate and quantifiable, can be made. (For purposes of this
discussion, "electronic processes" employ application software, so using
digital signatures with an electronic process is tantamount to enabling
the application software to accept such digital signatures. That, in
turn, requires the application software to interact with the PKI under
which the digital certificates are issued to end users, who are
sometimes referred to as "subscribers.")

Many of the benefits cited below accrue from the use of electronic
processes, rather than from the [per se]{.underline} use of digital
signatures in those processes. However, as discussed above, public key
technology creates a trusted environment which promotes the use and
growth of *all* electronic processes, so it is appropriate to attribute
these benefits in substantial measure to public key technology.
Potential benefits which should be evaluated include:

**D1.1 [Time Savings]{.underline}**

Use of electronic processes and digital signatures can reduce the time
required to process information collections from sources inside or
outside the agency. These may involve claims for financial or other
benefits, bids on procurements, or simply inquiries involving private or
proprietary information. Reduced response time benefits both the agency
(by reducing per-transaction processing costs) and the recipient, the
latter in ways which it may be difficult to measure, but which can be
categorized as \"increased responsiveness of government to its
citizens."

**D1.2 [Cost Savings]{.underline}**

The long-term cost of performing agency business (per the agency's
budget request to Congress) may be reduced, by decreasing transaction
time and cost as cited above, increasing accuracy and productivity (thus
making staff available for reassignment to other agency priorities),
reducing maintenance or operating costs associated with paper-based
systems, and by providing a more trusted means of allowing users to pay
for services provided (and the level of service desired) where
appropriate. These effects become more pronounced as the number of
transactions increases.

**D1.3 [Enhanced Service]{.underline}**

The availability and accessibility of agency processes to users inside
the agency, to the public, and to other outside entities is enhanced
owing to the strong authentication which digital signatures provide,
thus allowing the agency to supply broader service and also facilitating
its ability to promote Administration goals and objectives to a wider
audience. With the burgeoning use of the Internet, and the increasing
sophistication of the American public in the use of electronic
processes, microcomputers and networks, electronic accessibility to
Federal agencies provides an opportunity for a member of the public to
reach out and touch his or her government when and where it is
convenient for the individual. In effect, government is available 24
hours a day, seven days a week, creating a properly improved perception
of government's desire and willingness to serve the public. Many private
companies are already operating in this fashion over the Internet.

**D1.4 [Improved Quality and Integrity of Data]{.underline}**

With electronic processes using digital signatures, the quality and
integrity of data collected is substantially improved, which reduces
cost and improves process efficiency. For example, unlike paper
processes, online forms can include field edit functions and immediate
data integrity and consistency checks. Thus, errors can be detected
during input and corrected at that time (i.e., before transmission),
saving agency and customer time and effort. This approach also ensures
the customer that the information he or she is providing will be
accepted and that no errors were inadvertently introduced as a result of
data-entry mistakes, which could be caused by poor penmanship on the
part of the customer or just typographical errors on the part of the
government employee. Moreover, the increased trust (strong
authentication) which digital signatures afford may help assure users to
supply electronically that private information needed to receive the
full benefit of electronic transactions.

These types of interaction are already becoming commonplace in the
on-line market. Software providers encourage electronic registration of
their products using query screens which prompt the user for
information, identify fields which must be filled out, provide options
for entries, and generally check to ensure the fields contain legitimate
information (e.g., checking that a phone number includes an area code;
verifying that the zip code corresponds to the telephone area code; and
so on). Getting the process to the point where a single transaction with
a customer requires only one interaction to satisfy that customer's
needs should produce strong benefits.

***Question 2**. How much will it cost to: (a) either convert an
existing electronic processing system (that is, a system which processes
information electronically or digitally) to use digital signatures, or
convert an existing non-electronic process to an electronic one using
digital signatures; and (b) operate such a system after conversion?*

> **D2.0 [Discussion]{.underline}**
>
> Federal agencies perform this type of analysis whenever they consider
> implementing information technology in their work processes. Many of
> the requirements and much of the doctrine in this area can be found in
> OMB Circular A-130 and its references, or in requirements developed by
> each agency to implement A-130 and the Computer Security Act of 1987.
> This includes evaluating such aspects as the full life cycle cost of
> the system using digital signatures, system maintenance, facilities,
> training, backup, auditing, personnel needs, and so on. The same
> analytical methodology should be applied to the planning an agency
> undertakes to evaluate the use of digital signatures for its
> electronic processes. The evaluation should touch upon the following
> issues in establishing expected costs:
>
> **D2.1 [Required Level of Trust]{.underline}**
>
> The cost of implementing an application using digital signatures will
> depend on the level of trust (or assurance) that the application will
> be required to provide. Trust in this context means with what level of
> certainty the application meets the first three principles set forth
> in the Background section (2.0) above -- authentication, data
> integrity, and non-repudiation -- and thus can defend against the
> threats which a miscreant may pose. The agency needs to establish how
> the required level of trust affects implementing digital signatures in
> the application (and attendant costs), and whether the technology
> should be used on a "per-transaction" or other basis. Agencies should
> consider:
>
> \(1\) the nature of the transactions (e.g., number or frequency, and
> amount of information transferred per session), especially those
> containing financial information or data requiring protection for
> privacy or proprietary reasons;
>
> \(2\) the level of assurance (if any) that the application currently
> possesses without digital signatures, measured against the principles
> of Section 2.0, and whether that level warrants changing;
>
> \(3\) the scope of the application, especially whether it is
> anticipated to grow because growth may create financial or other
> pressures that digital signatures can better address;
>
> \(4\) the nature and expectations of the users, including their
> demographics and access to electronic methods of interaction; and
>
> \(5\) the views of key stakeholders (such as privacy and consumer
> advocates).
>
> **D2.2 [Integrity of Public and Private Keys]{.underline}**
>
> Public and private keys must be managed properly to ensure their
> integrity. For private keys, this responsibility falls primarily on
> the shoulders of the user. For example, he or she must keep the
> private signature key secret to avoid being impersonated. The
> integrity of the public key, by contrast, is established using a
> digital certificate issued by a Certification Authority (CA, discussed
> further below) that cryptographically *binds* the individual's
> identity to his or her public key (that is, binds the identity to the
> public key that corresponds to the individual's private signature
> key).
>
> A PKI includes the ability to recover from situations where an
> individual's private signature key is lost, stolen, compromised or
> destroyed; this is done by revoking the digital certificate containing
> the private key's corresponding public key (discussed further below).
> The user then creates or is issued a new public/private key pair, and
> gets a new digital certificate on the new public key. These activities
> do incur transaction costs.
>
> Moreover, compromise or loss of a private signature key could have
> financial consequences if the services which the user receives by
> employing that signature key involve monetary transactions. In that
> case, who is responsible for those consequences may have to be
> resolved legally under common law doctrines involving what is the
> appropriate standard of care for control of the private key, and how
> did the user's behavior measure up to that standard. Unlike the use of
> credit cards, where the presumptive rule regarding user liability in
> the event of a compromise or loss of a PIN is usually capped at \$50
> per card, no federal law currently defines liability for loss of a
> private digital signature key.
>
> To ensure the integrity of public keys, the situation is more
> complicated and requires an explanation of the role of a Certification
> Authority (CA) in the PKI. In brief, upon being presented with proper
> evidence of identity (usually through a separate entity called a
> Registration Authority), the CA issues a digital certificate which
> contains the applicant's public key, identity, and other information
> (such as duration of the certificate), all signed by the CA's private
> key. The certificate may then be distributed or placed in publicly
> available data bases (called repositories). The CA operates under a
> Certificate Policy (CP) and Certification Practices Statement (CPS)
> which collectively describe the CA's responsibilities and duties to
> its customers and trading partners - that is, how it is conducting its
> affairs in compliance with its contracts and, where applicable,
> federal or state law. The uses for which a certificate may be employed
> depend upon the requirements surrounding its issuance -- for example,
> how identity proofing was done by the RA before certificate issuance,
> how well the private key is protected, and so on.
>
> From the discussion above, the basic issues involving CAs which affect
> the cost of the application are:
>
> \(1\) Whether the agency should operate its own Certification
> Authority; "outsource" that function, such as by employing a CA run by
> another Federal agency or one or more private companies (which may
> include the Access Certificates for Electronic Services contract
> offered by the General Services Administration to facilitate delivery
> of PKI services to agencies); or simply accept certificates signed by
> other Federal or commercial sector CAs.
>
> \(2\) What level of "trust" the agency requires for the certificates,
> in order to rely upon them to consummate the transaction at issue.
> This includes determining the level of identity-proofing required for
> a subscriber to get a certificate; the strength of the cryptography
> employed (e.g., key lengths and algorithms); how the corresponding
> private key is protected; and other factors. Agencies must determine
> the required level of trust premised upon several objective or
> subjective factors, including:
>
> \(a\) Statutory requirements;
>
> \(b\) Administration or agency policy;
>
> \(c\) Trading partner practices.
>
> \(3\) Whether the CA will need to interoperate with those run by other
> Federal agencies or with commercially available CAs, and if so, how
> that will be accomplished. Such interoperability is important if the
> agency wishes to have the certificates its CA issues accepted by other
> parties, and if it wishes to accept certificates issued by those other
> parties. Issues here are whether the agency CA will interoperate with
> the Federal Bridge CA (thus providing interoperability with all other
> agency CAs which do likewise), or whether the agency CA will
> interoperate in some other fashion.
>
> \(4\) Whether the CA will need to operate 24X7; how often certificate
> revocation information needs to be published (or whether an on-line
> process needs to be in place for that purpose, such as using the
> On-line Certificate Status Protocol); and whether a local or remote
> backup CA is needed in order to continue operation if the main CA goes
> down.
>
> **D2.3 [Quantification of the Consequences of Potential
> Risks]{.underline}**
>
> The use of digital signatures entails potential risks, some of which
> are known and understood, others of which are known and less well
> understood (see *Question 3* below), and still others which may not
> yet be known. The consequences of each risk may be related in
> principle to a potential cost to the agency. For example, if the
> agency concludes that a higher incidence of fraud is likely (note that
> a strong case can be made that the actual use of public key technology
> may have exactly the opposite effect), then it may be able to define
> possible financial impacts by extrapolating losses due to fraud
> without digital signatures. The point here is simple: to the extent
> that the consequences of a potential risk can be identified (per
> *Question 3*), an agency should consider whether its financial impacts
> can be quantified.

**D2.4 [Policy, Practices, and Procedures]{.underline}**

> Policies, practices, and procedures for the use of public key
> technology may need to be developed for the application at issue.
> Indeed, the starting place on a policy level for a PKI is the
> development of a Certificate Policy and, if the agency has decided to
> run its own PKI, the preparation of a Certification Practices
> Statement. Writing these documents is likely to consume substantial
> resources, but those resources are well spent since they create the
> entire framework for the agency's PKI, including the issuance,
> revocation, and use of certificates.
>
> Beyond the CP and CPS, existing agency policy, practices and
> procedures may have to be altered or amended. Ideally, these processes
> should apply broadly to an agency's electronic transactions as a
> whole, or to classes of transactions, and there should be some
> consistency or common elements across the Federal government.
>
> The most important factors to consider in the development of a CP
> and/or CPS, and in any revisions to other agency policies, practices
> or procedures, include:
>
> \(1\) Whether the agency currently accepts the use of digital or other
> electronic forms of signature for documents submitted within the
> agency, by other agencies, or by non-Federal government parties
> including by the public;
>
> \(2\) What auditing should be done and how it is properly supported
> reflecting the electronic and possibly encrypted nature of records;
>
> \(3\) Reviewing how to ensure protection of personal information under
> the Privacy Act, especially since use of public key technology may
> require the creation of new data bases containing information which
> would make some of those data bases "systems of records" under the
> Privacy Act. For example, where an agency either contracts for or
> operates its own Registration Authority, the data base created for
> identify-proofing purposes would be a system of records and thus would
> require notice in the Federal Register. Repositories of certificates
> maintained by an agency or by a contractor to the agency would also
> likely be systems of records. By contrast, however, a repository of
> certificates run by commercial entity separate from the government,
> for broader commercial purposes, but which the agency might access to
> obtain a person's digital certificate, would *not* be a system of
> records. Questions concerning whether a new data base required for the
> application of public key technology constitutes a system of records
> should be resolved with agency counsel and, if appropriate, the Office
> of Management and Budget.
>
> \(4\) How long a digital signature on a document may need to be
> retained, and be able to be validated, subsequent to its having been
> made. This affects:
>
> \(a\) The duration for records retention for documents such as
> certificates and CRLs;

\(b\) The form of the document, since once a digital signature is made,
the document cannot be reformatted or otherwise changed without
destroying the signature;

> \(c\) What software may need to be retained in order to validate a
> signature made in the past;
>
> \(d\) Whether trusted time-stamp services are needed so that the time
> of the signature, and of the documents (certificates, CRLs) needed to
> validate the signature, are known in a trustworthy fashion; and
>
> \(e\) Who should provide this capability -- i.e., whether the ability
> to validate a signature on a document after the corresponding
> certificate has expired is a obligation that should be imposed on the
> agency end user, or on some central authority such as that which is
> responsible for the entire agency PKI.

\(5\) What the agency may want to require of subscribers (i.e., those to
whom certificates are issued) prior to certificate issuance. For
example, it is usually good practice to have a "subscriber agreement" in
place which the subscriber manually signs setting out his or her
obligations to protect the private signature key, and notify appropriate
authorities if it is stolen, lost, compromised or destroyed. Often the
provisions of a subscriber agreement can be placed into other documents
(such as an employment contract, or a security agreement).

**D2.6 [Connectivity to Existing Agency Infrastructure]{.underline}**

> For an agency's applications program to use public key technology
> properly, including establishing the PKI itself, proper connectivity
> must be provided to the agency's existing electronic infrastructure.
> This infrastructure may include extensive mainframe and other
> "back-end" information processing systems. Many of the
> infrastructure's systems employ security devices such as firewalls
> aimed at providing proper segregation and security, and virtually all
> have databases which may need to be used to support a PKI and have
> their integrity respected in doing so. Thus, two issues warrant
> specific consideration:
>
> \(1\) Identifying with which parts of the existing agency electronic
> infrastructure the application using public key technology *needs* to
> interface, and with which parts interfacing would be *desirable* but
> not essential. The latter may include providing capabilities which are
> not critical to the specific application, but which provide
> functionality desired by the agency for other reasons. Factors to
> consider include:
>
> \(a\) how the application and the PKI will function across security
> and access control devices such as firewalls;
>
> \(b\) how the application will interact securely with data bases or
> directories which exist separate from the application but from which
> the application must draw, or whether those data bases will be
> replicated to minimize or reduce the need for such secure access.
>
> \(2\) Establishing the costs associated with providing the *necessary*
> and the *desired* interfaces, including those costs associated with
> making the transition to public key technology (e.g., the need to
> operate multiple systems until the new one demonstrates reliable
> operation).
>
> **D2.7 [Interoperability with Other Agency
> Infrastructures]{.underline}**
>
> As an expansion of the issues expressed in section D2.6 above,
> appropriate connectivity to and consistency with (interoperability
> with) electronic infrastructures present in other agencies, and the
> Federal (and possibly non-Federal) PKI in general, needs to be
> evaluated. Interoperability is a complex issue which should be
> considered from several angles:
>
> \(1\) Policy interoperability -- that is, how the "level of assurance"
> of certificates issued under the agency's Certificate Policy "map" to
> those of external parties. Doing such "policy mapping" depends upon
> several objective and subjective factors (e.g., comparison of identity
> proofing mechanisms; how private key protection is afforded; strength
> of cryptography; etc.). The Federal PKI Policy Authority performs this
> function for Federal agencies desiring to interoperate with the FBCA,
> so that the Certificate Policy of the FBCA becomes the "universal
> translator" of levels of assurance among agencies. In addition to
> policy mapping, another element of policy interoperability is ensuring
> that certificates conform to a consistent Certificate Profile which
> describes what extension fields the certificates will have, how those
> fields are to be populated, and how they are to be interpreted by
> application software. The Federal government has Federal Certificate
> Profile developed by NIST that is useful for this purpose; it can be
> found by accessing the Technical Working Group web page through the
> Steering Committee web page (http://gits-sec.treas.gov).
>
> \(2\) Technical interoperability -- which implicates several elements:
>
> \(a\) PKI to PKI interoperability -- that is, the ability of different
> CAs either to cross-certify or to accept some other mechanism (such as
> Certificate Trust Lists) so that the users in one PKI domain can
> accept as trusted (at some appropriate level of assurance) the
> certificates issued by another PKI domain;
>
> \(b\) Application to application interoperability -- that is, the
> ability of different products that accept certificates to do so with
> certificates issued outside their PKI domain; this entails the ability
> to create and process certificate trust paths from the domain of the
> relying party to the domain of the certificate issuer, using for
> example cross-certificates issued by the FBCA to both domains. It also
> means doing policy mapping using information in the FBCA
> cross-certificates which allows the relying party to establish how
> much confidence he or she should have in the certificate received from
> the sender's domain. Further, it means interpreting the extension
> fields in X.509v3 certificates in a consistent and compatible fashion;
>
> \(c\) Intra-application interoperability -- that is, the ability of a
> single application to accept certificates even within its own domain
> from different CA products. This can be vexing because CA products
> differ in the functionality they supply and the way they supply it.
> Each CA product generally needs to have an application "enabled" to
> accept its certificates using a specific "toolkit," and once so
> enabled, the application will work with certificates issued by that
> product; to have it accept certificates issued by another CA requires
> the application to be enabled with yet another toolkit. While vendors
> are working to minimize this need for multiple "enablements," there
> will always be some elements which will require that. For example,
> each CA product does encryption key recovery differently, so it is not
> possible to simply "unplug" one CA product and "plug in" a new one
> seamlessly. This inability to do "plug and play" with many PKI
> products will improve with time, but it is unlikely to ever vanish;
>
> \(d\) Directory interoperability -- that is, the ability to supply
> directory services to the PKI and to application programs which allows
> certificates and CRLs to be found and used.
>
> So summing up interoperability issues, an agency should determine what
> policy and technical interoperability it needs or may need with
> external parties, and then consider which products best fulfill those
> needs considering the factors set forth above.
>
> **D2.8 [Records Management]{.underline}**
>
> Proper management of electronic records maintained or used as part of
> the application must be ensured. This entails:
>
> \(1\) Retaining those records necessary for long-term system operation
> including, where appropriate, all certificates or CRLs produced by a
> CA;
>
> \(2\) Retaining audit records and other materials necessary to
> establish proper system operation at any point in time, were that
> necessary for legal or other purposes;
>
> \(3\) Ensuring past records stored using certain electronic formats or
> media remain recoverable as those formats or media are replaced with
> newer technology (e.g., the use of 5 ¼ inch floppy disks is
> diminishing, and the number of microcomputer systems with 5 ¼ inch
> disk drives is also declining). This concern is not unique to public
> key technology, although the ability to preserve a digital signature
> does preclude the approach of simply reformatting documents to adjust
> to a new format or medium.
>
> **D2.9 [Compliance with PKI Standards]{.underline}**
>
> There is no single Federal standard that defines and describes a PKI
> or the use of public key technology. There are, however, several
> standards (FIPS, ANSI, and so forth) that are relevant to public key
> technology and a PKI; the standards, or a reference to a web site from
> which they may be downloaded, can be obtained through the agency's
> Information Systems Security Officer or FPKI Steering Committee
> representative. Since some of these standards are in the process of
> revision to reflect the evolving nature of public key technology, it
> is important to contact the Steering Committee to ensure the agency's
> evaluation is based on the most recent information.
>
> **D2.10 [Enabling Applications Programs]{.underline}**
>
> A PKI is just an infrastructure, like a highway. By itself, it does
> little. What makes it useful is when applications programs employ the
> certificates and services it supplies. This means that applications
> programs either have to be PKI-enabled or PKI-aware out of the box
> (which is true of some applications such as secure messaging clients
> that employ S/MIME), or they have to be enabled separately. Such
> enabling may involve using PKI-vendor "plug-ins" which can be added
> into the application software; or it may involve far more detailed
> programming. Thus, agencies must understand the cost associated with
> making their applications PKI-enabled, and especially able to employ
> the PKI product or service selected by the agency for the
> infrastructure. Further, as discussed above concerning
> interoperability, agencies need to understand that enabling an
> application to operate with one vendor's PKI products does not ensure
> that the application will also operate with a different vendor's PKI
> products -- indeed, at this stage, just the opposite is usually true.
> However, enabling a product to accept digital certificates issued to
> the X.509v3 standard does afford interoperability -- that is, the
> application can accept such certificates from multiple vendor CAs --
> assuming, as described above, that the certificates honor a consistent
> Certificate Profile for their extension fields.
>
> **D2.11 [Apprising Affected Parties]{.underline}**
>
> Affected entities inside and outside the agency will need to be
> apprised of the availability of certificates and PKI-enabled
> applications, and subscribers (those to whom certificates were issued)
> as well as users (those who may not hold certificates but may rely
> upon a certificate in deciding whether to allow a transaction to
> consummate) will need to be trained in their use, from registration
> for certificates, to certificate issuance, to applications programs
> that rely on certificates for electronic transactions to consummate.

***Question 3**. What are the risks associated with the use of public
key technology for this application?*

> **D3.0 [Discussion]{.underline}**

The risks associated with the use of public key technology can be broken
down into three areas: (a) fraud; (b) failure of the system to fulfill
its purpose (service failure or shortfall); and (c) liability. Each area
is discussed separately below. In considering each area, however, it is
useful for the agency to evaluate risk in two separate contexts. First,
does the use of public key technology create "new" risk - and if so,
what is its "absolute" level (e.g., what is the greatest monetary or
intangible loss the agency can suffer)? Second, how does that level of
risk compare to the risk already engendered using existing systems
supplying the same service to the public or other entities today (if
that service exists today) - in other words, relative risk?

> The use of digital signatures may actually reduce risk compared to
> existing electronic and paper-based processes. Once a digital
> certificate has been properly issued, the ability to impersonate
> usually reduces to a simple question: can you get that party's private
> key used for making his or her digital signature? If you cannot, then
> identity fraud becomes extremely difficult. However, this raises an
> important issue for the government: establishing the responsibilities
> and obligations of all parties in the new infrastructure, including
> those of individual users.
>
> **D3.1 [Fraud]{.underline}**
>
> Concerns have been expressed that the use of digital signatures in
> lieu of paper signatures will make it more difficult to prosecute
> individuals seeking to defraud the government. The line of argument
> goes as follows. Today, an individual who wishes to defraud an agency
> may submit a fraudulent claim for benefits, but that individual's
> signature on the paper embeds what are called "biometric" or
> "forensic" elements unique to the individual. In other words, his or
> her physical signature on the paper can be shown, by experts in court
> if necessary, to be bound to that person. Thus, an important link for
> the government to prove fraud - that the accused actually signed the
> fraudulent claim - can be established in accordance with commonly
> accepted legal principles respecting the "biometrics" of the
> signature, e.g., handwriting analysis.
>
> For digital signatures, however, there are no imbedded "biometric"
> elements -- the binding of the individual to the private/public key
> pair is done through the RA described previously using an identity
> proofing mechanism suitable for the ultimate intended use of the key
> pair. Thus, if a person "signs" a fraudulent claim with his or her
> private key (that is, he or she digitally signs the document), there
> are no physical or biometric characteristics which may be linked to
> that person by a handwriting or other expert. Instead, with a PKI,
> control of the private key used to sign documents becomes the critical
> factor since the only thing which binds an individual to a
> public/private key pair is the certificate issued by a CA (discussed
> earlier) relying upon the information supplied by a Registration
> Authority. Thus, a person who has committed fraud with his or her
> private signature key may attempt to convince a court that the key was
> somehow accessed and used by some other (unidentified) person.
>
> An analogous defense, however, can be asserted by someone making a
> physical signature. The party attempting the fraud may subtly but
> deliberately change the written signature on the fraudulent document
> so that in court, the party can renounce the signature and claim it is
> not identical to other specimens of his or her "real" signature.
> Similarly, the party attempting the fraud could claim that someone
> impersonated his or her signature - a claim which would be more
> difficult to refute because of the availability of optical scanners
> which can create an excellent impression of any image, including an
> individual's signature.
>
> In practice, fraud is commonly detected as the result of the
> application of a number of risk management controls established by
> Federal agencies, and a physical signature [per se]{.underline} is
> typically used as but one element in a complex chain of evidence
> necessary to establish civil liability or criminal guilt in a court of
> law. In fact, many agencies have successfully prosecuted employees who
> use PINs and passwords to access computer systems for fraudulent
> purposes, regardless of the fact that no written signature was
> connected with the fraudulent act itself. Moreover, the use of
> electronic transactions having digital signatures can assist in
> detecting fraud because of the ability to aggregate data more quickly
> and analyze it more readily, looking for atypical behavior.
>
> For these reasons, Federal agencies planning to use public key
> technology for digital signatures must develop and make known
> obligations for managing private keys and establish appropriate policy
> governing their user and protection by subscribers. Subscribers must
> understand their obligations, and in some fashion (e.g., through a
> subscriber agreement), attest to that understanding, if they are to be
> held accountable in the event of a problem.
>
> Additionally, any applications which ask a subscriber to make a
> digital signature should be engineered so that: (a) the subscriber is
> clearly presented with an irrefutable description of what he or she is
> doing when the subscriber is asked to click on the button (and enter
> the authentication data to unlock his or her private key) which
> results in the digital signature being made; (b) there are appropriate
> jurats or other statements attesting to the intent of the signer, and
> then captured on the document which is actually digitally signed; (c)
> the document which is actually signed is fully visible -- "what you
> see is what you get" is honored; and (d) once the signature is made,
> and the document is sent to its destination, the destination replies
> with a "return receipt" that is also digitally signed by the
> recipient. These are the types of considerations which strengthen the
> ability of the relying party to hold the signer accountable (i.e.,
> make it more difficult for the signer to repudiate the transaction).
>
> To provide additional signature strength, the relying party may
> require that signatures only be made using private keys created and
> stored on hardware tokens meeting appropriate FIPS requirements, and
> that applications programs (and the operating system on which they
> run) employ standards that make it more difficult for malicious code
> to be present or go unnoticed.
>
> Agencies may also need to develop fraud control measures specific to a
> PKI environment. Because of the lack of case law on these matters, and
> because there is an absence of Federal law speaking specifically to
> this situation, it is impossible to be certain how a court of law or a
> jury would deal with a case involving allegations of fraud using
> digital signatures. Thus, a Federal agency seeking to receive
> digitally-signed applications for claims, benefits, or similar
> transactions where the risk of fraud is substantial, should consider
> whether to amend the practices it had been using for processing paper
> applications to add safeguards in the electronic environment.
>
> Summarizing the points above, a robust digital signature
> implementation would ensure that: (1) the individual can be strongly
> linked to a particular transaction (e.g., the signature should capture
> the entire document, not just isolated elements such as the answers to
> questions held in a separate file); (2) intent can be demonstrated
> (i.e., that the individual intended to sign the document); (3)
> knowledge can be demonstrated (i.e., that the individual knew exactly
> what he or she was doing when the digital signature was made); and (4)
> a digitally signed receipt is sent after the transaction, ideally
> reciting the relying party's view of exactly what was signed and the
> intent of the signature. These safeguards, and related concerns, are
> discussed in separate Department of Justice guidance being issued
> pursuant to OMB guidance under GPEA. That guidance should be reviewed
> by every agency seeking to employ digital signatures.
>
> **D3.2 [Service Failure or Shortfall]{.underline}**
>
> An important goal of using electronic processes with public key
> technology is to ensure parties seeking government services get those
> services quickly, efficiently and with trust. But a service failure or
> shortfall can result from several factors, including poor design or
> implementation of the software providing or using the public key
> technology, or inadequate training of the service providers or users.
> Thus, employing electronic processes in general, and those with public
> key technology in particular, creates risks that the system will not
> function as planned. (Of course, the level of service of paper-based
> systems is not high, and they too can fail to satisfy customers in
> quality or speed.)
>
> Agencies will need to develop methods to manage system failures or
> curtailments and deal with customer inquiries and complaints related
> to electronic transactions that use public key technology. Factors to
> consider here are the consequences to users of service delay or
> interruption; likelihood of delay or interruption; and ability to use
> a separate system until the electronic processes using public key
> technology are restored.
>
> A related and equally important issue is the need to incorporate
> electronic services using digital signatures within the scope of
> Agency disaster recovery plans. At a minimum, Agencies should consider
> establishing backup sites for their key PKI components (RA, CA,
> directories) which supply the services necessary for applications
> programs to use certificates.
>
> **D3.3 [Liability]{.underline}**

#  Whenever a Federal agency interacts with outside parties, it must face the question of how its actions make it legally liable to those and other affected parties.

Under the doctrine of sovereign immunity, the Federal government is not
liable for its actions unless legislation specifically waiving immunity
exists. Under the Federal Tort Claims Act of 1946, however, the Federal
government partially waived its immunity from tort liability and
established conditions under which suits and claims may be filed against
the government. The Act preserves immunity for traditional intentional
torts and for the acts or omissions of Federal agencies and employees
where those acts or omissions are part of a discretionary function or
duty. Beyond that, the Federal government is liable "in the same manner
and to the same extent as a private individual under like
circumstances."

> In cases involving contracts between the Federal government and
> non-Federal entities, disputes are resolved by applying standard
> contract law in Federal courts established specifically for that
> purpose. The more complicated contract scenario involves the situation
> where an individual or business has contracted with a CA for its
> services, and through some error on the part of the CA, a loss has
> occurred. If the Federal government were a party to the underlying
> transaction, and the CA were operating under a Certification Practices
> Statement (CPS) which was in accord with the Federal agency's
> Certificate Policy (CP), the plaintiff could attempt to establish the
> liability of the Federal agency, particularly if the CA, through its
> CPS, attempted to limit its dollar liability. Therefore, Federal
> agency CPs must clearly state the liabilities of the CA and the
> agency. This is another factor which an agency must consider when
> deciding whether to run its own CA or to outsource that function.
>
> It is useful to note that agencies operating as regulators typically
> must meet standards set forth in the Administrative Procedure Act
> (APA). For example, if a regulatory agency accepts comments on a
> rulemaking using digital signatures, and a problem later arises with
> that use, the agency may only be liable (unrelated to tort liability)
> if their actions were "arbitrary and capricious," which is typically a
> higher standard (that is, one which is harder for the plaintiff to
> demonstrate that the agency failed to meet its duty) than those
> imposed in other statutes.
>
> From the discussion above, the government's liability in the event of
> a problem with electronic processing in most cases can be addressed
> through well-established legal principles, analogous precedents, and
> existing statutes and regulations. Once again, the Department of
> Justice has issued guidance on this matter pursuant to OMB direction
> under GPEA, so agencies are encouraged to review that guidance as they
> consider the use of public key technology.

***Question 4**. How should the benefits determined in response to
Question 1 be compared to the costs established in response to Question
2 and the risks discussed in response to Question 3?*

**D4.0 [Discussion]{.underline}**

This question is more often a policy judgment than anything else,
especially where the benefits contain both quantitative and
non-quantitative elements. The agency must decide what the proper method
is to compare or weigh the costs against the benefits so as to come to
an appropriate business decision on whether an electronic process using
digital signatures is preferable to one which does not use that
technology. Some considerations which the agency should keep in mind as
it performs this evaluation are:

**D4.1 [Inherent Value]{.underline}**

Ideally, the use of digital signatures would save the agency money in
the short or long run. However, there are circumstances where the use of
digital signatures may be warranted even without such savings. For
example, building the good will of the public and elected state and
local officials by demonstrating that government services can be
supplied more quickly and effectively in a trusted electronic
environment may warrant substantial up-front and continuing costs. In
that case, the issue boils down to whether there is sufficient value to
the government and citizens for the money being spent on the service -
not whether the service [per se]{.underline} is saving the government
money. To say it another way, would an additional expense be justified
by increased or enhanced service?

**D4.2 [Part of a Bigger Whole]{.underline}**

Agencies may find it useful to evaluate costs and benefits not simply on
an application basis, but on an overall service delivery basis. The
costs associated with establishing and running a PKI for digital
signatures may support multiple applications and multiple agency
programs, and therefore the same PKI over time will serve increasingly
large numbers of customers and other capabilities such as encryption.
Consequently, up front development costs of the PKI may be evaluated as
something to be incurred over time (like maintenance costs) and in the
context of a total service delivery program.

**D4.3 [Public Acceptance]{.underline}**

Even if the use of digital signatures exposes agencies to new fraud
risks and creates increased uncertainty about prosecuting certain kinds
of fraud owing to legal factors described above, such uncertainty may
diminish with time as legislation is enacted or case law develops, and
it may be far outweighed by the economic and other advantages gained.
For example, use of credit cards beginning in the 1950s significantly
increased potential and actual fraud compared to the use of checks or
other paper transactions for exchanging funds. Yet, as history has
shown, the public has accepted that the benefits derived far outweigh
the drawbacks. Likewise the potential for fraudulent use of cellular
phones is far higher than for hard-wired phones in one's home, yet once
again, the public has accepted that the benefits of cellular phone use
far outweigh that drawback. Additionally, in both situations, industry
has adapted and developed new controls and technology enhancements to
reduce fraud while continuing to experience tremendous growth in these
sectors.

**D4.4 [OMB A-130 Risk Evaluation]{.underline}**

The proposed application must meet the risk-based standard set forth in
the Computer Security Act of 1987 and OMB Circular A-130, Appendix III,
namely, is any benefit associated with the use of digital signatures for
an application "commensurate with the risk and magnitude of the harm
from the loss, misuse, or unauthorized access to or modification of the
information?" This guidance provides substantial flexibility to agency
managers because it recognizes that one size does not fit all, that a
sensible business application of digital signatures by an agency should
recognize that agency's specific situation in managing data.

***Question 5**. What are the critical implementation issues which an
agency should consider as it seeks to implement and use a PKI for
digital signatures?*

**D5.0 [Discussion]{.underline}**

Below is a checklist of the most important issues that agencies must
consider in implementing and using a PKI for digital signatures. For
each item, brief specific guidance is provided.

**D5.1** ***Prepare a Certificate Policy and, if applicable, a
Certification Practices Statement.*** These are the policy framework
documents for the entire PKI, and they create the disciplined
environment necessary for parties wishing to rely on certificates issued
by the PKI. These documents in effect "map" the agency's business model
for electronic transactions to the PKI, setting forth what types of
certificates the agency will issue (or purchase), or accept, for its
business needs. The CP should be prepared in PKIX Part 4 format (also
known as "Chokani/Ford" framework), which lists all of the issues that
the organization should consider. The agency need only create a CPS if
it is going to operate its own CA (or have a contractor do it on behalf
of the agency); no CPS preparation is required if the agency obtains PKI
services only, but in that case, the agency will need to ensure that
provisions of the CPS prepared by the service offerer are suitable for
the agency's needs. Note that included in this process is the
identification by the agency of the critical employees who will actually
run the PKI software -- e.g., be responsible for the safeguarding and
use of the CA signing key.

**D5.2** ***Decide what directory services are required by the
applications which the PKI is intended to serve, and ensure they are
available or are obtained.*** Such services allow the CA to publish CRLs
so that users can readily discover them; and allow users to easily
obtain certificates for digital signature validation (which is
unnecessary if the certificates are conveyed as part of the transaction
as with S/MIME clients) or for encryption purposes.

**D5.3 *Ensure that the need for agency PKI interoperability with
parties external to the agency is established and addressed.*** For
interoperability with other Federal agencies, use of the Federal Bridge
CA will probably provide the most efficient mechanism, so preparation of
the agency Certificate Policy should carefully consider the CP honored
by the FBCA.

**D5.4** ***Ensure that as the PKI is developed, agency applications are
made PKI-enabled (or purchased PKI-enabled).*** The best time to
engineer applications programs to use the PKI is concurrent with the
selection and implementation of the PKI; that provides the greatest
flexibility since both the infrastructure and the applications programs
can be adjusted to fit. This effort includes ensuring that applications
programs can create appropriate certificate trust paths; process those
paths; and find and check certificate revocation information through
Certificate Revocation Lists (CRLs), Online Certificate Status Protocol
(OCSP), or validation authorities. Moreover, this is the time to ensure
that the applications contain the proper user "interface" -- that is,
that they fulfill the legal requirements to minimize risk and provide
information suitable for later litigation, such as appropriate jurats,
notices to users about the meaning of their making a digital signature,
and so on.

**D5.5** ***If practical, implement the PKI and applications in stages
rather than all at once.*** Incremental implementation provides maximum
opportunity to "learn as you go" and make adjustments as the process
proceeds. Moreover, it allows the agency to scale up such functions as a
"help desk" as the number of users increases, rather than having to
employ a large help desk (which can be manpower intensive) from the
start.

**D5.6** ***Where practical, integrate PKI registration processes into
established personnel or security practices.*** For example, make the
process of registering to obtain a digital certificate part of the
process an employee goes through to obtain an agency identification
credential, or the process an employee goes through to be certified or
qualified to perform a function, or get a security clearance. This
approach also has the advantage of allowing an agency to place into
standard employment or security paperwork which an employee must sign,
the requirements governing subscription to a PKI (i.e., getting the
digital certificate). Finally, this approach is consistent with the
points in D5.5 concerning incremental ramp-up.

**D5.7** ***Identify (and act upon) requirements to make the PKI
software, directories, and applications programs operate through
firewalls and routers***. For example, many PKI programs require certain
TCP/IP ports be available (open). Executing this through firewalls may
require obtaining approval of system security personnel.

**D5.8** ***Decide whether to employ CRLs, OCSP, or a "Validation
Authority" approach for publishing or making available certificate
revocation information.*** The CRL approach is employed by most
commercially available software today; the OCSP approach is analogous to
the current credit card model and is seeing increasing adoption; the
validation authority approach (for which there are also commercial
products available today) involves establishing a central location into
which certificate revocation information is published from multiple CAs
to facilitate certificate checking.

**D5.9 *Decide whether to employ an on-line (e.g., HTTP-based) or
off-line (e.g., S/MIME) functionality -- or both.*** S/MIME (Secure
MIME) is an open standard for messaging (e-mail) which includes digital
signatures on documents and messages, but it does not provide for an
interactive environment. By contrast, browser-based models support
interaction but do not yet have open standards reflecting how HTML or
XML pages are digitally signed -- all such solutions currently available
employ proprietary approaches and thus may not be interoperable between
products. Effort is underway to establish an open standard for XML
digital signatures, but how quickly that will be completed is uncertain.

**D5.10 *Establish who will fulfill audit roles for the PKI.*** These
roles may reside within the office of the agency's Chief Information
Officer; within the Inspector General's office; within the office
responsible for information security; or somewhere else.

**D5.11 *Address any liability issues which warrant consideration.
***This includes stating what liability, if any, the agency is able and
willing to incur in the use of certificates it issues, and if so, under
what circumstances. Generally speaking, the agency PKI should be viewed
as just another way to convey or preserve trust between transacting
parties (established pursuant to other relationships such as contracts
or regulations), rather than creating trust per se.

**D5.12 *Resolve how to deal with validating a digital signature well
after it is made.*** This includes ensuring that all of the information
required to validate a digital signature after the relevant certificates
have expired is available (i.e., the expired certificates, and the CRLs
or other information showing that the certificates were valid at the
time the signature putatively was made). It also includes addressing
whose responsibility it is to provide long-term signature validation
services -- i.e., should the organization responsible for relying on
that signature be able to do it, or should the infrastructure provide
that capability "automatically?" Answering these questions requires
understanding for how long the agency wishes to be able to validate a
signature, and whether it is willing to accept something other than
original signature validation (e.g., accept the validation of a
signature made by a digital archivist that the signature was validated
as of some date subsequent to its having been made). Indeed, as the
cryptographic strength of a digital signature diminishes with time, it
may be necessary to have a trusted party (sometimes called a "digital
archivist") oversign the original document (and original signature)
periodically, using a signature with stronger cryptography.

*Appendix (1): [Description of Public Key Technology and the Public Key
Infrastructure]{.underline}*

**A1.0** Public key technology and a PKI depend upon complicated
mathematical concepts but their effects are simple and understandable.
When a Federal agency (or employees of such an agency) starts to use the
PKI, the agency (or an employee of that agency - call that person "Bob")
begins with a pair of "keys," which look like very long character
strings and are actually digital representations of very large numbers.
These keys are either chosen by Bob or provided through trustworthy
mechanisms, subject to certain mathematical requirements. One of these
keys is secret (*private*) and the other is published (*public*).

**A1.1** The essence of public key technology is that messages or
transactions authenticated or encrypted using one of Bob's keys can only
be verified or decrypted using his other key. Thus, when Bob uses his
private key to sign an electronic message or other transaction
digitally, anyone who knows Bob's corresponding public key can verify
Bob's signature. A similar method using public key technology can be
used to encrypt messages for confidentiality as they transit an open
network such as the Internet.

**A1.2** The PKI uses special digitally-signed messages (called
"certificates") to bind Bob's identity to his public keys. A digital
certificate is issued by a trusted "Certification Authority" (CA) and
signed using that CA's private key. When someone else (call her
"Alice" - she may be a private citizen, a company, a public interest
group, or some other entity seeking to interact with a Federal agency,
or she may even be an employee of that Federal agency or a different
agency) wants to obtain with certainty Bob's public key, she gets Bob's
certificate. Where or how Alice gets Bob's certificate is not
important - she may get it from Bob in person, or from an on-line
"repository" for certificates, or from Bob's homepage on the World-Wide
Web, or from Bob's credit card issuer; once she gets it from whatever
source, Alice checks the certificate by validating the CA's digital
signature. Alice now knows Bob's public key and name with certainty and
can validate any messages sent to her which were signed with Bob's
private key. These transactions may be conducted with assurance even
though Bob and Alice may have never met, and although they sound
complex, they can be done automatically by the underlying network of
computers with no burden placed on Alice or Bob.

**A1.3** To validate the CA's signature on Bob's certificate, Alice must
first know the public key of Bob's CA. Alice always knows the public key
of at least one CA that she trusts. CAs may issue certificates to each
other. If Alice does not know the public key of Bob's CA, she may still
be able to find a certificate issued by a CA whose key she does know,
that certifies the public key of Bob's CA. In essence, a CA Alice trusts
"vouches" for one she does not know. Much of the challenge of building a
robust global PKI is in the management of certificates between CAs, as
well as the software and infrastructure that automate the process of
building and validating these trust chains of certificates.

**A1.4** As a general matter, good security practices will permit and
encourage Bob to have different public-private key pairs for signature
and confidentiality uses, and to reflect his different roles (e.g., as
an agency official, and as a private citizen and consumer). This is
analogous to a person having different passwords for use on different
computer systems, or different Personal Identification Numbers (PINs)
for use with different financial accounts.

**A1.5** The scientific, academic, and business communities recognize
that the capabilities described above provide the best way to replace
handwritten signatures in the electronic world, to authenticate
identities securely, and to maintain confidentiality on open networks.
Realizing this vision of transacting electronic business with security
and privacy requires that the various implementations of public key
technologies work together smoothly and in a fashion transparent to the
user - which is one of the goals of this document.

**A1.6** Finally, it is useful to describe briefly the PKI itself. The
PKI is not simply software or hardware. It is an *infrastructure*, that
is, a combination of products, services, facilities, policies,
procedures, agreements, and people that provides for and sustains secure
interactions on open networks such as the Internet. It is not a single
monolithic entity, but a distributed system in which the component
elements may include public key infrastructures which are interoperable
and interconnected. The infrastructure provides assurances that
information is protected while being entered, during transit, and when
stored. The underlying technology is already developed by private
industry and is being marketed and used commercially. The PKI promotes
interoperability among commercial products and the early integration of
security features into those products.

**A1.7** The PKI can be likened to elements of the telephone network.
When one wants to contact someone else, it is necessary to access a
phone directory or an information operator to get that person's
telephone number - analogous to the role the CA plays in supplying a
digital certificate of the person to be contacted. When someone moves to
a new location and changes telephone numbers, the infrastructure must
adjust its information to reflect that fact. When you want to know the
number of the person who has dialed you, "caller-id" provides that -
another part of the telephone network infrastructure analogous to the
authentication process in public key technology.

**A1.8** Finally, for a complete description of public key technology
and its relationship to electronic transactions, two useful references
are [Secure Electronic Commerce]{.underline} by Ford/Baum, and [Applied
Cryptography]{.underline} by Schneier.

*Appendix (2): [Description of Public Key Certificates and the
Certification Process]{.underline}*

**A2.0** The PKI employs a Certification Authority (CA) to provide
digital certificates binding the identity of an individual to his or her
public keys. (An individual may have more than one public key \-- for
example, for acting as an agency official or as a private citizen \--
but a digital certificate includes a single public key.) A separate
entity, called a "Registration Authority" (RA), may be used to certify
the individual's identity to the CA so that the CA will issue a digital
certificate.

Thus, for a user (who is known as a "subscriber" in this context), the
process of getting a digital certificate for the first time may entail:

> Step 1: Generating (or having someone generate for the user) a key
> pair containing a public and private component; if someone other than
> the user generates the key pair, then the subscriber incurs some risk
> of misuse since his or her "private" key is known by at least one
> other entity;
>
> Step 2: Going to the RA (which may or may not be part of the CA) with
> proof of identity and a copy of the public key; in some cases, where
> the required level of "identity-proofing" is not high, it may be
> possible to do this on-line with appropriate safeguards such as those
> envisioned in the GSA Access Certificates for Electronic Services
> (ACES) effort;
>
> Step 3: At the RA, physically signing some paperwork (so that a
> physical signature is on file), which accepts for the subsrciber the
> responsibility for the protection of the private key (corresponding to
> the public key) and its use.

**A2.1** After following its procedures to verify the identity of the
individual requesting a digital certificate, the RA communicates
electronically with the CA who issues the digital certificate (signed
with the CA's private key) binding the subsrciber's public key to his or
her identity. The CA then usually places the certificate in a public
data base, called a repository, which may hold certificates issued by
many CAs. Repositories can be replicated, be on-line, and be freely
accessible, with much less protection than CAs require.

**A2.2** When a user (Alice) needs to communicate with another user
(Bob), Alice obtains Bob's certificate containing his public key from a
repository. Bob's certificate is signed by the private key of the CA.
Alice then verifies the CA's signature on Bob's digital certificate
using the CA's public key, and recovers Bob's public key. These
functions are normally done automatically by the software in a fashion
transparent to the user. Note that if someone from outside this process
were successful in surreptitiously substituting into a repository's data
base a bogus certificate for Bob with a different public key, the
signature on the bogus certificate would not validate with the CA's
public key because it was not signed by the CA's private key. This is an
example of the safeguards embedded within public key technology. It does
not matter where or how Alice gets Bob's certificate (Bob could even
physically hand it to her on a disk), since it is the CA's signature on
the certificate which authenticates it.