2.	Security Requirements

The security requirements for the KRA and for the Requestor have been defined to 
allow a variety of product architectures.  These include using a monolith 
product on which no other software/firmware can be loaded, using a monolith 
product on which other software/firmware can be loaded, using a layered product 
that has a distinct operating system, application, and cryptographic module.

The requirements for the KRA and the Requestor have been defined so that all of 
these architectures can be evaluated.  This is especially true of the 
requirements in the following areas: Audit, Identification and Authentication, 
some of the Access Control, and Protection of Trusted Security Functions.

Furthermore, the product architecture may imply some of the requirements do not 
apply since the threat a requirement is supposed to mitigate does not exist.  
For example, if the product is a monolith on which no other software/firmware 
can be loaded, the domain separation, trusted path, and reference validation 
mechanism requirements do not apply since the untrusted software threat does not 
exist.
	2.1.	Key Recovery Agent Requirements
	2.1.1.	Level  1 - Medium Assurance
	2.1.1.1.	Cryptographic Functions 
	2.1.1.1.1.	All cryptographic modules shall be FIPS 140-1, Level 2 or 
higher compliant. 
	2.1.1.2.	Cryptographic Algorithms
	2.1.1.2.1.	The key recovery scheme shall be implemented so that only FIPS 
approved algorithms are required to use it.  The implementation of these 
algorithms shall conform to the applicable FIPS standard(s).

(Note: It was requested that the above section be moved under confidentiality.  
It is left here is since there are aspects to various schemes that are not 
related to confidentiality, e.g., source authentication, binding to encrypted 
data, integrity, etc.  After the committee reviews this draft, this note will be 
deleted.)
	2.1.1.3.	Confidentiality:

These requirements are intended to protect against both the outsider and insider 
threats.  The only insider threat addressed is the unauthorized user.  
Authorized insider threat is handled elsewhere using audit, role separation, and 
multi-person control. 
	2.1.1.3.1.	The KRA shall protect all key recovery information stored 
against disclosure to unauthorized individuals.
	2.1.1.3.2.	The KRA shall protect key recovery information transmitted 
against disclosure to parties other than the requestor(s).
	2.1.1.3.3.	The strength of the algorithm used to protect the key recovery 
information shall be greater than or equal to the maximum strength of the 
encryption or key management algorithms used for usage or generation of the keys 
being recovered.
	2.1.1.4.	 Audit

These requirements are used to create a log of information to allow oversight by 
a security officer to detect unauthorized operations by a key recovery agent.  
	2.1.1.4.1.	The product shall be capable of generating an audit record for 
the following events: 

		Start-up and shutdown of the audit functions; and
		All auditable events as defined in the functional components 
included in this standard; (FAU_GEN.1.1)
	2.1.1.4.2.	The following actions shall be auditable:
		Any specific operation performed to process audit data stored in the 
audit trail. (Note: This include backup and deletion of audit trail) 
		Any attempt to read, modify or destroy the audit trail.
		All requests to use authentication data management mechanisms.
		All modifications to the audit configuration that occur while the 
audit collection functions are operating.
		All requests to access user authentication data 
		Any use of an authentication mechanism. (e.g. login) The 
authentication information shall not be stored in the audit trail.
		All attempts to use the user identification mechanism, including the 
user identity provided. 
		Any attempt to perform an operation on the audit trail. 
		Use of a security-relevant administrative function;
		Explicit requests to assume the security administrative role;
		The allocation of a function to a security administrative role. 
		The addition or deletion of a user to/from a security administrative 
role. 
		The association of a security-relevant administrative function with 
a specific security administrative role.
	2.1.1.4.3.	The following actions shall be audited.  The keys shall not be 
included in the audit:
		Requests, responses, and other transactions generated by the 
product, including key recovery responses.
		Requests, responses, and other transactions received by the product, 
including key recovery requests.
	2.1.1.4.4.	The product shall record within each audit record at least the 
following information: 
		Date and time of the event, type of event, subject (user) identity, 
and success or failure of the event; and 
		Other information, as described in the functional component audit 
events (FAU_GEN.1.2)
	2.1.1.4.5.	The product shall be able to generate a human understandable 
presentation of any audit data stored in the permanent audit trail. 
(FAU_POP.1.1)
	2.1.1.4.6.	The audit trail shall not store the old or new authentication 
information (e.g., password) 
	2.1.1.4.7.	The product shall be able to associate each auditable event 
with the identity of the user that caused the event. (FAU_GEN.2.1)
	2.1.1.4.8.	The product shall provide the authorized administrator with 
the ability to empty the audit trail. (FAU_MGT.1.1) (Note: emptying the audit 
trail means backup and delete).
	2.1.1.4.9.	 The product shall be able to include or exclude auditable 
