draft minutes

PKIX WG Meeting 11/7/05

Edited by Steve Kent

Chairs: Stephen Kent <kent@xxxxxxx> & Tim Polk <tim.polk@xxxxxxxx>

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)