PKIX WG Meeting 7-26-07

 

Edited by Steve Kent

Chairs: Stephen Kent <kent@bbn.com> &  Stefan Santesson <stefans@microsoft.com>

 

The PKIX WG met once for one hour, during the 69th IETF. A total of approximately 52 individuals participated in the meeting.

 

 

Document Status Review - Stefan Santesson (Microsoft)

 

Service SAN and Lightweight OCSP were approved by the IESG and are in the RFC EditorŐs queue. SCVP, RFC 3280bis and the three CMC document are under IESG review. Work on the ECC and DSA with SHA-2 algorithms can resume now that FIPS 186-3 has been issued. (Slides)

 

 

PKIX WG Specifications

 

Server-based Certificate Validation Protocol (SCVP)- David Cooper (NIST) and Paul Hoffman (VPNC)

Paul Hoffman is working with David Cooper to make the necessary changes to deal with the HTTP. Because of the complexity of getting all the HTTP use details correct, Paul proposes to use TCP over a new port to avoid this complexity. This probably will require a new WGLC, due to the extent of the changes. (no slides)

 

Subject public key info resolution for ECC - Tim Polk (NIST)

The latest proposal from the design tem tasked with addressing this problem <awaiting additional details from Tim>. (no slides)

 

 

Related Specifications Presentations

 

WebDAV for Certificate Publishing and Revocation - David Chadwick (University of Kent)

     Proposal to use WebDAV as an alternative to LDAP to avoid problems that arise with LDAP. These problems include firewall traversal restrictions, no ability to search for CRL or certificates based on content, and an ability to retrieve an individual certificate or CRL if multiple ones are associated with a Subject. The proposed mechanism also can be used for revocation status checking in a novel fashion. (The mechanism does require the CA to generate one CRL per-subject.) To support this capability in PKIX we would need to define two new AIA access methods, one to represent a URL for a certificate in the revoked state, and the other for a not-revoked certificate state. Several security concerns were cited, and solutions proposed. David would want the document to be an Experimental or Standards track RFC if adopted by PKIX. Several questions were raised, and it was agreed that the discussion should be continued on the list. The candidate I-D is draft-chadwick-webdav-00.txt. An example implementation interface is provided at: http://issrg-beta.cs.kent.ac.uk/ (Slides)

 

 

Cisco Systems' Simple Certificate Enrollment Protocol (SCEP) -  Andy Nourse (Cisco Systems)

     SCEP has been implemented by a wide range of vendors, to work with Cisco products, where this protocol was developed as an alternative to the CMC and CMP work in PKIX. Cisco would like to publish this as an Informational, independent RFC. Tim Polk noted that SCEP would be a third, published RFC for a certificate request/response protocol and that he, as Security co-AD, was not enthusiastic about that. Steve Kent noted that SCEP was developed outside of the IETF environment, in competition with the PKIX work, and thus its publication as an RFC might send a bad message about vendors circumventing the IETF standards process. He also noted that if Cisco wants to pursue this path it is free to do so; ultimately the decision rests with the RFC Editor, although the IESG does have input to the process. Paul Hoffman and Steve Farrell suggested that publication is beneficial as a way of establishing a stable, published reference for the protocol. (Slides)

 

PKI Resource Query Protocol (PRQP) - Massimiliano Pala (Dartmouth)

     The proposal from Max is to add a level of indirection to the current AIA mechanism, to more easily allow a CA to make new services available, or to change the access points (URLs) for existing services, without having to issue new certificates to users. A new extension could be defined to hold a URL that is a pointer to a server that provides the URL for all the services offered by the CA that issued the certificate. The proposed protocol is called PRQP (PKI Resources Query Protocol). Further discussion on the list is needed to determine of PKIX should adopt this as a new work item. The candidate I-D is draft-pala-prqp-00.txt (Slides)

 

Framework on Key Compromise, Key Loss & Key Rollover: David Chadwick on behalf of Denis Pinkas (Bull)

      This is a proposal from Denis for a new PKIX work item to create an Informational RFC for key rollover situations, both planned and unanticipated for CAs, AAs, TSAs, etc. As above, a discussion is needed o the PKIX list to determine if PKIX will adopt this as a WG item. Phill-Hallem Baker and Stefan feel that this document, because it is not a protocol, but more a practices and procedures document, should be published outside of PKIX. Steve Kent noted that 3647, and its predecessor, 2527, are also procedures documents, and it are possibly the most widely cited PKIX RFCs! The I-D Denis wants PKIX to consider is draft-pinkas-pkix-pki-dr-kr-00.txt. (Slides)

 

Three short fixes - Phillip Hallam-Baker (VeriSign)

     Phillip proposed 3 items on the WG list a few months ago: member since, community name, and security indicator suppression. The list discussion was not positive for any of these proposals. For example, the member since extension seems more like a way for a long-established CA to lock in clients, i.e., a marketing feature that might disproportionately benefit VeriSign. Others expressed the opinion that the Logotype extension was sufficient for community name. Some folks objected to the security indicator suppression as redundant because there are other mechanisms for unauthenticated SSL. For the latter case there is also the concern that this is a technical attempt to fix a procedural problem that has been created by browser vendors who are putting questionable, default TAs into products. Unless there is a strong show of support for any of these proposals, the WG chairs do not anticipate further action on them.