------------------PKIX WG Meeting 11/10/03

Edited by Steve Kent

Chairs: Stephen Kent <kent@bbn.com>, Tim Polk 
<tim.polk@nist.gov>

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 WG last call comments. Attribute Certificate Policies is in WG last 
call, but there is some question re support for the document. A straw poll on 
the document indicated about seven in favor of standards track 
progression, and about 4 in favor of an informational RFC, and a fair 
amount of 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 the 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 (Gemini 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 the 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]