draft meeting minutes

[Stephen Kent <kent@xxxxxxx>]

Folks,

	Attached are the DRAFT minutes from the two days of PKIX meetings
at the 40th IETF.  I would appreciate it if those who were presenters at
the meetings could review the minutes and send me corrections before Xmas.

Thanks,

Steve
-----------------------------------------------------------

PKIX WG Meeting Minutes (12/8+10/97)

Approximately xxx attendees participated in the two PKIX WG session at
the 40th IETF.  Several of the PKIX I-Ds have been through working
group last call and have moved on to the IESG for review, but a few
issues remain and must be resolved prior to IESG approval and IETF
last call.


Part 1 (Certificate/CRL Profile)

This draft completed WG last call, but a few issues remain to be
resolved.  Issues relating to use of algorithm OIDs and some ASN.1
errors have been resolved, and the authors have avoided inclusion of
some legal language that was previously proposed.

Unresolved issues:
	- There is disagreement about wildcarding in names (e.g., DNS
and RFC 822).  A small group met to resolve this issue after the (2nd)
meeting.  That group suggested disallowing use of asterisks in these
name forms as a means of conveying the notion that the name was a
placeholder for a set of names.  Instead, a new document will be
created to describe name form conventions, on a per-application
context basis, with explicitly declared semantics, in support of the
requirements that motivated use of wildcard name forms.
	- We are using '88 ASN.1, but BMP string is a new ASN.1
construct, so this is a technical matter (but does not affect bit on
the wire format).
	- There is a related issue is use of UTF8, a new ('98 ASN.1)
character set encoding, an alternative to BMP.  This appears to be an
issue at the IESG last call level of approval, but is not an issue
among PKIX members.
	- For key usage, we propose to stay with what X.509 says,
despite disagreements over whether it is the "right" interpretation.
	- Should CRLDistributionPoint be critical, non-critical, or at
the discretion of the CA?  Currently, it cannot be marked critical,
but this can cause problems.  The concern is that if marked critical,
then a client without support for this would reject the certificate,
even if the user was willing to ignore this extension, as required by
X.509. Not resolved.

Part 2 (split into LDAP, FTP, HTTP, OCSP)

No problems with FTP or HTTP.  LDAP issues revolve around v2 vs. v3
usage.  We agree to add a new work item to deal with v3, since current
LDAP use in PKIX is based on v2.  There was a suggestion to add a work
item to develop a minimal schema for PKIX use of LDAP.  This is a
possible overlap with the LDAP WG, so coordination is required.  Later
during the week the LDAP WG chair was contacted and it was determined
that creation of a schema for use with PKIX was within the purview of
the PKIX WG. See slides for additional details.


Part 3 (Certificate Management Protocol)

No issues here other than the character set concerns raised under Part 1.


Certificate Request Syntax (PKCS7/10 focus)

A proposal was made to move work on this to S/MIME WG, and Schiller
and Housley (S/MIME WG chair) have no objections.  However, this work
is not S/MIME-specific and several PKIX and S/MIME WG members believe
that this work item should remain in PKIX, as it is more general.  The
fundamental question is whether CRS is a completely separate protocol,
focused on S/MIME, or if it is a profile for Part 3.  Not resolved,
but straw poll of attendees showed a plurality of attendees in favor of
keeping the work item in this WG, and only a single vote in favor of
moving it to S/MIME.  The S/MIME WG, meeting two days later, concurred
with this and did not recommend adoption of CRS within that WG.

At the second PKIX WG meeting, a compromise approach was announced,
reconciling CRS and CMP.  In essence, CRS will be revised and will
define a common request syntax, and CMP will adopt this syntax as the
certificate payload type within that protocol (replacing the current
certificate payload format).  The Security AD approved the progression
to IETF last call with a modified version of CMP, reflecting this
change.  This new, harmonized certificate request format will appear
as a separate RFC.  CMS will make use of the same format and that
protocol will progress as a separate RFC as well.


Time-Stamping and Notary Protocols

These are new, potential work items, discussed on a preliminary basis
in Munich.  Two presentations: Rob Zuccherato (Entrust) on time
stamping and notary functions, and Stewart Haber (Surety) on time
stamping. See slides for additional details.

Entrust- Timestamping service described here deals exclusively with
establishing existence of data (really a hash of data) at a point in
time.  Basic notary service for data demonstrates that a requester
posses data (not just a hash of the data) at a given time.  A
certificate notary service requires validation of a certificate chain
for the requester, including CRLs and ARLs.  There is also a fancy
data notarization service, encompassing data validity, and a combined
service of data possession and validity.  Some folks note that
validation of data (and certificates) is outside the scope of what
real world notaries do in the U.S. (but Latin Notaires do have broader
functions).

Surety- Stewart provided an overview of timestamping problem and
solution space, with a focus on the hash tree technology developed
(patented) and offered by Surety as a service.  The current Surety
service offers a 1 second granularity,

At least one WG member argued that the notary and timestamping
functions are not completely PKI-specific, and we should try to avoid
duplication of efforts like the PKIX/SPKI situation.  Another member
noted that there is a new I-D for time stamping via NTP, that raises
possible overlap concerns as well.  One possible outcome is a split of
time stamping vs. notary functions.  Certificate path validation, a
part of the described notary service, does make sense for PKIX,
consistent with X.509 validation procedures.

A straw poll during the second PKIX meeting showed a strong sentiment
that this WG amend its charter to include development of a standard for
time stamping, but there was not strong support for adding a work item
to develop notary functions (other than certificate path validation).


OCSP

Mike Myers provided a status review for this I-D, and responded to
comments that have appeared on the WG list over the last few weeks.  A
number of modifications will be made as a result of these comments
Mike described a schedule for revisions and (new) comments to bring
OCSP to WG last call in time for the next (LA) IETF meeting.  Included
in the revisions will be a better characterization of the contexts in
which OCSP are expected to operate, since that range of environments
has grown since OCSP was initially designed.