events from the set of audited events based on the following attributes: User 
identity, and/or Event Type (FAU_SEL.1.1) (Note: The requirement applies to the 
auditable events only.  The always audited events must never be excluded or 
excludable from the set of audited events.)
	2.1.1.4.10.	The product shall store generated audit records in a permanent 
audit trail. (FAU_STG.1.1)
	2.1.1.4.11.	 The product shall restrict access to the audit trail to the 
authorized administrator. (FAU_PRO.1.1)
(Note: This requirement implies providing integrity to the audit trail)
	2.1.1.5.	 Identification and Authentication

These requirements permit the unique identification of key recovery agent 
personnel.  This facilitates individual accountability via audit functions and 
access controls.  Requirements are levied on the strength of the authentication 
mechanism and the robustness of the authentication mechanism against attacks by 
rogue key recovery agent personnel.    

These requirements do not apply to electronic transactions (requests and 
responses).  The electronic transactions may be identified and authenticated (if 
the scheme permits) using the access control policy.
	2.1.1.5.1.	 The product shall provide functions for initializing and 
modifying KRA personnel authentication data. (FIA_ADA.3.1)
	2.1.1.5.2.	The product shall restrict the use of these functions on the 
KRA personnel authentication data for any user to the authorized administrator. 
(FIA_ADA.3.2)
	2.1.1.5.3.	The product shall allow authorized KRA personnel to use these 
functions to modify their own authentication data in accordance with the 
identification and authentication policy. (FIA_ADA.3.3) (Note: The 
identification and authentication policy is to permit each person to change 
his/her authentication information.)
	2.1.1.5.4.	The product shall protect from unauthorized observation, 
modification, and destruction authentication data that is stored in the product. 
	2.1.1.5.5.	The product shall be able to terminate the KRA personnel 
session establishment process after five unsuccessful authentication attempts. 
(FIA_AFL.1.1)
(Note: If the product terminates the session after less than five unsuccessful 
attempts, the product meets the above requirement)
	2.1.1.5.6.	After the termination of a KRA user session establishment 
process, the product shall be able to disable the user account until account is 
enabled by an authorized administrator (i.e., security administrator). 
(FIA_AFL.1.2)
	2.1.1.5.7.	The product shall authenticate any KRA user's claimed identity 
prior to performing any functions on the user's behalf. (FIA_UAU.1.1)
	2.1.1.5.8.	 The product shall uniquely identify each KRA user before 
performing any actions requested by the user. (FIA_UID.2.1)
	2.1.1.5.9.	 The product shall provide a mechanism to verify that  secrets 
(i.e., authentication information such as passwords) meet the FIPS PUB 112 
"Password Usage" and Department of Defense Password Management Guideline (CSC-
STD-002-85).
(Note: The above requirement implies that the product (as opposed to procedural 
means and management instructions) will enforce the password length, aging, etc. 
type requirements.  If we do not want product to enforce the requirement, the 
above requirement should be deleted)
	2.1.1.6.	 Access Control

These requirements provide countermeasures against entities spoofing as an 
authorized requestor or end user.  The requirements in this section ensure that 
the product implements and enforces the scheme claimed.  In other words, before 
performing any key recovery related action, the product must validate security 
services (e.g., confidentiality, integrity, source authentication, etc.).  
Similarly, the product must apply the security services according to the scheme.
	2.1.1.6.1.	The product shall verify authentication and integrity services 
for the received transactions as determined by the standard compliant protocol 
(scheme). (FPT_ACP.1.1)
	2.1.1.6.2.	The product shall decrypt the received transactions if the 
standard compliant protocol requires the transaction to be encrypted. 
(FPT_ACP.1.2)
	2.1.1.6.3.	The product shall apply authentication, integrity, and 
confidentiality services to all transactions (i.e., requests and responses) as 
determined by the standard compliant protocol. (FPT_ACP.1.3)
	2.1.1.6.4.	The product shall release the keys only to authorized users.
	2.1.1.6.5.	The KRA shall release the key only if the requester is 
authorized to receive the key associated with the user specified in the request 
and for the validity period (time), if applicable to the standard compliant 
protocol.
	2.1.1.6.6.	The product shall ensure that security policy enforcement 
functions are invoked and succeed before any security-related operation is 
allowed to proceed.  (FPT_RVM.1.1)
(Note: This requirement simply states that the product security features must be 
always invoked, and not bypassable)
	2.1.1.6.7.	The product shall maintain a security domain for its own 
execution that protects it from interference and tampering by untrusted 
subjects. (FPT_SEP.1.1)
	2.1.1.6.8.	The product shall enforce separation between the security 
