9 June 1997
Source: http://csrc.nist.gov/krdp/
In May 1996, the Office of Management and Budget (OMB) released a white paper titled "Enabling Privacy, Commerce, Security, and Public Safety in the Global Information Infrastructure". This paper stated that "government and industry must work together to create a security management infrastructure and attendant products that incorporate robust cryptography without undermining national security and public safety". In support of this goal, a Key Recovery Demonstration Project (KRDP) was initiated in order to demonstrate the practicability of the recovery of keys that support data encryption in Federal government applications. Approximately ten Federal agencies will participate in a pilot program in which different key recovery technologies will be implemented, tested, and evaluated. A brief description of the pilot agency applications is found in an KRDP Project Summary.
The National Institute Of Standards and Technology (NIST) has issued a Broad Agency Announcement (BAA) that solicits products and services that will be used to support this project. Three possible methods of key recovery are depicted in Key Recovery Examples.
KRDP Implementation Evaluation Criteria identify the functional and security concerns related to the Federal governments's need to have emergency access to encrypted data.
The following additional documents may be useful to contracting organizations that are responding to the BAA.
In January 1994, NIST issued "Security Requirements for Cryptographic Modules" as Federal Information Processing Standard (FIPS) 140-1. The standard specifies the security requirements that are to be satisfied by a cryptographic module utilized within a security system protecting unclassified information within computer and telecommunication systems. When applicable, responders to the BAA are asked to provide FIPS 140-1 compliance status for their offered product or service; however, compliance with FIPS 140-1 is not required for participation in this project.
A Certification Authority (CA) system certifies the public key that is part of a public/private key pair that can be used to support data encryption. Vendors of CA systems that are responding to the BAA are asked to state to what extent their product or service complies with the NIST draft "Minimum Interoperability Specification for PKI components" which was issued for public comment in December,1996.
Until recently, federal agencies have not made significant use of commercial cryptography to protect sensitive unclassified information. However, as federal agencies have begun to realize the sensitivity of their information and that cryptography can help protect that information, more agencies are making use of encryption mechanisms. As encryption becomes more prominent, providing a means for management and other authorized entities to recover keys in the event that a user is away on vacation or is terminated from employment will become critical to the continued operation of each organization. Key recovery (also known as emergency access) is a security service which allows for the decryption of encrypted information through the retrieval of information required to implement that mechanism. Key recovery ensures that mechanisms are in place for management and other authorized entities to recover encrypted information.
The Interagency Working Group on Cryptography Policy (IWG) has established a task group to demonstrate the practicability of key recovery as an element of a key management infrastructure/public key infrastructure (KMI/PKI). The Task Group is formed jointly of representatives from the Government Information Technology Services Board (GITS) and the IWG. The Task Group is chaired by a representative from the Department of the Treasury, who also serves as the Champion for Security and Privacy for the GITS Board with participation from NIST, FBI, NSA, and GSA and each agency with a pilot selected from this demonstration.
Ten Federal agency pilots will test the elements of the vision laid out in the white paper, "Enabling Privacy, Commerce, Security and Public Safety in the Global Information Infrastructure." In addition, the pilots have been selected based on their ability to:
The following presents a brief description of each candidate agency's pilot:
The Department of Energy's (DOE) Office of Energy Research EDI/Internet Security project will test emerging security technologies for Electronic Data Interchange (EDI) that are based on the Internet standards for secure e-mail. Participants include six Federal agencies and eight academic research organizations currently involved in Electronic Research Administration (ERA). The project will test the interoperability of multiple vendors' products across an open systems environment. The initial implementation will focus on processing electronic grant application requirements. Point of Contact: Jean Morrow, jean.morrow@mailgw.er.doe.gov
The U.S. Electronic Grants pilot project will demonstrate that a secure electronic grants system can be built around low cost, World Wide Web technology while maintaining the standard EDI structure required for government-wide data sharing. The Department of Transporation (DOT) Federal Railroad Administration will lead the project in cooperation with its Electronic Grants partners including the Federal Highway Administration, Federal Transit Administration, Federal Aviation Administration, U.S. Coast Guard, Department of Energy, Department of Education, Department of Interior, Office of Naval Research, Environmental Protection Agency, and Small Business Administration. In fiscal year 1995, approximately $300 billion in grants were awarded government wide to support research and development, environmental protection, education, transportation safety, economic development, improved public health and similar programs. DOT and its partners will pilot this application with a small segment of grantees that represent universities, state and local governments and non-profit organizations. Point of Contact: Bradley Smith, bradley.smith@fra.dot.gov
The Lawrence Livermore National Laboratory (LLNL) is in the process of building a Public Key Infrastructure (PKI) to support both its Programmatic and Business operations. Part of those operations include network interactions with many other DOE laboratories, facilities, and vendors. In order to utilize the network, LLNL's infrastructure must provide strong authentication, non-repudiation, message integrity, and privacy for the information being exchanged. An Emergency Access capability is viewed as a critical part of this infrastructure if the full potential of public key encryption technology for privacy is to be realized. LLNL will exercise the Emergency Access capabilities of a commercial software product to ascertain its ability to meet requirements. Point of Contact: Frank Ploof, fploof@llnl.gov
The National Institute of Standards and Technology's (NIST) has responsibility for providing technical support to the other Federal agencies that are participating in the Key Recovery Demonstration Project (KRDP). NIST will issue a Broad Agency Announcement (BAA)that solicits information from vendors about the availability of products, components, and services that can be used in the KRDP. NIST will chair the panel which evaluates responses to the BAA. NIST will also assist the KRDP pilot agencies in the development of their implementation plans. NIST will act as the technical lead for the testing of all pilot Emergency Access systems. NIST will coordinate the development of a comprehensive test suite for each pilot system and assist in evaluating and reporting the test results. In order to establish a pilot public key infrastructure for the KRDP and test the interaction among Certification Authorities (CAs) for the other pilots, NIST will procure and operate a root CA. NIST will also acquire COTS products which provide a secure E-Mail and file encryption capability and permit key recovery. NIST will evaluate and demonstrate the new technology in the NIST Security Division Laboratory. Point of Contact: Jerry Mulvenna, jerry.mulvenna@nist.gov
The National Technical Information Service's (NTIS) FedWorld Secure Web and Certificate Authority Project will prototype trusted-agent services that support digital signature, the encryption of files and messaging, and authorized emergency access to encrypted information through key recovery management. Point of Contact: Mike Williams, mwilliams@fedworld.gov
The Social Security Administration (SSA) and Pitney Bowes Inc. are conducting a proof-of-concept demonstration project with a group of small employers. The project participants securely submit their annual W2/W3 data to SSA over the Internet using public/private key technology. SSA has proposed an expansion of the project to incorporate a test of emergency access to the W2/W3 data. Point of Contact: John Sabo, jtsabo@ssa.gov
The North American Trade Automation Prototype (NATAP): The trilateral Information Exchange and Automation Working Group developed a vision for processing commercial transactions to fulfill the provisions of Article 512 of the North American Free Trade Agreement (NAFTA). The prototype will cover land border transactions: truck and rail. Participants will include Customs, Immigration, Transportation, Census, state and local authorities, and the international trade community. During the prototype, traders and brokers will submit common, standardized, commercial goods and transportation data to the governments (Canada, Mexico, U.S.) in UN/EDIFACT syntax via the Internet using a Trade Software Package (TSP). The governments will perform processing and selectivity functions and return the results of their processing to the trader or broker via the Internet. Transaction related data consists of proprietary information such as trading relationships among sellers and buyers, importers, etc., the prices paid for merchandise, and the declarations made to the governments for the payment (or refund) of import duties, taxes, and fees. This information must be protected against unauthorized access. Accordingly, the TSP must have adequate security through encryption and decryption. (For further info see http://www.itds.treas.gov) Point of Contact: Edward Grose, edward.grose@grosee00.customs.sprint.com
The Patent and Trademark Office's (PTO) International Patent Document Exchange Project will demonstrate the exchange of patent documents in secure electronic form between the Trilateral Offices (U.S. Patent and Trademark Office, European Patent Office, and Japanese Patent Office) and the International Bureau of the World Intellectual Property Office (WIPO) to reduce processing costs and the burden on applicants. Point of Contact: Wesley Gewehr, gewehr@uspto.gov
The Small Business Administration (SBA) Electronic Lending Program is an initiative to re-engineer business loan guarantee processes. The Emergency Access project will feature acceptance of electronic applications for SBA guarantees on FA$TRAK loans from a small group of bank lenders. Point of Contact: Donna Clark, donna.clark@sba.com
The Department of the Treasury, jointly with the GSA Center for Electronic Messaging Technologies, will implement an Electronic Messaging Services Network Infrastructure. This will be comprised of a private Administrative Management Domain for federal government use offering origin authentication, secure access management, data confidentiality, data integrity, non-repudiation, and emergency access. This infrastructure will consist of: SMTP and X.400 email, X.500 directory services, and an Electronic Commerce Clearing House. Point of Contact: Michele Rubenstein, michele.rubenstein@dasis.treas.gov
The further information or if you have any questions about the Key Recovery Demonstration Project, please contact Ms. Patricia N. Edfors, U.S. Department of the Treasury, at (202) 622-1552,patricia.edfors@cio.treas.gov
[Commerce Business Daily: Posted May 29, 1997] From the Commerce Business Daily Online via GPO Access [cbdnet.access.gpo.gov] PART: U.S. GOVERNMENT PROCUREMENTS SUBPART: SUPPLIES, EQUIPMENT AND MATERIAL CLASSCOD: 70--General-Purpose Information Technology Equipment OFFADD: National Institute of Standards & Technology, Acquisition & Assistance Div., Bldg. 301, Rm B117, Gaithersburg, MD 20899 SUBJECT: 70--SUPPORT DATA ENCRYPTION IN FEDERAL GOVERNMENT APPLICATIONS SOL 52SBNB7C1208 DUE 071197 POC Marsha Rodgers (301)975-6398, FAX (301)963-7732 DESC: BROAD AGENCY ANNOUNCEMENT -- The National Institute of Standards and Technology (NIST) is soliciting proposals for products and services which will demonstrate the viability of the recovery of keys that are used to support data encryption in Federal government applications. BACKGROUND: In May 1996, the Office of Management and Budget (OMB) released a white paper entitled "Enabling Privacy, Commerce, Security, and Public Safety in the Global Information Infrastructure". This paper stated that "government and industry must work together to create a security management infrastructure and attendant products that incorporate robust cryptography without undermining national security and public safety". Recently, a task group was formed for the purpose of testing the feasibility of implementing emergency key recovery capabilities in Federal Government applications. Approximately ten Federal agencies will participate in a Key Recovery Demonstration Project (KRDP), formerly known as the Emergency Access Demonstration Project (EADP) , to demonstrate the viability of key recovery. In this Broad Agency Announcement (BAA), NIST is soliciting products and services to support this project. GOALS: Specific goals of the KRDP include the following : (a) demonstrate the practicality of key recovery in Federal Government applications; (b) determine to what extent Commercial Off-The-Shelf ( COTS) products or commercially available services currently exist to support key recovery. Products that can be modified with minimum difficulty will also be considered; (c) determine how these products and services can be integrated into existing applications; (d) identify, implement, test and evaluate diverse key recovery technologies; and (e) identify barriers to interoperability among applications that use different key recovery technologies and make recommendations for lessening or removing those barriers. OBJECTIVES: Different methods of key recovery will be demonstrated . Encryption keys will be recovered by Key Recovery Agents upon receipt of an authorized request; keys used for digital signatures will not be recovered. Off-the-shelf technology is being sought for use on this project; there are no restrictions on standards compliance or algorithm usage. The KRDP will include a Public Key Infrastructure (PKI) which consists of a root Certification Authority (CA) and several dependent Certification Authorities. CAs certify the public keys of particular user communities and provide certification paths to other CAs so that public keys in other CA domains may be verified. The root CA will be located at and be operated by NIST. The remaining CAs will be located either at the sites of agencies participating in the project or at third party sites. Other components of the KRDP that will be procured under this BAA include Organization Registration Authorities (ORAs) and Key Recovery Agents (KRAs). ORAs authenticate users, validate requests, and interact with the Certification Authorities; ORAs may also request key recovery from a KRA. KRAs are used to recover keys, key components or plaintext messages upon the receipt of an authorized request. The infrastructure imposes no implementation constraints. An example of the services provided by a CA and a KRA could be included in a single product. An example infrastructure which illustrates three possible methods for accomplishing key recovery in a PKI environment can be found at the web site specified in this BAA. PROPOSAL CONTENT: NIST is seeking the following information about off-the-shelf products and/or services that can be used in the Key Recovery Demonstration Project: the functionality of the product or service (e.g., CA, ORA, KA, user); whether a product or a service is being offered; a list of all features (e.g., key generation) provided by the product or service; a description of the proposed key recovery methodology to be used, if appropriate; whether the proposed product or service is currently available and, if not, the expected date of availability; the requirements for operating or communicating with the proposed product or service; information which specifies how the product or service can be integrated with the product(s) and service(s) provided by other vendors or with other project elements (e.g., CA, ORA), if applicable; any constraints on product integration, such as dependence on a particular cryptographic algorithm, cryptographic product, communication interface etc.; and the extent to which additional negotiated enhancements to the product and/or service can be made . Since the enhancements that may be requested cannot be specified at this time, a general statement about the capability of responding to such a request is all that is required. The following information about the KRDP elements should be provided when being proposed by a vendor: (1) Certification Authority - A Certification Authority system certifies public keys and optionally generates public/private key pairs and may act as a certificate repository. If a Certification Authority system is provided as a service, specify the services provided and the cost of each service. Explain any factors that will cause the cost to vary and the method of obtaining the services that are provided. If a Certification Authority can be purchased, explain the impact of any factors that will affect the initial procurement cost and provide the cost of operating the system.Vendors who provide only a certificate repository service should specify the cost and the method of accessing this service . (2) Key Recovery Agent - If key recovery is provided as a service, specify the cost of registering with the key recovery service and the costs of key recovery operations. Indicate how these costs will vary, depending upon the number of users that are registered and the number of key recoveries that are performed. Specify the key archival services provided, if applicable, and the cost of these services. List and specify the costs of cryptographic products that must be used in conjunction with the key recovery service. If a key recovery product can be procured for operation by the user or user's representative, list all factors that will affect pricing. List and specify the costs of cryptographic products that must be used in conjunction with the key recovery service. (3) Organization Registration Authority - Specify all costs associated with the procurement and operation of an Organization Registration Authority. Explain the method of interaction with the Certification Authority and the Key Recovery Agent,wherever applicable. (4) User Software - Specify the functionality and cost of all user software that is required to perform encryption/decryption, key generation, key recovery, certificate path acquisition and verification and to interact with other system elements (e.g., Certification Authority, Key Recovery Agent). Responders should also provide any additional information about the functional capabilities, performance and cost of their product or service that will assist Federal agencies participating in the Key Recovery Demonstration Project in evaluating the offerings. Where cryptographic functions are performed, responders should state the degree to which their offered product or service complies with FIPS 140-1 . Where applicable, responders should specify the degree to which their offered product or service complies with the NIST draft " Minimum Interoperability Specification for PKI Components". SUBMISSIONS - Offerors are encouraged to submit concise, but descriptive proposals which will be accepted until 5:00 P. M., EST on JULY 11, 1997. Five (5) copies of the proposal shall be submitted to the following address: Marsha Rodgers, Acquisition and Assistance Division, National Institute of Standards and Technology, Building 301 Room B117, Gaithersburg, Maryland 20899. PROPOSALS SENT BY FAX OR E-MAIL WILL BE REJECTED. Proposals will be selected through a technical/scientific/business decision process with technical and scientific considerations being most important. Individual proposal evaluations will be based on acceptability or nonacceptability without regard to other proposals submitted under the announcement. HOWEVER, DUE TO BUDGETARY CONSTRAINTS, ALL ACCEPTABLE PROPOSALS MAY NOT BE FUNDED. No award will be made without a proposal to perform the specific effort within an estimated cost and time framework. PROPOSAL FORMAT- Proposals shall consist of two separate parts. Part 1 shall provide the technical proposal and Part 2 shall address costs. The proposal must not exceed the number of pages stated below (a "page" is defined to be a sheet of paper no greater than 8 x 11 inches, in type not smaller than 12 pitch) . Part 1 shall include: (1) Cover Page (1 Page) (a) Title: Key Recovery Demonstration Project Proposal; (b) Name of organization submitting proposal; (c) Contracting Official (Name, Title, Address, Telephone Number, Electronic Mail Address); (d) Technical Contact (Name, Title, Address, Telephone Number, Electronic Mail Address); (2) Organization Description (1 page)- (a) Principal business of organization; (b) Major qualifications and past achievements in data encryption/key recovery technology;(c) KRDP system elements for which proposal is being submitted.(3) Offered Products and/or Services (1-3 pages per offered product or service) - For each offered product and/or service, responders should provide the corresponding information requested in the Proposal Content Section of this BAA. Part 2, Costs, shall be supported by detailed breakdowns of labor hours by labor category and tasks/subtasks, materials, travel, computer and other direct and indirect costs. ADDITIONAL INFORMATION: The following documents can be accessed at World Wide Web site http://csrc.nist.gov/krdp: KRDP Project Summary, FIPS - 140-1, Implementation Evaluation Criteria for the KRDP, "Enabling Privacy, Commerce, Security, and Public Safety in the Global Information Infrastructure", referenced on Page 1, draft Minimum Operability Specification for PKI Compontents, and example Methods of Key Recovery. Any further technical questions relating to the BAA should be directed to : Jerry Mulvenna, Phone - (301) 975-3631, E-Mail Address - jerry.mulvenna@nist.gov. Any contractual questions should be directed to Marsha Rodgers at (301)975-6398. The period of performance of the BAA is six months from the date of each award. This announcement constitutes a Broad Agency Announcement as contemplated in FAR 6.102(d)(2). There will be no formal request for proposals or other solicitations regarding this announcement. Proposals shall be valid for a periodof twelve (12) months after submission. Where the effort consists of multiple portions which could reasonably be partitioned for purposes of funding, these should be identified with separate cost estimates for each. The Government reserves the right to select for award any, all, part, or none of the proposals received in response to this announcement. This BAA is an expression of interest only, and does not commit the Government to pay any pre-proposal or proposal preparation costs. All responsible sources may submit a proposal which shall be considered. EVALUATION CRITERIA/AWARD PROCESS : Proposals will be evaluated based on acceptability or unacceptability using the following criteria which are listed in decreasing order of priority: (1) Utility for Meeting Project Goals - For data recovery systems, the offered products and/or services should provide a method of implementing key recovery in Federal Government applications or the means to be integrated with the products and services offered by other contractors to provide this service. Reference the Implementation Evaluation Criteria for the KRDP at the above-mentioned web site. (2) Availability of Offered Products and/or Services - The offered products or services should be able to be integrated within a timeframe that will allow testing to commence as soon as possible.(3) Compliance with Applicable Standard or Specification- Where applicable, the degree to which the offered product or service complies with FIPS 140-1 or the draft "Minimum Interoperability Specification for PKI Components" shall be considered a positive factor in the proposal evaluation.(4)Diversity of Key Recovery Solutions- A primary project goal is to implement, demonstrate and evaluate different solutions for key recovery. Accordingly, products and/or services providing differing solutions will be preferred.(5) Past Performance - the offeror's capabilities, related experience, facilities, techniques, or unique combinations thereof which are integral factors for achieving the proposed objectives; and (6) Cost and cost realism - Cost realism will be used only as an evaluation criterion in proposals which have significantly under-or-over-estimated the cost to complete their effort. All awards made in response to this BAA shall be subject to availability of Government funds. Proposals will be evaluated and ranked by a Source Selection Evaluation Panel (SSEP) composed of representatives of Federal Agencies participating in the KRDP. LINKURL: http://www.nist.gov/admin/od/contract/contract.htm LINKDESC: NIST Contracts Homepage EMAILADD: Contract@nist.gov EMAILDESC: NIST Contracts Office CITE: (W-149 SN078311)
The Key Recovery Demonstration Project (KRDP) will include a Public Key Infrastructure (PKI) which consists of a root Certification Authority and several dependent Certification Authorities. The following figure shows an example infrastrucrture which illustrates three possible methods for accomplishing key recovery in a PKI environment. CAs certify the public keys of particular user communities and provide certification paths to other CAs so that public keys in other CA domains may be verified. Organization Registration Authorities (ORAs) authenticate users, validate requests, and interact with the Certification Authorities; ORAs may also request key recovery from a Key Recovery Agent (KRA). Key Recovery Agents are used to recover keys, key components, or plaintext messages upon the receipt of an authorized request. The infrastructure imposes no implementation constraints. For example, the services provided by a CA and a KRA could be included in a single product.
In method A of the example infrastructure, a key has been stored and is directly accessible by the Key Recovery Agent. In method B, key components have been stored at separate storage locations from which they may be retrieved. In method C, the Key Recovery Agent does not need to store the user's key. For example, a message header could contain a session key that has been encrypted with a key known by the Key Recovery Agent. Although the figure shows the key recovery services as being provided by a remote entity, these services can be colocated with any of the elements shown on the figure (e.g., ORA, user).
The objective of the Key Recovery Demonstration Project is to demonstrate the feasibility of emergency access to encrypted information in order to meet federal requirements for continuity of business, public safety, and national security interests. The demonstration project will examine various techniques for emergency access using varied technical approaches to encourage creativity in developing these capabilities. The demonstration project will not access digital signatures and, consequently, will encourage capabilities that use separate keys for digital signature and confidentiality. The choice of terms used in this list of criteria is intended to allow for this variety. The purpose of this evaluation criteria is to provide a disciplined approach to identifying and addressing the functional and security concerns related to the federal government's needs for emergency access to encrypted data. The criteria will serve as the basis for testing emergency access systems of pilot applications. The demonstration project members will enhance these criteria to meet the needs of each pilot application. However, the criteria presented below will serve as the minimum core criteria. Rationale for the enhancement of the criteria will be part of the business and cost/benefit analyses conducted for each pilot.
A. Authorized requester(s) is that individual or entity permitted to obtain a key and/or key component under conditions specified pursuant to proper, lawful authorization.
B. Data is specific individual facts or a list of such items; facts from which conclusions can be drawn; any or all facts, numbers, letters, symbols, etc. that can be processed or produced by a computer.
C. Emergency access - acquisition of the plaintext information associated with ciphertext for which the decrypting key is not readily available.
D. Emergency access system (EAS) - includes the policies, procedures, and all emergency access components required to recover encrypted data.
E. Key - a parameter that determines the transformation from plaintext to ciphertext and/or vice versa.
F. Key component - one of at least two parameters having the format of a key that is combined with one or more like parameters to form a key
G. Key encryption key - a key used exclusively to encrypt and decrypt keys.
H. Key Recovery Agent - company, individual and/or entity that runs an Emergency Access System.
I. Key Recovery Center - location from which keys are obtained, for the purpose of emergency access.
J. Owner of the data - to be determined for each pilot.
K. Session, as in session data, is a logical connection between two terminals; part of a message transmission when two parties are exchanging messages; that which takes place after a communications circuit has been set up and is functioning, and which ends when the circuit has been terminated.
A. An EAS shall implement policies, procedures, and mechanisms to ensure the confidentiality, integrity, and availability of the EAS and the information it processes, stores, audits and transmits.
B. The EAS shall implement procedures to recover from compromise of the confidentiality, integrity or availability of the EAS, subsystems, and keys and/or key components.
C. It should not be possible for an unauthorized person or process to alter, disable, bypass or corrupt an EAS, its subsystems or its components.
D. An EAS shall be designed and operated so that a failure by a single person, procedure, or mechanism does not compromise the confidentiality, integrity or availability of keys and/or key components or the EAS itself.
E. Unencrypted keys and/or key components shall be protected against modification, deletion and unauthorized disclosure while in storage, transmission or transfer.
F. The EAS shall ensure that each key recovery center (KRC) is uniquely identified. Encrypted data shall be bound to (associated with) the unique identity of the KRC and other information which is sufficient for the emergency access system to recover the encrypted data. This information shall be in an accessible format and occur with reasonable frequency to provide emergency access.
G. An EAS shall ensure emergency access to encrypted data without inducing errors, and without intruding upon or disrupting data system and/or storage service.
H. An EAS shall maintain data relating to emergency access events in sufficient detail for auditing by authorized officials or their representatives.
I. An EAS shall ensure that only the requested key and/or key component(s) shall be provided.
J. An EAS shall ensure that the decrypted data, and the key and/or key component(s) are obtainable in a timeframe reasonable to support federal government business operations.
K. An EAS shall enforce the start and end of a time interval for authorized access to stored data, session data, and/or multiple sessions of data.
L. In response to a proper, lawful authorization, an EAS shall be capable of providing more than one key and/or key component at once or over the authorized time interval, if appropriate.
M. An EAS shall be capable of providing the key and/or key component needed to decrypt the data regardless of whether the sender's or receiver's cryptographic product generated or received the ciphertext.
N. The EAS shall ensure that key and/or key components are provided only after authenticating the identity and authority of the requester, and in response to established mechanisms and/or procedures pursuant to proper, lawful authorization.
O. The EAS shall disclose keys and/or key components only to authorized requester(s).
P. The EAS shall ensure access to keys and/or key components for the life of the encrypted data. In addition, in the event an EAS subsystem or component dissolves or otherwise terminates emergency access operations, the emergency access capability shall be transferred to another EAS that meets the federal client's performance and security requirements.
Q. The EAS shall protect against disclosure of information to unauthorized entities regarding the identity of the person and/or organization whose key and/or key component(s) is requested, the fact that a key and/or key component was requested or provided, and the identity of the requester.
R. The Key Recovery Agent shall be a federal department or agency, or a U.S. registered company(ies), or through a U.S. treaty relationship.
S. The EAS operating procedures shall designate an individual(s) responsible as security and operations officer(s); all EAS shall designate individual(s) responsible for the security and the operations of their subsystems.
T. Non-Government entities performing EAS functions shall possess suitable evidence of corporate viability, e.g., a Certificate of Good Standing for the State of Incorporation, appropriate business registration documents, a credit report, errors and omission insurance coverage.
U. The entities performing EAS functions shall certify compliance with all applicable federal, state, and local laws and regulations.
V. The EAS serving the U.S. Government business shall interoperate only with EAS that meet these criteria.