Posted to:
cyberia-l@listserv.aol.com
Date: Mon, 9 Dec 1996 15:03:27 -0800
From: "John A. Thomas" <jathomas@netcom.com>
John Taber and I attended the first meeting of the technical advisory committee to develop a Federal Information Processing Standard (FIP) for the federal "key management infrastructure." The meeting was held December 5 and 6, 1996 near the Dallas/Fort Worth Airport. Although the official documents referred only to "key recovery" instead of "key escrow", representatives used both terms interchangeably.
The committee is an advisory body to the Dept. of Commerce. Its recommendations pass through the National Institute of Technical Standards (NIST). The charter states membership will be no more than 24, so the ten "federal liaisons" present are apparently not considered members of the committee. The chairman is Stephen Kent, chief scientist for information security at BBN Systems.
The other members of the committee were employees of various computer and computer-security firms, including Sun Microsystems, Microsoft, Intel, Lucent Technologies, Cisco Systems, Digital Equipment, IBM and Motorola. Some security related firms were Trusted Systems, GlobalKey, and CygnaCom. Officials from Chase Manhattan Bank and Visa were also present. The only academic member was Dorothy Denning of Georgetown University.
The government liaisons included Michael Gilmore of the FBI, Jan Manning of NSA, and representatives of NIST, the Federal Reserve Bank, and the Defense Information Systems Agency. Some representatives were from agencies having no apparent need for cryptography, and therefore key recovery, such as the Small Business Administration and the Social Security Administration. Kent later questioned why the SBA would need key recovery when it had no need to store encrypted data. SSA needs encryption only when it receives confidential information over insecure systems.
Mary Good of the Commerce Department opened the meeting with a speech charging the committee to develop a federal key-recovery standard that can be extended to "public policy". Good urged the committee to confine itself to technical issues only, and arrive at a standard that could be implemented and would not be merely theoretical. Good also asked for "transparency" in key recovery, and a couple of the government liaisons mentioned this as well. Kent's opening remarks included the comment that the FIPS would only deal with crypto key recovery, not recovery of digital signatures, or with public key certification.
Most of the rest of the first day was taken up with introductions and comments by the members and liaisons. The general tenor of comments from corporate representatives was that key recovery had not been important to their customers, and while they did not oppose a key recovery standard for the government, they did oppose any effort to make it mandatory or make it a requirement for export. Some differed on whether an export requirement would be a problem.
Some typical comments follow. GlobalKey (which runs a private encrypted mail system) said using key escrow would be against is policy, and its customers would not accept it. Oracle stated it had had no requirement for key escrow from customers and saw no need for key escrow from its customers. It supported software-only solutions, and emphasized they must have no classified content. Motorola stated it was important not to impact the performance of wireless systems. Motorola advocated an open system supporting multiple algorithms and opposed the trusted third-party concept. Microsoft said it was pragmatic, willing to provide key recovery if customers want it, but it definitely does not want it mandated, nor tied in with export licensing. The Digicom member assumed the committee was not concerned with individual privacy rights vis-a-vis the corporate employer's power to recover an employee's encrypted message.
Jan Manning of NSA and Patricia Edfors of Treasury said the government had a corporate interest in key recovery like any other business, as well as for national security or law enforcement purposes. Manning agreed there was no place in the FIPS for concern over individual privacy rights and urged the committee to avoid privacy issues.
Kent said another issue the committee would face was the timeliness of any response required to a key-recovery request. Gilmore of FBI says the FBI's need for timeliness would vary, depending on the investigation. Denning said that data other than law-enforcement related messages could need timely recovery, citing encrypted medical data, or encrypted data from some kind of sensor. Another parameter for timeliness would be the number of requests made in a given time.
Although the issue was not explicitly debated, the commercial members seemed to feel that key recovery should be directed to stored data, while the government representatives were clearly using the term to cover both stored data and communications. Someone asked how session keys in a communication system were archived, and Denning remarked she didn't know of any system which archived session keys. The following morning, Kent said the issues included key recovery for storage, key recovery for communications, and key recovery for staged delivery (email). This seemed to remove the doubts some members had about the scope of the proposal. We were left wondering how key archiving could possibly work in communications networks. Consider a system where encrypted packets arrive in any order, with different keys and different key expirations.
After a commenter asked for clarification of who the users of the new standard were assumed to be, Kent stated: "The government wants the FIPS so that industry will produce products that government can use, and others will use as well." When another commenter pointed out that a user could defeat a key-recovery system with superencryption or other means, Kent said "...we have to be willing to let [that case] slip through the cracks."
Some participants attempted to distinguish between key backup and key recovery, the latter being the case where the parties to the communication are themselves unwilling to give up keys. Denning responded that "key recovery is backup." The distinction seems to be about who is a party to the communication -- the corporation whose employee has lost his keys, or the employee himself. Confusion on this point may exist because the members didn't distinguish the case where an entity using key recovery doesn't care about it in particular cases, but another entity, government, very well might.
Kent asked if the new standard should require a data recovery field in encrypted messages or files, and if so, should there be check for integrity of this field. Requiring a recipient to check this would encourage senders to use the standard. Someone asked how a recipient could check if a sender were, in fact, escrowing data, even if the field were present. Others said requiring a data-recovery field would make compatibility difficult for older systems, or "...those choosing not to use key recovery." Some expressed concern for the impact on system performance of sending extra bits. Miles Smid of NIST once referred to the data-recovery field as a "LEAF," invoking some laughter from those recalling Clipper's "law-enforcement access field."
Following a question on interoperability with systems not using the standard, Manning of NSA said the new export law required products to interoperate only with products using key recovery. This brought some irritated responses from the commercial members. One asked if the government had some bottom line the committee would have to accept if there were to be a FIPS. Manning said NSA had some requirements, and he assumed the FBI did as will. Kent suggested the government side put together a position paper. A member then asked who the customers of FIPS were supposed to be; given the government's special requirements, why was industry input even needed? Smid of NIST said industry input was needed, or no one would build systems for the government to use; also, the government may be involved in key recovery in commercial systems where "...public safety is involved." (It seemed plain that "public safety" in this committee is a code word for "law enforcement").
Kent suggested that if private parties want to operate key-recovery services (apparently meaning escrow services), they would have some negligence defense if they used a federal standard.
On the following day, December 6, Dorothy Denning presented a high-level schematic of key recovery associated with key fields and encrypted data. The schematic was thrown together the night before. She promised to make it available on her web page (www.georgetown.edu/~denning/).
Patricia Edfors of Treasury spoke about federal public key infrastructure pilot projects. She also described an "Emergency Access Demonstration Project," which was to "demonstrate the viability of key recovery, as a security service, for federal business applications." The project is to last 9-15 months, beginning August 1996. There will apparently be participation between certain government agencies and some private firm. Edfors said no attempt would be made to recover digital signature keys, create a key management infrastructure, or mandate which cryptography is used. However, "export requirements" will apply to all plans.
Kent wondered why the government would need key recovery for itself. He seemed to feel that key recovery for an individual's worksation is a data protection issue (backups) rather than true key recovery. Members mentioned a few cases where an employee was unable to decrypt his files, but no one knew of a case where an organization was unable to obtain shared data (e.g., a database), because it was encrypted. Other members seemed reluctant to accept his distinction. They seem to view key recovery as a way to audit proper use of organization assets by employees, or to protect the organization from malicious acts of employees, or to recover data if a custodian is run over by a bus.
Discussions continued to frame the issues for the project and assign functional tasks for sub-committees. Gilmore of the FBI said most key-recover issues would arise (for law enforcement) in the context of search warrants, not wiretaps, although the latter could be very important. In a question as to how long escrowed or archived keys should be kept, Gilmore said as long as the data existed, which might be indefinitely. When pressed, Gilmore said this was because some crimes have no statute of limitation. We thought some members might be mentally calculating storage requirements for session keys in a large communications system, if key storage and indexing was to be indefinite.
Manning of NSA said the National Archives, for example, would have to have access to recovery keys forever. No one asked why the National Archives might be archiving encrypted data.
Boland of GlobalKey also asked about keys to encrypted voice or video. No one seemed to have thought of this before.
Kent wrapped things up with a list of issues for discussion at the next meeting. These included:
The next meeting will be held in the San Francisco area on February 19 and 20, 1997. Before then the members will confer by email and attempt to set up working groups to present papers on particular topics.
The meeting ended with an opportunity for public comment. None was offered.
Our opinion was that the only reason for the existence of this project was the insistence of the government, primarily the law enforcement and state security agencies. Private industry seems to feel there is little demand for a key-recovery standard, since those needing it can implement it themselves. Industry representatives were obviously worried about export restrictions requiring key escrow, and possible attempts to make it mandatory in some way. As corporations use encryption more and more, there will obviously be a need to develop key recovery systems inside the firm. The justification for a federal standard, however, seems weak.
We felt that this project would probably end in failure, through inability of the industry and government parties to compromise, or if a standard did issue, few private firms would use it. It's even doubtful a standard could be completed and adopted before private systems are firmly in place. Is the whole thing just more of the government's increasingly delusional effort to control private cryptography, or does someone besides the security agencies really want a standard?
The committee will post information at www.crsc.nist.gov. We can fax a copy of the materials handed out. We'll try to answer any questions by email (or phone, if you're really in a hurry).
John A. Thomas | (972) 263-4351 | jathomas@netcom.com
Bowles & Thomas, L.L.P. | Voice | CompuServe 75236,3536
410 N.W Eleventh St. | (972) 262-6520 |
Grand Prairie, Tx 75050 | Fax | PGP public key available
=======> After January 1, 1997:
John A. Thomas | (972) 387-8880 | jathomas@netcom.com
Dolce & Thomas, L.L.P. | Voice | CompuServe 75236,3536
5720 LBJ Fwy., Suite 470| (972) 387-8881 |
Dallas, Texas 75240 | Fax | PGP public key available
[End post]
Material below provided by John Thomas, Bowles & Thomas LLP; digitized by jya.com December 9, 1996
Documents from the FIPS committee meeting 5-6 Dec.:
3. List of government liaisons
4. Questions for discussion passed out by chairman
6. Set of slides by Patricia Edfors of Treasury regarding federal PK infrastructure
7. Set of slides by Edfors regarding key recovery demonstration project
Agenda
Meeting of the Technical Advisory Committee
to Develop a Federal Information Processing Standard
for the Federal Key Management Infrastructure
December 5-6, l996
Sheraton Grand Hotel at Dallas/Ft. Worth Airport
Dallas, Texas
Note: All portions of Committee meetings will be open.
Thursday, December 5, 1996
11:00 Welcome, Agenda Overview, Initial
Introductions
Executive
Secretary
Edward Roback
11:10 Chairperson's Remarks
Stephen Kent
11:15 Opening Address
Under Secretary
of Commerce for Technology,
Mary L. Good
11:35 Discussion and
Member
Introductions / Perspectives (Part I)
12:30 Lunch (on own)
2:00 Member Introductions / Perspectives (Part II)
3:45 Break / Recess of Formal Meeting
4:00 Information Briefing: Ethics and
Federal Advisory
Committee Act
Office of the
General Counsel,
U.S. Department
of Commerce
David Maggi
Friday, December 6, 1996
Resume Formal Meeting
9:00 Member Introductions / Perspectives
(Part III)
(as necessary)
10:15 Break
10:45 Information Briefing:
Federal Key
Recovery Pilots
Patricia Edfors
11:45 Framing Issues for Discussion
Stephen Kent
12:00 Lunch (on own)
1:30 Logistics & Timing: Future
Meetings
Discussion
of Agenda for Next Meeting
1:45 Development of Workplan, Work Groups, etc.
3:15 Break
3:30 Public Participation
(5 min. max
per speaker;
sign up in
advance with Secretary)
4:00 Open
5:00 Adjourn
Technical Advisory Committee
to Develop a Federal Information Processing Standard
for the Federal Key Management Infrastructure
Chairperson
Dr. Stephen Thomas Kent
Chief Scientist - Information Security
BBN Systems
MS 1312A
70 Fawcett Street
Cambridge, MA 02140
Mr. Joe A. Alexander
Senior Marketing Manager
Sun Microsystems Federal, Inc.
7900 Westpark Drive Suite A110
McLean, VA 22102-4203
Dr. Josh Benaloh
Cryptographer
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
Mr. Walter E. Boland
Chief Engineer GlobalKey, Inc.
P.O. Box 1817
Colorado Springs, CO 80901
Dr. Ernest Brickell
Vice President, Chief Scientist
CertCo
8205 Spain NE Suite 201
Albuquerque, NM 87109
Mr. Thomas P. Cahill
Vice President
Chase Manhattan Bank
4 Chase Metrotech Center
11th Floor Brooklyn, NY 11245
Mr. David W. Carman
Senior Cryptographic Engineer
Trusted Information Systems, Inc.
3060 Washington Road (Rt. 97)
Glenwood, MD 21738
Dr. Santosh Chokhani
President CygnaCom Solutions
1477 Chain Bridge Road
Suite 201
McLean, VA 22101
Dr. Dorothy E. Denning
Computer Science Department
Georgetown University
Reiss 225
Washington, DC 20057
Dr. John S. Edwards
President
DIGICOM, Inc.
1420 Springhill Road, # 600
McLean, VA 22102
Mr. Garland S. Ellis, Sr.
General Manager
Intel Corporation
Data Security Operation
CH6-410
5000 W. Chandler Blvd.
Chandler, AZ 85226
Dr. Mark H. Etzel
Lucent Technologies
Bell Laboratories
300 Brickstone Square FL6
Andover, MA 01810-1435
Mr. William A. Franklin
AT&T
P.O. Box 20046
Greensboro, NC 27215
Mr. Roger French
Digital Equipment Corporation
Manager, Security Program Office
MS: ZK01-31E11
110 Spit Brook Road
Nashua, NH 03062-2698
Mr. Richard K. Hite
Vice President
VISA International
900 Metro Ctr. Blvd.
Foster City, CA 94404-2170
Mr. Russell D. Housley
Chief Scientist
SPYRUS, Inc.
P.O. Box 1198
Herndon, VA 20172
Mr. Ken Konechy
Rainbow Technologies, Inc.
50 Technology Drive
Irvine, CA 92618
Dr. Michael J. Markowitz
Vice President
Information Security Corporation
1141 Lake Cook Road
Suite D
Deerfield, IL 60015
Dr. Stephen M. Matyas
IBM Corporation
IBM Internet Division
522 South Road, MS P330
Poughkeepsie, NY 12601-5400
Mr. Joe Pato
Hewlett-Packard Company
800 Apollo Drive
Chelmsford, MA 01824-3623
Mr. Donald E. Rothwell
Vice President and Director
Information Security Operations
Motorola
8201 E. McDowell, H2005
Scottsdale, AZ 85252
Executive Secretary
Edward Roback
NIST/CSL
Computer Security Division
Building 820, Room 426
Gaithersburg, MD 20899
Federal Liaisons to the
Technical Advisory Committee
to Develop a Federal Information Processing Standard
for the Federal Key Management Infrastructure
Mr. Howard F. Bolden
US Small Business Administration
OIRM/ Suite 4000
409 3rd Street, SW
Washington, DC 20416
Mr. Clem O. Boyleston
Department of Energy
Mr. Jan Manning
National Security Agency
Director NSA
9800 Savage Rd.
Ft. Meade. MD 20755
Ms. Patricia Edfors
US Department of the Treasury (GITS)
1425 New York Ave., SW
Suite C-126
Washington, DC 20220
Mr. Michael Gilmore
Federal Bureau of Investigation
Engineering Research Facility
Building 27958A
Quantico, VA 22135
Dr. Frank Perry
Technical Director for
Engineering and Interoperability
Defense Information Systems Agency
Dept. of Defense
Mr. John T. Sabo
Social Security Administration
Office of Programs & Policy
Mr. Larry P. Shomo
Special Assistant for IT Security
Office of the NASA Chief Information Officer
NASA Headquarters, Code AO
Washington, DC 20546
Mr. Miles E. Smid
Computer Scientist
NIST Building 820, Room 426
Gaithersburg, MD 20899
Mr. Richard Sweeney
Federal Reserve Bank
104 Marrietta Street, NW
Atlanta, GA 30303-2713
- To what extent does a key recovery FIPS need to (can be?) be algorithm independent? Will the FIPS apply to symmetric key management systems, or only to asymmetric systems?
- What level of responsiveness will be required by law enforcement, corporate and individual users, with respect to retrieval of keys from recovery centers?
- Will products be required to perform some sort of check to ensure that keys they are using are covered by a key recovery system?
- Will the FIPS include criteria for secure and reliable operations for key recovery centers?' If so, will a government agency, or approved laboratories, be responsible for certifying that a key recovery center operates in a fashion consistent with the FIPS criteria (vs. free market approaches)?
- What are the separable aspects of the "key recovery problem" and what portions of the problem should be addressed by the FIPS?
- How should the committee organize itself to address these parts of the problem that will be the subject of the FIPS?
[Transcription of original]
| {K}Ki | ... | {K}Kn | {Data}K |
Recovery key Ki is archived
with key recovery/escrow center (TTP)
whole or split
Recovery key Ki is unique to
Product - Clipper/Capstone
User - Nortel, CertCo, Fortezza
Center - TIS, RSA, IBM, AT&T
Recovery key Ki is associated with
sender
receiver
Recovery key Ki is used for
recovery of K only
distribution of K and recovery
Recovery services
release Ki or time-bound derivative
use Ki to decrease & release K
Standards needed for
recovery fields
recovery services & center operation
Set of slides by Patricia Edfors of Treasury
regarding federal PK infrastructure
GITS 10.13
Federal Public Key
Infrastructure Activities
The Vision
The Approach
The Objectives
The Course of Action
Federal Agency Activities Involving Digital Signature Technology
Industry Partners
|
|
|
|
|
NIST |
|
|
|
|
|
|
|
|
CRADA Partners |
|
|
|
|
CA |
|
|
|
|
|
|
|
|
|
|
NSA |
GSA/USPS |
NTIS |
CommerceNet |
|
|
|
Business |
|
|
|
|
|
|
|
|
|
IRS |
DEA |
EPA |
FDA |
GNMA/HUD/ |
NASA |
SSA |
|
|
FAA |
NIST |
USPS |
DOE |
LLNL |
NATAP |
Census |
|
|
Library of |
National Archives |
CIA |
EOP |
NSA |
Southwest |
Georgia |
|
|
Defense Messaging |
GSA/USPS |
Federal Reserve |
Defense Travel |
Transportation |
Agriculture |
FAA/ARINC |
|
|
HCFA |
NTIS |
SSA PEBES |
SBA |
Federal Networking |
FAA/ARINC |
DOD |
|
Service |
|
|
|
|
|
|
|
|
|
AT&T/ISC |
Motorola |
Verisign |
GTE |
Nortel |
Spyrus |
Certicom |
|
|
Cylink |
RSA |
Tandem |
Dyncorp |
IRE |
Zebulon |
Mergent |
|
|
Proxy (ARINC) |
CygnaCom |
TIS |
BBN |
CommerceNet |
Microsoft |
|
|
|
|
|
VISA |
Mastercard |
|
|
|
Set of slides by Edfors regarding key recovery demonstration project
Emergency Access
Demonstration Project
Emergency Access Task Group
Interagency Working Group on Cryptographic Policy
Demonstration Objective
Rationale
Need for privacy implies need for encryption
Encryption requires use of crypto keys
Keys can be lost, stolen, modified
Team Members
Treasury - Chair
NIST
NSA
FBI
Pilot Selection Criteria
Pilot Applications
Team Members (continued)
GTE
VeriSign
SourceFile
Netscape
Microsoft
Premenos
RSA
TIS
Nortel
Motorola
Lotus
AT&T/ISC
Pitney-Bowes
Tandem
Others TBD
Industry Selection Criteria
Demonstration Approach
- Core, Pilots & Industry develop
- design criteria tailored
- Core assists with system security eng'g
Demonstration Locations
We are NOT
[End]
Thanks to John Thomas.
