DRAFT PKIX WG Meeting Minutes

Stephen Kent <kent@bbn.com> Mon, 19 July 1999 17:55 UTC

Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27385 for <pkix-archive@odin.ietf.org>; Mon, 19 Jul 1999 13:55:35 -0400 (EDT)
Received: from localhost (daemon@localhost) by mail.proper.com (8.8.8/8.8.5) with SMTP id KAA07194; Mon, 19 Jul 1999 10:41:25 -0700 (PDT)
Received: by mail.imc.org (bulk_mailer v1.12); Mon, 19 Jul 1999 10:41:23 -0700
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA07168 for <ietf-pkix@imc.org>; Mon, 19 Jul 1999 10:41:22 -0700 (PDT)
Received: from [128.89.0.110] (COSMEC.BBN.COM [128.89.0.110]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id NAA16248; Mon, 19 Jul 1999 13:42:53 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: kent@po1.bbn.com
Message-Id: <v04020a01b3b8f6824668@[128.89.0.110]>
In-Reply-To: <600.932379868@cs.ucl.ac.uk>
Date: Mon, 19 Jul 1999 13:39:49 -0400
To: Theo PAGTZIS <T.Pagtzis@cs.ucl.ac.uk>
From: Stephen Kent <kent@bbn.com>
Subject: DRAFT PKIX WG Meeting Minutes
Cc: ietf-pkix@imc.org
Precedence: bulk
List-Archive: http://www.imc.org/ietf-pkix/mail-archive/
List-Unsubscribe: mailto:ietf-pkix-request@imc.org?body=unsubscribe

Theo,

Thanks for the reminder.  Below are the draft meeting minutes from last
week. I will accept comments, corrections, etc. until Saturday, 7/31,
before publishing the final form for the IETF Secretariat.

I want to thank Russ and Denis, who share the award for fastest submission
of slides.  All other speakers from the PKIX sessions should send me their
slides for inclusion in the IETF archives, in PPT format.

Steve Kent
Co-chair, PKIX WG

-----

PKIX WG Meeting 7/14/99
Edited by Steve Kent (WG co-chair)

The PKIX WG met only once during the 45th IETF and a approximately 180
individuals participated in these meetings.

The meeting began with a review of the status of all of the WG document,
presented by Warwick Ford, WG co-chair. The following text summarizes the
status of the documents:

PKIX COMPLETED DOCUMENTS

PKIX Cert/CRL Profile (RFC 2459)
		Approved as Proposed Standard
KEA Algorithms for Profile (RFC 2528)
		Approved as Informational RFC
HTTP/FTP Operations (RFC 2585)
		Approved as Proposed Standard
LDAP V2 Operational Protocols (RFC 2559)
		Approved as Proposed Standard
LDAP V2 Schema (RFC 2587)
		Approved as Proposed Standard
OCSP (RFC 2560)
		Approved as Proposed Standard
CMP (RFC 2510)
		Approved as Proposed Standard
CRMF (RFC 2511)
		Approved as Proposed Standard
Certificate Policy/Practices Guideline (RFC 2527)
		Approved as Informational RFC

PKIX WORK IN PROGRESS

ECDSA Algorithms for Profile (draft-ietf-pkix-ipki-ecdsa-01.txt)
		New draft to be issued for WG last call shortly
CMC (draft-ietf-pkix-cmc-02.txt)

Diffie-Hellman POP (draft-ietf-pkix-dhpop-00.txt)
		Ready for WG last call
Qualified Certificates (draft-ietf-pkix-qualified-qc-03.txt)
		Ready for WG last call
CMMF (draft-ietf-pkix-cmmf-02.txt)
		This item to be dropped from the program
Time Stamp (draft-ietf-pkix-time-stamp-00.txt)
		Near to WG last call
DCS (draft-ietf-pkix-dcs-00.txt)
		Under WG review
PKIX Rodamap (draftietf-pkix-roadmap-??.txt)
		Under WG review.
Others??


Reports on Established Projects:


Progressing RFC 2459 to Draft Status (R. Housley-Spyrus)
Russ described the requirements for progression to draft standard status
and solicited inputs from the PKIX community in support of this
progression. He also solicited edits to 2459 and noted that a defect report
on policy mapping in certificate validation processing has been filed. This
defect is expected to be resolved in a meeting in September, and the
results will be reflected in the revisions to 2459. Depending on the
resolution of this defect, it may be necessary for 2459 to "cycle in
grade," or it may be possible to progress to draft standard status. A straw
poll on a technical detail of delta CRL management was conducted, and the
consensus was to allow delta CRLs to be based on any specified base (vs.
only the most recently issued base).

Revision of RFC 2527 Certificate Policy Practice Guidelines (J. Rodriguez-IBM)
An activity on revising this informational RFC, based on operational
experience in the CA realm, and inputs from the legal community (ABA) has
been initiated. A small group has been created, with a corresponding
mailing list (pkix4@raleigh.ibm.com), to pursue this revision.

CMC and Diffie-Hellman POP (J. Schaad-Microsoft)
Final draft for CMC will be published in about one week, and then go to WG
last call.  The D-H POP draft will follow shortly.


PKIX Roadmap (S. Turner-IECSA)
Updated QC discussion, and added a number of items (not all of which are
accepted as work items for the WG). A comparison of PKIX vs. other
certificate profiles will be the subject of a separate document, as per the
recommendation of the WG chairs.

Time Stamping Protocol (D. Pinkas-Bull)
Denis has taken over as editor for this work, from R. Zuccherato.  A new
draft (version 2) was posted just prior to the IETF. Major revisions
include the scope of the protocol, removal of TDA support, moving status
outside of the signed token per se, removal of support for sequence of
hashes, format of TST time, etc.  Choice of TST format uses GeneralisedTime
plus sub-second granularity as a separate component, taken directly from
NTP. But this second component is primarily used as a means to serialize
time stamps within a one-second interval, not specifically to offer highly
precise time stamps. The question was raised whether it is appropriate to
make dual use of this field, i.e., for sub-second accuracy and for
serialization. Alternative is to use GeneralizedTime to millisecond
accuracy, and then use serial number for further serialization. This needs
to be resolved on the list.

Denis observed that time stamping is an area rife with intellectual
property claims.  A list of patents in this area, provided by Denis,
illustrates the recent history in this area (back to 1989).  It is noted
that a submission to ISO in April 1989, in part of work on a
non-repudiation framework, constitutes early published work in this area,
perhaps calling into question some of the most general patents on time
stamping.  Work will continue to resolve the cloud that hangs over this
work item. (See slides for additional details.)

Data Certification Server Protocol (C. Adams-Entrust)
Peter Sylvester is the new lead editor and a new I-D has been published as
of this week. Scope has been pretty broad, encompassing features of
notarization OCSP, SCVP, TSP, etc. So, this is an example of the question
raised on the list with regard to different protocols for different
services, or a grand unified protocol approach. Possible options include
freezing this spec now as an experimental protocol, reduce scope to avoid
conflicts with other work items and continue as a standard track protocol,
or keep broad scope and kill other protocols. Denis notes that, from a
conformance standpoint, bundling would create the need to allow subset
compliance, since not all clients or servers will need all of the features
offered by a unified protocol. Discussion explored the dimensions in which
one may choose to partition protocols, e.g., mandatory use of a server for
non-repudiation vs. optional use of a server for operations that could be
performed by a client.

Simple Certificate Validation Protocol (P. Hoffman-VPN & A. Malparni-Valicert)
Questions arise about many different parts of this proposal, including use
of the "tiny" syntax, choice of higher level encapsulation formats, support
for non-X.509 (OPGP) certificates, etc.  The authors agreed to delete the
tiny syntax for now, due its controversy. (One WG chair pointed out that
support for other than X.509 certificates is not within scope for PKIX.
Members of the OPGP WG question this position, asserting that the IESG
precluded OPGP from pursuing its own PKI work. This needs to be addressed
via discussion with the security ADs.) Denis and others provided more
detailed criticism. A straw poll of attendees shows did not show clear
consensus for or against the general notion of offloading certificate
processing from a client. Discussion of this topic will continue on the
list, and a new draft (minus the tiny syntax) will be published.

Qualified Certificates (S. Santesson)
A new draft will be posted in the next two weeks, reflecting the latest set
of changes based on mailing list discussions.  Highlights of this new draft
include: "de-legalization" of scope of the document, explicit syntax for
representing pseudonyms, an extension for inclusion of a hash of biometric
data (for human verification), and a new extension for marking a
certificate as qualified (via reference to an OID) and for expressing
reliance limits, separate from the use of the policy extension.  The author
requested that a WG last call be issued, after the list has had a chance to
review this latest version.


Other Topics:

LDAPv3 Profile (D. Chadwick- University of Salford)
Description of what features of LDAP v3 are relevant to PKIX and thus why a
profile is needed. This is especially important because LDAP v2 is being
phased out as an IETF standard and PKIX must migrate to v3.  The author is
soliciting comments from the list, and will co-ordinate with the LDAP WG as
well.

Attribute Certificates	(S. Farrell-SSE)
Stephen briefly reviewed the document, which profiles the X.509 AC.
Several WG members discussed appropriate forms of linkage between the AC
and the PKC, i.e., name vs. certificate or key hash, vs. issuer and serial
#, revisiting a debate on the list. This discussion did not resolve the
debate. General agreement to include a standard attribute set, but still
need to resolve details of these attributes, and must require support for
creation of new AC extensions. Questions were raised whether a new,
lightweight protocol is needed pull ACs, vs. use of LDAP, as an adjunct to
the push model that now underlies the AC use model.  Straw poll showed
overwhelming support to remove the retrieval protocol from the document.
This document defines the base profile, plus extensions that are optional.
The WG needs to work out details of what is base vs. extension. Do we need
an extension in the AC authority's public key certificate to characterize
what the authority is authorized to issue what ACs, or should this be done
via an attribute certificate itself?

Basic Event Representation Token (M. McNeil-GMT)
The author notes that this proposal relates to the TSP work, but uses what
is believed a more compact format so that it may be used in environments
where the size of the response from a TSA is too big. The primary use model
provided here is rather implementation-specific, i.e., tamper-evident
hardware in a local context, vs. a TSA accessible via a network.  A
Security AD raised questions about any intellectual property claims
associated with this model, as this may affect whether the proposal is
appropriate for an IETF WG. The speaker stated that he is aware of no IP
with regard to the proposed formats, etc. A PKIX WG chair expressed concern
over the apparent product-specific nature of the proposed model.  The
author acknowledges that only one vendor (Datum) offers the sort of
hardware cited as the primary use example. The WG chairs and the Security
ADs will discuss whether this work is appropriate for PKIX, given the
issues cited above.

CMP Interoperability Testing	(R. Moskowitz-ISSA)
Bob reported results of four classes of testing for 5 CMP implementations,
conducted by ICSA and NIST. The next workshop will continue and expand
testing.  One lesson from this work is that the CMP RFC fails to mandate
defaults in many instances, which reduces interoperability.  Bob's analysis
of this testing is that we need more MUSTs in this standard!  One security
concern arose, with regard to the size of the salt used in registration.

Temporal Data Token (M. Duren-WetStone)
Presentation focused on format for TDT (in the TSA) that helps attest to
the integrity of the time source, i.e., providing a link to a trusted time
source. This approach pushes evidence of time source into a token, vs.
other, external measures that a TSA takes to ensure the accuracy and
integrity of its time source. A claimed feature of this approach is that it
allows a client to be able to verify the utility (for non-repudiation) of
the returned token immediately, vs. the deferred verification more typical
of TSA operation. As with the BERT presentation, the speaker was asked
about possible intellectual property claims and about the breadth of vendor
support for the propose TDT format.  The speaker asserted that he was aware
of no IP claims, and that he was aware of at least two vendors who had
expressed interest in this format, although no more than one was building
products to this spec at this time.  The WG Chairs and the Security ADs
also will need to discuss whether this is within the scope of PKIX, before
this item progresses.