Current Meeting Report
Slides


2.5.7 Public-Key Infrastructure (X.509) (pkix)

NOTE: This charter is a snapshot of the 52nd IETF Meeting in Salt Lake City, Utah USA. It may now be out-of-date. Last Modified: 25-Sep-01
Chair(s):
Stephen Kent <kent@bbn.com>
Tim Polk <wpolk@nist.gov>
Security Area Director(s):
Jeffrey Schiller <jis@mit.edu>
Marcus Leech <mleech@nortelnetworks.com>
Security Area Advisor:
Jeffrey Schiller <jis@mit.edu>
Mailing Lists:
General Discussion:ietf-pkix@imc.org
To Subscribe: ietf-pkix-request@imc.org
In Body: subscribe (In Body)
Archive: http://www.imc.org/ietf-pkix
Description of Working Group:
The PKIX Working Group was established in the Fall of 1995 with the intent of developing Internet standards needed to support an X.509-based PKI. Several informational and standards track documents in support of the original goals of the WG have been approved by the IESG. The first of these standards, RFC 2459, profiles the X.509 version 3 certificates and version 2 CRLs for use in the Internet. The Certificate Management Protocol (CMP) (RFC 2510), the Online Certificate Status Protocol (OCSP) (RFC 2560), and the Certificate Management Request Format (CRMF) (RFC 2511) have been approved, as have profiles for the use of LDAP v2 for certificate and CRL storage (RFC 2587) and the use of FTP and HTTP for transport of PKI operations (RFC 2585). RFC 2527, an informational RFC on guidelines for certificate policies and practices also has been published, and the IESG has approved publication of an information RFC on use of KEA (RFC 2528) and is expected to do the same for ECDSA. Work continues on a second certificate management protocol, CMC, closely aligned with the PKCS publications and with the cryptographic message syntax (CMS) developed for S/MIME. A roadmap, providing a guide to the growing set of PKIX document, is also being developed as an informational RFC.

The working group is now embarking on additional standards work to develop protocols that are either integral to PKI management, or that are otherwise closely related to PKI use. Work is ongoing on alternative certificate revocation methods. There also is work defining conventions for certificate name forms and extension usage for "qualified certificates," certificates designed for use in (legally binding) non-repudiation contexts. Finally, work is underway on protocols for time stamping and data certification. These protocols are designed primarily to support non-repudiation, making use of certificates and CRLs, and are so tightly bound to PKI use that they warrant coverage under this working group.

Additional work will be initiated on a profile for X.509 attribute certificates, resulting in a new RFC and, perhaps, in extensions to existing certificate management standards to accommodate differences between attribute certificates and public-key certificates.

Goals and Milestones:
Sep 99   Update RFC 2459, in anticipation of progression from PROPOSED to DRAFT
Done   Complete approval of CMC, and qualified certificates documents
Dec 99   Update March/April RFCs, for progress from PROPOSED to DRAFT
Done   Complete time stamping document
Done   Continue attribute certificate profile work
Done   Complete data certification document
Done   Complete work on attribute certificate profile
Internet-Drafts:
Request For Comments:
RFCStatusTitle
RFC2459PSInternet X.509 Public Key Infrastructure Certificate and CRL Profile
RFC2510PSInternet X.509 Public Key Infrastructure Certificate Management Protocols
RFC2511PSInternet X.509 Certificate Request Message Format
RFC2527 Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework
RFC2528 Internet X.509 Public Key Infrastructure Representation of Key Exchange Algorithm (KEA) Keys in Internet X.509 Public Key Infrastructure Certificates
RFC2559PSInternet X.509 Public Key Infrastructure Operational Protocols - LDAPv2
RFC2585PSInternet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP
RFC2587PSInternet X.509 Public Key Infrastructure LDAPv2 Schema
RFC2560PSX.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP
RFC2797PSCertificate Management Messages over CMS
RFC2875PSDiffie-Hellman Proof-of-Possession Algorithms
RFC3039PSInternet X.509 Public Key Infrastructure Qualified Certificates Profile
RFC3029E Internet X.509 Public Key Infrastructure Data Validation and Certification Server Protocols
RFC3161PSInternet X.509 Public Key Infrastructure Time Stamp Protocols (TSP)

