TO: TACDFIPSFKMI Members DATE: 01 OCT 97

I apologize for being late (one day late as I write this) with this
document. I want you to know that the members of Working Group 1 (aka
Frameworks) submitted their input in sufficient time to put this
together and get it out on time. It was my travel schedule that
prevented us from meeting the target date and prevented me from
completing the final tasks listed below. Roger French

**1.1 OVERVIEW**

## Overview

##  Below is version 2.0 of the Overview and it is for review by the TACDFIPSFKMI. It represents the changes I thought were appropriate after reviewing the NIST comments, Santosh's mark-up, and the notes I took, and can barely read, at the Seattle meeting. Please review this before the Orlando meeting in less than two weeks.. NOTE: I have to add something about Interoperability to the Overview, but have not done that yet. Also note that the paragraph on supporting components will need to be changed to align with the whatever components are described in section 1.3. 

## 

The Federal Government has a right and a responsibility to protect the
information and data contained in, processed by, and transmitted between
its IT systems. Ownership of the information is often shared with
individuals, companies, and organizations and therefore requires that
the government protect that information on its own behalf and on behalf
of those co-owners. That protection needs to be meet Federal Government
standards and the standards of those co-owners.

Protection of information on IT systems is complicated and evolving. One
aspect of such protection is the requirement that certain information or
information in specific states provide its own protection. An example of
such a state is information in transit on the Internet. The method of
such self protection is encryption, the process whereby the information
is scrambled using methods which make it easy for authorized entities to
decrypt and difficult for all others to decrypt. When sufficient
strength and protection of the decryption key is provided, encryption
can adequately protect the information from disclosure to unauthorized
parties. However, the unavailability, loss, or corruption of those keys
will also prevent disclosure to authorized parties. The solution to this
problem is to provide a method of recovering decryption keys by
authorized parties.

The generation, storage, and recovery of decryption keys is a complex
process. This process needs to be rigidly defined, stringently
implemented, and conscientiously managed and operated. Such requirements
are needed to ensure that the process provides its proposed benefit and
prevents an inappropriate increase in vulnerability. The FIPS addresses
those aspects of the encryption process, the recovery process, and the
supporting components of both processes.

The encryption process described in the FIPS includes their components,
their actions and interfaces, and the sum of their interactions. Such
components include the Encrypting Party (often the Sender for
transmitted data,) the Encrypted Data Medium, the Decrypting Party
(often the Receiver for transmitted data,) the Recovery Data Medium, and
the Key Recovery Agent. It should be noted that the preparation of
recovery information is the responsibility of the encryption process,
not the recovery process.

The recovery process described in the FIPS includes processes and
requirements for recovery requesters; structure, process and
requirements including performance of the key recovery agents; and a
description of the interactions between the parties involved in the
recovery.

The supporting components described in the FIPS are integral parts of
the key recovery process, and are needed to ensure the functionality of
the key recovery process and the security of the keys. Such supporting
components include the vendor products for the users, for the key
recovery agents, and for the requesters. They also include the
registration agent or process, the methods to authenticate the key
sources, licensing agents, and system policy authorities.

To further the understanding of the overall key recovery process,
examples will be presented to describe general key recovery methods.
Such examples include Stored Files, Encrypted Email, Real-time
Communications, and the recovery of a specific key.

NOTE: It should be noted that the output of the TACDFIPSFKMI (TAC) is
technical advice to the Secretary of Commerce regarding the technology
of and technical use of key recovery. The TAC has not addressed and will
not provide policy advice regarding the extent of usage of key recovery
on any IT systems nor the scope of systems covered by the proposed FIPS.

***For Your Consideration: "It is not the purpose of the FIPS to make
existing systems that do not interoperate, interoperate now with Key
Recovery." Does a statement like that belong in the FIPS. If so, is it
enough to state it early, perhaps in the overview. The Overview, and
perhaps other parts of Section 1.0, need***

***It is the intent of the FIPS that Key Recovery shouild not effect the
interoperability of systems, protocols, or applications. Any entities
that interoperate without Key Recovery should, if possible, interoperate
with it. The exception is when either the Key Recovery systems technical
structure requires less or no interaction or when the application and
its usage either require no interoperation or when such interoperation
will preclude a specific requirement or capability of the system or of
the implementation.***

**1.2 Key Recovery System**

