Subject: draft minutes

From: Stephen Kent <[email-masked]>
Date: Mon, 7 Nov 2005 16:03:57 -0500

Please send me a message with any requested corrections before 11/28:

Steve
-----

PKIX WG Meeting 11/7/05

Edited by Steve Kent

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

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

Document status - Tim Polk (NIST)
Three RFCs just issued: 4158, 4210, and 4211.
Three documents in the RFC editor's queue: CertStore HTTP, 3770bis, 
and CRL AIA.
Two documents with the ADs: AC Policies & PKIX Repository Locator.
Other documents:
-	SIM is undergoing revisions to address WG co-chair comments 
before being forwarded to the IESG.
-	The authors are being asked to create a matrix
-	A new version of 3280bis will be submitted after this meeting.
-	The WG chairs have requested a new version of the GOST 
algorithms to be posted, before initiating a last call
(Slides)

PKIX WG Document Presentations

RFC 2797bis, CMC transport, and CMC Compliance - Jim Schaad (Soaring Hawk)
Last call will be initiated for all three after this meeting. Updates 
include features to support SIM certificate requests. (Slides)

SCVP rev 21- David Cooper (NIST)
	Text was added to clarify conformance requirements. WantBack 
items were made optional. New, optional items were added to allow an 
SCVP server to relay responses from other SCVP servers, and to label 
responses with an identity specified by a requestor, if the server 
has multiple identities. The reference to validation policies was 
tightened, so that only OIDs, not URIs, are accepted. Policy 
parameters, in addition to validation algorithm parameters, are now 
supported, but the optional validation policy attributes were 
removed, since no examples have been provided and the need for this 
facility was not well established.

The one remaining problem here is how to make this protocol agile 
with regard to the hash algorithm employed for certificate 
references. Today SHA-1 is hardwired. Updating the spec to specify 
another hash function does not satisfy the new algorithm agility 
requirement. Steve Kent suggested that the hash function can be an 
aspect of the server's validation policy, to satisfy the agility 
requirement. Russ Housley suggested that the OID of the hash employed 
be explicitly returned, in case the server's policy changes over time 
(but the policy OID does not). A straw poll was conducted to get a 
sense of the room for the two alternatives described in the last 
slide in this presentation. The first alternative received 12 votes, 
vs. 0 for the second. (Slides)

SHA-1 Collisions & OCSP - Russ Housley (Vigil Security)
	 Based on the recent NIST hash workshop, Russ suggests that 
we begin making plans to move away from  SHA-1, with a 2010 target 
for transition. NIST will begin work on a successor to SHA-256, but a 
new algorithm may be 5 years away. The only good alternative now is 
SHA-256.

	From an algorithm agility perspective, OCSP request/response 
exchange needs to provide a way for the requestor to know which 
algorithms the responder (server) supports. This could be supported 
by adding a new protocol to negotiate the hash algorithm prior to 
entering into the OCSP exchange. Alternatively, the responder's 
certificate could have an extension that specified supported hash 
algorithms. This also might be addressed via configuration at the 
requestor, although this is problematic given the intent of changing 
the algorithm twice over the next 10 years. Russ suggests a request 
extension that allows the requestor to specify which hash functions 
(and signature algorithms) it supports. There is still a need to 
select one of the three approaches cited above, to allow a requestor 
to determine which algorithms are supported by the responder.

	Russ suggests that the WG find volunteers to update OCSP, and 
to examine other PKIX protocols to determine whether they exhibit 
similar problems and, if so, how to fix them. Stephen Farrell asks 
whether there may be a way to solve this problem more generically, 
rather than engineering a solution for each protocol in PKIX, and in 
other WGs.  (Slides)

SHA-2 Support in PKIX - Tim Polk (NIST)
        We currently specify how to use SHA-2 (SHA-256 & SHA-512) for 
RSA (RFC 4055), but not for DSA or EC-DSA. Tim suggests that two new 
drafts be generated, one for DSA and one for ECDSA, because the two 
algorithms are at different stages of NIST publication. NIST has 
volunteered to write these two drafts, but additional co-editors are 
welcome. (Slides)

Service Names as Subject Alt Names - Stefan Santesson (Microsoft)
       The draft has been revised since its initial version. It no 
longer is bound as tightly to the DNS SRV record example. The 
assumption here is that the user (host) knows the service name and 
domain name and determines whether the server to which it connects is 
appropriate, based on the server's certificate. Steve Kent suggests 
that we need to revisit the security implications of use of this 
facility, given the revised definition of the use model. Stefan 
suggests that use of name constraints for this extension may be 
appropriate. Since the string comparison is against the locally 
configured service name, not the DNS SRV string, UTF8 seems to be the 
right encoding choice. (Slides)

Related Specifications & Liaison Presentations

Carl Wallace (Orion Security) - LTANS WG status
	LTANS is meeting the same day (in the same room) at this 
IETF. Carl requests review by PKIX WG members of the evidence record 
I-D and an archive protocol I-D from LTANS. Note potential 
relationships between SCVP and LTNANS work.  (no slides)