Current Meeting Report

PKIX WG Meeting 1/11/01

Edited by Steve Kent

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

The PKIX WG met once during the 52nd IETF. A total of approximately 112
individuals participated in the meeting.

Tim Polk began with a review of the agenda. Two brief presentations
on non-working group IDs were added to the end, if time permits.

Document Status Overview
The PKIX Certificate and CRL Profile (draft-ietf-pkix-ipki-new-part1-11.txt), and the companion Algorithms document (draft-ietf-pkix-ipki-pkalgs-05.txt), have been approved by the IESG and are in the RFC Editor's queue. Russ Housley (RSA) provided more detailed discussion of the changes between these documents and their predecessors. Two documents, the PKIX Roadmap & Policy Framework, have been revised and are ready for republication as Informational RFCs. Three RFCs are ready for progression to Draft Standard status: CRMF, CMP, and OCSP(v1). CRMF and CMP have completed interoperability testing, but results still need to be documented. OCSP has completed and documented the interoperability testing. CMC is expected to follow soon. (See slides)

Interoperability Testing - Jim Schaad (Soaring Hawk Consulting)
Jim has constructed a matrix to document interoperability requirements re new-part-1. Paul Hoffman (IMC) noted that the requirements for progression to Draft seem to require that ALL options be show to be interoperable, not just the MUSTs. The co-chairs will seek clarification of this issue with the Security ADs.

Implementation Experience - Steve Hanna (Sun)
Implementation experience illustrates that path validation is very complex. This experience argues for ways to minimize the need for developers to create their own, additional implementations, e.g., use of DPV, use of libraries (e.g., Getronics or JSE). Use of a certificate path API, in this case based on Java, also can help, and that is being pursued through the Java Community Process. The API allows for customization validation checks. Initial implementation by Sun does not support all the (optional) features in the final version of new-part-1, due to need to freeze code prior to finalization of that document. Steve suggests changing PKIX path validation algorithm to prohibit loops and ignore self-signed certificates, consistent with X.509 comments and a recent defect report. (See slides)

Attribute Certificate Profile - Steve Farrell (Baltimore)
In RFC editor's queue, awaiting publication of new-part-1. No word yet re implementation experience for this profile.

DPV/DPD Requirements Draft - Denis Pinkas (Integris)
This document, draft-ietf-pkix-dpd-dpv-req-00.txt, has been published as an ID after considerable discussion on the list. (Delegated digital signature validation is a separate document, which will be pursued separately, as noted below). Separate validation and discovery policies are used to control these respective functions at a server. Management of the policies is separate, and can be effected via separate protocols or locally (directly). This architecture allows for simple requests and responses, because it removes specification of the policy from these messages, and this is consistent with the motivations for DPV/DPD, based on use by constrained clients. Note use of "cautionary period" parameters to accommodate delays inherent in revocation mechanisms, both OCSP and CRLs. This approach is not a panacea, but it does provide a set of useful policy controls. (See slides)

DPV Protocol Draft (SCVP) - Russ Housley (RSA)
Russ and Ambarish are working to revise SCVP to make it compliant with the requirements document. Discussion during the meeting argues for a separate document to deal with the management protocol, vs. the request/response protocol. Questions remain re the use of extensions, and their criticality. Also, it is not yet clear how to reference a certificate that is not passed in the request. Issuer name and serial number is a poor choice for searching today, although it may be OK in the future for LDAP. Also not clear whether it is necessary to include this added complexity, for possibly minor bandwidth savings. Defer attribute certificate support for now. Another open issue is how to authenticate messages between client and server, which may be different for DPV vs. DPD. Finally, should SCVP be extended to support DPD, as well as DPV? (See slides)

Proxy Draft - Doug Engert (Argonne Labs)
Work is continuing on this draft. A number of questions have been raised on the list and are being resolved. Implementations will be developed in 2002, as part of the Globus project. (See slides)

