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

NOTE: This charter is a snapshot of the 49th IETF Meeting in San Diego, California. It may now be out-of-date. Last Modified: 11-Oct-00


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

Sep 99


Complete approval of CMC, and qualified certificates documents

Dec 99


Update March/April RFCs, for progress from PROPOSED to DRAFT

Dec 99


Complete time stamping document

Dec 99


Continue attribute certificate profile work

Dec 99


Complete data certification document

Mar 00


Complete work on attribute certificate profile


Request For Comments:






Internet X.509 Public Key Infrastructure Certificate and CRL Profile



Internet X.509 Public Key Infrastructure Certificate Management Protocols



Internet X.509 Certificate Request Message Format



Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework



Internet X.509 Public Key Infrastructure Representation of Key Exchange Algorithm (KEA) Keys in Internet X.509 Public Key Infrastructure Certificates



Internet X.509 Public Key Infrastructure Operational Protocols - LDAPv2



Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP



Internet X.509 Public Key Infrastructure LDAPv2 Schema



X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP



Certificate Management Messages over CMS



Diffie-Hellman Proof-of-Possession Algorithms

Current Meeting Report

PKIX WG Meeting 12/12-13/00
Edited by Steve Kent (WG co-chairs)

The PKIX WG met twice during the 48th IETF. A total of approximately 200 individuals participated in the first meeting, and about 150 in the second.

Day 1 (12/12/00)

Tim quickly reviewed the agenda and document status, noting that there are 20 I-Ds in progress. (see slides)

Qualified Certificates Profile - Stefan Santesson (Addtrust) This document has been approved as a Standards track RFC and is currently in the editors queue. Stefan briefly discussed the status of the corresponding ETSI specification that refers to this RFC. In a new item, Stefan briefly discussed the idea of a new extension that could be used to refer (with integrity) to corporate logos for subjects and issuers, as an aid to users when they display certificates. Steve Kent expressed some concern that such graphics might undermine the security offered by the name constraints extension, IF a CA accidentally or maliciously binds a logo to a name which is not really related to the name.

Attribute Certificate Profile - Steve Farrell (Baltimore) This document has been through working group Last Call and is currently under Area Director Review. Steve described the status of this document, including changes made as a consequence of Last Call. Denis alluded to a problem in the base ISO spec which has been inherited by the PKIX document. A paragraph will be added to the document addressing the security concerns that arise when two CAs have the same name.

Data Validation and Certification Server - Carlisle Adams (Entrust)
This document has been approved as a Experimental track RFC and is currently in the editing queue.

Time Stamp Protocols (TSP) - Denis Pinkas (Bull)
This document has been through working group Last Call and is currently under Area Director Review. Denis described the changes made to the TSP specification as a consequence of Last Call, and the creation of an appendix to specify the SIA extension. This appendix is a temporary one, and the SIA extension will later be moved to RFC 2459bis, when then document is issued. ETSI will work on a TSP security policy document, analogous to one ETSi is working on for CA security policy. Denis offers to initiate further work, to specify a set of standard TSA policies. This would require a mod to the current PKIX charter.

Permanent Identifier - Denis Pinkas (Bull)
This document is stable and ready for progression as an RFC. The question before the WG is what status should be attached to the document, i.e., standards track, informational, or experimental? A quick poll of attendees suggests support for standards track, but since the number of folks who claim familiarity with the document was small, we will bring this to the list for a straw poll for final resolution. Bob Moskowitz cited a potential problem with current CA implementations, if one tried to request a certificate with a new name, signing the request with a key bound to a certificate with a different name.

Technical Non-Repudiation - Tom Gindin (IBM)
This document is ready to proceed as an Informational track specification. Denis presented a few slides raising issues that he feels need to be addressed prior to publication as information. For example, he notes that ETSI has a standard for 1-way NR which is viewed as sufficient for legal NR purposes, not consistent with this draft. Denis will correspond with Tom to resolve this and related issues.

Delegated Path Validation & Discovery Services - Steve Kent (BBN)
The working group has been presented with two alternative Proposals: Simple Certificate Validation Protocol (SCVP) and extensions to OCSP (v2) for Delegated path Discovery and Validation. Steve Kent presented a proposed set of criteria, and associated rationales, for use in evaluating these competing proposals. Steve will follow up with an extended message on the topic to the mailing list, to establish consensus for selection criteria.

Day 2 (12/13/00)

CMP/CRMF Interoperability Results - Bob Moskowitz (ICSA Labs)
Bob has been organizing interoperability testing for CRMF/CMP Implementations. This testing will support the progression of CMP and CRMF to Draft standard. Bob discussed results of recent test activities, which are leading to an interoperability test report. Bob and Carlisle Adams also noted that the PKI Forum intends to stage an OCSPv1 interoperability activity.

Certificate Management Protocol (CMP) - Carlisle Adams (Entrust)
This document incorporates clarifications to RFC 2510. These changes are proposed as a result of interoperability testing. This specification is ready for Last Call and progression of CMP to Draft Standard. The editors believe that the changes made from the previous version are minor and thus the document should progress to DRAFT standard.

Certificate Request Message Format (CRMF) - Carlisle Adams (Entrust)
This document incorporates clarifications to RFC 2511. These changes are proposed as a result of interoperability testing. This specification is now ready for Last Call and progression of CRMF to Draft Standard.

Certificate and CRL Profile revisions - Russ Housley (SPYRUS)
This document is the follow-up to RFC 2459. A new draft of this document has been published. The document is ready for Working Group Last Call, modulo a difference of opinion between X.509 and PKIX re name constraints. It is not clear whether we can achieve agreement with X.509 over this, or if we need to diverge. We set 2/14 as a "drop dead" date, i.e., either we reconcile with X.509 by then, OR we assign a distinct OID for the "PKIX name constraints extension." This date was chosen based on a planned X.509 meeting in late January. Since a number of changes have been made and since they are substantive, this document will be considered as a Proposed Standard.