domains of subjects in the system. (FPT_SEP.1.2)
	2.1.1.6.9.	The product shall distinguish between security-relevant 
administrative functions from other functions. (FPT_TSA.2.1)
	2.1.1.6.10.	The set of security-relevant administrative functions shall 
include all functions necessary to install, configure, and manage the product; 
minimally, this set shall include assignment/deletion of authorized users from 
security administrative roles, association of security-relevant administrative 
commands with security administrative roles, assignment/deletion of subjects 
whose keys are held, assignment/deletion of parties who may be provided the 
keys, product cryptographic key management, actions on the audit log, audit 
profile management, and changes to the system configuration. (FPT_TSA.2.2)
	2.1.1.6.11.	The product shall restrict the ability to perform security-
relevant administrative functions to a security administrative role that has a 
specific set of authorized functions and responsibilities. (FPT_TSA.2.3)
(Note: The term security administrative role refers to generic trusted 
administrative roles.  Security administrator role is one, but not the only one, 
of these security administrative roles.)
	2.1.1.6.12.	The product shall be capable of distinguishing the set of KRA 
operators authorized for administrative functions from the set of all other 
users. (FPT_TSA.2.4)
	2.1.1.6.13.	The product shall allow only specifically authorized KRA 
operators to assume the security administrative role. (FPT_TSA.2.5)
	2.1.1.6.14.	The product shall require an explicit request to be made in 
order for an authorized KRA operator to assume the security administrative role. 
(FPT_TSA.2.6)
	2.1.1.7.	 Non-Repudiation

These capabilities facilitate trusted time source to further support 
accountability. 
	2.1.1.7.1.	The product shall be able to provide reliable time stamps for 
its own use. (FPT_STM.1.1)
	2.1.1.7.2.	The product shall be able to generate evidence of receipt for 
received transactions. (FCO_NRR.2.1)
(Note: The above requirement means using the reliable time stamp to requirement 
to put a trusted time stamp on the receipt.   Furthermore, this requirement 
means that the product shall be able to generate evidence of receipt of: 
registration or deposit of key recovery information from users, and requests 
from requestor)
	2.1.1.8.	Availability

These requirements are intended to provide the capability for a key recovery 
agent to recover in the event of a system failure or compromise.  They act as a 
counter to the threat of the unauthorized destruction of the key recovery 
information or capabilities at the key recovery agent facility.
	2.1.1.8.1.	The KRA facility shall have the capability to securely 
replicate any key recovery information stored.
(Note: The intent of the above requirement is for continued on-line access in 
case of a facility failure.  In light of that, should this be a requirement on 
the component since it is a system architecture issue.  Please note that the 
multiple KRAs requirement at Level 2 is to prevent one KRA from compromising key 
recovery information)
	2.1.1.8.2.	The KRA facility shall have a secure backup of the key 
recovery information stored.
(Note: The intent of the above requirement is for ability to rebuild the key 
recovery database in case of KRA system failure.  In light of that, should this 
be a requirement on the component since this a facility operations related 
issue)
	2.1.1.9.		Protection of Trusted Security Functions
	2.1.1.9.1.	Before establishing a session with KRA operator, the product 
shall display an advisory warning message regarding unauthorized use of the 
product. (FTA_TAB.2.1)
	2.1.1.9.2.	The default advisory warning message displayed by the product 
shall be as follows: "This system shall be used only by authorized personnel and 
only for authorized key recovery purposes.  Violation shall result in criminal 
prosecution and civil penalties". (FTA_TAB.2.2)
	2.1.1.9.3.	The product shall restrict the capability to modify the 
warning message to the authorized administrator. (FTA_TAB.2.3)
	2.1.1.9.4.	Upon successful session establishment, the product shall 
display the date, time, method, and location of the last successful session 
establishment to the KRA operator. (FTA_TAH.1.1)
	2.1.1.9.5.	Upon successful session establishment, the product shall 
display the date, time, method, and location of the last unsuccessful attempt to 
session establishment and the number of unsuccessful attempts since the last 
successful session establishment. (FTA_TAH.1.2)
	2.1.1.9.6.	The data specified above shall not be removed without KRA 
operator intervention. (FTA_TAH.1.3)
	2.1.2.	Level 2 - High Assurance
	2.1.2.1.	Cryptographic Functions
	2.1.2.1.1.	All cryptographic modules shall be FIPS 140-1, Level 3 or 
higher compliant. 
	2.1.2.2.	 Cryptographic Algorithms
	 Same as Level 1
	2.1.2.3.	Confidentiality:

Level 2 requires additional protection against the insider threat of a rogue key 
recovery agent by requiring multi-party control on access to the key recovery 
information. 
	 All level 1 requirements and;
	2.1.2.3.1.	The system shall be designed for multiple KRAs.  Two or more 
