PKIX WG Meetings Minutes

A total of approximately 190 IETF members attended the PKIX WG 
meetings (two time slots) on 6/25/96.  Steve Kent and Warwick Ford, co-
chairs, presided over the meeting.  Steve Kent  prepared these meeting 
minutes.

Agenda
	Introduction
	ISO X.509 Update
	PKIX Part 1 (Certificate and CRL Profiles) Review
	PKIX Part 3 Management Protocols Review
	DoD Management Protocols
	Japanese PKI Report
	ASN.1 Documentation
	Validity Periods
	Reference Implementations & Conformance Testing

Steve Kent welcomed attendees to the WG meeting and solicited 
additions to the agenda.

Warwick Ford provided a review of the newly revised X.509 AM, based 
on the editing meeting in early June.  A number of changes from the 
DAM have been made, and many of these were motivated by comments 
and suggestions from the PKIX membership.  Major changes relevant to 
PKIX  include criticality bit assignments, key usage, name forms, basic 
constraints, indirect CRLs, hold mechanism, and delta CRL mechanism.  
See WarwickŐs slides for more details of the AM/DAM changes.  The 
AM is available at ftp://NC-
17.MA02.Bull.com/pub/OSIdirectory/Certificates.

Russ Housley reviewed the PKIX Part 1 document, which profiles the 
X.509 AM for Internet use. The document also adds 3 extensions that are 
Internet-specific.  This document describes what it means to support 
each extension, from the perspective of a certificate issuer and 
certificate user.  It also specifies whether the extension is recommended 
or not, and whether it is critical, not critical, or either (at the 
discretion of the CA).  There was almost unanimous agreement that the 
final document must contain the ASN.1 syntax and the accompanying 
processing rules to make this document comprehensive, i.e., so that 
readers will not have to refer to the base ISO document.  Still, there is 
a need to exercise care in creating this mirror document and to track 
defect reports relative to the ISO base document.  Work on this 
document will now move to a phase where WG inputs are needed to 
help decide the status of different extension features, i.e., to 
indicate whether a compliant implementation (issuer or user) MUST, 
SHOULD, or MAY provide support for the extension, plus any Internet-
specific constraints imposed on the syntax of the extension.  See the 
Internet-Draft for details.

Stephen Farrell reviewed the status of the current draft of the PKIX 
Part 3 document, which describes management protocols for use with 
certificates and CRLs.  Very little progress has been made on this 
document since the LA meeting, so this was a short report. See the 
Internet draft for more details. A brief discussion of the relationship of 
PKCS-10 to a part of this document ensued, with the proposal that 
PKIX profile PKCS-10.  This suggestion will be explored in more depth 
on the mailing list.

Greg Bergren provided a report on DoD work on certificate management 
protocols, analogous to the protocols being described in the PKIX Part 3 
document.  Specifically, Greg spoke of experience gained from work on 
MMP, the MISSI (Multi-level Information System Security Initiative) 
Management Protocol.  Three items were suggested as important 
features present in MMP, but not addressed in the PKIX documents:
	- CA support for mail list (for secure e-mail, e.g., MSP)
	- ability to request a CRL from a CA 
	- support for indirect CRLs (ICRLs)
However, an Internet-specific extension described earlier in this 
meeting already supports CRL requests being directed to various 
destinations.  Also, ICRLs are part of the X.509 v3 extensions being 
profiled.  So, the only major feature of MMP not also encompassed by 
the PKIX Part 3 document, is mail list agent support.  It is not clear if 
mail list support belongs here, since this is an application-specific 
technology, not applicable to most certificate applications.  However, 
several WG members noted that this technology might be more 
generally useful, e.g., for conferencing applications.  Greg offered to 
send a message to the PKIX list  providing pointers to SDN.703  (the 
MMP spec) and to SDN.701 (the MSP specification, for a discussion of 
mail list facilities).