A key recovery system enables authorized persons to access plaintext
from encrypted data when the decryption key is not otherwise available.
Key recovery is a broad term that applies to many different techniques.

The key recovery system model defines the minimal set of system
components needed to perform key recovery. The key recovery system model
is a generalized model, which supports a wide variety of different key
recovery techniques and data applications. The data applications
supported by the key recovery system model include:

-   Interactive communication sessions.

-   Store-and-Forward applications.

-   Data Storage.

The key recovery system model contains the following components:

-   System A (Encryption-Enabled)

-   System B (Encryption-Enabled)

-   Encrypted Data Medium

-   Recovery Information Medium

-   Requester

-   Key Recovery Agent(s)

The model depicts a key recovery system capable of encrypting data,
creating key recovery information \-- for the key to be recovered \--
and recovering the key from the key recovery information, for an
authorized request.

1.2.1 Encryption and Enablement Process

The four components \-- System A, System B, Encrypted Data Medium, and
Recovery

Information Medium \-- collectively define a subset of the model called
the

\"Encryption and Enablement Process.\"

The process of encrypting data and creating key recovery information is
performed by one or more encryption-enabled systems, denoted in the key
recovery system model as System A and System B. An encryption-enabled
system is one that can communicate using cryptography, i.e., it can
encrypt and decrypt data. It is assumed that System A or System B or
both Systems A and B have the capability to create key recovery
information. However, the key recovery system model does not prescribe
which system or systems must have a key recovery capability. The
encrypted data and key recovery information produced by these systems
are maintained on some appropriate medium, denoted in the key recovery
system model as the Encrypted Data Medium and Recovery Information
Medium, respectively. The Recovery Information Medium may be the same or
different from the Encrypted Data Medium.

1.2.1.1 Components and Their Interactions

1.2.1.1.1 Systems A & B

Systems A and B are systems capable of communicating with each other
using cryptography (i.e., they are encryption-enabled).

Each system contains a cryptographic application capable of interacting
with a like cryptographic application in the other system. Each system
contains a cryptographic subsystem that provides a set of cryptographic
services to the cryptographic application. At least one system (A or B)
must have a key recovery subsystem capable of providing a set of key
recovery services to the cryptographic application which, at a minimum,
includes services for creating key recovery information. It is also
possible for one system (A or B) to implement a set of key recovery
services capable of \"handling\" the key recovery information provided
by another system, but has no capability to create key recovery
information by itself. A system that meets this minimal requirement is
said to be key recovery aware. Thus, the standard assumes that two
systems can interoperate in compliance with the standard as long as both
systems are key recovery aware and at least one of the systems is
capable of creating key recovery information.

NOTE: In situations where it is convenient to show a directional flow of
the encrypted data, System A may be optionally labeled \"Sender\" or
\"Encryptor\" and System B may be optionally labeled \"Receiver\" or
\"Decryptor.\" However, the key recovery system model itself is intended
to be a generalized model, covering interactive sessions, where each
system may be both a sender and receiver.

1.2.1.1.1.1 Sender

The Sender is the system that encrypts data, either for storage or for
transmission to a Receiver.

The Sender may or may not create key recovery information.

Typically, the Sender will create key recovery information (i.e., enable
key recovery) in order to comply with an established key recovery
policy. The key recovery policy specifies the conditions under which key
recovery information must be created; the policy may also indicate the
allowable key recovery agents, and how and where the key recovery
information must be maintained (stored or transmitted). However, the
Sender may elect to create key recovery information in situations where
key recovery is deemed desirable, although not specifically required by
the Sender\'s key recovery policy. The Sender may also create key
recovery information for the Receiver, in situations where the Receiver
is incapable of creating its own key recovery information. If key
recovery is not required by the key recovery policy and the Sender does
not desire key recovery, then no key recovery information will be
created.

1.2.1.1.1.2 Receiver

The Receiver is the system that receives encrypted data and decrypts
its.

The Receiver may or may not create key recovery information.

Typically, the Receiver will create key recovery information in order to
comply with an established key recovery policy (see also 1.2.1.1.1.1
Sender). However, the Receiver may elect to create key recovery
information in situations where key recovery is deemed desirable,
although not specifically required by the Receiver\'s key recovery
policy. The Receiver may also create key recovery information for the
Sender, in situations where the Sender is incapable of creating its own
key recovery information. If key recovery is not required by the key
recovery policy and the Receiver does not desire key recovery, then no
key recovery information will be created.