KRAs shall be required to obtain the key recovery information. 
	2.1.2.4.	 Audit:

Level 2 adds a real time alarm to the security officer in the event of the audit 
trail becoming full to prevent audit data from being lost.  It also requires the 
auditing of additional events consistent with the additional security 
requirements (i.e. trusted path) added at Level 2.
	Includes all the requirements of Level 1 and;
	2.1.2.4.1.	The product shall generate an alarm to the authorized 
administrator if the size of the audit data in the audit trail exceeds a pre-
defined limit. (FAU_MGT.4.1)
	2.1.2.4.2.	The product shall provide the authorized administrator with 
the ability to manage the audit trail at any time during the operation of the 
product. (FAU_MGT.4.2)
	2.1.2.4.3.	The following actions shall be auditable:
		Execution of the tests of the underlying machine and the results of 
the tests. 
		All attempted uses of the trusted path functions.
		Identification of the initiator and target of the trusted path.
		Attempts to provide invalid inputs for administrative functions
		The invocation of the non-repudiation service.  The audit event 
shall include identification of the information, the destination, and a copy of 
the evidence provided.  The event shall exclude all private and secret keys in 
encrypted or unencrypted form.
	2.1.2.5.	 Identification and Authentication

Level 2 enhances assurance by supporting a hardware token.  This provides an 
additional countermeasure to the threat of an attack on the authentication 
mechanism and the subsequent unauthorized access to key recovery information or 
critical functions.

		All Level 1 requirements and the following;
	2.1.2.5.1.	 The product shall support a token based authentication.  The 
token shall meet FIPS 140-1 Level 2 requirements.
	2.1.2.6.	Access Control

Level 2  requires multi-party access controls for release of key recovery 
information and establishes roles and responsibilities for key recovery facility 
personnel as additional countermeasures  to the threat of a single rogue key 
recovery agent.  
		All Level 1 requirements and the following;
	2.1.2.6.1.	The KRA shall embody a facility for multi-party  (at least 2) 
authorization in support of the release of key material.
(Note: The following requirements are to provide for strict role separation)
	2.1.2.6.2.	The product shall distinguish security-relevant administrative 
functions from other functions. (FPT_TSA.3.1)
	2.1.2.6.3.	The set of security-relevant administrative functions shall 
include all functions necessary to install, configure, and manage the product; 
minimally, this set shall include assignment/deletion of authorized users from 
security administrative roles, association of security-relevant administrative 
commands with security administrative roles, assignment/deletion of subjects 
whose keys are held, assignment/deletion of parties who may be provided the 
keys, product cryptographic key management, actions on the audit log, audit 
profile management, and changes to the system configuration. (FPT_TSA.3.2)
	2.1.2.6.4.	The product shall restrict the ability to perform a security-
relevant administrative function to the security administrative role(s) 
authorized to use that function. (FPT_TSA.3.3)
	2.1.2.6.5.	The product shall be capable of distinguishing the set of 
users authorized for administrative functions from the set of all other users. 
(FPT_TSA.3.4)
	2.1.2.6.6.	The product shall allow only specifically authorized users to 
assume only those security administrative roles for which they have been 
authorized. (FPT_TSA.3.5)
	2.1.2.6.7.	The product shall require an explicit request to assume a 
specific security administrative role to be made in order for an authorized user 
to assume that security administrative role. (FPT_TSA.3.6)
	2.1.2.6.8.	The product shall define a set of security administrative 
roles that minimally includes security administrator, system operator, crypto 
officer and audit administrator. (FPT_TSA.3.7)
	2.1.2.6.9.	The security administrator shall perform the following 
functions: assignment/deletion of authorized users from security administrative 
roles, association of security-relevant administrative commands with security 
administrative roles, assignment/deletion of subjects whose keys are held, and 
assignment/deletion of parties who may be provided the keys.
	2.1.2.6.10.	The system operator shall change system configuration and run 
the system.
	2.1.2.6.11.	The crypto officer shall manage the cryptographic keys.
	2.1.2.6.12.	The audit administrator shall manage audit log and audit 
profiles.
	2.1.2.6.13.	The product shall associate each security-relevant 
administrative function with at least one security administrative role. 
(FPT_TSA.3.8)
	2.1.2.6.14.	The product shall enforce checks for valid input values for 
security-relevant administrative functions as described in the Administrative 
guidance. (FPT_TSU.1.1)
	2.1.2.7.	Non Repudiation

Level 2 requires additional capabilities to prove the origin of transmissions to 
allow recipients to counter the threat of an adversary spoofing as a Key 
Recovery Agent.

		All Level 1 requirements and the following;
	2.1.2.7.1.	The product shall generate evidence of origin for transmitted 
