meeting minutes

[Stephen Kent <[e-mail]>]

Folks,

Due to a communication problem between Tim and me, we failed to 
distribute the minutes to the list for comment, as is our usual 
practice.  We did manage to submit them to the Secretariat, just in 
time, and the slides from presentations also were submitted.  We 
apologize for this procedural error.  Herewith are tghe minutes as 
submitted to the Secretariat earlier this week:

--------

PKIX WG Meeting 12/11/01

Edited by Steve Kent

Chairs: Stephen Kent <[e-mail]>, Tim Polk <[e-mail]>

The PKIX WG met once during the 52nd IETF. A total of approximately 112
individuals participated in the meeting.


Tim Polk began with a review of the agenda. Two brief presentations 
on non-working group IDs were added to the end, if time permits.

Document Status Overview
	The PKIX Certificate and CRL Profile 
(draft-ietf-pkix-ipki-new-part1-11.txt), and the companion Algorithms 
document (draft-ietf-pkix-ipki-pkalgs-05.txt), have been approved by 
the IESG and is in the RFC Editor's queue. Russ Housley (RSA) 
provided more detailed discussion of the changes between these 
documents and their predecessors. Two documents, the PKIX Roadmap & 
Policy Framework, have been revised and are ready for republication 
as Informational RFCs. Three RFCs are ready for progression to Draft 
Standard status: CRMF, CMP, and OCSP(v1). CMC is expected to follow 
soon. (See slides)

Interoperability Testing - Jim Schaad (Soaring Hawk Consulting)
	Jim has constructed a matrix to document interoperability 
requirements re new-part-1. Paul Hoffman (IMC) noted that the 
requirements for progression to Draft seem to require that ALL 
options be show to be interoperable, not just the MUSTs. The 
co-chairs will seek clarification of this issue with the Security ADs.

Implementation Experience - Steve Hanna (Sun)
	Implementation experience illustrates that path validation is 
very complex.  This experience argues for ways to minimize the need 
for developers to create their own, additional implementations, e.g., 
use of DPV, use of libraries (e.g., Getronics or JSE).  Use of a 
certificate path API, in this case based on Java, also can help, and 
that is being pursued through the Java Community Process. The API 
allows for customization validation checks. Initial implementation by 
Sun does not support all the (optional) features in the final version 
of new-part-1, due to need to freeze code prior to finalization of 
that document. Steve suggests changing PKIX path validation algorithm 
to prohibit loops and ignore self-signed certificates, consistent 
with X.509 comments and a recent defect report. (See slides)

Attribute Certificate Profile - Steve Farrell (Baltimore)
	In RFC editor's queue, awaiting publication of new-part-1. No 
word yet re implementation experience for this profile.

DPV/DPD Requirements Draft - Denis Pinkas (Integris)
		This document, draft-ietf-pkix-dpd-dpv-req-00.txt, 
has been published as an ID after considerable discussion on the 
list. (Delegated digital signature validation is a separate document, 
which will be pursued separately, as noted below). Separate 
validation and discovery policies are used to control these 
respective functions at a server. Management of the policies is 
separate, and can be effected via separate protocols or locally 
(directly). This architecture allows for simple requests and 
responses, because it removes specification of the policy from these 
messages, and this is consistent with the motivations for DPV/DPD, 
based on use by constrained clients. Note use of "cautionary period" 
parameters to accommodate delays inherent in revocation mechanisms, 
both OCSP and CRLs. This approach is not a panacea, but it does 
provide a set of useful policy controls. (See slides)


DPV Protocol Draft (SCVP) - Russ Housley (RSA)
	Russ and Ambarish are working to revise SCVP to make it 