Delegated Signature Validation Denis Pinkas (Integris)
This document, draft-ietf-pkix-dsv-req-00.txt, represents a separate set of requirements for delegated signature validation, analogous to the DPV/DPD requirements work reported earlier. The document defines requirements for signature validation policies, and a request/response protocol that supports initial interaction with a DSV, as well as re-validation and later validation by a distinct third party (a different DSV server), all in support of non-repudiation. Note the extended time frame for DSV vs. DPD/DPV, i.e., DSV may often take place much later, long after a transaction, and after certificates associated with the transaction have expired. Some discussion of whether this is an appropriate new work item, which will be brought to the list. Agreement to keep this separate from DPV/DPD work. (See slides)

Supplemental Algorithms - Ari Singer (NTRU)
This document, draft-ietf-pkix-pkalgs-supp-00.txt, describes additional algorithms that may be used with PKIX data (e.g., certificates and CRLs) and protocols, including extended DSA and SHA, as well as better ASN.1 for NTRU algorithms. (See slides)

LDAP documents David Chadwick (Univ. Salford)
This LDAP v3 document, draft-ietf-pkix-ldap-v3-04.txt, has not changed, but since LDAP v2 is moving to historical, which suggests moving text from the v2 document into this document, to replace references to the v2 document. Ready to go to last call, pending resolution of this issue (reference to historical document vs, copying text from that document). The schema and matching rules document, draft-ietf-pkix-ldap-schema-02.txt, has changed from the previous version, adding PKI schema, changing syntax for assertions, and including component matching rules for attribute certificates. Several open issues remain to be resolved. Plan to resolve these issues and go for last call after summer IETF meeting. (See slides)

Policy Requirements for Time Stamping - Denis Pinkas (Integris)
This is a proposal to take an existing ETSI document and publish it as an informational RFC. It is analogous to the CA policy RFC, and is linked to previous PKIX work, i.e., RFC 3161. Will bring the question to the PKIX list. (See slides)

RFC 3161 Interoperability Testing - Denis Pinkas (Integris)
Mailing list exchanges indicate there are at least 7 implementations available now, and this is a first step in gathering interoperability info pursuant to progress from Proposed to Draft Standard status.

Missing Link for Large PKIs- Denis Pinkas (Integris)
This brief discussion explored the question of how one binds a key to a person, in the physical world. Suggestion is to develop an Informational RFC on this topic. Will bring this to the list. (See slides)

NIST Activities - Tim Polk (NIST)
NIST, ICSA, and others are interested in developing a profile for PKI support for IPsec. Also, a PKI R&D workshop sponsored by NIST, NIH, and Internet 2 will be held April 2002, at NIST. (See slides for detail; slides were not presented in the meeting due to time constraints.)

Non-PKIX Work Items

DNS for Certificate Distribution - Simon Josephson (RSA)
This (personal, not PKIX) document describes how to use DNESEC to provide a secure means of publishing and acquiring self-signed certificates stored there. Could be used for short-lived certificates or for root certificates. (See slides)

Certificate Request for Wireless Environments - Jaeho Yoon (Korean Information Security Agency)
This (personal, not PKIX) document describes a proposal for a certificate retrieval protocol for use in wireless environments.

Slides

Proxy Certificate Profile
Supplemental Algorithms Draft Update
First Annual PKI Research Workshop
PKI for IPsec VPNs
LDAP Schema and Syntaxes for PKIs and PMIs
Operational Protocols - LDAPv3
Implementing CertPath Validation: Lessons Learned
Certificate and CRL Profile and Public Key Algorithms
Simple Certificate Validation Protocol
Delegated Path Validation and Delegated Path Discovery Protocol Requirements
Delegated Signature Validation (DSV-REQ)
The missing link for large PKIs
Policy requirements for Time-Stamping Authorities
TSP - RFC 3161- Interoperability testing
Certificate Interop Matrix
Supplemental Algorithms Draft Update
First Annual PKI Research Workshop
PKI for IPsec VPNs
LDAP Schema and Syntaxes for PKIs and PMIs
Operational Protocols - LDAPv3
Implementing CertPath Validation: Lessons Learned