key recovery requests or responses. (FCO_NRO.1.1)
(Note: The above requirement shall also the reliable time stamp service to 
include the time in the evidence)
	2.1.2.7.2.	The product shall provide a capability to verify the evidence 
of origin of information to the recipient. (FCO_NRO.1.3)
	2.1.2.7.3.	The product shall provide a capability to verify the evidence 
of receipt of proof of receipt to the originator of message (i.e., recipient of 
proof of receipt). (FCO_NRR.2.3)
	2.1.2.7.4.	The product shall provide the originator the ability to 
request evidence of receipt on information. (FCO_NRR.2.3)
	2.1.2.8.	 Availability Same as Level 1.
	2.1.2.9.	Protection of Trusted Security Functions: Same as Level 1 and 
the following:
	2.1.2.9.1.	The product shall provide a communication path between itself 
and local human users that is logically distinct from other communication paths 
and provides assured identification of its endpoints. (FTP_TRP.1.1)
	2.1.2.9.2.	The local human users shall have the ability to initiate 
communication via the trusted path. (FTP_TRP.1.2)
	2.1.2.9.3.	The product shall require the use of the trusted path for 
initial user (i.e., KRA operator) authentication. (FTP_TRP.1.3)
	2.1.2.9.4.	The product shall provide the authorized administrator with 
the capability to demonstrate the correct operation of the security-relevant 
functions provided by the underlying abstract machine. (FPT_AMT.1.1)
	2.1.2.9.5.	The product shall preserve a secure state when abstract 
machine tests fail. (FPT_FLS.1.1) 
	2.2.	End User Product
	2.2.1.	Level 1 - Key Recovery Capable End User Products
	2.2.1.1.	Cryptographic Functions 
	2.2.1.1.1.	All cryptographic modules shall be FIPS 140-1, Level 1 
compliant. 
	2.2.1.2.	Cryptographic Algorithms
	2.2.1.2.1.	The key recovery scheme shall be implemented so that only FIPS 
approved algorithms are required to use it.  The implementation of these 
algorithms shall conform to the applicable FIPS standard(s).
	2.2.1.3.	Confidentiality

This requirement is intended to minimize the vulnerability created by the key 
recovery mechanism.  The key recovery mechanism should not be weaker and thus 
easier to attack than the original encryption mechanism. 
	2.2.1.3.1.	The strength of the algorithm used to protect the key recovery 
information shall be greater than or equal to the maximum strength of the 
encryption or key management algorithms.
	2.2.1.4.	Integrity/Authenticity

These requirements counter the threat of a single end user or an outsider 
corrupting the key recovery information.
	2.2.1.4.1.	The end user product shall be capable of generating key 
recovery information.
	2.2.1.4.2.	The key recovery information shall provide source 
authentication.
	2.2.1.4.3.	The end user product shall be capable of securely binding 
(i.e., with integrity) the key recovery information to the encrypted 
communications.
	2.2.1.4.4.	The end user product shall be capable of verifying the source 
and integrity of key recovery information
	2.2.1.5.	 Key Recovery Functionality
	2.2.1.5.1.	 The key recovery mechanism in the end user product shall be 
always activated/deactivated by the system administrator.
(Note: The above requirement will be taken out if it appears some place else.)
	2.2.2.	Level 2 - Mandatory Enforcement of Key Recovery
	2.2.2.1.	Cryptographic Functions 
	2.2.2.1.1.	All cryptographic modules shall be FIPS 140-1, Level 2 
compliant. 
	2.2.2.2.	Cryptographic Algorithms: Same as Level 1
	2.2.2.3.	 Confidentiality: Same as Level 1
	2.2.2.4.	 Integrity/Authenticity: Same as Level 1
	2.2.2.5.	 Key Recovery Functionality
	2.2.2.5.1.	 The key recovery mechanism shall be always activated in the 
end user product.
(Note: The above requirement will be taken out if it appears some place else.)
	2.3.	Registration Agent.  Registration Agents maintain the information on 
products and their key recovery protocol (scheme).  Thus, the requirement on the 
registration agent is to maintain the integrity of the product information.
	2.3.1.	Integrity/Authenticity

These requirements counter the threat of an adversary spoofing as the 
registration agent and of unauthorized access to the information and critical 
functions at the registration agent. 
	2.3.1.1.	 The Registration Agent shall verify authentication and 
integrity services for the received product information.
	2.3.1.2.	 The Registration Agent shall apply authentication and 
integrity services to the product information it transmits.
	2.3.1.3.	The Registration Agent shall ensure that the product 
