Minutes of the April 22-23, 1998 Meeting of the 
Technical Advisory Committee 
to Develop a Federal Information Processing Standard 
for the Federal Key Management Infrastructure

Wednesday, April 22, 1998

A quorum being present, the ninth meeting of the Committee was called to order 
at 9:15 a.m. by the Chairman, Dr. Stephen Kent, at the Tremont House Hotel, 
Boston, Massachusetts.  As with all other TAC meetings, all sessions were open 
to the public.  In addition to the Chairman, members present were: Josh Benaloh, 
Tom Cahill, Dave Carman, Santosh Chokhani, Paul Clark, Jack Edwards, Mark Etzel, 
Daniel Harkins, Richard Hite, Mike Markowitz, Mike Matyas, Joe Pato, and Don 
Rothwell.  Government liaisons in attendance were Elaine Barker, Clem Boyleston, 
Tony DiClemente, Diane Dunshee, Julie Lever, Jan Manning, and John Sabo. Also 
attending was Mark Bohannon, Chief Counsel for the Technology Administration, of 
the Department of Commerce.

Ed Roback reviewed the agenda for the two-day meeting and the handout materials.  
(See references.)  The Chairman then proceeded to discuss his goal for the 
meeting as reaching agreement on the spirit of what is in each of the sections 
and as much agreement as possible on the specific wording. 

Diane Dunshee reported on results of the government liaisons' work to address 
the questions raised by the TAC at the February meeting (which Dr. Benaloh had 
drafted).  (See references.)  Highlights included a discussion of the liaisons' 
view that a system administrator function is needed, and whether a switch should 
be present to allow user and administrator choices for key recovery (KR). A user 
option for key recovery selection or de-selection is permissible if the system 
administrator has not made the use or non-use of KR mandatory.  Ms. Dunshee 
continued with an explanation of the need for higher security for KRAs and why 
the liaisons felt that compliance with FIPS 140-1, level 2 was therefore 
warranted. 

During these discussions, the Chairman expressed concern that many of the 
government responses did not completely describe the basic underlying 
requirement, but were, rather, at the level of derived requirements.  It would 
help the TAC's work if the basic requirements were completely described and 
understood.  

Next followed a lengthy discussion of the issue of receiver validation. The need 
for specific examples of how this might be achieved was identified.  Dr. 
Markowitz raised the need to clarify whether the validation was done for only 
the recipient in question or all recipients.  After discussion, there appeared 
to be agreement that the validation under discussion was for the specific 
receiver.   

Dr. Kent then reviewed plans for the rest of the TAC meeting.  First the TAC 
would conduct a top-level review of the document, then a more detailed review of 
each section, and finally focus on sections that the TAC determines require more 
attention.  

With no members of the public expressing interest in addressing the Board, the 
lunch break ensued. 

Following the lunch break, the Chairman began the section by section review.  

Overview.  Regarding section 1, he noted that there should be a discussion of 
what is in the rest of the FIPS and what is outside the scope of the FIPS (e.g., 
operational security issues for a KRA).  He agreed to re-draft the overview 
section.  (ACTION - Dr. Kent)  Mr. Roback pointed out that such issues could 
also be addressed in the accompanying letter to the Secretary.

There followed a discussion of an observation made by Mr. Harkins that much of 
the document seems to imply that the endpoint of the encryption is the same as 
the endpoint of the communications.  He noted that he does not see sufficient 
justification for KR for other than end-to-end communications.  Mr. Harkins will 
draft text to address this issue for the TAC's consideration.  (ACTION - Mr. 
Harkins)

It was noted that the terms "recovery data medium" and "encrypted data medium" 
need to be edited out of the document.  Also, the discussion of interoperability 
in the overview will be eliminated, as there are currently three separate 
discussions of interoperability, not counting the section prepared by the 
Chairman and inadvertently omitted in the consolidated draft.