Public Key Algorithms and Identifiers - Russ Housley (SPYRUS)
This document is a companion to the Certificate and CRL Profile. This specification contains the algorithm-specific information, such as OIDs and encoding information. This specification is ready for WG Last Call and is expected to progress to Proposed Standard with the Certificate and CRL Profile. Jim Schaad suggested that DSA/SHA-1 be mandated, with RSA/MD2 prohibited for new certificates. An attendee suggested that RSA should be mandated, based on existing deployment. Charlie Kaufman suggested that clients be required to support both RSA and DSA and that CAs be required to sign with either RSA or DSA, to maximize interoperability. Jeff Schiller noted that the SAAG argued for consistency among the major certificate client protocols: IPsec, S/MIME, and TLS. Steve Kent agreed to call for a straw poll on the PKIX list re this topic.

OCSPv2 - Michael Myers (VeriSign)
This document incorporates clarifications and enhancements to RFC 2560, plus DPD & DPV extensions. A major issue is whether we should progress this document to DRAFT, or make changes, specifically to the certificate ID mechanism, to cycle at proposed. Mike described the proposed new certificate ID forms; the WG needs to decide if support for all of these forms is appropriate. For example, an attendee noted that issuer name and serial number works even if the server is CRL driven, but certificate hash is not derivable from a CRL. Thus support for some forms of certificate IDs implies server database capabilities that must be explicitly defined and agreed upon. Another attendee raised concerns that the status response (a CHOICE today) may be overloaded when one tries to encompass path validation, vs. validation of individual certificates. Another attendee noted that there are a number of TBD items in the I-D, suggesting that there are a number of issues to be resolved before this document is ready. Steve Kent noted that processing the DPD and DPV extensions represents substantial new functionality and complexity to an OCSP v1 server, so that it is not appropriate to characterize the complexity of these new extensions purely in terms of their (minimal) syntax.

Comments on OCSPv2 - Denis Pinkas (Bull)
Denis agreed that there is a need to revise OCSP, for several minor but important editorial reasons, but he argues that while there are deficiencies in the certificate ID in v1, but that existing OCSP clients do find the certificate ID facility adequate for the simple purpose of revocation status checking. The major motivation for expanding the certificate ID types is to support extensions such as DPV or DPD. He suggested that we revise OCSP, but only to add an ASN.1 module OID, re-specify a mandatory algorithm, and to clarify the status returned, not to support extensions such as DPD and DPV.

Comments on OCSPv2 - Ambarish Malpani (ValiCert)
Ambarish notes that there are at least 11 independent implementations of OCSP v1, many users, etc. For the original, intended purpose, he argues that the current deployment success attests to the adequacy of the current spec. He noted that the use model assumes that the client has all of the certificates in a chain and thus the limitations on certificate IDs are not severe, although he admitted the design could have been better in this regard.

PKIX Roadmap - Sean Turner (IECA)
This document provides an overview or "roadmap" of the work done by the IETF PKIX working group. It defines common terms, describes basic theory behind PKI, and provides an overview of PKIX documents and the relationships between them. This document is now fairly stable; the editor and WG chairs agree to execute WG last call, for this to become an informational RFC.

Operational Protocols, LDAPv3 - David Chadwick (Univ. of Salford)
This document is the LDAPv3 analog of RFC 2559. This document describes the features of LDAPv3 that are essential, or not required, or are optional for servers to support a PKI based on X.509. David reviewed the mandatory, recommended and not recommended, aspects of the profile.

CP/CPS Framework - Tim Polk (on behalf of Santosh Chokhani, Cygnacom)
An ad hoc group of PKIX and ABA members has been working on revisions to RFC 2527, the "Certificate Policy and Certification Practices Framework". A new draft will be posted in the near Future and comments will be solicited from the PKIX WG. This update will describe expected changes in the document. Tim did not present Santosh's slides, due to time constraints, but the slides will be posted to the IETF web site.

Attribute Certificate Acquisition Protocol - Steve Farrell (Baltimore)
This document specifies a deliberately limited protocol for requesting attribute certificates from a server. No presentation was made on this document, since there was no significant progress to report.

Repository Locator Service - Phil Hallem-Baker (VeriSign)
This document leverages DNS and DNS SRV records to enable Certificate using systems to locate PKI repositories based on a domain name, identify the protocols that can be used to access the repository, and obtain addresses for the servers that host the repository service. The current plan is to progress this as an experimental track RFC.

PKIX and XML - Phil Hallem-Baker (VeriSign)
Phil first notes that mere re-encoding of certificates in XML does not seem to be a valuable exercise. A second approach might be to re-encode and change some semantics at the same time, but this too is not very attractive. Instead, the work Phil reported on envisions a fresh start for a native XML PKI model, using XML encryption, signatures, SOAP, etc., i.e., a PKI that is deeply entwined in the XML environment. Several observations are made about why PKI deployment has not been as successful as we would all hope, e.g., applications that are not compliant with standards. XML key management services (XKMS) is an attempt to provide an interface, not an infrastructure, which will yield a very small footprint implementation (because of delegated validation), thus removing an impediment from deployment. "Trust services" form the core of this scheme, using delegated validation in various structural schema, e.g., completely centralized, DNS-tree structure, PGP-web, X.509 cross certification, etc. It is not clear in which context this work should proceed, e.g., it may be more appropriate in W3C vs. the IETF.


Requirements for Technical Non-Requdiation
Certificate and CRL Profile and Public Key Algorithms
Future Directions for OCSP
CMP Interop Project