Subject: draft meeting minutes

From: Stephen Kent <[email-masked]>
Date: Fri, 14 Nov 2003 17:07:32 -0500

Folks,

here are draft minutes from this week's PKIX WG meeting at the 58th IETF.

Please provide comments next week, so that I can submit a final 
version before Thanksgiving.  (that's Nov 27th, for non Turkey 
eaters).

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

PKIX WG Meeting 11/9/03

Edited by Steve Kent

Chairs: Stephen Kent <[email-masked]>, Tim Polk <[email-masked]>

The PKIX WG met once during the 58th IETF. A total of approximately 
73 individuals participated in the meeting.

Agenda review and document status - Tim Polk (NIST)
	There are a number of WG documents in various stages in the 
process. Two RFcs (3628 & 3647) were issued since the last IETF 
meeting.  Three documents (Permanent Identifiers, CMP and CRMF) will 
be revised based on IESG comments. The Logotypes I-D has been revised 
in response to IESG comments and should be approved soon. The Proxy 
Certificates and IP Addresses & AS Identifiers I-Ds are in the hands 
of the IESG. Five documents are close to emerging from the WG. SCVP 
is being revised to reflect WSG last call comments. Attribute 
Certificate Policies is in WG last call, but there is some about re 
support for the document. A straw poll on the document indicated a 
little support for progressing the I-D, but mostly just indifference. 
Qualified certificates will enter WG last call after the meeting. The 
EEC "NIST Curves" I-D and the path building I-D also will be forward 
to the ADs by January.

	Ongoing work items include Subject Identification Method 
(SIM), PK algorithms, LDAP specs, OCSPv2, and progression of 
3279/3280. the only new work item is a name comparison spec (to 
address international name issues), an initial draft of which is 
slated for the Seoul meeting. [slides]

PKIX WG Specifications

SIM - Jongwook Park (KISA) & Tim Polk (NIST)
	This specification is still in early stages of development. 
Current efforts are concentrating on formalizing security goals and 
requirements.  The implementation details are still being revised, 
and in some cases appear as a TBD in the current draft. Unresolved 
issues include where to put the hash value, e.g., as an extension vs. 
as an otherName, and some details of the two-pass hashing function. 
[slides]

RFC 3039bis (Qualified Certificates) - Stefan Santesson (Microsoft)
	The QC document is technically stable and incorporates he 
required changes for 3280 alignment.  Minor issues remain for the 
ASN.1 in the document; the AD has provided clear guidance for 
resolution. Three issues raised on the list (regarding the document 
name, timeline for progression, and its relationship to RFC 3039) 
were also discussed. The WG chairs and the AD indicated that WG Last 
Call is appropriate at this time, and that the new specification 
should obsolete RFC 3039.

Certificate Path Building  - Peter Hesse (Orion Security)
       This document, intended to become an informational RFC, was 
written to provide guidance and recommendations to developers 
building X.509 public-key certification paths within their 
applications, based on experience gained in several contexts. The 
document describes different PKI structures, considerations for 
forward vs. reverse path construction, tree pruning, etc. emphasis on 
value of disallowing repeated name/key combination in a path. 
Guidance is based on experience with various products, but must 
describe processes that are consistent with PKIX RFCs. This is just 
an advisory document, not proscriptive, and so there will be no 
MUSTs, SHOULDS, etc. Plan to release another version of the document 
by the end of this month, then proceed to WG last call. [slides]

OCSPv1 problem - Mike Meyers (Traceroute)
	OCSP has a facility in which a client may include a nonce in 
a request, to detect and reject replays of responses. Unfortunately, 
the RFC did not make perfectly clear that a client MUST reject a 
response that did not include a nonce, if the client included a nonce 
in the request. Similarly, the RFC did not make clear what a server 
should do if it receives a request with a nonce, but is incapable of 
generating a response containing a nonce, i.e., a server that deals 
only with pre-signed responses.
	A straw poll indicated that the vast majority of clients deal 
with these issues properly, but not all. OCSP servers that rely on 
caching do not generate a unique response for each request, so they 
omit nonces.  An error could be returned by a server to indicate the 
inability to respond properly to a request with a nonce, but errors 
are not signed, so this does not address the security concern.
	Russ Housley, the cognizant AD made the following observation 
re this issue. "When an OCSP Client puts a nonce in an OCSP Request, 
replay protection is expected. Therefore, the OCSP Responder MUST 
include the same nonce value in the OCSP Response.  If the OCSP 
Client receives an OCSP Response that fails to include the correct 
nonce value, it MUST be rejected."

Liaison/Related Projects

IPsec PKI Profile - Brian Korver (Xythos Software)
	Announcement of a BOF on this topic on Thursday, 9 AM.

Steve Hanna (Sun) - OASIS PKI Obstacles Survey Report
	Steve is the co-chair of the OASIS PKI technical committee. 
Effort is trying to determine obstacles to successful PKI deployment 
and adoption, and to recommend ways to eliminate these obstacles. 
Survey generated 200 responses. Most significant obstacles include:
- lack of application support
- high costs
- complexity, lack of understanding
- interoperability problems

Suggested fixes include:
- free software
- cookbook deployment guidance
- path validation guidance
- too many standards for some function, too general, not enough 
standards for other functions

Action plan now available for public review. [slides]

Path Validation Conformance Tests - Tim Polk [NIST]
	A suite of tests has been developed by NIST and several 
contractors, designed to ensure that products implement RFC 3280 
properly. It is an extensive suite of tests. NIST's goals are to 
encourage vendors to submit products for testing, and for users to 
demand products that pass the tests. Common Criteria Protection 
Profiles have been created, based on these tests, in an effort to 
achieve the goal noted above. These profiles should be validated and 
available for use by the end of 2003.  [slides]