Security Model. The Chairman began by inquiring exactly what the section was 
intended to accomplish.  Dr. Matyas replied that it will let readers map an 
existing KR system to the model and let the model give insight into KR that 
might go beyond any particular technique.  Dr. Kent noted that the model should 
concretely define what each of the functions entails.  For example, review and 
remove functional requirements from Section 5 that should belong in Section 2.  
Interoperability should also show up in Section 2.  It would be a natural place 
to describe what the interoperability issues are in this environment rather than 
have sections 4 and 7 describe them separately.

It was also suggested that the requirements be referenced by a numbering 
sequence and collectively listed at the end of the document so as to insure that 
none of the requirements are overlooked.

 It was also suggested, without disagreement, that the requirements in the FIPS 
should be sequentially numbered.  (ACTION - NIST) 

The TAC then briefly discussed the remaining section topics in the outline, and 
a roadmap to reorganizing the document was prepared and distributed by the 
Chairman.  (See references.) 

KRS Components/Products - This section could be turned into an appendix, with 
the exception of the Sections 3.1.1 through 3.1.3 which will be put into another 
section somewhere.  Term of "end-user system" used in figures will be changed to 
"cryptographic end system."

Interoperability - Sections 4.1 and 4.2 will be removed while 4.3 and 4.4 will 
be integrated into Section 2.7 (Interoperability) along with previously drafted 
merial from the Chairman.

Functional Requirements  -- Some sections will be incorporated into section 2 
and some will be incorporated into the security requirements (old section 6, new 
section 3).

Security Requirements  -- This section will be revised and become the new 
section 3.

Interoperability Requirements  --  Some of these points are also covered in 
other sections of  the report and will be moved or eliminated accordingly.   
7.1.7 should be eliminated.  7.2 will be attached to another section. Some 
requirements in 7.1 will be moved to Section 2, others to the security 
requirements section.

Assurance Requirements   -- Minor revisions will be made; this section will 
become the new section 4. 

Appendix A  -- This section will contain examples, as needed, to assist 
developers and vendors in understanding the KR model.  

Appendix B -- This appendix will describe a recommended key recovery block 
format as guidance that standards bodies [or government designers] may refer to 
when they employ encapsulation.

Appendix C -- This will contain X509v3 certificate extensions and a profile for 
other extension employed in such certificates. This current draft is a starting 
point, but there is a need for more work.

Appendix D  --  This will contain illustrative examples of how key recovery 
enabled systems can be designed to maximize interoperability, both with systems 
that do not implement key recovery, and with systems that implement different 
key recovery schemes.

Dr. Kent then discussed how the TAC could address issues the following day. Four 
groups would be needed:  1) Section #2, (Dr. Matyas and Ms. Barker to 
coordinate), 2) Sections 3.1.1 - 3.1.3 (Mr. Carman to coordinate), 3) Section #6 
(Ms. Dunshee to coordinate) and 4) Interoperability and Overview (Dr. Kent).  

The meeting was then recessed for the day at 5:00 p.m.

Thursday, April 23, 1998

The meeting was reconvened at 9:15 a.m. on Thursday, April 23, 1998.  A public 
attendee, Daniel J. Greenwood, Deputy General Council for Commonwealth of 
Massachusetts, commented that they are very interested at the State level in the 
encryption effort and its potential effects on State and local business.  He 
said that they had participated in the recent CRISIS report done by the NRC.  He 
stated that while the Commonwealth has no formal position on key recovery 
issues, they believe that this FIPS will be a very important issue to States.  
He offered to review the draft and provide feedback to the Committee prior to 
its next meeting, if such an option were available and appropriate, or during 
public comment periods.

Next, the committee separated into small groups and revisited separate sections 
of the draft document, as planned the previous day.  They reconvened as a 
committee at 11:30 a.m. to begin discussion of the editorial changes made by the 
individual groups.

Dr. Kent's rewrite of the overview now consists of three pieces, starting with 
several paragraphs of a general introductory nature followed by 1.1 -- scope of 
the standard; 1.2 a roadmap to the standard; 1.3 security levels of the 
requirement, 1.4 security assurance levels. 

