Minutes of the February 25-26, 1998 Meeting of the 
Technical Advisory Committee 
to Develop a Federal Information Processing Standard 
for the Federal Key Management Infrastructure
Wednesday, February 25, 1998
A quorum being present, the eighth meeting of the Committee was called to
order at 9:15 a.m. by the Chair, Dr. Stephen Kent.  In addition to the
Chair, members present were: Joe Alexander, Josh Benaloh, Tom Cahill, Dave
Carman, Santosh Chokhani, Paul Clark, Jack Edwards, Mark Etzel, Bill
Franklin, Roger French, Daniel Harkins, Ken Konechy, Mike Matyas, and Joe
Pato.  Government liaisons in attendance were Elaine Barker, Miles Smid,
Julie Lever, Diane Dunshee, Jan Manning, Clem Boyleston, Richard Sweeney,
Judith Currie (a new attendee representing BXA). Also attending was Mark
Bohannon of the Department of Commerce.
After administrative announcements by Executive Secretary Ed Roback, Dr.
Kent thanked all the members for their work efforts in the working drafts
that had been provided between the meetings.  After short general
discussion, the Committee then heard a status report from each of the
working groups.  
Working Group #1 (Framework) Status Report - Roger French
Mr. French began by discussing the efforts from Work Group #1 meeting of
February 24 which met to review the WG draft in detail.  He then reviewed
the WG draft components.  The announcement section is virtually complete.
At the last TAC meeting the introduction was divided into three sections:
rationale, development of the FIPS, and overview of the FIPS itself.  After
much discussion, the rationale was discarded; Miles Smid and Ed Roback are
to write the FIPS development paragraphs; the overall summary will be
addressed when the FIPS is nearly complete.  Regarding the model, Mr.
French noted that Mike Matyas would brief it in detail.  The functional
requirements work has also progressed, thanks to the collaboration of Mike
Matyas, Jan Manning, Dianne Dunshee, and Elaine Barker.  Policy issues were
moved into a guidance document (from the appendix).  Interoperability
issues would have to be tracked in the FIPS to be sure the issues
identified in the WG's work were not inadvertently omitted.  
Working Group #2 (Security Models) Status Report - Josh Benaloh
Dr. Benaloh extended thanks to Dianne Dunshee, Jan Manning and Santosh
Chohkani for their efforts to clarify the security requirements.   There
was considerable discussion regarding whether to provide in the FIPS for a
role of a System Administrator to make it possible for recovery to be
selectable but not necessarily by the end user.  Dr. Kent noted that in
some contexts the user and the system administrator would be the same
person.  He asked Dr. Benaloh if a note to this effect would address the
issue.  In further discussion the "default-on" requirement was also raised
as an issue which the TAC needed to address. 
Working Group #5 (Interoperability) Status Report - Paul Clark
Dr. Clark began by noting that the WG had moved many of the routine
interoperability requirements to other WGs.  The issue of formats remains
to be resolved. Should the document specify type guidelines for the
standardization of formats that would be acceptable under the FIPS or
specify specific formats?  Support of a secure format(s) is not overly
onerous. Does the government envision constraints for specifying formats?
Question of how many and what constraints is the main question regarding
formats.  Security requirements make reference to the interaction between a
requester and a KRA via a standard protocol.
Working Group #8 (Documentation and Assurance) Briefing  -  Santosh Chokhani
Dr. Santosh Chokhani reported on WG8's activities.  In short, no action
items remain from the earlier draft, so the current draft is as it stands
at this time.
Model Presentation
Dr. Mike Matyas presented the new key recovery model to the TAC, covering
the general model for key recovery: KRI generation function, KRI management
function, and the 
key recovery function.  The TAC then proceeded to discuss the proposed
model.  Dr. Matyas also spoke on the subject of key recovery block [KRB]
idea and whether the group felt that this example would be one that should
be included in the standard. Clarity between the use of the term
'self-escrow' was discussed and noted that it needed to be resolved and
used consistently throughout the document.  
During the afternoon portion of the meeting the members met in meetings of
Working Groups 1 and 5.  After these meetings were concluded, the Committee
met as a whole and discussed the outcome of the respective group meetings.
No actions were taken on behalf of the TAC by the WGs.  In the short
briefings after the WG sessions, Mike Matyas discussed refinements to the
proposed KR Model.  Although no formal vote was taken, when asked, the
Committee appeared to be in general agreement with the proposal.  Also, the
interoperability working group noted that KRR or KRA interoperability will
not be addressed at this time as it is not a requirement of this effort.  A
minimum set of data between a KRA and a KRR will, however, be defined.
The meeting was then recessed for the day at 5:20 p.m.
Thursday, February 26, 1998
The meeting reconvened at 9:15 a.m.    In order to facilitate progress on
the drafts for TAC consideration, the morning session broke into three
groups: 1) security requirements, 2) issue of taking systems and
establishing correspondence to the functional models for mapping them
appropriately and work on the data element definitions for KRA and KRR and
3) defining of security requirements of those exchanges.
Before the Committee recessed for lunch, each group gave a short synopsis
of their work efforts from the morning session.  Dave Carman reported that
their breakout group had mapped a few KR systems to the model and it proved
robust. In response to the question, it was determined that the model
should support the Royal Holloway system.  The security requirements had
been realigned into six functions and copies distributed.  
In a discussion about the TAC's timetable, Mark Bohannon stated that
currently there are no plans to extend the charter of this Committee after
it expires in July.  There will be opportunities to work with NIST in other
ways on follow-up activities.  Therefore, there would only be two more TAC
meetings (4/98 and 6/98).  
Within one to two weeks, all of the revisions that have been made to date
should be sent to NIST to format it accordingly into a FIPS-like document.
This product should be shipped out to the members asking for any further
revisions to be sent back to NIST before the next meeting in April.    In
April, the TAC could conduct a very detailed review of the document.
Expectation for June meeting would be to have a candidate document to take
a vote on.  The vote would be on the Committee's agreement of a candidate
document to forward to NIST to be further developed as a FIPS.
Further development of the glossary/definitions is still needed and
comments should be provided to NIST on an ongoing basis.
The discussion then turned to a list of issues which Dr. Benaloh had
identified that required the TAC's attention.  These included:  1) how the
TAC will use its remaining time, 2) the default-on requirement, 3) the
system administrator issue, 4) partial compliance, 5) interoperability
between compliant and non-compliant systems, 6) switches for warning
messages, 7) strong binding of KRA data to the user & validation
requirements for KRI, 8) recoverability for KRA-KRR encrypted interactions,
and 9) receiver verification.  The first five issues were discussed in some
detail; however, because there was not time to discuss each in detail, Dr.
Benaloh stated that he would provide the TAC with a write-up of each issue
shortly following the meeting.  (ACTION - Dr. BENALOH)
Regarding how the TAC would use its remaining time, Dr. Kent said that work
would continue focusing on the model, and the security and functional
requirements.  Basic interoperability regarding the KRR-KRA would be
finished.  He would also like to see NIST aggregate the draft revised
pieces (due to NIST in two weeks) into a coherent FIPS for distribution and
review before the April meeting.  In April the TAC would conduct a very
detailed line-by-line review of the draft.  He would like to go into the
June meeting without the need to make changes at the meeting.  To
accomplish this, about two weeks following the April meeting a revision
would be circulated for comment with a request that each member indicate
(as in voluntary standards bodies) their intended vote (and if no, what
would have to be changed to change the vote to a "yes.")  
On the issue of the default-on, after much discussion, it was agreed that
the government liaisons had to address what it would really mean to be
"default-on."  
Regarding the system administrator issue, the question was raised whether a
switch could only be under the system administrator's control.  It was
pointed out that many end users are in fact their own administrators,
although it was suggested that the product might have  a "system
administrator" mode.  One way to address this issue would be for an
organization to configure and distribute an approved configuration of a
product in-house.  The question was then posed to the government liaisons
whether this would be acceptable.  (ACTION - LIAISONS)  There was also
discussion of a three-way switch (always-on, administrative control, user
control).  
The TAC then discussed issues regarding partial compliance.  There was no
clear resolution of this matter.
After discussing the many issues involving interoperability, Drs. Clark and
Matyas agreed to go back and define the basic requirement for a KR block.
On the requirements side, the question still remains of what it means to
complete a validation (i.e., that the user was using KR).  The Security WG
needs to more clearly examine the KR validation requirements and to check a
large number of schemes against them.  Dr. Kent agreed to send out a note
summarizing this discussion and issues raised and to be addressed.  (Action
- Dr. KENT)
The meeting was adjourned at 6:15 p.m.
References (on file with the Secretariat) 
#1 - General Overview
#2 - Announcement section
#3 - Interoperability Section
#4 - Working Group #2 section
#5 - Working Group #5 section
#6 - Working Group #8 section 
#7  - KMI Policies (appendix)