Subject: minutes & slides

From: Stephen Kent <[email-masked]>
Date: Tue, 11 Apr 2000 17:26:15 -0400

Folks,

Below is a draft of the meeting minutes.  I'm awaiting Warwick's 
document status inputs, but otherwise the minutes are complete and 
ready for comments, prior to submission to the IETF Secretariat.

As for slides, I have sets from Polk, Turner, Malpani, and Santesson. 
Stil missing are slides from:

P. Sylvester-EdelWeb
M. Myers-VeriSign
S. Farrell-SSE
D. Pinkas-Bull

Steve
-----

PKIX WG Meeting 3/29-00
Edited by Steve Kent (WG co-chair)

The PKIX WG met once during the 47th IETF and a total of 
approximately ??? individuals participated in this meeting.

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

<GET INPUT FROM WARWICK>

PKIX WORK IN PROGRESS

<GET INPUT FROM WARWICK>

ACTIVE PROJECTS:

Revisions to RFC 2459 & ECDSA (T. Polk-NIST)
New document published on 3/10/00, to fix errors, align with latest 
X.509 revisions, etc.  Major changes to certificate path validation 
are included, especially a detailed CRL processing section. ASN.1 
appendix was updated too. Authors still need to include some better 
examples. Suggestion made to remove the 1997 ASN.1 syntax, vs. the 
1988 syntax, to avoid inconsistencies. There was prior agreement to 
move the ECDSA algorithm into Part 1, but this is probably a bad idea 
due to the changing algorithm landscape. Instead, the proposal is to 
remove section 7 and combine it with the ECDSA document to create a 
new PKIX document, devoted to algorithms. The authors plan to submit 
both documents for WG last call by the end of April. (See slides for 
more details.)

Qualified Certificates  (S. Santesson-AddTrust)
This ID has completed WG last call. A major debate arose with regard 
to use of the SerialNumber attribute as a means of differentiating 
between otherwise identical DNs, vs. using it as a unique ID 
irrespective of the rest of the DN. This is an example of a larger 
issue, i.e., situations where a subset of the DN is sufficient to 
uniquely identify a subject.  There is no general syntactic mechanism 
to specify what subset of a DN might exhibit this property, although 
one might convey this information via certificate policy or other 
means. Denis Pinkas responded with slides suggesting the need for a 
mechanism to solve a subtly different problem, i.e., defining a 
permanent identifier for a subject, even when the directory name 
changes, e.g., due to marriage, divorce, change of address, 
intra-organizational change, etc. Proposal is to create new name 
type, a new OID under OtherName, which is expressly used for this 
purpose, as an alternate subject name. This name form will be 
composed of DN attributes. No constraints would be imposed on the 
name form.  The uniqueness of the new name form is not global, but 
local to the issuer. Denis would like to add this to the QC document, 
but it was observed that the advertised benefits for permanent IDs 
apply outside of the QC context, e.g., for intra-organizational 
access control. A proposal was made to progress this as a separate, 
small document, which can be merged into the QC document or into 2459 
in the future, if there is suitable support.  The motivation here is 
to not derail the progress of the QC document. (See slides for more 
details.)

PKIX Roadmap  (S. Turner-IECA)
This document has been updated to version 5, which includes revisions 
to the POP and Key Usage sections. The author plans to include the 
recent debate on qualified certificates (see above). The suggestion 
is made to issue this document as an Informational RFC once the QC 
and revised part 1 documents are approved for publication as RFCs. 
The Informational RFC will be updated periodically to track the 
evolution of PKIX documents. (See slides for more details.)

Time Stamping Protocol  (D. Pinkas-Bull)
In addition to minor fixes and syntax changes to simplify the ASN.1, 
some changes were made to accommodate requests from an ISO committee 
that is also working on time stamping and wanted both protocols to be 
closely aligned. The changes made in TSP accommodated most but not 
all of the requests. A news version of the document will be issued 
soon, while we await a response from ISO re the current set of 
changes. (See slides for more details.)

DVCS  (P. Sylvester-EdelWeb)
This is the current version of the document that began as a notary 
protocol from Adams & Zuccherato, and then became the data 
certification service protocols, before editorial responsibility 
shifted. Motivation for this protocol is to support a central 
infrastructure for document security management, e.g., in an intranet 
or extranet environment, or for other long term secure document 
management. The protocol is designed to enable delegation of 
signature verification, notarization, and even certificate use 
controls to a server (vs. and end system). The presentation included 
a number of scenarios motivating the need for the protocol and its 
features. The question arises whether the complex document management 
system features described here is really an infrastructure component 
within the purview of this WG or it is more of an application? (See 
slides for more details.)