information it maintains is not modified by unauthorized parties.
	2.4.	Licensing Agent. Licensing Agents shall perform a compliance audit 
of the KRA to ensure that the KRA operates in accordance with the KRA's stated 
policy.
	2.5.	Requestor

The requirements for the requestor are defined with strict operating system and 
user authentication controls in mind in order to ensure that the requestor 
system has good security controls for the key recovery information.  Thus, the 
requestor system requires a true operating system (e.g., NT, UNIX, etc.) as 
opposed to Windows 95 type clients. 
	2.5.1.	Level  1 - Medium Assurance
	2.5.1.1.	Cryptographic Functions 
	2.5.1.1.1.	All cryptographic modules shall be FIPS 140-1, Level 2 or 
higher compliant. 
	2.5.1.2.	Cryptographic Algorithms
	2.5.1.2.1.	The key recovery requests and responses shall be implemented 
so that only FIPS approved algorithms are required to use them.  The 
implementation of these algorithms shall conform to the applicable FIPS 
standard(s).
	2.5.1.3.	Confidentiality
	2.5.1.3.1.	The requestor shall protect key recovery information received 
and/or stored against disclosure to unauthorized individuals.
	2.5.1.3.2.	The requestor shall protect key recovery request (specially 
the identities of subjects and time periods, if applicable) transmitted against 
disclosure to parties other than the KRA.
	2.5.1.4.	Audit
	2.5.1.4.1.	The product shall be capable of generating an audit record for 
the following events: 
		Start-up and shutdown of the audit functions; and
		All auditable events as defined in the functional components 
included in this standard; (FAU_GEN.1.1)
	2.5.1.4.2.	The following actions shall be auditable:
		Any specific operation performed to process audit data stored in the 
audit trail. (Note: This include backup and deletion of audit trail) 
		Any attempt to read, modify or destroy the audit trail.
		All requests to use authentication data management mechanisms.
		All modifications to the audit configuration that occur while the 
audit collection functions are operating.
		All requests to access user authentication data 
		Any use of an authentication mechanism. (e.g. login) The 
authentication information shall not be stored in the audit trail.
		All attempts to use the user identification mechanism, including the 
user identity provided. 
		Any attempt to perform an operation on the audit trail. 
		Use of a security-relevant administrative function;
		Explicit requests to assume the security administrative role;
		The allocation of a function to a security administrative role. 
		The addition or deletion of a user to/from a security administrative 
role. 
		The association of a security-relevant administrative function with 
a specific security administrative role.
	2.5.1.4.3.	The following actions shall be audited.  The keys shall not be 
included in the audit:
		Requests, responses, and other transactions generated by the 
product, including key recovery responses.
		Requests, responses, and other transactions received by the product, 
including key recovery requests.
	2.5.1.4.4.	The product shall record within each audit record at least the 
following information: 
		Date and time of the event, type of event, subject (user) identity, 
and success or failure of the event; and 
		Other information, as described in the functional component audit 
events (FAU_GEN.1.2)
	2.5.1.4.5.	The product shall be able to generate a human understandable 
presentation of any audit data stored in the permanent audit trail. 
(FAU_POP.1.1)
	2.5.1.4.6.	The audit trail shall not store the old or new authentication 
information (e.g., password) 
	2.5.1.4.7.	The product shall be able to associate each auditable event 
with the identity of the user that caused the event. (FAU_GEN.2.1)
	2.5.1.4.8.	The product shall provide the authorized administrator with 
the ability to empty the audit trail. (FAU_MGT.1.1) (Note: emptying the audit 
trail means backup and delete).
	2.5.1.4.9.	 The product shall be able to include or exclude auditable 
events from the set of audited events based on the following attributes: User 
identity, and/or Event Type (FAU_SEL.1.1) (Note: The requirement applies to the 
auditable events only.  The always audited events must never be excluded or 
excludable from the set of audited events.)
	2.5.1.4.10.	The product shall store generated audit records in a permanent 
audit trail. (FAU_STG.1.1)
	2.5.1.4.11.	 The product shall restrict access to the audit trail to the 
authorized administrator. (FAU_PRO.1.1)
(Note: This requirement implies providing integrity to the audit trail)
	2.5.1.5.	Identification and Authentication

The requirements in this section are for the identification and authentication 
of the various requestor personnel.  These requirements do not apply to 
electronic transactions (requests and responses).  The electronic transactions 
may be identified and authenticated (if the scheme permits) using the access 
control policy.
	2.5.1.5.1.	 The product shall provide functions for initializing and 
modifying user authentication data. (FIA_ADA.3.1)
	2.5.1.5.2.	The product shall restrict the use of these functions on the 
user personnel authentication data for any user to the authorized administrator. 
(FIA_ADA.3.2)
	2.5.1.5.3.	The product shall allow authorized users to use these 