In situations where key recovery information is received from the
Sender, the Receiver may perform a verification step to validate the
correctness or integrity of the key recovery information. The
verification step could consist of checking all or part of the received
key recovery information, or any other information that could be used
beneficially to determine the correctness or integrity of the received
key recovery information.

In situations where the Receiver creates key recovery information for
the Sender, the Sender may receive the key recovery information and
perform a simiilar verification step to validate the correctness or
integrity of the key recovery information.

1.2.1.1.2 Encrypted Data Medium

The encrypted data medium represents the \"location\" where the
encrypted data is stored or communicated, such as a storage device or
communications channel. The key recovery system model does not prescribe
how or where the encrypted data must be stored or communicated, as long
as it can be accessed by an authorized Requester.

The key recovery system model assumes that both systems (A and B) can
access to the Encrypted Data Medium.

1.2.1.1.3 Recovery Information Medium

The recovery information medium represents the \"location\" where the
recovery information is stored or communicated, such as a storage device
or a communications channel. The key recovery system model does not
prescribe how or where the recovery information must be stored or
communicated, as long as it can be accessed by an authorized Requester.

The recovery information itself can be managed or handled in a variety
of ways. It may exist for only a brief time, during electronic
transmission, or it may exist for a relatively long time, on a storage
device.

The key recovery system model assumes that both systems (A and B) are
able, where needed or desired, to access the Recovery Information
Medium.

1.2.1.2 Interaction Summary

Both systems (A and B) have access to the Encrypted Data Medium. Thus,
the key recovery system model simultaneously embraces the following
three separate applications: (a) interactive session, (b)
store-and-forward, e.g., E-mail, and (c) file storage.

Both systems (A and B) are able to access the Recovery Information
Medium. Thus, the key recovery system model embraces key recovery
systems where one or both systems have the capability to create recovery
information and one or both systems can make that recovery information
available by putting it on a Recovery Information Medium. The model also
embraces key recovery systems where one or both systems have access to
the recovery information created by the other system, thus allowing each
system to potentially validate the recovery information created by the
other system in order to ensure that it is authentic.

In a typical interaction scenario, System A (acting as a sender)
encrypts an e-mail message and sends it to System B (acting as a
receiver). In this case, the Encrypted Data Medium is a communications
path. System A also creates key recovery information, which is appended
to the encrypted message in the form of a message header. In this case,
the Recovery Information Medium is also the same communications path
used to transmit the encrypted data, i.e., the Encrypted Data Medium and
the Recovery Information Medium are one and the same. Upon receipt of
the encrypted message, System B validates the recovery information and
decrypts the message.

1.2.2 Recovery Process

The Requester and the Key Recovery Agents form another subportion of the
key recovery system model called the \"Recovery Process.\"

The process of recovering a key from the key recovery information is
handled by additional key recovery system components \-- denoted in the
key recovery system model as Requester and Key Recovery Agents. An
authorized Requester \-- with access to the Encrypted Data Medium and
the Recovery Information Medium \-- interacts with one or more Key
Recovery Agents to recover the cryptographic key from the key recovery
information.

A recovered key can then be used to recover the data, either directly or
indirectly. The data encrypting key is said to be recovered directly
when the recovered key is the same key that was used to encrypt the
data. Indirect key recovery occurs when the recovered key is a key
encrypting key which is then used to decrypt or recover the data
encrypting key.

1.2.2.1 Components and Their Interactions

1.2.2.1.1 Requester

The Requester is an entity who seeks to recover information that will
allow the decryption of encrypted data. To this end, the Requester
always performs the step of key recovery; the step of data recovery is
optional.

The Requester is defined as the entity who interacts with one or more
Key Recovery Agents \-- using key recovery information \-- to recover a
key. Many different algorithms and procedures can be used to recover a
key. For example, the Requester might interact with one Key Recovery
Agent to recover a whole key, or the Requester might interact with two
or more Key Recovery Agents to recover several pieces of information
that, in turn, permit the Requester to recover or reconstruct the whole
key.

The Requester must always have access to the recovery information
corresponding to the (desired) key to be recovered. However, the
Requester will need access to the encrypted data only if it performs the
additional step of data recovery.