OCSP Extensions  (M. Myers-VeriSign)
The document has been significantly reduced in size, consistent with 
a reduced scope definition.  The newly defined scope includes: 
delegated path validation, validation path discovery, trusted point 
specification, and extended status replies. There was some discussion 
about possible ambiguity with regard to path validation, i.e., it is 
important that the server produce the same validation result as a 
local, RFC 2459-compliant implementation. A brief list of additional 
requirements was presented. A WG member noted that OCSP requires 
inclusion of the hash of parts of the issuer's certificate, which 
says that OCSPX cannot perform complete path validation for a client. 
Another WG member requested that the list be polled to determine if 
delegated path validation is a required facility to be provided by a 
PKIX work product. (See slides for more details.)

SCVP  (A. Malpani-ValiCert)
This presentation began with a review of OCSP and its rationale. 
Specifically, OCSP assumes that the client has constructed a 
validation chain and is just asking the server to check the status of 
each certificate in the chain. The motivation for SCVP is to offload 
path construction and validation to a server, as a response to 
customer requests, e.g., for limited processing environments or 
anywhere the client does not want to implement the complex task of 
path generation and validation. Unlike OCSPX, there is no presumption 
that the client has other than the target certificate available as a 
starting point for path validation. Here too one must verify that 
remote validation is a needed service. (See slides for more details.)

A small group will generate a requirements document to characterize 
the motivations for remote validation services, to define the 
requirements for such services, and to compare the candidate 
protocols relative to these requirements.  The group members will 
include the authors of the competing protocols and a WG co-chair.

Attribute Certificates (S. Farrell-SSE)
Small changes have been made to this document to maintain synch with 
the latest X.509 documents, plus minor fixes. Plan is to issue a new 
draft and move quickly to WG last call.

OTHER TOPICS

PKI Disclosure Statements (S. Santesson & M. Baum-VeriSign)
A section of the ABA ISC has proposed a new form of document to be 
issued by a CA.  The PKI Disclosure Statement (PDS) is not a 
replacement for a CP or CPS. Rather the PDS is intended to address 
certain consumer disclosure legal requirements for which a CP or CPS 
is inappropriate. The set of data to be included is small and well 
defined.  It might be represented in XML, although this is not an 
explicit requirement.

Mobile Credentials (S. Farrell-Baltimore)
Desire to provide a standard protocol for downloading/uploading 
credentials, e.g., for systems that have limited local storage.  This 
issue has been raised in the WAP forum, but it might be well pursued 
in the IETF, maybe in PKIX.

---

From: Stephen Kent <[email-masked]>
Date: Wed, 12 Apr 2000 18:02:20 -0400

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
CMC (draft-ietf-pkix-cmc-05.txt)
- Approved to Proposed - In RFC Editor processing
Diffie-Hellman POP (draft-ietf-pkix-dhpop-02.txt)
	- In the AD's hands?

PKIX WORK IN PROGRESS

Revised Profile (draft-ietf-pkix-new-part1-01.txt)
ECDSA Algorithms for Profile (draft-ietf-pkix-ipki-ecdsa-02.txt)
	- Finished - will be folded into Revised Part 1
Revised CMP (draft-ietf-pkix-rfc2510bis.00)
Qualified Certificates (draft-ietf-pkix-qc-03.txt)
	- WG Last Call pending closure
PKIX Roadmap (draft-ietf-pkix-roadmap-05.txt)
Time Stamp (draft-ietf-pkix-time-stamp-06.txt)
	- Approved by WG - ready for forwarding to IESG
Operational Protocols - LDAPv3 (draft-chadwick-pkixldap-v3-01.txt)
Attribute Certificate Profile for Authorization 
(draft-ietf-pkix-ac509prof-02.txt)
Limited Attribute Certificates (draft-ietf-pkix-laap-00.txt)
DCS (draft-ietf-pkix-dcs-04.txt)
Simple Certificate Validation Protocol (SCVP) (draft-ietf-pkix-scvp-02.txt)
OCSP Extensions (draft-ietf-pkix-ocspx.txt) - posted on IMC site
CMP over HTTP (draft-ietf-pkix-cmp-http-00.txt)
CMP over TCP (draft-ietf-pkix-cmp-tcp-00.txt)

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Wed, 12 Apr 2000 15:29:13 -0700

>         - Finished - will be folded into Revised Part 1

This doesn't match what we agreed to in the meeting, as is reflected in 
Steve's minutes. The words from the minutes are "There was prior agreement 
to move the ECDSA algorithm into Part 1, but this is probably a bad idea 
due to the changing algorithm landscape. Instead, the proposal is to remove 
section 7 and combine it with the ECDSA document to create a new PKIX 
document, devoted to algorithms."

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Stephen Kent <[email-masked]>
Date: Wed, 12 Apr 2000 18:42:10 -0400

Paul,

You're right.  We'll fix the document status part of the minutes.

Steve