Kikuchi Hiroaki described the status of certificate infrastructure in 
Japan, including a discussion of the certification hierarchy deployed 
for PEM use two years ago.  He also provided statistics on PEM use, and 
ongoing work on an expended PKI. Analysis of web of trust for use in 
Japan, based on preliminary experiments and an estimated 100,000 user 
base, suggests a web diameter of about 13.  A full web for a large portion 
of the population would suggest a much larger diameter, but it is not 
clear that even the smaller (13) diameter is viable. One possible 
solution is to have ISPs act as CAs; also an organization for computer-
based authentication (ICAT) is interested in helping organize CAs at a 
national level.  (See http://www.icat.or.jp for more info.)  Use HTTP 
for on-line registration, CRL distribution, and policy statement 
distribution.  User software PEMCAT available for Macs, Windows, 
and UNIX.  Future work will focus on v3 certificates, public key 
algorithms other than RSA, and more experimentation.

Steve Kent renewed a call for ASN.1 (88) documentation to help 
facilitate implementation of certificate and CRL processing.  Tim Polk  
agreed to work on providing this sort of documentation from NIST 
resources. It was reported that Burt Kalaski offered to secure copyright 
release for the RSA Labs document, ŇA LaymanŐs Guide to a Subset of 
ASN.1, BER and DERÓ for publication as an Internet RFC, either in 
whole or part.  Steve Kent agreed to follow up with RSA Labs on this 
topic.  This document is available via the RSA web site:  
http://www.rsa.com/ftpdir/pub/pkcs/ps/layman.ps (postscript) or 
http://www.rsa.com/ftpdir/pub/pkcs/ascii/layman.asc (ASCII).

Denis Pinkas lead a brief discussion of issues related to interpretation 
of the validity period field in the X.509 (v1) certificate. He notes that 
interpretation of this field differs based on whether the signature 
mechanism is being used for non-repudiation or authentication and 
integrity.  For non-repudiation, in the absence of the 
privateKeyUsageValidityPeriod extension, then the private key is 
assumed to have been valid during the validityInterval, but the public 
key is assumed to be valid forever, i.e., for use in verifying signatures 
generated during the validityInterval timeframe.  However, this may 
not be sufficient in all circumstances, e.g., due to concerns over the 
cryptanalytic strength of the signature and/or hash algorithms.  Note 
that for non-repudiation to be effective, one must establish the 
timeframe in which a signature was purportedly applied, and that the 
key used was not reported as revoked during that time frame.  In 
contrast, when the private key is used for encryption purposes, ... Denis 
argues that when the key is used for encryption, the validity interval 
applies only to the public key, and the private key is assumed to ŇliveÓ 
forever.  Others note that the definition of this field applies to the 
certificate, not to either the private or public key, but to the binding 
between the public key and the other certificate attributes.  The 
validityInterval field also is interpreted as delimiting the interval 
over which the certificate would be retained on a CRL.

Tim Polk talked about NIST activities in the conformance testing and 
interoperability testing arena, and thus his interest in these topics 
relevant to PKIX.  Three NIST projects relevant to PKIX:
	- minimum interoperability specification for PKI components 
(MISPC)
	- conformance testing for PKI components
	- reference implementation for PKI components
MISPC is being pursued by NIST with co-operation/assistance from 
commercial entities, under CRADAs.  Scope includes certificate and 
CRL profiles, CA/RA management protocols, etc.  Work is independent 
of signature and hash algorithms and of underlying transport 
mechanisms.  MISPC should be available by September 30, 1996.  NIST 
will then (staring in September) develop tests to measure conformance 
of PKI components relative to the MISPC.  NIST also wants to develop 
CA, RA, and client reference implementations, for free distribution.  
These implementations should support multiple algorithms and 
provide a sanity check for the test suite.  Existing NIST contributions 
include DSA and SHA-1 code, a CA/RA implementation, and sample 
client software.  NIST is looking for assistance in developing the 
reference implementations.  They have decided that the CRADA 
process is not ideally suited to this task, but they are open to other 
suggestions on how to proceed, e.g., funding or donated development 
resources.

Denis Pinkas reviewed (verbally, no slides) a few of his comments 
relative to the Part 1 and Part 3 PKIX I-Ds. DenisŐ comments are 
already available via the mail list, and so are not reproduced here.