**Records Management Guidance**

**For PKI-Unique Administrative Records**

Final

March 14, 2003

[\
]{.smallcaps}

**Table of Contents**

[Document Status 1](#document-status)

[1. Introduction 2](#introduction)

[2. Background 4](#background)

[3. Purpose and Scope 6](#purpose-and-scope)

[4. PKI Records Producing Functions and Activities
10](#pki-records-producing-functions-and-activities)

[5. PKI-Unique Records Management Guidance
15](#pki-unique-records-management-guidance)

[5.1 Guidance for Operational Systems
18](#guidance-for-operational-systems)

[5.2 Guidance for Recordkeeping Systems
26](#guidance-for-recordkeeping-systems)

[Appendix A. Glossary, Acronyms and Abbreviations
33](#appendix-a.-glossary-acronyms-and-abbreviations)

[Appendix B. Example PKI-unique Administrative Records Series
39](#appendix-b.-example-pki-unique-administrative-records-series)

# Document Status 

This final version of the *Records Management Guidance for PKI-Unique
Administrative Records* has been produced for the CIO Council and
records management community by the Federal Public Key Infrastructure
Steering Committee's Legal/Policy Working Group and the National
Archives and Records Administration. It addresses the following sets of
received comments.

  ------------ ------------------------------------- ---------------- ------------
  **\          **\                                   **Distribution   **Comments
  Draft        For Review by**                       Date**           Date**
  Number**                                                            

  One          Legal and Policy Working Group,       6/21/02          7/17/02
               FPKISC                                                 

  Two          Federal PKI Steering Committee        7/29/02          8/9/02

  Three        NARA, DOJ                             8/19/02          9/27/02

  Four         Federal PKI Steering Committee (final 10/15/02         10/29/02
               review)                                                

  Five         CIO Council                           11/5/02          12/16/02

  Final        Final                                 03/14/03         03/01/03
  ------------ ------------------------------------- ---------------- ------------

# 1. Introduction 

A public key infrastructure (PKI) is defined as "a set of policies,
processes, server platforms, software and workstations used for the
purpose of administering certificates and public-private key pairs,
including the ability to issue, maintain, and revoke public key
certificates."[^1] A PKI is also an asymmetric cryptography security
environment that is built on a set of standards and guidelines that
require the production, receipt, and maintenance of certain
administrative records during the planning, implementation, operation,
auditing/monitoring and reorganization or termination of the
infrastructure.

Regulatory, legal or audit issues could arise during the operation of
PKIs in the conduct of business by federal agencies that require the
retrieval and delivery of PKI-unique administrative records. Retrieval
may also be required in the course of subsequent agency business
transactions. Therefore, retaining and managing records according to
regulations and good practices for the authorized retention period
should be fundamental elements of a PKI. With the understanding that a
record file copy is established as soon as data content or document
content is finalized or received, this fundamental need for records
management is an integral part of a PKI and applies whether the records
are being retained and managed in an operational system[^2], or in a
recordkeeping system[^3].

As a means to assist agencies in the management of PKI-unique
administrative records, the development of this guidance was jointly
initiated by NARA and the Legal and Policy Working Group \[LPWG\] of the
Federal Public Key Infrastructure Steering Committee \[FPKISC\], which
operates under the mandate of the Chief Information Officers' \[CIO\]
Council.

The target audience for this guidance includes federal agency
information technology, records management and operations personnel
responsible for planning, implementing, operating or otherwise
documenting and managing records produced by PKI administrative
activities. Other entities, such as state and local government agencies,
as well as commercial entities interacting with government agencies may
find this guidance document useful and may adopt and or modify it to
suit their specific needs.

The remaining content of this guidance is organized as follows:

> Section 2. Background, discusses the situation with respect to
> existing records management guidance and articulates specific
> questions that need to be answered when developing guidance unique to
> a PKI.
>
> Section 3. Purpose and Scope, presents the key considerations that
> form the basis for the records management guidance.
>
> Section 4. PKI Records Producing Functions and Activities, describes
> the various processes and activities, including example records
> inherent in a PKI environment and categorizes them as either
> PKI-unique or PKI-supporting.
>
> Section 5. PKI-Unique Records Management Guidance, delineates the
> guidance for the management of PKI-unique administrative records and
> is segmented into two areas: "operational" and "recordkeeping"
> systems.
>
> There are two supporting appendices: Appendix A -- Glossary, Acronyms
> and Abbreviations; Appendix B -- Example PKI-unique Administrative
> Records Series, which presents an example of how PKI-unique records
> can be logically categorized by activity.

# 2. Background 

Currently, there are several general sources of guidance for managing
records generated in an electronic application environment. In response
to requirements stated in the Government Paperwork Elimination Act
(GPEA), NARA issued a document entitled \"Records Management Guidance
for Agencies Implementing Electronic Signature Technologies\" dated
October 18, 2000 (transmitted as part of Bulletin 2001-02 on October 19,
2000). NARA also has promulgated regulations in 36 CFR Part 1234 that
provide general guidance for the management of electronic records. The
Department of Defense (DOD) 5015.2 Design Criteria Standard for
Electronic Records Management Software Applications, Version 2,
delineates comprehensive guidance for the management of electronic
records in general. OMB Circular A-130 contains general guidance in
Appendix III related to the need for the management of records created
in a security infrastructure. However, A-130 does not specifically
address the management of records unique to a PKI.

Current guidance that addresses PKI-specific records is at a very high
level (CARAT[^4]) or only provides discussion of issues (PAG[^5]),
rather than setting forth specific requirements. Section 4.5.5 Records
Archival of the X.509 Certificate Policy and Certificate Practices
Framework (RFC 2527) dated January 3, 2002 (X.509 CP/CPS Framework),
only suggests a framework for managing records and appears to relate
exclusively to an operational system environment. This framework does
not provide specific guidance for managing records during the authorized
retention period, nor does it address the management of other PKI-unique
administrative records that are created outside of the operational
system, such as a Certificate Policy (CP), Certification Practice
Statement (CPS), or subscriber agreement.

Statements made in Section 4.5.5 Records Archival of the latest X.509
CP/CPS Framework and in several certificate policy drafts, such as from
the Federal Bridge Certification Authority (FBCA), Digital Signature
Trust (now part of Identrus) and VeriSign, suggest that government
agencies and PKI software vendors primarily are interpreting the term
"records archival" as meaning "backup" of the records in a PKI
operational system. This interpretation does not reflect the meaning of
"archival" and "archiving" as understood by records managers: a
trustworthy logical or physical repository of records that is protected
from loss, alteration, and deterioration for the full duration of the
authorized retention period. Satisfying various requirements for
protecting records as trustworthy evidence means that they should be
managed in an environment that supports the functionality required of a
recordkeeping system.

In essence, the current guidance and framework are either too general or
too narrowly focused to address the specific requirements for managing
PKI-unique administrative records, particularly regarding higher level
certificate environments where retention periods can run from ten to
twenty-plus years. Examples of key questions left unanswered by current
guidance are:

-   Since the X.509 CP/CPS Framework, Section 4.5.5 Records Archival
    appears to focus on operational PKI systems, what guidance is needed
    to manage records that are created or received outside of the
    operational system, such as paper records or records created and
    stored in electronic form by an office productivity application?

-   If the data that underlies records are being retained in database
    tables on the operational system and also being retained as the
    record file copy for the full retention period, what is needed on
    the operational system to manage the disposition of the records
    according to the authorized retention schedule?

-   What data elements (metadata) should be available on the operational
    system to allow for either:

    -   Managing the disposition of database records when the authorized
        retention period expires?

    -   Transferring database records to a recordkeeping system for
        management during longer term retention periods?

-   Should non-current or non-active PKI-unique records (e.g., expired
    digital certificates) be transferred from an operational system to a
    recordkeeping system and, if so, when and using what methods?

-   If records are transferred from an operational system to a
    recordkeeping system, what practices should be in place to ensure a
    complete and accurate transfer?

-   If the record file copy is maintained in a recordkeeping system,
    what practices need to be followed to preserve it for a long term
    retention period? The retention periods of each agency will vary
    according to their needs and should be developed by each agency and
    approved by NARA.

This guidance document is aimed at providing answers to these questions
in the form of perspectives, examples and guidance for managing
PKI-unique administrative records.

In an effort to determine the areas and issues that should be considered
when developing more detailed PKI-unique administrative records
management guidance, two Focus Groups sessions with participants from
multiple federal agencies were conducted on March 18 and 20, 2002. Key
issues identified in these Focus Groups have been addressed, as
appropriate, in Section 5. PKI-unique Records Management Guidance.

# 

# 3. Purpose and Scope 

This document provides records management guidance for both operational
and recordkeeping environments that will assist federal agencies in the
management of administrative records produced or received during the
planning, implementation, operation, audit or monitoring and
reorganization or termination of a PKI. This guidance supplements the
general electronic signature records management guidance issued by NARA
on October 18, 2000 entitled \"Records Management Guidance for Agencies
Implementing Electronic Signature Technologies.\"

The focus of this guidance is on PKI-unique administrative records (as
opposed to transaction records that incorporate the use of a public key
certificate or cryptographic key). This guidance may apply to both
classified and unclassified PKI-unique administrative records.
PKI-unique records are specific to the administrative functions related
to planning, implementing, operating, auditing or monitoring, and
reorganizing or terminating a PKI and are generally appraised as
temporary. Records that are not unique to a PKI are called "supporting
records." Supporting records are data or documents that are produced in
most implementations of a computer or communications security
infrastructure and are covered by existing records schedules or other
guidance. Examples of supporting records are hardware/software
documentation, training records, and personnel records (which are
specifically covered in a General Records Schedule). While this document
identifies both the unique and supporting functions and activities that
are part of a PKI, this guidance focuses specifically on records that
are unique to the PKI.

The following diagram delineates the specific group of records, namely
PKI-unique records (in the bolded box), that are the subject of this
guidance.

**Figure 1. Relationship of PKI-unique Records\
**

Several additional considerations define the scope of this guidance
document:

-   PKI records in general do not constitute a unique body of records
    although they are becoming of central importance to modern
    electronic business practices; nonetheless, basic records management
    regulations, standards and good practices all apply equally to
    records created or received in a PKI environment.

-   This guidance addresses the need for records management according to
    the particular mode within which the PKI-unique records are being or
    will be retained. Guidance is provided for two basic modes:

    -   *Operational System*: The need for records management guidance
        is especially critical for operational systems because little if
        any guidance exists and operational systems typically do not
        provide the functionality that is necessary for managing
        records. Operational systems maintain records in such a way that
        they can be accessed rapidly in the day-to-day activities of
        running a PKI, and potentially for a shorter time period than
        the authorized retention period. Many of the records that are
        required to establish the validity of a certificate or the
        operational integrity of the PKI at a given point in time are
        created or received and maintained on an operational system,
        such as the system operated by a Certification Authority (CA) or
        Registration Authority (RA). Since these records may be the
        official and possibly the only source of this information during
        part if not all of the authorized retention period, the
        operational system can be said to contain the "record file
        copy"[^6] of that information. Operational systems must ensure
        that the integrity of the records they manage is protected which
        may entail transferring records to a recordkeeping system before
        they are changed or replaced. Operational systems that currently
        do not meet the guidance outlined in Section 5.1 should be
        modified to conform.

    -   *Recordkeeping System*: A recordkeeping system typically does
        not "create" records, rather it receives electronic records from
        an operational PKI system or from an office productivity
        application (e.g., word processing) or tracks paper records, or
        scanned, digital images of paper records for the purpose of
        providing retention and disposition management as well as long
        term retrieval and reproduction of the record file copy for the
        authorized retention period. Guidance for a recordkeeping system
        is required in order to allow for operational records to be
        transferred to a long-term records management environment and
        for the management of records created or received outside of the
        operational system.

> Although the distinction between an operational system and a
> recordkeeping system is useful in this document, the professional
> community of PKI-system implementers should think through the
> implications of using the preceding definition as the working
> definition of recordkeeping system in other environments.

-   Furthermore, records management guidance is considered in the
    context of the following sources for a record file copy:

    -   *Operational system*: A record file copy of a specific record
        (e.g., a digital certificate) can be derived from relational
        database tables that have been populated from content submitted
        or entered via an Internet form or otherwise key-entered by a
        subscriber or administrative person, as well as automatically
        generated event log information.

    -   *Office productivity application*: Text-based documents that do
        not require a handwritten signature to be complete could be
        retained as the record file copy.

    -   *Paper*: Represents the record file copy when received into a
        PKI activity in paper form (such as documents from an applicant
        or other entity used for identity proofing) or if handwritten
        signatures need to be affixed to finalize the document or
        content, e.g., subscriber agreement, Certificate Policy (CP) or
        Certification Practice Statement (CPS). The documents may be
        printed from an operational system (such as from a database form
        or template) or from an office productivity application in order
        to apply handwritten signatures.

    -   *Digital Images*: A paper record also may be scanned and
        converted to a digital image that is retained and tracked in
        electronic form.

> These 'sources' highlight the diversity of record copies for
> PKI-unique administrative records. This is not intended as a
> recommendation to use these source systems as recordkeeping systems.
> PKI-unique administrative records should be separated from these
> source systems into recordkeeping systems, whenever possible.

-   This guidance assumes that the implementation, operation and
    management of a PKI may involve disparate technology platforms and
    architectures that can change over time. Therefore, the requirements
    and good practices delineated in this guidance are technology
    independent.

    This guidance is limited to defining and describing the requirements
    (or "what" is needed) for meeting records management regulations and
    good recordkeeping practices for PKI-unique administrative records.
    It does not define or suggest "how", i.e., which technology or
    products should be employed to implement the guidance.

    This guidance does not define or recommend retention periods. The
    retention periods for each agency may vary considerably based on the
    needs and requirements of the agency. Records schedules should be
    developed to meet the specific needs of each agency's PKI
    implementation and then approved by NARA. PKI-unique administrative
    records that are created or received in the course of government
    business may only be disposed of in accordance with instructions
    articulated in an approved records schedule. Agencies may contact
    their NARA appraisal staff for more information on scheduling PKI
    administrative records.

    This guidance does not address the area of records confidentiality
    since the requirements for the level and duration of confidentiality
    is very specific to the needs of each agency.

    Although individual PKI subscribers may be government employees,
    private citizens, or both; this guidance only addresses the
    maintenance of records by individual government subscribers. This
    guidance does not cover the maintenance of transaction records
    generated by such, as those records are not administrative in
    nature.

    This guidance is not intended to be a primer or educational tool for
    understanding cryptography or the technical details of how a PKI
    functions or operates. To adequately apply this guidance in planning
    for appropriate records management of PKI-unique administrative
    records there should be close cooperation between records management
    personnel and personnel implementing the PKI. Please refer to the
    Web site of the National Institute of Standards and Technology
    (NIST) for information related to cryptography and PKI technology in
    the form of Federal Information Processing Standards and
    informational NIST publications --
    http://csrc.nist.gov/pki/documents/.

# 4. PKI Records Producing Functions and Activities 

The objective of this section is to present a functional view of a PKI
administrative environment where records are created or received and
managed.

In the overall context of information resource management systems or
information technology, a PKI primarily is a cryptographic security
architecture and infrastructure and should be treated as such in the
planning, documentation, implementation and management of the PKI.
Certain functions and activities of a PKI generate records that may
entail unique management requirements. However, there are many
activities that merely support a PKI and produce records that are found
in other security infrastructures. In this context, the general
policies, procedures and requirements defined in Appendix III, Security
of Federal Automated Information Resources of OMB Circular No. A-130,
should be considered and applied, where applicable, in the management of
administrative records produced in conjunction with a PKI.

The major sources used in developing this overview of PKI functions and
activities are:

-   *Introduction to Public Key Technology and the Federal PKI
    Infrastructure,* 26 February 2001, National Institute of Standards
    and Technology

-   *Federal Agency Use of Public Key Technology for Digital Signatures
    and Authentication, NIST Special Publication 800-25*, October 2000,
    National Institute of Standards and Technology, Federal Public Key
    Infrastructure Steering Committee, Kathy Lyons-Burke

-   *Internet X.509 Public Key Infrastructure Certificate Policy and
    Certification Practices Framework*, July 2001

-   *ITU-T Recommendation X.509 ISO/IEC 9594-8: "Information
    technology - Open systems interconnection - The directory:
    Public-key and attribute certificate frameworks"*

-   *X.509 Certificate Policy For The Federal Bridge Certification
    Authority (FBCA),* June 18, 2002

-   *CARAT Guidelines for Constructing Policies Governing the Use of
    Identity-Based Public Key Certificates*; National Automated Clearing
    House Association (NACHA), The Internet Council Certification
    Authority Rating and Trust (CARAT) Task Force, January 14, 2000

-   *PKI Assessment Guidelines (PAG), v0.30*, Information Security
    Committee, Section of Science and Technology, American Bar
    Association, June 18, 2001

-   *WebTrust Program for Certification Authorities*, AICPA/CICA, August
    25, 2000, Version 1.0

-   *Access Certificates for Electronic Services (ACES) Request for
    Proposal*, General Services Administration, Amendment 00046, August
    27, 1999.

The remainder of this section presents an overview of the PKI
administrative record processes with examples of activities and related
records.

Figure 2 below broadly depicts the administrative functional processes
of a PKI and identifies example activities and example records produced
from these activities. These examples of activities and records are not
intended to be all inclusive, rather only to provide a perspective (see
Table 1. for a more comprehensive listing of PKI administrative
activities).

**Bolded** example activities and records represent the PKI-unique
activities that are the focus of this guidance.

Figure 2. PKI Administrative Processes -- Example Activities and Records

Table 1 presents a more complete list of example functions and
activities of a PKI and differentiates them as being either unique or
supporting a PKI environment. However, there may be other activities
that are unique to a particular PKI application or to a particular CA's
implementation. The records management guidance defined in Section 5 is
designed for the PKI-unique activities identified in this table and the
activities and records identified in Appendix B. Example PKI-unique
Administrative Records Series.

**Table 1. PKI Functions/Activities Differentiated As Either PKI-Unique
or Supporting**

+------------------------------------------+--------------+------------+
| **EXAMPLE RECORDS-GENERATING**           | **\          | **PKI\     |
|                                          | PKI --       | SU         |
| **FUNCTIONS/ACTIVITIES**                 | UNIQUE**     | PPORTING** |
+==========================================+==============+============+
| **Plan and Define PKI Environment**      |              |            |
+------------------------------------------+--------------+------------+
| -   Develop business case and            |              | X          |
|     requirements                         |              |            |
+------------------------------------------+--------------+------------+
| -   Perform risk/cost analysis           |              | X          |
|     (determine level vs. cost of         |              |            |
|     security infrastructure)             |              |            |
+------------------------------------------+--------------+------------+
| -   Authorize project                    |              | X          |
+------------------------------------------+--------------+------------+
| -   Develop project plan                 |              | X          |
+------------------------------------------+--------------+------------+
| -   Develop certificate policy (CP)[^7]  | X            |            |
+------------------------------------------+--------------+------------+
| -   Develop certification practice       | X            |            |
|     statement (CPS)[^8]                  |              |            |
+------------------------------------------+--------------+------------+
| -   Define certificate profile           | X            |            |
+------------------------------------------+--------------+------------+
| -   Concept of operations                | X            |            |
+------------------------------------------+--------------+------------+
| -   Develop PKI SOPs per CP and CPS      | X            |            |
+------------------------------------------+--------------+------------+
| -   Develop recordkeeping strategy and   | X            |            |
|     procedures per CP and CPS            |              |            |
+------------------------------------------+--------------+------------+
| -   Conduct insource/outsource           |              | X          |
|     (third-party) analysis               |              |            |
+------------------------------------------+--------------+------------+
| -   Establish personnel requirements     |              | X          |
+------------------------------------------+--------------+------------+
|                                          |              |            |
+------------------------------------------+--------------+------------+
| **Establish/Install/Start Up**           |              |            |
+------------------------------------------+--------------+------------+
| -   Select CA (internal or third party)  | X            |            |
+------------------------------------------+--------------+------------+
| -   Select RA (internal or third party)  | X            |            |
+------------------------------------------+--------------+------------+
| -   Review and approve third-party CA,   | X            |            |
|     RA CPS (as required)                 |              |            |
+------------------------------------------+--------------+------------+
| -   Conduct CA/RA accreditation          | X            |            |
+------------------------------------------+--------------+------------+
| -   Select/Establish certificate         | X            |            |
|     repository                           |              |            |
+------------------------------------------+--------------+------------+
| -   Establish certificate archive        | X            |            |
+------------------------------------------+--------------+------------+
| *Internal Install*                       |              |            |
+------------------------------------------+--------------+------------+
| -   Acquire software and hardware        |              | X          |
+------------------------------------------+--------------+------------+
| -   Install software                     |              | X          |
+------------------------------------------+--------------+------------+
| -   Install hardware                     |              | X          |
+------------------------------------------+--------------+------------+
| -   Test and validate hardware and       |              | X          |
|     software                             |              |            |
+------------------------------------------+--------------+------------+
| -   Test security procedures             |              | X          |
+------------------------------------------+--------------+------------+
| -   Create CA public key pair (Key       | X            |            |
|     Ceremony)                            |              |            |
+------------------------------------------+--------------+------------+
| *Third Party Execution*                  |              |            |
+------------------------------------------+--------------+------------+
| -   Develop/Execute third-party          |              | X          |
|     contractor agreement                 |              |            |
+------------------------------------------+--------------+------------+
| -   Develop contractual recordkeeping    | X            |            |
|     agreement                            |              |            |
+------------------------------------------+--------------+------------+
| -   Validate third-party systems         |              | X          |
+------------------------------------------+--------------+------------+
|                                          |              |            |
+------------------------------------------+--------------+------------+
| **Operate**                              |              |            |
+------------------------------------------+--------------+------------+
| -   Personnel: Clear (background         |              | X          |
|     checks), hire, and train             |              |            |
+------------------------------------------+--------------+------------+
| -   Identity proofing                    | X            |            |
+------------------------------------------+--------------+------------+
| -   Register users                       | X            |            |
+------------------------------------------+--------------+------------+
| -   Issue digital certificate            | X            |            |
|     (implicitly includes generate keys,  |              |            |
|     deliver public or private key, Prove |              |            |
|     possession of private key and verify |              |            |
|     public key)                          |              |            |
+------------------------------------------+--------------+------------+
| -   Establish Certificate Revocation     | X            |            |
|     List (CRL)                           |              |            |
+------------------------------------------+--------------+------------+
| -   Maintain CRL                         | X            |            |
+------------------------------------------+--------------+------------+
| -   Maintain CARL (CA Revocation List -- | X            |            |
|     FBCA)                                |              |            |
+------------------------------------------+--------------+------------+
| -   Renew certificates                   | X            |            |
+------------------------------------------+--------------+------------+
| -   Revoke/suspend certificates          | X            |            |
+------------------------------------------+--------------+------------+
| -   Install HW/SW updates                |              | X          |
+------------------------------------------+--------------+------------+
| *Interoperate (FBCA)*                    |              |            |
+------------------------------------------+--------------+------------+
| -   CA identity proofing                 | X            |            |
+------------------------------------------+--------------+------------+
| -   Policy mapping                       | X            |            |
+------------------------------------------+--------------+------------+
| -   Technical interoperability testing   | X            |            |
+------------------------------------------+--------------+------------+
| -   Cross certification agreements       | X            |            |
+------------------------------------------+--------------+------------+
| -   Border directory technical           | X            |            |
|     specifications                       |              |            |
+------------------------------------------+--------------+------------+
| **Audit/Monitor**                        |              |            |
+------------------------------------------+--------------+------------+
| -   Create audit trail data of PKI       | X            |            |
|     events, e.g. certificate revocation, |              |            |
|     certificate renewal, etc.            |              |            |
+------------------------------------------+--------------+------------+
| -   Monitor external security            |              | X          |
+------------------------------------------+--------------+------------+
| -   Investigate internal fraud or        |              | X          |
|     misconduct                           |              |            |
+------------------------------------------+--------------+------------+
| -   Internal audit of SW and security    |              | X          |
+------------------------------------------+--------------+------------+
| -   Internal audit of records management |              | X          |
|     practices                            |              |            |
+------------------------------------------+--------------+------------+
| -   External audit of HW/SW and security |              | X          |
+------------------------------------------+--------------+------------+
| -   Cross certification audits           | X            |            |
+------------------------------------------+--------------+------------+
|                                          |              |            |
+------------------------------------------+--------------+------------+
| **Reorganize or Terminate Operations**   |              |            |
+------------------------------------------+--------------+------------+
| -   Plan to terminate, consolidate or    | X            |            |
|     reorganize                           |              |            |
+------------------------------------------+--------------+------------+
| -   Approval                             | X            |            |
+------------------------------------------+--------------+------------+
| -   Notify subscribers                   | X            |            |
+------------------------------------------+--------------+------------+
| -   Transfer inactive keys and CRL to    | X            |            |
|     storage                              |              |            |
+------------------------------------------+--------------+------------+
| -   Transfer consenting subscribers      | X            |            |
|     certificates to new CA for           |              |            |
|     reissuance                           |              |            |
+------------------------------------------+--------------+------------+
| -   Revoke all certificates              | X            |            |
+------------------------------------------+--------------+------------+
| -   Shut down and dispose of RA and CA   |              | X          |
|     HW/SW                                |              |            |
+------------------------------------------+--------------+------------+
| -   Destroy CA private keys              | X            |            |
+------------------------------------------+--------------+------------+

# 5. PKI-Unique Records Management Guidance 

The PKI-unique records management guidance is segmented into two areas,
one for operational systems and one for recordkeeping systems (as
identified and previewed in Section 3. Purpose and Scope). Since a
record file copy is established as soon as data content or document
content is finalized or received, both the operational and recordkeeping
systems will have obligations for managing the records during the
authorized retention period. However, operational and recordkeeping
systems have fundamentally different purposes and require different
approaches for managing records:

1)  *Guidance for Operational Records*, Section 5.1: In most PKI
    operational systems, the active content (such as public key
    certificate data elements) and event information (audit log)
    typically are stored in relational database tables. While the data
    may be backed up for disaster recovery purposes, operational systems
    typically do not provide the necessary functionality to effectively
    manage records disposition nor other traditional records management
    functions. For example, a PKI system periodically may create a
    backup copy of "auditable events," but only the most recent three or
    four copies are kept because older copies are overwritten by the
    newer copies.\
    \
    Since little if any records management guidance exists for
    operational systems and they typically do not provide the
    functionality that is necessary for records management, the need for
    guidance is especially critical.\
    \
    In order to emphasize the necessity for implementing records
    management functionality in operational systems, the guidance for
    operational systems is intentionally kept separate from that of
    recordkeeping systems (even though there is some overlap in the
    individual guidance points).

2)  *Guidance for Recordkeeping Systems*, Section 5.2: The basis of the
    guidance for recordkeeping systems is to ensure that all trustworthy
    PKI-unique records are preserved as evidence for the authorized
    retention period. Guidance for a recordkeeping system is required
    for the following reasons:

-   To manage PKI-unique administrative records (and possibly other
    supporting PKI administrative records) that are not created or
    received by the operational system, such as paper records and
    electronic records that are created on office productivity
    applications or are scanned images of paper documents. The guidance
    for recordkeeping systems applies to all PKI-unique records
    independent of the media on which they are stored.

-   To provide for the transfer of operational system records to a
    recordkeeping system when the status of the record changes (no
    longer current or active) or certain events related to one or more
    records occur (e.g., expiration of a public key certificate).

A key premise for this guidance is that PKI-unique administrative
records do not constitute a new category of records that require a total
"reinvention" of life cycle records management policies and guidance.
While the records a PKI produces may be unique in their content and
application, the records management practices, as already embodied in
certain federal statutes, regulations, guidance and standards, still
apply.

The guidance tables in Sections 5.1 and 5.2 have two columns, 'Guidance'
and 'Source'. It is important to note, however, that the portions of the
*Code of Federal Regulations* cited in the 'Source' column do
[not]{.underline} articulate specific PKI-unique recordkeeping
requirements. In no cases should *CFR* citations in the 'Source' column
be an indication of a mandatory requirement; rather, one of potential
applicability warranting further examination. In all cases, potential
applicability of the cited sources should be discussed between the
Agency Records Officer and the NARA Appraisal Archivist. A source for
each guidance is cited and is drawn from the following references:

-   NARA "Records Management Guidance for Agencies Implementing
    Electronic Signature Technologies"

-   NARA 36 CFR 1234 Regulations

-   DoD 5015.2 Standard, Version 2

```{=html}
<!-- -->
```
-   ITU-T Recommendation X.509 ISO/IEC 9594-8

```{=html}
<!-- -->
```
-   FBCA X.509 Certificate Policy

-   GSA ACES Certificate Policy

-   Good practice

As a first consideration, existing regulations are cited as the source.
Where specific regulations currently do not exist to support the
guidance, then existing records management guidance or standard, such as
DoD 5015.2, is cited. Good practice is cited only in those instances
where no specific regulatory source or other official guidance, standard
or framework can be identified, yet where the guidance point is very
important to ensure proper management of records for the authorized
retention period. This is particularly the case in defining certain
records management guidance for operational systems and for the transfer
of records from an operational to a recordkeeping system. Good practice
guidance is derived from various records management studies and reports
and from knowledge and experience derived in the process of applying
good records management practices in commercial and public entities.

This guidance applies whether the PKI operational system and
recordkeeping system are controlled internally by an agency, by a
contractor or some mix of the two.

This guidance takes into account the stipulation to avoid "undue or
excessive recordkeeping requirements" as mandated by the Paperwork
Reduction Act and the CARAT Guidelines.[^9] In other words, this
guidance is kept to a minimum with the goal of achieving good records
management while allowing federal agencies as well as PKI operational
system vendors and recordkeeping system vendors to implement the
guidance without undue cost.

While intended to be comprehensive, this guidance may not have
identified all example PKI-unique functions, activities and example
records, nor have defined every element of guidance that will be
required in every agency PKI implementation. It is the responsibility of
each agency to ensure that they are retaining the appropriate PKI-unique
administrative records and are employing all necessary records
management guidance required to meet their regulatory, legal and
business needs. Once again, if you require assistance in applying this
guidance, contact your agency's NARA Appraisal Archivist in the Life
Cycle Management Division.

## 5.1 Guidance for Operational Systems

The guidance in this section is organized into thirteen separate
categories that encompass the PKI-unique activities identified in the
operations and audit components of Table 1. PKI Functions/Activities
Differentiated As Either PKI-Unique or Supporting.

A key operational systems requirement is to determine whether and when
PKI-unique administrative records will be transferred from an
operational system environment to a recordkeeping system environment. If
this is not immediately the case, at the very least the operational
system must ensure the integrity and authenticity of the information it
produces which is eventually to be transferred to a recordkeeping
system. As the operational system begins to provide some or all of the
functions of an recordkeeping system it will need to implement the same
guidance articulated here that applies to a stand-alone recordkeeping
system. Neither the FBCA X.509 CP nor 36 CFR specifically address this
point because in most instances the transfer may depend upon the
operational status of the records or the length of the retention period.
NARA regulations refer to "current" and "non-current records." The
latter includes records that are no longer required for current agency
business.[^10] From the perspective of PKI-unique records, one instance
of non-current records would be expired digital certificates.
Nonetheless, this section assumes that, at some point in time during the
authorized retention period, many PKI-unique administrative records will
be transferred from an operational system environment to a recordkeeping
system environment.

+-------------------------------------------------+--------------------+
| **5.1 Guidance for Operational Systems**        |                    |
+=================================================+====================+
| **Guidance**                                    | **Source**         |
+-------------------------------------------------+--------------------+
| 1.  **Records Capture**                         | 1.  NARA "Records  |
|                                                 |     Management     |
| > 1.1 Enable the capture, automatically where   |     Guidance for   |
| > possible, of accurate and complete records at |     Agencies       |
| > or near the time of an administrative event   |     Implementing   |
| > (e.g., issuance of a digital certificate,     |     Electronic     |
| > certificate renewal, certificate revocation,  |     Signature      |
| > etc.)                                         |     Technologies"  |
| >                                               |                    |
| > 1.2 Support automatic tracking of all         | 1.2 FBCA X.509 CP, |
| > activities relating to the capture of records | 4.51               |
| > in an audit trail or event log, including     |                    |
| > identification of the individual initiating   | 1.3 DoD            |
| > the activity and the time and date of the     | 5015.2[^11]        |
| > activity                                      |                    |
| >                                               |                    |
| > 1.3 Enable the population, automatically      |                    |
| > where possible, of records series title,      |                    |
| > retention period, and vital records status    |                    |
+-------------------------------------------------+--------------------+
| 2\. **Record Metadata**[^12]                    | 2.1 DoD            |
|                                                 | 5015.2[^13]        |
| > 2.1 The minimum attributes to be captured for |                    |
| > each PKI-unique event (both for audit log and | 2.2 DoD 5015.2     |
| > event data records, e.g., certificate         |                    |
| > issuance, CRL entries) to facilitate records  |                    |
| > management are:\                              |                    |
| > For Retrieval:\                               |                    |
| > - Common Name\                                |                    |
| > - Certificate Number\                         |                    |
| > - Date of Event                               |                    |
| >                                               |                    |
| > \- Distinguished Name (when available)\       |                    |
| > For Retention and Business Resumption         |                    |
| > Management\                                   |                    |
| > - Records Series Title\                       |                    |
| > - Records Series Retention Period\            |                    |
| > - Vital records status                        |                    |
| >                                               |                    |
| > 2.2 Restrict changes in metadata to           |                    |
| > authorized users                              |                    |
+-------------------------------------------------+--------------------+

+----------------------------------------------+-----------------------+
| 3\. **Records Retrieval**                    | 3.1 DoD 5015.2        |
|                                              |                       |
| 1.  Support searching and retrieving of      | 3.2 DoD 5015.2        |
|     records based upon one or more record    |                       |
|     metadata elements (e.g., common name or  | 3.3 Good Practice     |
|     retention period)                        |                       |
|                                              |                       |
| 2.  Support the presentation and             |                       |
|     interpretation (i.e., rendering) of any  |                       |
|     retrieved record (e.g., a digital        |                       |
|     certificate composed of multiple         |                       |
|     database attributes) in a usable form    |                       |
|                                              |                       |
| 3.  Support browsing and graphical           |                       |
|     navigation of retrieved records          |                       |
+----------------------------------------------+-----------------------+
| 4\. **Records Disposition**                  | 4.1 Good Practice     |
|                                              |                       |
| > 4.1 Provide a means to identify the        | 4.2 DoD 5015.2        |
| > retention status of records using the      |                       |
| > Record Series and/or Retention period      | 4.3 Good Practice     |
| > attributes identified in 2.1 above         |                       |
| >                                            | 4.4 Good Practice     |
| > 4.2 Enable time, event, and time-event     |                       |
| > dispositions[^14]                          | 4.5 Good Practice     |
| >                                            |                       |
| > 4.3 Provide a means to delete individual   | 4.6 FBCA X.509 CP,    |
| > records based on their retention status    | 4.6.3                 |
| >                                            |                       |
| > 4.4 Restrict the capability of defining    | 4.7 Good Practice     |
| > the record series title and retention      |                       |
| > period to authorized individuals           |                       |
| >                                            |                       |
| > 4.5 Enable changes in record series titles |                       |
| > and retention periods by authorized        |                       |
| > individuals                                |                       |
| >                                            |                       |
| > 4.6 Restrict records destruction commands  |                       |
| > and instructions to authorized users       |                       |
| >                                            |                       |
| > 4.7 Enable identification of records that  |                       |
| > have no assigned disposition (e.g., the    |                       |
| > Records Series Title or Records Retention  |                       |
| > attributes are missing or null value)      |                       |
| > including the ability to produce a list of |                       |
| > such records                               |                       |
+----------------------------------------------+-----------------------+
| 5.  **Records Integrity**                    | 5.1 36 CFR 1234.28    |
|                                              |                       |
|     1.  Prevent unauthorized access to       | 5.2 DoD 5015.2        |
|         records                              |                       |
|                                              | 5.3 Good Practice     |
|     2.  Prevent any changes to stored        |                       |
|         records -- protect the record for as | 5.4 FBCA X.509 CP,    |
|         long as it resides in the system     | 4.5.4                 |
|                                              |                       |
|     3.  Ensure that an auditable entry is    | 5.5 36 CFR 1234.28    |
|         captured for all events associated   |                       |
|         with extending the usability of      |                       |
|         records over time through media      |                       |
|         renewal or migration                 |                       |
|                                              |                       |
|     4.  Prevent modification to or deletion  |                       |
|         of event log entries                 |                       |
|                                              |                       |
|     5.  Maintain at least one up-to-date     |                       |
|         copy of all records and associated   |                       |
|         metadata off site in the event one   |                       |
|         or more records is corrupted or      |                       |
|         otherwise becomes unreadable         |                       |
+----------------------------------------------+-----------------------+
| 6.  **Records Storage (Operational)**        | 6.1 36 CFR 1234.28    |
|                                              |                       |
|     1.  Prevent unauthorized physical access | 6.2 FBCA X.509 CP,    |
|         to records                           | 4.6.2                 |
|                                              |                       |
|     2.  Support the backup of records with a | 6.3 36 CFR 1234.30    |
|         frequency that assures complete      |                       |
|         recovery                             | 6.4 36 CFR 1234.30    |
|                                              |                       |
|     3.  Maintain duplicate or back-up copies | 6.5 36 CFR 1234.30    |
|         of records in geographically         |                       |
|         separate repositories from the       | 6.6 36 CFR 1234.30    |
|         record copy                          |                       |
|                                              |                       |
|     4.  Use external labels with removable   |                       |
|         storage media to provide unique      |                       |
|         identification for the records,      |                       |
|         including date of creation           |                       |
|                                              |                       |
|     5.  Store records in a stable            |                       |
|         environment where the temperature    |                       |
|         and relative humidity are maintained |                       |
|         at 62° to 68° Fahrenheit and 35% to  |                       |
|         45% Relative Humidity                |                       |
|                                              |                       |
|     6.  Implement a comprehensive disaster   |                       |
|         recovery plan                        |                       |
+----------------------------------------------+-----------------------+
| 7.  **Vital Records**                        | 7.1 36 C FR 1236.22   |
|                                              |                       |
|     1.  Identify records that are essential  | 7.2 36 CFR 1236.24    |
|         to resumption of business if there   |                       |
|         is a natural disaster or system      | 7.3 36 CFR 1236.28    |
|         failure (see recommendation for      |                       |
|         including a Vital Record attribute   |                       |
|         in 2.1 above)                        |                       |
|                                              |                       |
|     2.  Ensure that vital records can be     |                       |
|         quickly and fully recovered          |                       |
|                                              |                       |
|     3.  Support the authorized destruction   |                       |
|         of vital records                     |                       |
+----------------------------------------------+-----------------------+
| 8.  **Records Audit Trail**                  | 8.1 Good Practice     |
|                                              |                       |
|     1.  Ensure that all actions related to   | 8.2 FBCA X.509 CP,    |
|         records retention and disposition    | 4.5.1                 |
|         are recorded as auditable events     |                       |
|                                              | 8.3 Good Practice     |
|     2.  For each records retention or        |                       |
|         disposition event, capture the       |                       |
|         following attributes as an auditable |                       |
|         event log record:                    |                       |
|                                              |                       |
| -   Common Name                              |                       |
|                                              |                       |
| -   Distinguished Name (when available)      |                       |
|                                              |                       |
| -   Certificate Serial Number                |                       |
|                                              |                       |
| -   A success or failure indicator           |                       |
|                                              |                       |
| -   Type of actionable event                 |                       |
|                                              |                       |
| -   Identity or entity or operator that      |                       |
|     caused the event                         |                       |
|                                              |                       |
| -   Date and time                            |                       |
|                                              |                       |
|     1.  Support the transfer of event log    |                       |
|         records to a recordkeeping system    |                       |
+----------------------------------------------+-----------------------+
| 9.  **Records Privacy**[^15]                 | 9.1 GSA ACES CP, 2.8  |
|                                              |                       |
|     1.  Physical and electronic security     | 9.2 GSA ACES CP, 2.8  |
|         methods must protect against         |                       |
|         unauthorized access to records and   | 9.3 GSA ACES CP, 2.8  |
|         associated metadata that are covered |                       |
|         by \[or subject to\] the Privacy Act | 9.4 GSA ACES CP, 2.8  |
|                                              |                       |
|     2.  Protect the privacy of records       |                       |
|         collected during identity proofing   |                       |
|         and applicant registration           |                       |
|                                              |                       |
|     3.  Support authorized revision or       |                       |
|         correction of any subscriber record  |                       |
|         or metadata information that is not  |                       |
|         correct                              |                       |
|                                              |                       |
|     4.  Ensure that subscriber records are   |                       |
|         used only for the purposes for which |                       |
|         they were collected                  |                       |
+----------------------------------------------+-----------------------+
| 10. **Records Security**                     | 10.1 FBCA X.509 CP,   |
|                                              | 4.6.3                 |
|     1.  Protect records from unauthorized    |                       |
|         physical and electronic access       | 10.2 FBCA X.509 CP,   |
|                                              | 5.1.2                 |
|     2.  Maintain controlled access to the    |                       |
|         repository where records are         | 10.3 FBCA X.509 CP,   |
|         physically stored                    | 5.1.2                 |
|                                              |                       |
|     3.  Maintain a physical access log that  | 10.4 Good Practice    |
|         is inspected periodically            |                       |
|                                              |                       |
|     4.  Support the use of techniques to     |                       |
|         detect unauthorized changes in       |                       |
|         records                              |                       |
+----------------------------------------------+-----------------------+
| 11. **Record Freezes/Holds\                  | 11.1 36 CFR 1228.54   |
|     **                                       |                       |
|                                              | 11.2 36 CFR 1228.54   |
|     1.  Check records against existing hold  |                       |
|         or freeze orders prior to authorized | 11.3 Good Practice    |
|         destruction of records to ensure     |                       |
|         that they are not inadvertently      |                       |
|         deleted                              |                       |
|                                              |                       |
|     2.  Optionally, extract records that     |                       |
|         have been identified as part of a    |                       |
|         hold or freeze order from the        |                       |
|         operational system and move to a     |                       |
|         recordkeeping system for management  |                       |
|         during the hold or freeze period     |                       |
|                                              |                       |
|     3.  Ensure that only authorized users    |                       |
|         may implement the guidance           |                       |
|         identified in 11.1 and 11.2 above    |                       |
+----------------------------------------------+-----------------------+
| 12. **Records Transfer to a Recordkeeping    | 12.1 Good Practice    |
|     System**                                 |                       |
|                                              | 12.2 Good Practice    |
|     1.  Support transfer of records and      |                       |
|         associated metadata to an electronic | 12.3 Good Practice    |
|         recordkeeping system on fulfillment  |                       |
|         of specified criteria, that may      | 12.4 Good Practice    |
|         include:                             |                       |
|                                              |                       |
| -   Cut-off date for non-current or          |                       |
|     non-active records such as the end of a  |                       |
|     quarter, the calendar year, fiscal year, |                       |
|     or other defined cycle                   |                       |
|                                              |                       |
| -   Elapsed time since the occurrence of a   |                       |
|     specified event such as the expiration   |                       |
|     of a digital certificate                 |                       |
|                                              |                       |
| -   Cut-off based upon the database          |                       |
|     supporting the PKI reaching a certain    |                       |
|     percentage of total storage capacity     |                       |
|                                              |                       |
|     1.  Generate an auditable event that     |                       |
|         documents the date of transfer of    |                       |
|         records to the recordkeeping system  |                       |
|                                              |                       |
|     2.  Confirm the integrity of transferred |                       |
|         records by verifying that no record  |                       |
|         was altered during their transfer to |                       |
|         a recordkeeping system               |                       |
|                                              |                       |
|     3.  All of the documentation and         |                       |
|         metadata (including the record       |                       |
|         series title, retention period, and  |                       |
|         vital records status) associated     |                       |
|         with the transferred records must be |                       |
|         transferred to the recordkeeping     |                       |
|         system.                              |                       |
+----------------------------------------------+-----------------------+
| 13. **Long Term Retention (Operational       | 13.1 36 CFR 1234.30   |
|     System)**                                |                       |
|                                              | 2.  Good Practice     |
|     1.  Ensure that records can be           |                       |
|         retrieved, viewed, reproduced, and   | 13.3 36 CFR 1234.30   |
|         processed during the authorized      |                       |
|         retention period                     | 13.4 36 CFR 1234.24   |
|                                              | (c)[^16]              |
|     2.  Adopt a storage medium that has both |                       |
|         a life expectancy of at least 20     | 13.5 Good Practice    |
|         years and multi-vendor support       |                       |
|                                              | 13.6 Good Practice    |
|     3.  Migrate records from old storage     |                       |
|         media to new storage media every ten |                       |
|         years                                |                       |
|                                              |                       |
|     4.  Transfer records to an electronic    |                       |
|         recordkeeping system as appropriate  |                       |
|         (see 12.1)                           |                       |
|                                              |                       |
|     5.  Validate the integrity of electronic |                       |
|         records after every preservation     |                       |
|         activity by confirming that no       |                       |
|         record has been changed              |                       |
|                                              |                       |
|     6.  Maintain a preservation history file |                       |
|         that documents all actions taken to  |                       |
|         preserve records                     |                       |
+----------------------------------------------+-----------------------+

##  

## 5.2 Guidance for Recordkeeping Systems

This guidance is organized into eleven separate categories that
encompass the PKI-unique activities identified in the example functions
and activities identified in Table 1. PKI Functions/Activities
Differentiated As Either PKI-Unique or Supporting.

The guidance for recordkeeping systems provides for the situation
whereby records being managed in an operational system that are no
longer considered current or active, or for other valid purposes, will
be transferred to a recordkeeping system in order to ensure that records
are preserved as evidence in a trustworthy and usable manner for the
authorized retention period. The recordkeeping system guidance also
applies to records that are not created or received by a PKI operational
system, such as paper records and electronic records that are created on
office productivity applications or are scanned images of paper
documents.

This recordkeeping guidance applies to all PKI-unique administrative
records independent of the media on which they are stored.

An example of a recordkeeping system is a Records Management Application
that has been certified under DoD 5015.2.

+------------------------------------------------+---------------------+
| **5.2 Guidance for Recordkeeping Systems**     |                     |
+================================================+=====================+
| **Guidance**                                   | **Source**          |
+------------------------------------------------+---------------------+
| 1.  **Records Capture**                        | 1.1 CFR 1234.22,    |
|                                                | 1234.24[^17];       |
| 1.1 Receive records from an operational system |                     |
| according to the following guidance:           | NARA "Records       |
|                                                | Management Guidance |
| > For records received where the origination   | for Agencies        |
| > source is database tables or proprietary or  | Implementing        |
| > raw data formats:                            | Electronic          |
| >                                              | Signature           |
| > \- Transfer sufficient metadata to support   | Technologies"       |
| > retrieval and retention management           |                     |
| >                                              | 1.2 Good Practice   |
| > \- Preferably be in or be converted to a     |                     |
| > technology neutral format (e.g. XML, RTF)    | 1.3 36 CFR          |
| >                                              | 1234.22[^18]        |
| > \- If not in a technology neutral format,    |                     |
| > then operational system software in which    | 1.4 Good Practice   |
| > the tables resided during the retention      |                     |
| > period to enable restoration and rendering   | 1.5 Good Practice   |
| > for reproduction must also be retained       |                     |
| >                                              | 1.6 36 CFR          |
| > For records received in                      | 1234.32[^19]        |
| > "as-rendered-for-viewing" format:            |                     |
| >                                              |                     |
| > \- Be in a technology neutral format (e.g.   |                     |
| > XML, RTF)                                    |                     |
| >                                              |                     |
| > \- Provide metadata sufficient to support    |                     |
| > retrieval and retention management in the    |                     |
| > form of a file that can be automatically     |                     |
| > loaded or manually entered into the          |                     |
| > recordkeeping system                         |                     |
| >                                              |                     |
| > 1.2 Accept import of PKI-unique record file  |                     |
| > copy in technology neutral formats (e.g.,    |                     |
| > XML, RTF) from office productivity systems   |                     |
| >                                              |                     |
| > 1.3 Support management of records in paper   |                     |
| > format, e.g., a CP or CPS that contains      |                     |
| > handwritten signatures                       |                     |
| >                                              |                     |
| > 1.4 Maintain an event log that documents the |                     |
| > date of transfer from an operational system  |                     |
| > to a recordkeeeping system                   |                     |
| >                                              |                     |
| > 1.5 Confirm integrity of records by          |                     |
| > verifying that no changes have occurred in   |                     |
| > records received from an operational system  |                     |
| >                                              |                     |
| > 1.6 Ensure that all of the metadata,         |                     |
| > supporting event log data, and information   |                     |
| > associated with a record are completely and  |                     |
| > accurately transferred                       |                     |
+------------------------------------------------+---------------------+
| 2.  **Records Metadata**                       | 2.1 Good Practice   |
|                                                |                     |
|     1.  Transfer the minimum attributes        | 2.2 Good Practice   |
|         specified in the guidance for          |                     |
|         Operational Systems to the             | 2.3 DoD 5015.2      |
|         recordkeeping system                   |                     |
|                                                | 2.4 DoD 5015.2      |
|     2.  For electronic records created in an   |                     |
|         office productivity system or for      | 2.5 Good Practice   |
|         paper records or scanned images of     |                     |
|         paper records, metadata should be      | 2.6 DoD 5015.2      |
|         captured that is consistent with the   |                     |
|         minimum requirements stated in Section | 2.7 Good Practice   |
|         5.1.2 Metadata. This is required in    |                     |
|         order to be able to retrieve all       |                     |
|         records related to a subscriber (e.g., |                     |
|         using common name) or to an auditable  |                     |
|         event. Metadata in addition to the     |                     |
|         operational metadata may be required   |                     |
|         such as for a CP or CPS that cannot be |                     |
|         identified with a common name or       |                     |
|         certificate number. Identification     |                     |
|         using PKI-unique attributes, such as   |                     |
|         the associated ObjectID of the record, |                     |
|         may be required.                       |                     |
|                                                |                     |
|     3.  Support the capability to view and     |                     |
|         print complete record metadata or      |                     |
|         user-specified portions of the         |                     |
|         metadata                               |                     |
|                                                |                     |
|     4.  Support assignment of a unique         |                     |
|         computer-generated record identifier   |                     |
|         for each record (electronic or paper)  |                     |
|         regardless of where the record is      |                     |
|         stored                                 |                     |
|                                                |                     |
|     5.  Support identification of record       |                     |
|         location in terms of the hard copy     |                     |
|         file or electronic location (system,   |                     |
|         path, and media)                       |                     |
|                                                |                     |
|     6.  Support generation of a human readable |                     |
|         and computer readable label to be      |                     |
|         attached to all paper records          |                     |
|                                                |                     |
|     7.  Restrict changes to records, files,    |                     |
|         sub-series, and series to authorized   |                     |
|         individuals                            |                     |
+------------------------------------------------+---------------------+
| 3.  **Records Classification**                 | 3.1 DoD. 5015.2     |
|                                                |                     |
|     1.  Support a classification scheme that   | 3.2 36 CFR          |
|         can represent records, files,          | 1234.24[^20]        |
|         sub-series, and series organized in a  |                     |
|         hierarchy with a minimum of four       | 3.3 36 CFR 1234.24  |
|         levels.                                |                     |
|                                                | 3.4 36 CFR 1234.24  |
|     2.  Logically aggregate individual records |                     |
|         into files (folders)                   | 3.5 Good Practice   |
|                                                |                     |
|     3.  Logically aggregate files into records | 3.6 Good Practice   |
|         sub-series                             |                     |
|                                                |                     |
|     4.  Logically aggregate records sub-series |                     |
|         into records series                    |                     |
|                                                |                     |
|     5.  Support browsing and graphical         |                     |
|         navigation of the files and            |                     |
|         classification scheme structure; and   |                     |
|         the selection, retrieval and display   |                     |
|         of electronic records and their        |                     |
|         contents through this mechanism.       |                     |
|                                                |                     |
|     6.  Maintain an audit trail of any         |                     |
|         records, files, sub-series, and series |                     |
|         that are reclassified so that their    |                     |
|         entire history can be reconstructed    |                     |
+------------------------------------------------+---------------------+
| 4.  **Records Retrieval**                      | 4.1 DoD 5015.2      |
|                                                |                     |
|     1.  Support retrieval and viewing or       | 4.2 Good Practice   |
|         reproduction of records based upon one |                     |
|         or more metadata attributes (e.g.      | 4.3 36 CFR 1234.24  |
|         common name, date-range, records       |                     |
|         series, etc)                           | 4.4 Good Practice   |
|                                                |                     |
|     2.  Support retrieval, and rendering of a  | 4.5 DoD 5015.2      |
|         specific PKI-unique record (e.g.,      |                     |
|         digital certificate or multiple        |                     |
|         digital certificates                   |                     |
|                                                |                     |
|     3.  Support the rendering of any retrieved |                     |
|         record (e.g., a digital certificate)   |                     |
|         in a form that is usable by humans     |                     |
|                                                |                     |
|     4.  Restrict retrieval of records based    |                     |
|         upon user access permissions           |                     |
|                                                |                     |
|     5.  Support browsing and graphical         |                     |
|         navigation of retrieved records        |                     |
+------------------------------------------------+---------------------+
| 5.  **Records Disposition**                    | 5.1 DoD 5015.2      |
|                                                |                     |
|     1.  Restrict the capability for defining   | 5.2 DoD 5015.2      |
|         retention periods, disposition         |                     |
|         actions, and the changing of retention | 5.3 DoD 5015.2      |
|         periods to authorized individuals      |                     |
|                                                | 5.4 DoD 5015.2      |
|     2.  Enable time, event, and time-event     |                     |
|         disposition                            | 5.5 DoD 5015.2      |
|                                                |                     |
|     3.  Enable automatic calculation of        | 5.6 Good Practice   |
|         destruction date where appropriate     |                     |
|                                                | 5.7 DoD 5015.2      |
|     4.  Support authorized changes in the      |                     |
|         disposition of records, files, records | 5.8 DoD 5015.2      |
|         sub-series, and records series         |                     |
|                                                | 5.9 DoD 5015.2      |
|     5.  Support authorized individuals to      |                     |
|         enter data indicating when a specified |                     |
|         event or time-event has occurred that  |                     |
|         affects the authorized retention of    |                     |
|         records                                |                     |
|                                                |                     |
|     6.  Support authorized individuals to view |                     |
|         the disposition attributes for each    |                     |
|         record, file, record sub-series, or    |                     |
|         records series                         |                     |
|                                                |                     |
|     7.  Support the identification and         |                     |
|         rendering of records, including        |                     |
|         associated metadata, that are eligible |                     |
|         for destruction                        |                     |
|                                                |                     |
|     8.  Support the requirement for a second   |                     |
|         confirmation from an authorized user   |                     |
|         before deleting records                |                     |
|                                                |                     |
|     9.  Produce documentation related to all   |                     |
|         authorized record destruction          |                     |
+------------------------------------------------+---------------------+
| 6.  **Records Integrity**                      | 6.1 36 CFR 1234.28  |
|                                                |                     |
|     1.  Prevent unauthorized access to records | 6.2 DoD 5015.2      |
|                                                |                     |
|     2.  Prevent any changes to stored records  | 6.3 FBCA X.509 CP   |
|         -- protect the record for as long as   | 4.5.4               |
|         it resides in the system               |                     |
|                                                | 6.4 36 CFR 1234.30  |
|     3.  Prevent modification or deletion to    |                     |
|         records history log entries            |                     |
|                                                |                     |
|     4.  Maintain a second up-to-date copy of   |                     |
|         all records and associated metadata,   |                     |
|         including history log entries, off     |                     |
|         site for records recovery              |                     |
+------------------------------------------------+---------------------+
| 7.  **Records History Log**                    | 7.1 Good Practice   |
|                                                |                     |
| 7.1 Ensure that all activities taken to ensure |                     |
| the continued usability of records through     |                     |
| media renewal or migration to a new technology |                     |
| platform are fully documented in a records     |                     |
| history log                                    |                     |
+------------------------------------------------+---------------------+
| 8.  **Records Privacy**[^21]                   | 8.1 GSA ACES CP,    |
|                                                | 2.8                 |
|     1.  Physical and electronic security       |                     |
|         methods must protect against           | 8.2 GSA ACES CP,    |
|         unauthorized access to records and     | 2.8                 |
|         associated metadata that are covered   |                     |
|         by \[or subject to\] the Privacy Act   | 8.3 GSA ACES CP,    |
|                                                | 2.8                 |
|     2.  Protect the privacy of records         |                     |
|         collected during identity proofing and | 8.4 GSA ACES CP,    |
|         applicant registration                 | 2.8                 |
|                                                |                     |
|     3.  Support authorized revision or         |                     |
|         correction of any subscriber record or |                     |
|         metadata information that is not       |                     |
|         correct                                |                     |
|                                                |                     |
|     4.  Ensure that subscriber records are     |                     |
|         used only for the purposes for which   |                     |
|         they were collected                    |                     |
+------------------------------------------------+---------------------+
| 9.  **Records Security**                       | 9.1 36 CFR 1234.28  |
|                                                |                     |
|     1.  Protect records from unauthorized      | 9.2 FBCA X.509 CP,  |
|         deletion                               | 5.1.2               |
|                                                |                     |
|     2.  Maintain controlled access to the      | 9.3 FBCA X.509 CP,  |
|         repository where records are stored    | 5.1.2               |
|                                                |                     |
|     3.  Maintain an access log that is         | 9.4 Good Practice   |
|         inspected periodically                 |                     |
|                                                | 9.5 Good Practice   |
|     4.  Block external access to electronic    |                     |
|         records through an electronic          | 9.6 36 CFR 1234.30  |
|         "firewall"                             |                     |
|                                                | 39.7 6 CFR 1236.26  |
|     5.  Use techniques to detect attempted or  |                     |
|         unauthorized changes or modifications  |                     |
|         to electronic records                  |                     |
|                                                |                     |
|     6.  Store duplicate or back-up copies of   |                     |
|         records in a geographically separate   |                     |
|         archives or recordkeeping storage      |                     |
|         facility                               |                     |
|                                                |                     |
|     7.  Implement a comprehensive disaster     |                     |
|         recovery plan                          |                     |
+------------------------------------------------+---------------------+
| 10. **Record Freezes/Holds**                   | 10.1 36 CFR 1228.54 |
|                                                |                     |
|     1.  Provide the capability for authorized  | 10.2 36 CFR 1228.54 |
|         individuals to identify records that   |                     |
|         are subject to a "hold" or "freeze"    | 10.3 36 CFR 1228.54 |
|         order                                  |                     |
|                                                |                     |
|     2.  Provide the capability to extend or    |                     |
|         suspend (freeze/hold) the retention    |                     |
|         period of records beyond their         |                     |
|         scheduled disposition                  |                     |
|                                                |                     |
|     3.  Provide the capability for authorized  |                     |
|         individuals to "unfreeze" records      |                     |
+------------------------------------------------+---------------------+
| 11. **Records Preservation\                    | 11.1 FBCA X.509 CP  |
|     **                                         | 4.62                |
|                                                |                     |
|     1.  Support the capability to ensure the   | 11.2 DoD 5015.2     |
|         usability and trustworthiness of       |                     |
|         records throughout their authorized    | 11.3 36 CFR 1234.28 |
|         retention through migration to new     |                     |
|         software recordkeeping system          | 11.4 Good Practice  |
|         applications, new storage media, or    |                     |
|         new vendor technology neutral formats\ | 11.5 36 CFR 1234.30 |
|         \                                      |                     |
|         OR                                     | 11.6 Good Practice  |
|                                                |                     |
|     2.  Where achieving the guidance in 11.1   | 11.7 Good Practice  |
|         is not possible, then retain PKI       |                     |
|         software and hardware necessary to     | 11.8 36 CFR 1234.30 |
|         read, search, retrieve, and render     |                     |
|         records                                | 36 CFR 1234.30      |
|                                                |                     |
|     3.  Prevent unauthorized                   | 11.10 Good Practice |
|         physical/electronic access to the      |                     |
|         facility where the records are stored  |                     |
|                                                |                     |
|     4.  Adopt a storage medium that has a      |                     |
|         predicted life expectancy of at least  |                     |
|         20 years and has multi-vendor support  |                     |
|                                                |                     |
|     5.  Renew storage media through copying    |                     |
|         (exact duplication of the bit stream)  |                     |
|         or reformatting records from old       |                     |
|         storage media to new storage media     |                     |
|         (e.g., 3480 tape to 3490 tape) every   |                     |
|         ten years                              |                     |
|                                                |                     |
|     6.  Confirm after each media renewal       |                     |
|         activity (e.g., copy) that no record   |                     |
|         has changed                            |                     |
|                                                |                     |
|     7.  Migrate records to a technology        |                     |
|         neutral file format (e.g., XML, RTF)   |                     |
|         that has substantial vendor support    |                     |
|                                                |                     |
|     8.  Store records in a stable environment  |                     |
|         where the temperature and humidity are |                     |
|         maintained at 62°to 68° Fahrenheit and |                     |
|         35% to 45% Relative Humidity           |                     |
|                                                |                     |
|     9.  Annually inspect a statistical sample  |                     |
|         of records in the storage facility to  |                     |
|         confirm that no catastrophic loss has  |                     |
|         occurred or may be impending           |                     |
|                                                |                     |
|     10. Create and maintain a preservation     |                     |
|         history log that documents all actions |                     |
|         taken to extend the usability of       |                     |
|         storage media                          |                     |
+------------------------------------------------+---------------------+

# Appendix A. Glossary, Acronyms and Abbreviations

**Definitions**

These definitions are derived from a variety of sources, including the
NARA GPEA guidance, DoD 5015.2, X.509 PKIX, X.509 Certificate Policy for
the Federal Bridge Certification Authority (FBCA), and glossaries in
several books relating to PKI and digital signatures.

**As-rendered-for-viewing record.** A Logical PKI Record (see
definition) that has been rendered in a human-readable, reproducible
format, and then saved in that format as the record file copy. For
example, a single event, such as a certificate revocation, would be
rendered as viewable and usable by inserting the appropriate data
elements into a database form or template, then reproducing that
representation in a format that could be preserved as the record file
copy (such as on paper or in XML format)

**Archives.** A physical or logical space independent of a production
environment where records are protected from loss, alteration, and
deterioration so that they may be used as trustworthy evidence for as
far into the future as is necessary.

**Certification Authority.** A trusted organization that can accept
certificate applications from subscribers, issues digital certificates,
and either maintains status information about certificates or arranges
for a trust third party to perform these services. Note: in some cases,
a CA may be defined in a more narrow sense, such as "The CA is
collection of computer hardware, software and the people who operate it"
(Housley and Polk, p44).

**Certificate Policy.** A written document that identifies the
applicability of a class of certificates with common security
requirements and sets forth the requirements that are appropriate for
applications or uses. PKIX has created an outline and guidance for the
content of certificate policy documents.

**Certification Practice Statement.** A written document that
articulates the practices that a Certification Authority employs in
issuing, managing, revoking, and renewing certificates. PKIX has created
an outline and guidance for the content of certificate practice
statements.

**Certificate Revocation List.** This is a Certificate Authority's
listing of unexpired certificates that cannot be trusted, i.e., revoked
certificates.

**Classification.** The systematic identification and arrangement of
business activities and/or *records* into categories according to
logically structured conventions, methods, and procedural rules
represented in a classification scheme that meets the specific business
needs of the agency. A PKI classification scheme could be designed that
defines records, record files or folders, records sub-series, and
records series for each of the primary PKI administrative functions.

**Common Name.** The given name of an individual or organization that
corresponds to its real world identity.

**Content.** The information that a record is meant to convey that may
consist of words, phrases, numbers, symbols, and so on.

**Context.** The organizational, functional, and operational
circumstances in which documents are created and/or received and used.
The placement of records within a larger records classification system
providing cross-references to other related records.

**Current Records.** Records that are necessary to conduct the current
business of an office and therefore are readily available for
consultation and reference.

**Cut off.** Breaking, or ending, files at regular intervals, usually at
the close of a fiscal or calendar year, to permit their disposal or
transfer in complete blocks or segments.

**Disposition.** Actions taken regarding records after they are no
longer required to conduct current Agency business. (See Non-current
record)

**Distinguished Name.** A unique name or character string for each
individual in a CA directory that unambiguously identifies each
subscriber.

**Emergency Operating Records. (**See **Vital Records)**

**Event Disposition.** A disposition instruction in which a record is
eligible for the specified disposition (transfer or destroy) upon or
immediately after the specified event occurs. No retention is applied
and there is no fixed waiting period as with the \"timed" or combination
\"time-event\" dispositions. An example of event disposition would be
\"Destroy when no longer needed for current operations\".

**Freeze.** The suspension or extension of the disposition of temporary
records that cannot be destroyed on schedule because of special
circumstances, such as a court order or an investigation, that requires
a temporary extension of the approved retention period.

**Good** **Practice.** Good practice indicates that no specific
regulatory or other official standard or framework can be cited, yet
where the guidance point is very important to ensure proper management
of records for the authorized retention period. The good practice
guidance cited in this document is derived from various records
management studies and reports and from knowledge and experience derived
from the application of records management practices in commercial and
public entities.

**Individual Subscriber.** A subscriber is an individual who has
generated a private/public key pair and has been issued a digital
certificate after being appropriately identified and authenticated as
part of a registration process.

**Integrity.** The integrity of a record refers to its being complete
and unaltered over time.

**Legal and Financial Rights Records.** (see Vital Records)

**Logical PKI Record.** A logical PKI record consists of data content
stored in relational database tables or other proprietary or raw data
format that exists as a physical record only at the time of rendering
for viewing, printing, or saving. If the rendered physical record is not
printed or saved then it ceases to exist as a physical entity. If the
data content has not changed then a specific logical record can be
retrieved and accurately rendered innumerable times. As an example, the
data representing the content of a digital certificate may exist in two
or more database tables but the digital certificate exists as a physical
entity only at the time that the data content is retrieved and used to
populate a digital certificate template. This digital certificate may
then be printed or saved as a physical entity.

**Metadata.** Data describing stored data, that is, data describing the
structure, content, and context, and other characteristics of electronic
records. Record profile data.

**Non**-**current Record.** Records that are no longer required to
conduct agency business and therefore are ready for final disposition.
(See also Current Record**)**

**Object ID.** A unique identifier for a Certificate Policy that is
registered with the American National Standards Institute so that a
certificate issuer and a certificate users (subscriber) can both
recognize and reference the policy.

**Office Productivity. Applications.** Software packages that perform a
variety of office support functions, such as word processing, desktop
publishing, spreadsheet calculations, electronic mail, facsimile
transmission and receipt, document imaging, optical character
recognition (OCR), work flow, and data management. These applications
are generally those used to generate, convert, transmit, or receive
business documents.

**Operational System.** The software and hardware system that performs
the day-to-day activities of running and maintaining a PKI, such as a
CA. In an operational system, the active content (such as public key
certificate data elements) and event information (audit log) typically
are stored in relational database tables. Since this content or event
data may be the official and possibly the only source of this
information for a period of time, the operational system can be said to
contain the "record file copy" of that information. While the data may
be backed up for disaster recovery purposes, operational systems
typically do not provide the functionality that is necessary to
effectively manage records disposition nor other traditional records
management functions.

**PKI Administrative Record.** PKI records that are created, used,
maintained, and preserved to support on-going management and operation.
They do not include subscriber transactions where a public key has been
used for signing or for another purpose.

**PKI Event.** Any administrative transaction conducted as part of a
PKI, such as: the issuance of a digital certificate, certificate
renewal, certificate revocation, etc.

**PKI Transaction Record.** A record that is created by the actual use
of a public key pair to digitally sign an electronic document or
consummate an electronic commerce transaction. This PKI-unique
administrative records management guidance does not cover PKI
transaction records.

**Record** **File Copy.** A "record file copy" is the final or
"official" copy that is retained according to a NARA-authorized
retention schedule.

**Recordkeeping** **System.** A manual or automated system in which
records are collected, organized, and categorized to facilitate their
preservation, retrieval, use, and disposition for the authorized
retention period.

**Records Schedule.** A document that provides mandatory instructions
for what to do with records (and nonrecord materials) no longer needed
for current Government business.

**Record Series.** File units or documents arranged in accordance with a
filing system or maintained as a unit because they result from the same
accumulation or filing process, the same function, or the same activity;
have a particular form; or because of some other relationship arising
out of their creation, receipt, or use.

**Registration Authority.** An entity that is responsible for
identification and authentication of certificate subjects prior to the
issuance of certificates, but which does not sign or issue certificates
(i.e., a Registration Authority is delegated certain tasks on behalf of
an authorized CA).

**Retention Period.** The length of time that records must be kept
before they are destroyed. Records not authorized for destruction have a
retention period of "permanent." A retention period is sometimes
referred to as "Authorized Retention" because NARA has approved the
disposition of the records.

**Structure.** The physical and logical format of a record and the
relationships between the data elements

**Technology Neutral Format.** An openly published file format that
supports data interchange and interoperability across heterogeneous
product lines, media, devices, and systems.

**Time Disposition.** A disposition instruction that specifies when a
record shall be cut off and when the fixed retention period is applied.
The retention period does not begin until after the records have been
cut off. Example: \"Destroy after two years -- cut off at the end of the
calendar (or fiscal) year; hold for two years; then destroy\".

**Time-Event Disposition.** A disposition instruction that specifies
that a record shall be disposed of a fixed period of time after a
predictable or specified event. Once the specified event has occurred,
then the retention period is applied. Example: \"Destroy three years
after close of case\".

**Vital Records.** Essential records that are needed to meet operational
responsibilities under national security emergencies or other emergency
or disaster conditions (emergency operating records) or to protect the
legal and financial rights of the Government and those affected by
Government activities (legal and financial rights records). Emergency
operating records are the type of vital records essential to the
continued functioning or reconstitution of an organization during and
after an emergency (a vital record may be both an emergency operating
record and a financial rights record).

**Acronyms and Abbreviations**

**ACES**. Access Certificates for Electronic Services (General Services
Administration)

**CA**. Certification Authority

**CARAT**. Internet Council Certification Authority Rating and Trust
(CARAT) Task Force

**CFR**. Code of Federal Regulations

**CMM**. Capability Maturity Model

**CP**. Certificate Policy

**CPS**. Certification Practice Statement

**CRL**. Certificate Revocation List

**ERM**. Electronic Records Management

**FPKISC**. Federal Public Key Infrastructure Steering Committee

**FBCA**. Federal Bridge Certification Authority

**LPWG**. Legal and Policy Working Group of the Federal Public Key
Infrastructure Steering Committee

**OID**. Object Identifier

**PAG**. PKI Assessment Guidelines (American Bar Association)

**PKIX**. Public Key Infrastructure (X.509) (Internet Engineering Task
Force Working Group)

**RA**. Registration Authority

# Appendix B. Example PKI-unique Administrative Records Series

+-----------------------------------+-----------------------------------+
| **Series 1: Define and Establish  |                                   |
| A Public Key Infrastructure**     |                                   |
+-----------------------------------+-----------------------------------+
| ##                                |                                   |
+-----------------------------------+-----------------------------------+
| **PKI-UNIQUE**                    |                                   |
+-----------------------------------+-----------------------------------+
| **EXAMPLE ACTIVITIES**            | **EXAMPLE PKI-UNIQUE RECORDS BY   |
|                                   | ACTIVITY**                        |
+-----------------------------------+-----------------------------------+
| 1.1 Determine that a PKI is to be | 1.1 Authorizing documentation and |
| established and create a project  | project implementation plan       |
| implementation plan               |                                   |
+-----------------------------------+-----------------------------------+
| 1.2 Designate the entity to serve | 1.2 Decision approval records,    |
| as Certification Authority (CA)   | selection criteria, assessment of |
|                                   | available CAs                     |
+-----------------------------------+-----------------------------------+
| 1.3 Create Certificate Policy     | 1.3 Approval of Certificate       |
| (CP), Certification Practice      | policy and Certification Practice |
| Statement(CPS), and other key     | Statement, and key operating      |
| operating documents               | documents                         |
+-----------------------------------+-----------------------------------+
| 1.4 Develop operating procedures  | 1.4 Operating procedures manual   |
| in accordance with Certificate    |                                   |
| Policy and Certificate Practice   |                                   |
| Statement                         |                                   |
+-----------------------------------+-----------------------------------+
| 1.5 Conduct a risk cost analysis  | 1.5 Risk analysis studies,        |
| as required by GPEA and OMB       | recommendations, guidelines,      |
| Implementation Guidelines         | implementation procedures         |
+-----------------------------------+-----------------------------------+
| 1.6 Develop records management    | 1.6 Records management policy,    |
| policy, including migration       | plans, and migration strategies   |
| strategy for records retained for | to be implemented                 |
| a long time                       |                                   |
+-----------------------------------+-----------------------------------+
| 1.7 Select the entity to serve as | 1.7 Decision approval records,    |
| Registration Authority (RA)       | selection criteria, assessment of |
|                                   | existing RAs                      |
+-----------------------------------+-----------------------------------+
| **PKI-SUPPORTING**                |                                   |
+-----------------------------------+-----------------------------------+
| **EXAMPLE ACTIVITIES**            | **EXAMPLE PKI-SUPPORTING RECORDS  |
|                                   | BY ACTIVITY**                     |
+-----------------------------------+-----------------------------------+
| 1.8 Establish personnel           | 1.8 Job descriptions, training    |
| requirements                      | requirements, background checks   |
+-----------------------------------+-----------------------------------+

  ----------------------------------- -----------------------------------
  **Series 2: Launch/Install A Public 
  Key Infrastructure**                

  **PKI-UNIQUE**                      

  **EXAMPLE ACTIVITIES**              **EXAMPLE PKI-UNIQUE RECORDS BY
                                      ACTIVITY**

  2.1 Install and validate            2.1 Installation records, testing
  Certification Authority hardware    procedures
  and software                        

  2.2 Install and validate            2.2 Installation Record, testing
  Registration Authority hardware and procedures
  software                            

  2.3 Obtain final approval from      2.3 Approval/rejection documents
  oversight or authorizing body       

  2.4 Create CA signature key         2.4 Signature key creation record
                                      and signature key use/ validity
                                      requirements

  **PKI-SUPPORTING**                  

  **EXAMPLE ACTIVITIES**              **EXAMPLE PKI-SUPPORTING RECORDS BY
                                      ACTIVITY**

  2.5 Test security procedures        2.5 Test results and sample
                                      certificates

  2.6 Validate certification          2.6 Procedures to follow in
  revocation procedure                revoking certificates and
                                      maintenance of a certification
                                      revocation list

  2.7 Establish backup and storage    2.7 Overall storage policies and
                                      practices, including backup
                                      procedures and data restoration
  ----------------------------------- -----------------------------------

  ----------------------------------- -----------------------------------
  **Series 3: Operate a Public Key    
  Infrastructure**                    

  **PKI-UNIQUE**                      

  **EXAMPLE ACTIVITIES**              **EXAMPLE PKI-UNIQUE RECORDS BY
                                      ACTIVITY**

  3.1 Certification Application       3.1 Verification of identity,
                                      identity documentation

  3.2 Certificate Issuance and Key    3.2 Notification of applicant and
  Generation                          transmitting the certificate to the
                                      subscriber or transmitting a
                                      protocol[^22] to a subscriber that
                                      permits local generation of a key
                                      pair and escrow of an encryption
                                      key.

  3.3 Certificate Acceptance          3.3 Subscriber acknowledgement of
                                      acceptance of conditions of use of
                                      the certificate, including
                                      subscriber obligations

  3.4 Certificate Validation          3.4 Identity of requester, identity
                                      of certificate, verification or
                                      denial, Online Certificate Status
                                      Protocol, reason for denial,
                                      time/date stamp

  3.5 Certificate Revocation          3.5 Confirmation that conditions
                                      that merit revocation have been
                                      met, Certificate Revocation List ,
                                      update frequency, individual
                                      performing update

  3.6 Certificate Suspension          3.6 Confirmation that conditions
                                      that merit certificate suspension
                                      have been met. Reasons for the
                                      suspension, individual performing
                                      update

  3.7 Certificate Replacement         3.7 Confirmation that conditions
                                      which merit certificate replacement
                                      have been met and subscriber
                                      acknowledgement of receipt of
                                      certificate replacement

  3.8 Certificate Renewal             3.8 Confirmation that the
                                      subscriber has met the CP/CPS
                                      conditions for renewal as well as
                                      subscriber authorization to renew a
                                      certificate that has not been
                                      revoked, suspended, or expired

  3.9 Create and maintain an event    3.9 Auditable events specified in
  log                                 FBCA X.509 Certificate Policy
  ----------------------------------- -----------------------------------

  ----------------------------------- -----------------------------------
  **Series 3: Operate a Public Key    
  Infrastructure**                    

  **PKI-SUPPORTING**                  

  **EXAMPLE ACTIVITIES**              **EXAMPLE PKI-SUPPORTING RECORDS BY
                                      ACTIVITY**

  3.10 Hire and train personnel       3.10 Job applications, training
                                      records, background checks

  3.11 Install and validate software  3.11 Decision documents,
  updates                             installation and test records

  3.12 Notify users of new software   3.12 Notification to affected
                                      users, contingency plan if new
                                      software does not replicate the
                                      functionality of old software
  ----------------------------------- -----------------------------------

  ----------------------------------- -----------------------------------
  **Series 4: Audit and Monitor a     
  Public Key Infrastructure**         

  **PKI-UNIQUE**                      

  **EXAMPLE ACTIVITIES**              **EXAMPLE PKI-UNIQUE RECORDS BY
                                      ACTIVITY**

  4.1.1 Periodic internal review of   4.1.1 Audit report, reports on
  auditable events specified in X.509 compliance/non-compliance, remedial
  ACES Policy                         actions

  4.1.2 External review of auditable  4.1.2 Audit report, reports on
  events specified in X.509 ACES      compliance/non-compliance, remedial
  Policy                              actions

  4.1.3 Monitor compliance with       4.1.3 Reports on compliance audits,
  security requirements specified in  remedial actions
  the CPS and other operating         
  procedures                          

  **PKI-SUPPORTING**                  

  **EXAMPLE ACTIVITIES**              **EXAMPLE PKI-SUPPORTING RECORDS BY
                                      ACTIVITY**

  4.2.1 Investigate internal fraud or 4.2.1 Investigation reports,
  misconduct                          disciplinary actions, remedial
                                      actions taken

  4.2.2 Internal audit of software    4.2.2 Audit report, reports on
  and systems security                compliance with recommendations in
                                      audit report

  4.2.3 External audit of software    4.2.3 Audit reports based upon PAG
  and system security                 guidance, reports on compliance
                                      with recommendations in audit
                                      report
  ----------------------------------- -----------------------------------

  ----------------------------------- -----------------------------------
  **Series 5:                         
  Terminate/Consolidate/Reorganize A  
  Public Key Infrastructure**         

  **PKI-UNIQUE**                      

  **EXAMPLE ACTIVITIES**              **EXAMPLE PKI-UNIQUE RECORDS BY
                                      ACTIVITY**

  5.1 Determine that PKI is to be     5.1 Studies, reports,
  terminate, consolidate, or          recommendation, and action
  reorganized                         documents

  5.2 Obtain approval (if required)   5.2 Decision documents
  from appropriate entities to        
  terminate, consolidate, or          
  reorganize                          

  5.3 Notify subscribers              5.3 List of
                                      individuals/organizations to whom
                                      notice has been given, several
                                      examples of notices, identification
                                      of new CA, and option for
                                      subscribers to elect or reject the
                                      CA

  5.4 Transfer inactive keys and      5.4 Transfer document attesting to
  revocation certificate list to      legal custody along with access
  storage repository                  rights

  5.5 Transfer consenting             5.5 Transfer notices, list of
  subscribers' certificates and       subscribers who have agreed to use
  related material to new Certificate the new Certificate Authority
  Authority                           

  5.6 Destroy sensitive records       5.6 Approved disposal of records in
  involving privacy                   accordance with an authorized
                                      records schedule

  5.7 Shutdown and disposal of RA     5.7 Shutdown report with signoffs
  hardware and CA software            from appropriate individuals
  ----------------------------------- -----------------------------------

[^1]: *Introduction to Public Key Technology and the Federal PKI
    Infrastructure,* 26 February 2001, National Institute of Standards
    and Technology

[^2]: The software and hardware system that performs the day-to-day
    activities of running and maintaining a PKI, such as a CA (see
    Appendix A).

[^3]: A manual or automated system in which records are collected,
    organized, and categorized to facilitate their preservation,
    retrieval, use, and disposition for the authorized retention period
    (see Appendix A).

[^4]: *CARAT Guidelines for Constructing Policies Governing the Use of
    Identity-Based Public Key Certificates*; National Automated Clearing
    House Association (NACHA), The Internet Council Certification
    Authority Rating and Trust (CARAT) Task Force, January 14, 2000

[^5]: *PKI Assessment Guidelines (PAG), v0.30*, Information Security
    Committee, Section of Science and Technology, American Bar
    Association, June 18, 2001

[^6]: A "record file copy" is the final or "official" copy that is
    retained according to a NARA-authorized retention schedule.

[^7]: The Certificate Policy should delineate the policies for
    operational and record keeping systems.

[^8]: The Certification Practice Statement should state the practices
    that will be employed to manage PKI-unique records.

[^9]: "CARAT Guidelines, Guidelines for Constructing Policies Governing
    the Use of Identity-Based Public Key Certificates," (National
    Automated Clearing House Association -- NACHA, January 14, 2000): p.
    113.

[^10]: NARA regulations do not specifically define when current (active)
    records become non-current (inactive) records because this is
    largely seen as a records disposition issue that is determined by
    the business needs and legal requirements of each agency. The notion
    of current v. non-current records is rooted in the management of
    paper records where, after some elapse of time, records that were
    infrequently accessed could be moved from costly office space to
    less costly storage areas. There is a parallel with electronic
    records stored in an operational system where, after a period of
    time when the records are no longer frequently accessed or when they
    expire (such as an expired digital certificate), they could be moved
    to a recordkeeping system for longer term management and access.

[^11]: DoD 5015.2 C2.2.3.10 establishes the precedent for the concept of
    population of metadata elements relevant for record capture.

[^12]: These metadata attributes are intended to provide a means for
    managing retention in the operational environment, or to ensure that
    these critical records management attributes are available should
    the operational records be transferred at a later date to a
    recordkeeping environment.

[^13]: DoD 5015.2 C2.2.3.2 establishes a precedent of specifying
    mandatory recordkeeping metadata elements.

[^14]: Time disposition occurs when records are immediately available
    for disposition after the conclusion of a fixed period of time.
    Event disposition is when records are eligible for disposition
    immediately after the conclusion of an event (e.g., destroy when
    superseded). Time-event disposition occurs when a retention period
    is triggered by an event (e.g. transfer digital certificates to a
    recordkeeping system 60 days after expiration of the certificate).

[^15]: GSA ACES CP, Section 2.8 states: \"The Authorized CA shall
    protect the confidentiality of personal information regarding
    Subscribers that is collected during the applicant registration,
    ACES Certification application, authentication, and certificate
    status checking processes in accordance with the Privacy Act of
    1974, and Appendix (I and) III to OMB Circular A-130.\" The
    Department of Justice is the designated lead agency in the
    interpretation of Privacy Act requirements.

[^16]: This guidance is based upon the precedent of 36 CFR 1234.24 for
    transferring scheduled e-mail messages from an operational e-mail
    system to recordkeeping system.

[^17]: This guidance is based upon the precedent of 36 CFR 1234.24 for
    transferring scheduled e-mail messages from an operational e-mail
    system to a recordkeeping system.

[^18]: Citation of 36 CFR 1234.22 is based on its providing guidance for
    creating and managing text documents in an electronic recordkeeping
    system.

[^19]: Citation of 36 CFR 1234.32 is based on its providing guidance for
    the retention and disposition of electronic records.

[^20]: Citation of 36 CFR 1234.24 is based on its providing standards
    for the management of email records.

[^21]: See footnote 15

[^22]: ^1^ This process may include the generation of an encryption key
    by the CA which is escrowed. This escrowed key may be maintained as
    an administrative record as part of the key history file.