functions to modify their own authentication data in accordance with the 
identification and authentication policy. (FIA_ADA.3.3) (Note: The 
identification and authentication policy is to permit each person to change 
his/her authentication information.)
	2.5.1.5.4.	The product shall protect from unauthorized observation, 
modification, and destruction authentication data that is stored in the product. 
	2.5.1.5.5.	The product shall be able to terminate the user session 
establishment process after five unsuccessful authentication attempts. 
(FIA_AFL.1.1)
(Note: If the product terminates the session after less than five unsuccessful 
attempts, the product meets the above requirement)
	2.5.1.5.6.	After the termination of a user session establishment process, 
the product shall be able to disable the user account until account is enabled 
by an authorized administrator (i.e., security administrator). (FIA_AFL.1.2)
	2.5.1.5.7.	The product shall authenticate any user's claimed identity 
prior to performing any functions on the user's behalf. (FIA_UAU.1.1)
	2.5.1.5.8.	 The product shall uniquely identify each user before 
performing any actions requested by the user. (FIA_UID.2.1)
	2.5.1.5.9.	 The product shall provide a mechanism to verify that  secrets 
(i.e., authentication information such as passwords) meet the FIPS PUB 112 
"Password Usage" and Department of Defense Password Management Guideline (CSC-
STD-002-85).
(Note: The above requirement implies that the product (as opposed to procedural 
means and management instructions) will enforce the password length, aging, etc. 
type requirements.  If we do not want the product to enforce the requirement, 
the above requirement should be deleted)
	2.5.1.6.	 Access Control

The requirements under this section are to ensure that the product implements 
and enforces the transaction security.
	2.5.1.6.1.	The product shall verify authentication and integrity services 
for the received transactions as determined by the standard compliant protocol 
(scheme). (FPT_ACP.1.1)
	2.5.1.6.2.	The product shall decrypt the received transactions if the 
standard compliant protocol requires the transaction to be encrypted. 
(FPT_ACP.1.2)
	2.5.1.6.3.	The product shall apply authentication, integrity, and 
confidentiality services to all transactions (i.e., requests) as determined by 
the standard compliant protocol. (FPT_ACP.1.3)
	2.5.1.6.4.	 The product shall ensure that the key recovery information is 
destroyed (e.g., by zeroizing) when it is no longer required, when it is no 
longer valid (e.g., time expiry), when the KRA requires its deletion, or when 
the legal right to it expires, whichever occurs earlier.
	2.5.1.6.5.	The product shall ensure that security policy enforcement 
functions are invoked and succeed before any security-related operation is 
allowed to proceed.  (FPT_RVM.1.1)
(Note: This requirement simply states that the product security features must be 
always invoked, and not bypassable)
	2.5.1.6.6.	The product shall maintain a security domain for its own 
execution that protects it from interference and tampering by untrusted 
subjects. (FPT_SEP.1.1)
	2.5.1.6.7.	The product shall enforce separation between the security 
domains of subjects in the system. (FPT_SEP.1.2)
	2.5.1.7.	Non-Repudiation
	2.5.1.7.1.	The product shall be able to provide reliable time stamps for 
its own use. (FPT_STM.1.1)
(Note: We want to reply more on the KRA for time.  But, having requestor time 
stamp does not hurt)
	2.5.1.7.2.	The product shall be able to generate evidence of receipt for 
received transactions. (FCO_NRR.2.1)
(Note: The above requirement means using the reliable time stamp to requirement 
to put a trusted time stamp on the receipt.   Furthermore, this requirement 
means that the product shall be able to generate evidence of receipt of: 
registration or deposit of key recovery information from users, and requests 
from requestor)
	2.5.1.8.		Protection of Trusted Security Functions
	2.5.1.8.1.	Before establishing a session with a user, the product shall 
display an advisory warning message regarding unauthorized use of the product. 
(FTA_TAB.2.1)
	2.5.1.8.2.	The default advisory warning message displayed by the product 
shall be as follows: "This system shall be used only by authorized personnel and 
only for authorized key recovery purposes.  Violation shall result in criminal 
prosecution and civil penalties". (FTA_TAB.2.2)
	2.5.1.8.3.	The product shall restrict the capability to modify the 
warning message to the authorized administrator. (FTA_TAB.2.3)
	2.5.1.8.4.	Upon successful session establishment, the product shall 
display the date, time, method, and location of the last successful session 
establishment to the user (FTA_TAH.1.1)
	2.5.1.8.5.	Upon successful session establishment, the product shall 