A request for a key recovery service, made by a Requester to a Key
Recovery Agent, must be an authorized request. In other words, the
Requester issuing a request for key recovery service must have a legal
and lawful right to access the data, in whole or in part, that can be
decrypted, either directly or indirectly, using the key which is
recovered from the given set of key recovery information. Furthermore,
the Requester must prove its right to access that data.

Those with the right to access the data \"unlocked\" by a given set of
key recovery information would include the individual or enterprise that
\"owns\" the data, and any person or party with a lawful right to access
the data, e.g., law enforcement acting under the authority of a valid
warrant or court order, or an agent acting under the authority of
another party with a right-of-access to the data.

NOTE: The functions performed by a Requester may be separated and
performed by two or more components, if doing so would be advantageous.
For example, it may be more cost effective for an individual or
enterprise to employ the services of a trusted third party who assumes
the role of the Requester on behalf of the individual or enterprise.
Under such an arrangement, the Requester could recover the key, which in
turn would be provided to the individual or enterprise, and the
individual or enterprise could then recover the data using the recovered
key.

1.2.2.1.2 Key Recovery Agent

The Key Recovery Agent is a trusted entity who performs a recovery
service in response to an authorized request made by a Requester. Before
honoring such a request, the Key Recovery Agent authenticates the
Requester\'s right to receive the requested recovery service. The
recovery service consists of processing all or part of the recovery
information provided by the Requester to the Key Recovery Agent, and
returning an output value to the Requester.

The algorithm for processing the recovery information is dependent on
the algorithm originally used to create the recovery information, i.e.
it is algorithm specific. There are also many algorithms for creating
and processing the recovery information. For example, the output value
calculated by the Key Recovery Agent could be a whole key, or it could
be a key part or piece of information that the Requester will use in
combination with other recovered parts or pieces of information to
reconstruct or recover the whole key.

Note: The present standard does not prescribe a particular algorithm or
method for creating and processing the recovery information, or for
recovering or reconstructing the key.

NOTE: It is assumed that, where necessary, the components in the key
recovery system model can make use of cryptography to protect the
secrecy and integrity of the information transmitted from one component
to another.

1.2.2.2 Interaction Summary

In a typical key recovery scenario, the Requester \-- who is provided
with, or who acquires, a set of key recovery information, and who can
\"prove\" its right to access the data \"unlocked\" by the key to be
recovered from that key recovery information \-- sends a request for key
recovery service to one or more Key Recovery Agents. With each such
request, the Requester provides an appropriate portion of the recovery
information to each Key Recovery Agent, which may be all or part of the
key recovery information.

Before processing the key recovery service request, the Key Recovery
Agent authenticates the Requester\'s right to receive the requested key
recovery service. Each Key Recovery Agent processes its respective
portion of the recovery information and constructs an output value,
which is returned to the Requester.

If only one Key Recovery Agent is involved, the output value could be
the whole key, and the Requester is finished. On the other hand, two or
more Key Recovery Agents could provide key parts or pieces of
information that the Requester would use to reconstruct or recover the
whole key.

If the Requester is a third party who performs a key recovery service on
behalf of some other person or party, then the Requester returns the
recovered key to that person or party. However, if the Requester has
also been engaged to perform a data recovery service, the Requester \--
who is provided the encrypted data \-- will decrypt the provided
encrypted data with the aid of the recovered key and return the
recovered data to the person or party.

## 

## 1.3 Supporting Components

Specific implementations of the Key Recovery System model may require
"supporting" components to support the interactions between the main Key
Recovery System components. This section describes these supporting
components and provides example of how they may be used in a Key
Recovery System.

### Product Vendors

End User Product Vendors, Key Recovery Agent Product vendors, and
Requester Product Vendors produce products for use in the Key Recovery
System, and provide information to the Registration Agent as necessary.

### Registration Agent

The Registration Agent receives and archives vendor-specific information
required by the Requester to find, acquire, and parse recovery
information obtained from the recovery information medium.

Recovery information may include the following: (1) product serial
number, (2) vendor identification number, (3) recovery fields, (4)
certificates, and (5) session information.

### Authentic Public Key Source