New draft format will consist of Section 1:  Introduction; Section 2:  Model; 
Section 3:  Security Requirement and Section 4:  Security Assurance 
Requirements.  These sections will be followed by the appendices.

Ms. Barker reported on the changed proposed to Section 2.  Dave Carman reported 
on the changes proposed to Section 3 (the new section 2), which will address 
mappings, section 2.9 will address KR techniques drawing upon the language 
currently in 3.1.1 to 3.1.3.  Paul Clark discussed 7.l.l and 7.1.4 and other 
sections to be handed off to Section 2.  

Mr. DiClemente stated that the KRR-KRA requirement should have a standardized 
format for the law enforcement agencies to follow.  There was discussion whether 
this meant a single format for all or a single standardized format per system.  
(This was tied to the liaisons' response to Question 8.)  He also raised the 
issue regarding the affordability of dealing with such systems, particularly at 
the state and local levels.    Another major concern is electronic 
authentication of the request as well as the likely need to get multiple session 
keys as a result of a single authorization request.  Finally, he noted that in 
section 7.4.2, authority should be added (e.g., the Fourth Amendment).  

Diane Dunshee reported on the output of the group review of the security 
requirements section.  Common criteria references in this section will be 
deleted. Section 6.1.1.8 will also be deleted.

Following lunch, the TAC turned its attention to three issues:  1) system versus 
function level compliance, 2) partial compliance, and 3) security assurance.  

Dr. Benaloh had earlier raised the issue of whether the FIPS would provide a 
means to validate a system as conforming versus conforming only at a functional 
level.  It was agreed that the TAC could not properly address this issue in the 
FIPS and thus would consider raising the issue in the TAC's transmittal letter 
to the Secretary.   

On the issue of partial compliance, which was raised during the discussion of 
the liaisons' answers to the TAC's questions, there was no immediate agreement 
on how to proceed, but three options were identified:  1) only identified 
functions would be submitted for evaluation, all else ignored, 2) there would 
have to be a capability to turn off the non-compliant modes of KR functions if 
compliant modes of KR functions are activated, and 3) a product could not be 
considered as conformant if it has a KR function for which it does not have a 
compliant mode.  Dr. Kent asked that Dr. Etzel put together text describing each 
alternative for the TAC to discuss in June.  (ACTION - Dr. Etzel)

Following this was a discussion of the three assurance levels in Section 8 and 
how they should be reconciled with the two functional security levels.  It was 
decided that the standard would not provide for multiple assurance levels for 
each functional level.   Dr. Chokhani would, in general, revise the section to 
map the highest assurance level to functional level 2, the mid-level assurance 
to the functions involved in a KRR or KRA and the lowest level assurance to the 
rest of the functions.  (ACTION - Dr. Chokhani)

Mr. Roback reviewed a proposed TAC timeline that he developed.  (See 
references.)  Section coordinators are to submit their revised section to NIST 
by May 14, 1998.  (ACTION - Dr. Kent, Ms. Dunshee, Ms. Barker/Dr. Matyas, Dr. 
Chokhani, Mr. Carman, and Dr. Clark)  

The Chairman requested that when TAC members review the revised draft, should 
they identify particular issues which would result in a non-concurrence, they 
should bring specific suggested changes that, if adopted, would result in their 
support of the draft.  (ACTION - Members) 

In member discussions with the Chairman, it was discussed and decided that at 
the June meeting the committee would review the document section by section for 
a vote as well as to take a vote on the document as a whole.  (Votes will be 
taken if there is not concurrence.)  Members were asked to submit topics and 
draft text for the transmittal letter to the Chairman and Mr. Roback by June 1, 
1998.  (ACTION - Members)  

The meeting was adjourned at 3 p.m.

References (on file with the Secretariat)

1. Draft assembled standard
2. Interoperability Draft from WG#5
3. Government Liaison Answers to February TAC Questions
4. Proposed Timeline to Completion
5. Dr. Kent's revised Interoperability section (as distributed)
6. Roadmap outline for WG work on 4/23
7. Agenda
8. Federal Register Meeting announcement