display the date, time, method, and location of the last unsuccessful attempt to 
session establishment and the number of unsuccessful attempts since the last 
successful session establishment. (FTA_TAH.1.2)
	2.5.1.8.6.	The data specified above shall not be removed without user 
intervention. (FTA_TAH.1.3)
	2.5.2.	Level 2 - High Assurance
	2.5.2.1.	Cryptographic Functions
	2.5.2.1.1.	All cryptographic modules shall be FIPS 140-1, Level 3 or 
higher compliant. 
	2.5.2.2.	 Cryptographic Algorithms
	 Same as Level 1
	2.5.2.3.	Confidentiality Level 1 requirements and;
	2.5.2.4.	 Audit: Includes all the requirements of Level 1 and;
	2.5.2.4.1.	The product shall generate an alarm to the authorized 
administrator if the size of the audit data in the audit trail exceeds a pre-
defined limit. (FAU_MGT.4.1)
	2.5.2.4.2.	The product shall provide the authorized administrator with 
the ability to manage the audit trail at any time during the operation of the 
product. (FAU_MGT.4.2)
	2.5.2.4.3.	The following actions shall be auditable:
		Execution of the tests of the underlying machine and the results of 
the tests. 
		All attempted uses of the trusted path functions.
		Identification of the initiator and target of the trusted path.
		Attempts to provide invalid inputs for administrative functions
		The invocation of the non-repudiation service.  The audit event 
shall include identification of the information, the destination, and a copy of 
the evidence provided.  The event shall exclude all private and secret keys in 
encrypted or unencrypted form.
	2.5.2.5.	 Identification and Authentication Same as Level 1 and;
	2.5.2.5.1.	 The product shall support and token based authentication.  
The token shall meet FIPS 140-1 Level 2 requirements.
	2.5.2.6.	Access Control Same as Level 1 and the following;
	2.5.2.6.1.	Two or more users shall be required to request the recovery 
information from a KRA. 
	2.5.2.6.2.	 The product shall enforce checks for valid input values for 
security-relevant administrative functions as described in the Administrative 
guidance. (FPT_TSU.1.1)
	2.5.2.7.	Non Repudiation Includes the Level 1 requirements and;
	2.5.2.7.1.	The product shall generate evidence of origin for transmitted 
key recovery requests or responses. (FCO_NRO.1.1)
(Note: The above requirement shall also the reliable time stamp service to 
include the time in the evidence)
	2.5.2.7.2.	The product shall provide a capability to verify the evidence 
of origin of information to the recipient. (FCO_NRO.1.3)
	2.5.2.7.3.	The product shall provide a capability to verify the evidence 
of receipt of proof of receipt to the originator of message (i.e., recipient of 
proof of receipt). (FCO_NRR.2.3)
	2.5.2.7.4.	The product shall provide the originator the ability to 
request evidence of receipt on information. (FCO_NRR.2.3)
	2.5.2.8.	 Protection of Trusted Security Functions: Same as Level 1 and 
the following:
	2.5.2.8.1.	The product shall provide a communication path between itself 
and local human users that is logically distinct from other communication paths 
and provides assured identification of its endpoints. (FTP_TRP.1.1)
	2.5.2.8.2.	The local human users shall have the ability to initiate 
communication via the trusted path. (FTP_TRP.1.2)
	2.5.2.8.3.	The product shall require the use of the trusted path for 
initial user authentication. (FTP_TRP.1.3)
	2.5.2.8.4.	The product shall provide the authorized administrator with 
the capability to demonstrate the correct operation of the security-relevant 
functions provided by the underlying abstract machine. (FPT_AMT.1.1)
	2.5.2.8.5.	The product shall preserve a secure state when abstract 
machine tests fail. (FPT_FLS.1.1)
	2.6.	Authentic Public Key Source (APKS AKA Public Key Infrastructure 
(PKI))
	2.6.1.	Standards
	2.6.1.1.	 The APKS shall carry out transactions in accordance with the 
Minimum Interoperability Specifications for PKI Components (MISPC)
	2.6.2.	Security/Certificate Policy: The security of PKI and the 
degree to which the binding between an entity (subject or subscriber) and public 
key can be trusted, is determined by the Certificate Policy.  Certificate Policy 
is defined and described in Certificate Policy Framework.  Using this Framework, 
NIST has developed Baseline Security Requirements.   NIST plans to enhance these 
for up to three more strictly superior policies.  Thus, in order to define the 
security requirements for the APKS, we only need to select the proper 
certificate policy.  Please note the certificate policy security requirements 
are quite comprehensive.  For details, see IETF PKIX Part IV: Certificate Policy 
Framework.
	2.6.2.1.	 For Level 1, the APKS shall meet the medium Certificate 
Policy.  For Level 2, the APKS shall meet the high Certificate Policy.
??