In some implementations, an Authentic Public Key Source will be used to
provide a certificate infrastructure to support the use of public key
cryptography within the Key Recovery System. In a Key Recovery System
which provides Private Key Escrow-based recovery, the Authentic Public
Key Source may be very similar to a conventional Certificate Authority,
but will provide for the binding of properly escrowed public keys to
users. In a Key Recovery System based on Key Encapsulation, the
Authentic Public Key Source may instead bind public keys to legitimate
Key Recovery Agents.

### Licensing Agent

The Licensing Agent is responsible for evaluating and authorizing Key
Recovery Agents.

### Key Recovery System Implementation Examples

The following two sections describe two possible types of
implementations for the Key Recovery System which require the use of
supporting components. Neither example purports to be the only method of
satisfying this standard\--instead these examples are intended to
illustrate how these supporting components fit into a Key Recovery
System implementation.

#### Private Key Escrow Example

The core of a Private Key Escrow-based Key Recovery System is the escrow
of System A and System B's public/private key exchange keypairs with the
Key Recovery Agent(s). This example discusses component interactions for
three phases: establishment, normal operation, and recovery.

##### Establishment

First, the Key Recovery System's Authentic Public Key Source must
generate and securely maintain a public/private keypair. The public
portion of this keypair will be embedded or loaded into Key Recovery
System components. The private portion of the keypair will be used to
digitally sign component information to authorize their use in the Key
Recovery System.

To establish a Private Key Escrow-based Key Recovery System, End User
Product Vendors must describe to the Registration Agent how their
systems (A and B) deposit the key exchange field into the Encrypted Data
Medium and the Recovery Information Medium. End User Product Vendors
must also embed the Authentic Public Key Source root public key into
their systems (A and B) to enable authentication of interactions with
other Key Recovery System components.

Key Recovery Agent Product Vendors must also embed the Authentic Public
Key Source root public key into the Key Recovery Agent Product. Key
Recovery Agents must demonstrate to the Licensing Agent that they will
secure escrowed user private keys in accordance with the Key Recovery
System policy. Once approved, the Key Recovery Agent will be authorized
via the Authentic Public Key Source. This authorization will allow
systems (A and B) and Requesters to verify the legitimacy of a Key
Recovery Agent.

Systems (A and B) must securely escrow their public/private key exchange
keypair with a Key Recovery Agent prior to participating in the Key
Recovery System. Systems (A and B) can verify that they are
communicating with a legitimate Key Recovery Agent by verifying the Key
Recovery Agent information using the Authentic Public Key Source. The
Key Recovery Agent will then issue a certificate to the System (A and B)
verifying that the public/private keypair was successfully escrowed.

##### Normal Operation

System A provides for key recovery whenever it performs a key exchange
with System B provided System B's public/private keypair is escrowed
with a Key Recovery Agent. System A can determine if System B's
public/private keypair was escrowed by verifying System B's certificate
(using the Authentic Public Key Source root public key embedded in the
product). During key exchange, System A deposits the key exchange field
and key recovery information into the Recovery Information Medium. The
encrypted data to be communicated to System B is deposited into the
Encrypted Data Medium.

##### Recovery

A properly authorized Requester may recover the encryption key by first
retrieving information from the Registration Agent on how the key
recovery information has been deposited in the Recovery Information
Medium. The Requester then retrieves the key recovery information from
the Recovery Information Medium to determine the Key Recovery Agent.
Next, the Requester retrieves the key exchange field and sends it to the
Key Recovery Agent. The Key Recovery Agent verifies the authenticity of
the request, decrypts the key exchange field using the user's escrowed
private key, and securely returns the unwrapped encryption key to the
Requester.

The Requester uses the recovered encryption key to decrypt the encrypted
data which was gathered from the Encrypted Data Medium.

#### Key Encapsulation Example

The core of a Key Encapsulation-based Key Recovery System is the
encapsulation of the encryption key using the public key of a legitimate
Key Recovery Agent(s). This example discusses component interactions for
three phases: establishment, normal operation, and recovery.

##### Establishment

First, the Key Recovery System's Authentic Public Key Source must
generate and securely maintain a public/private keypair. The public
portion of this keypair will be embedded or loaded into Key Recovery
System components. The private portion of the keypair will be used to
digitally sign component information to authorize their use in the Key
Recovery System.