compliant with the requirements document. Discussion during the 
meeting argues for a separate document to deal with the management 
protocol, vs. the request/response protocol. Questions remain re the 
use of extensions, and their criticality. Also not yet clear how to 
reference a certificate that is not passed in the request. Issuer 
name and serial number is a poor choice for searching today, although 
it may be OK in the future for LDAP. Also not clear whether it is 
necessary to include this added complexity, for possibly minor 
bandwidth savings. Defer attribute certificate support for now. 
Another open issue is how to authenticate messages between client and 
server, which may be different for DPV vs. DPD. Finally, should SCVP 
be extended to support DPD, as well as DPV? (See slides)


Proxy Draft - Doug Engert (Argonne Labs)
	Work is continuing on this draft. A number of questions have 
been raised on the list and are being resolved. Implementations will 
be developed in 2002, as part of the Globus project.  (See slides)

Delegated Signature Validation Denis Pinkas (Integris)
	This document, draft-ietf-pkix-dsv-req-00.txt, represents a 
separate set of requirements for delegated signature validation, 
analogous to the DPV/DPD requirements work reported earlier. The 
document defines requirements for signature validation policies, and 
a request/response protocol that supports initial interaction with a 
DSV, as well as re-validation and later validation by a distinct 
third party (a different DSV server), all in support of 
non-repudiation. Note the extended time frame for DSV vs. DPD/DPV, 
i.e., DSV may often take place much later, long after a transaction, 
and after certificates associated with the transaction have expired. 
Some discussion of whether this is an appropriate new work item, 
which will be brought to the list. Agreement to keep this separate 
from DPV/DPD work. (See slides)


Supplemental Algorithms - Ari Singer (NTRU)
	This document, draft-ietf-pkix-pkalgs-supp-00.txt, describes 
additional algorithms that may be used with PKIX data (e.g., 
certificates and CRLs) and protocols, including extended DSA and SHA, 
as well as better ASN.1 for NTRU algorithms. (See slides)


LDAP documents David Chadwick (Univ. Salford)
	This LDAP v3 document, draft-ietf-pkix-ldap-v3-04.txt, has 
not changed, but since LDAP v2 is moving to historical, which 
suggests moving text from the v2 document into this document, to 
replace references to the v2 document. Ready to go to last call, 
pending resolution of this issue (reference to historical document 
vs, copying text from that document). The schema and matching rules 
document, draft-ietf-pkix-ldap-schema-02.txt, has changed from the 
previous version, adding PKI schema, changing syntax for assertions, 
and including component matching rules for attribute certificates. 
Several open issues remain to be resolved. Plan to resolve these 
issues and go for last call after summer IETF meeting. (See slides)


Policy Requirements for Time Stamping - Denis Pinkas (Integris)
	This is a proposal to take an existing ETSI document and 
publish it as an informational RFC. It is analogous to the CA policy 
RFC, and is linked to previous PKIX work, i.e., RFC 3616. Will bring 
the question to the PKIX list. (See slides)


RFC 3161 Interoperability Testing - Denis Pinkas (Integris)
	Mailing list exchanges indicate there are at least 7 
implementations available now, and this is a first step in gathering 
interoperability info pursuant to progress from Proposed to Draft 
Standard status.


Missing Link for Large PKIs- Denis Pinkas (Integris)
	This brief discussion explored the question of how one binds 
a key to a person, in the physical world. Suggestion is to develop an 
Informational RFC on this topic. Will bring this to the list. (See 
slides)


NIST Activities - Tim Polk (NIST)
	NIST, ICSA, and others interested in developing a profile for 
PKI support for IPsec. Also, a PKI R&D workshop sponsored by NIST and 
others, April 2002, at NIST.


Non-PKIX Work Items

DNS for Certificate Distribution - Simon Josephson (RSA)
	This (personal, not PKIX) document describes how to use 
DNESEC to provide a secure means of publishing and acquiring 
self-signed certificates stored there. Could be used for short-lived 
certificates or for root certificates. (See slides)


Certificate Request for Wireless Environments - Jaeho Yoon (Korean 
Information Security Agency)
	This (personal, not PKIX) document describes a proposal for a 
certificate retrieval protocol for use in wireless environments.