To establish a Private Key Escrow-based Key Recovery System, End User
Product Vendors must describe to the Registration Agent how their
systems (A and B) deposit the key exchange field into the Recovery
Information Medium. End User Product Vendors must also embed the
Authentic Public Key Source root public key into their systems (A and B)
to enable authentication of interactions with other Key Recovery System
components.

Key Recovery Agent Product Vendors must also embed the Authentic Public
Key Source root public key into the Key Recovery Agent Product. Key
Recovery Agents must demonstrate to the Licensing Agent that they will
secure their private keys in accordance with the Key Recovery System
policy. Once approved, the Key Recovery Agent will be authorized via the
Authentic Public Key Source. This authorization will allow systems (A
and B) and Requesters to verify the legitimacy of a Key Recovery Agent.

Systems (A and B) must load a public key from the Key Recovery Agent
prior to participating in the Key Recovery System. The Key Recovery
Agent issues a certificate to the System (A and B) verifying that the
public/private keypair is secured and maintained by the Key Recovery
Agent.

##### Normal Operation

System A provides for key recovery whenever it performs a key exchange
by encapsulating the encryption key in the public key(s) provided by the
Key Recovery Agent(s) and depositing the resulting key recovery field(s)
into the Recovery Information Medium. System B can determine if System A
has properly provided for key recovery by verifying the integrity of the
key recovery field. The encrypted data to be communicated to System B is
deposited into the Encrypted Data Medium.

##### Recovery

A properly authorized Requester may recover the encryption key by first
retrieving information from the Registration Agent on how the key
recovery information has been deposited in the Recovery Information
Medium. The Requester then retrieves the key recovery information from
the Recovery Information Medium to determine the Key Recovery Agent.
Next, the Requester retrieves the key recovery field and sends it to the
Key Recovery Agent. The Key Recovery Agent verifies the authenticity of
the request, decrypts the key recovery field using the corresponding
private key, and securely returns the recovered encryption key to the
Requester.

The Requester uses the recovered encryption key to decrypt the encrypted
data which was gathered from the Encrypted Data Medium.

4.  **SYSTEM POLICY**

1.4 A Cryptographic Key Recovery System shall provide a *policy
establishment* mechanism that enables an appropriately designated
administrator to implement system policy. Each installed instance of a
CKRS should reference a system policy, but the system policy may vary
from instance to instance. At a minimum, the system policy shall define
each of the following.

1.4.1 Affected data types.

1.4.1.1 The system policy shall define whether or not stored data is to
be made available for recovery.

1.4.1.2 The system policy shall define whether or not electronic mail is
to made available for recovery.

1.4.1.3 The system policy shall define whether or not real-time
communications are to be made available for recovery.

1.4.2 Access policy.

1.4.2.1 For each affected data type for which recovery has been
selected, the system policy shall define the recovery mechanism to be
used, i.e. precisely how the key recovery is to be done -- particularly
when a variety of key recovery options are available.

1.4.2.2 For each affected data type for which recovery has been
selected, the system policy shall define what recovery agent or agents
shall be used.

1.4.2.3 For each recovery agent selected, the system policy shall define
what requestors may recover the data.

1.4.2.4 For each requestor selected, the system policy shall define the
conditions under which each recovery agent shall make the data available
to the requestor.

1.4.2.5 For each recovery agent and affected data type, the system
policy shall define what measures are to be taken by the recovery agent
to prevent destruction of the data.

1.4.3 Data integrity policy.

1.4.3.1 For each recovery agent and affected data type, the system
policy shall define the requirements for maintaining integrity of the
data.

1.4.3.2 For each recovery agent and affected data type, the system
policy shall define whether a cryptographic "proof" of data integrity
shall be required (perhaps utilizing digital signature) and, if so, a
security confidence level for this "proof" (e.g. bit length).

1.4.3.3 For each recovery agent and affected data type, the system
policy shall define what (if any) measures are required to provide
"proof" (perhaps utilizing digital signatures verifiable by a third
party) of the source of the recovered data.

1.4.3.4 For each recovery agent and affected data type, the system
policy shall define the auditing procedures to be followed by the
recovery agent.

1.4.4 Interoperability policy.

1.4.4.1 For each affected data type, the system policy shall define what
(if any) interoperability restrictions are to be placed on the system.

1.4.4.2 For each affected data type, the system policy shall define what
(if any) interoperability conditions require a warning to the user.