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

NOTE: This charter is a snapshot of the 46th IETF Meeting in Washington, DC. It may now be out-of-date. Last Modified: 29-Sep-99


Stephen Kent <kent@bbn.com>
Warwick Ford <wford@verisign.com>

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

Current Meeting Report

PKIX WG Meeting 11/9+10/99
Edited by Steve Kent (WG co-chair)

The PKIX WG met twice during the 46th IETF and a total of approximately 285 individuals participated in these meetings over two days.

The meeting began with a review of the status of all of the WG document, presented by Warwick Ford, WG co-chair. The following text summarizes the status of the documents:


PKIX Certificate/CRL Profile (RFC 2459)
Approved as Proposed Standard
KEA Algorithms for Profile (RFC 2528)
Approved as Informational RFC
HTTP/FTP Operations (RFC 2585)
Approved as Proposed Standard
LDAP V2 Operational Protocols (RFC 2559)
Approved as Proposed Standard
LDAP V2 Schema (RFC 2587)
Approved as Proposed Standard
OCSP (RFC 2560)
Approved as Proposed Standard
CMP (RFC 2510)
Approved as Proposed Standard
CRMF (RFC 2511)
Approved as Proposed Standard
Certificate Policy/Practices Guideline (RFC 2527)
Approved as Informational RFC
In IETF last call
Diffie-Hellman Proof of Possesion
In IETF last call


Revised Profile (draft-ietf-pkix-new-part1-00.txt) Work underway

ECDSA Algorithms for Profile (draft-ietf-pkix-ipki-ecdsa-02.txt) Completed Wg last call and ready to forwarded to IESG

Qualified Certificates (draft-ietf-pkix-qc-02.txt)

PKIX Roadmap (draft-ietf-pkix-roadmap-04.txt)

Time Stamp (draft-ietf-pkix-time-stamp-04.txt)

Operational Protocols - LDAPv3 (draft-chadwick-pkixldap-v3-01.txt)

Attribute Certificate Profile for Authorization (draft-ietf-pkix-ac509prof-01.txt)

Limited AC Acquisition Protocol (draft-ietf-pkix-laap-00.txt)

DCS (draft-ietf-pkix-dcs-03.txt)

Simple Certificate Validation Protocol (SCVP) (draft-ietf-pkix-scvp-01.txt)

OCSP Extensions (draft-ietf-pkix-ocspx-00.txt)

CMP over HTTP (draft-ietf-pkix-cmp-http-00.txt)

CMP over TCP (draft-ietf-pkix-cmp-tcp-00.txt)

X.509 (2000) STATUS (S. Boyen- Entrust)

FPDAM Copenhagen meeting update. Deadline for revisions to ITU-T/ISO is 11/20, in preparation for March 2000 ballot. 2000 version (but not 1997 version), will adopt PKIX convention re basicConstraints. 1997 and 2000 text will reflect PKIX definition of v2 CRLs (with no extensions). New extension: inhibitAnyPolicy. Several new LDAP schema object classes defined for PKI support. Defect reports for several items being processed now. There will be a complete restructuring of the X.509 text, to improve it. Attribute certificate changes (v2) include removal of some overly complex features (cross domain and indirect delegation of privileges), and addition of object hash facilities, as a means of binding an AC to a PKC or a software module, etc. See slides for more details on this presentation.


Revisions to RFC 2459 (T. Polk-NIST)
Most text unchanged from RFC; a number of typos were fixed. Major changes are new path certificate path and added CRL validation text. (Old text was incomplete, new version corrects several defects discovered and then fixed in ISO/ITU-T text.) Other significant changes include AIA extension clarifications and DisplayText changes, plus addition of new extension from X.509 (inhibitAnyPolicy). Question: can we progress to Draft, or must we cycle as Proposed? The WG Chairs will talk with the Security ADs re this issue. The list is requested to identify 2 independent implementations as part of progression to Draft status. Please respond to the WG Chairs re this issue. Tim will work to resolve an issue with regard to the proper OID to use with the DC attribute in DNs. (This is an issue because another IETF WG defined this OID, but didn't register it properly.) A suggestion was made to keep ECDSA document (WG last call done) separate. A suggestion was made to add text to clarify the use of the NR bit, but most of the discussion was deferred to the more general NR topic at the end of the agenda.

CA Key Compromise Recovery (D. Pinkas) Both Germany and Italy, in digital signature regulations, require some for of ancillary time stamping of certificates to provide a transition interval for transition to newly issued certificates for users of the CA whose key was compromised. Adoption of these sorts of techniques would require extension of the path validation algorithm to process these time stamps, when there was an indication of CA key compromise. (This indication could be provided by having the CA revoke its self-signed certificate in a CRL that is signed using a separate CA key, or via OCSP responses signed using a separate key.) It is noted that this mechanism addresses the problem of the compromise of one key (a CA key) by adding a second signature (for a time stamp) under a separate key. It also is possible for a CA to use key splitting and thus achieve the same effect in a transparent fashion. It also was suggested that one could add an extension that is an independent signature of the PublicKeyInfo (and SubjectName?) fields, to achieve the same effect. See slides for more details on this presentation.

Qualified Certificates (S. Santesson)
Since Oslo meeting conducted WG last call, and as a result of the comments received, a new ID was published on 10/22. Changes include fixes to some ASN.1 syntax, inclusion of two new Subject attributes (pseudonym and title), plus a qcStatements extension. Ongoing discussion focuses on several topics: can two QCs be compared to determine whether the same person is represented (reword to warn about such comparisons, but don't prohibit them), inclusion of a static identifier (use dnQualifier), use of ISO 3166 trigraphs vs. digraphs (use digraphs), and a restructuring of the personal data field attributes (done). So, time for WG last call, on this revised ID. RFC 2459 will be modified to recommend (SHOULD) support for the pseudonym attribute. See slides for more details on this presentation.

OCSP Extensions (P. Baker-VeriSign)
Original protocol focuses on validation of one certificate, returns a signed response to a client for later use in NR, and allows for a per-use charging model. This proposal to extend OCSP to support path processing, while maintaining most of the syntactic basis of OCSP. It is noted that delegation of path processing does not necessarily indicate delegation of trust, if the protocol returns the data needed to verify what the server did to determine certificate validity. Note that certificate policy processing is target dependent, so offloading path validation requires that the client must pass data to the server, to parameterize validation, e.g., a URI. (Note that this reveals more info to the server that would be necessary if the client merely passed parameters that would have been sent across an API for local path processing.) Ultimately, this presentation proposes using OCSPX as the protocol for interacting with an authorization server, and that one can use the returned tokens as part of an audit trail.

Audience questions/comments: in what contexts might this be used vs. existing standard protocols (e.g., TLS, IPsec, etc.), whether the OCSP syntax is suitable for this application (OCSP does not pass full certificates), how attribute certificates fit in, two expressions of support for path construction and validation but not necessarily authorization.

PKIX Roadmap (S. Turner-IECSA)
Two updates since last meeting, focus on attribute certificates and non-repudiation. More text will be added for trust models, DCVS, POP, etc.

Time Stamping Protocol (D. Pinkas-Bull)
Denis discussed the differences between version 2 and version 4. Major changes include: A time stamp format based on GeneralizedTime (which allows sub-second time) and an optional field that specifies the accuracy of the first field is now employed. The serial number is now mandatory, allowing unique identification of a timestamp from a TSA. TDA extensions have been removed, but a facility for extensions has been retained. TSAs no longer explicitly assert anything about the hash function being used. The format of the TSTInfo has changed, and is now simpler. From a legal standpoint, there is better reason to believe that we can now proceed with this work without encountering significant intellectual property issues. The patent infringement case filed by Surety against Entrust resulted in the first four claims of the (most general) Surety patent being declared invalid. These claims covered the basic notions of time stamping as we perform it in the TSP. Other patent claims may still be applicable to implementations of a "secure" TSA clock, or the way the time stamp is employed. For example there is a patent on secure hardware implementation of a time stamp time source, and on the use of a time stamp to extent the lifetime of a certificate. The basic protocol patent issues seem to be resolved at this time, at least in the US patent system. See slides for more details on this presentation.

LDAPv3 Profile (D. Chadwick- University of Salford)
No presentation. Need to check on status of document re WG last call.

Attribute Certificates (S. Farrell-SSE)
Latest version moved LAAP to a separate draft, removed concept of "restrictions," added new AC revocation options (e.g., "never revoke" for short-lived certificates) and adds support of linking to owner via a hash value (currently just a link to a public key, but could be broadened to be more general). The new version is simplified and all parts are mandatory to implement. Several syntax changes were made, to help manage creation of new extension. More syntax changes will be required to align with v2 X.509 ACs. Plan is to create a 03 version before the March IETF and progress to WG last call around that time. See slides for more details on this presentation.

A new protocol (LAAP) for AC acquisition is defined here. It is currently encapsulated in CMP PKIMessage syntax. It is not a replacement for LDAP, but an alternative when one choose not to store ACs in a directory. The protocol is quite limited in scope, e.g., fetches just one AC. It is not designed to be a management protocol for ACs (could extend CMP/CMC for that purpose). Fetches are keyed using strings, either matched against attribute certificate string values or against string representations of AC OIDs. A number of open issues remain to be resolved, e.g., appropriate encapsulation and transport protocols. See slides for more details on this presentation.

Revision of PKIX Part 4 (J. Rodriguez-IBM)
Major changes to chapters 3, 4 and 5 have been made. No changes are proposed for sections 1, 6, 7, and 8. Revisions to sections 2 and 5 should be completed before the end of the month. Confusion over differences between a CPS and a certificate policy continues, with some coordination with ABA ISC. The glossary also needs work. Revisions to sections 4 and 3 are slated for completion by the end of the year. Plan to go to last call before the March meeting.


CMP/CMC Interoperability Testing (R. Moskowitz-ISSA & C. Adams-Entrust)
Experience with CMP testing workshops, involving 6 vendors, suggests some changes should be made to CMP. Most vendors implemented DSA, some RSA. Some changes are minor, e.g., default MAC for PKIProtection undefined. Major changes include a new Confirm message format and an overhaul mapping to various transport protocols (e.g., TCP and HTTP). Plan is to issue an ID with changes to RFC 2510 and to complete update by March meeting. Denial of service attacks will be better addressed by changes to accompanying text. The transport mapping discussion may be moved to a separate document. Question is whether the revised document can progress to Draft, given that the changes are mostly minor, or represent removal of material. The WG co-chairs need to contact the Security ADs to discuss the issue of document progression. Planning for CMC interoperability testing is now underway. See slides for more details on this presentation.

ETSI Electronic Signature Standard (D. Pinkas-Bull)
The intent is to align this technical work with an EU directive which is expected to be approved before the end of this year. The goal of this standard is to specify what is needed to provide digital signatures that are (legally) equivalent to a handwritten signature. The scope of this work includes product and service certification, as well as technical specifications for protocols and data formats in support of electronic signatures. This work assumes the use of qualified certificates. The URL for this document was posted to the PKIX list for comments. Signature policy is a new element of this work, and the policy must be represented in a machine-processable form. CMS is base syntax adopted here for signed data, with ASN.1-defined extensions to carry a variety of additional data necessary to create a non-repudiable transaction. Both CRLs and OCSP responses are supported. Two APIs are defined to support these data structures. See slides for more details on this presentation.

PKI Disclosure Statements (S. Santesson)
Paper developed with ABA ISC and International Chamber of Commerce (ICC). Not a substitute for a CPS or a certificate policy (CP). Focus is on most critical elements of a CPS or CP, to be deposited in a repository for retrieval by prospective relying parties. CPS and CP are too complex and thus there is a need for a simpler, standard format to represent the most critical data. (This is analogous to what was required of PCAs in RFC 1422 for the PEM PKI.) First version posted to PKIX list today, but we need to decide whether this will become a PKIX work item. One lawyer who attends the ABA ISC meetings was surprised to hear about this ...

Null Signature Algorithm (A. Malpani-ValiCert)
Motivation in part is that some data structures have a signature as an optional feature. One can achieve this effect by making the signature an optional data structure; this proposal suggests another way to represent this, i.e., by using a NULL algorithm for signatures. It also is suggested that this would be useful for testing. Comments from the floor were strongly negative. A straw poll of the meeting attendees showed strong opposition to adoption of this algorithm, so it will be dropped from the work item list.

Jonah Status (M. Shanzer-Iris)
Implementation of RFC 2459, CMP, CRMF, and LDAP (but not CMC or OCSP). C++ with a Java GUI, on NT and Solaris. Includes a CA, RA, and a trivial end entity. Now uses Cylink toolkit for crypto, but will make use of BSAFE soon. Jonah is exportable, but the crypto toolkit is not. Tested against NIST, Baltimore, Entrust, Trustpoint and Xeti.

Technical Requirements for Non-repudiation (T. Gindin-IBM)
The document was motivated by the list discussion over the role of the NR bit and ancillary certificate and CRL data. Note that the services described here do not constitute a complete service for legal non-repudiation, but may provide a suitable technical basis for legal non-repudiation. An obvious question is how this relates to the ETSI work described by Denis? Based on comments from the audience, Tom has decided to remove the legal references from the document, modify or delete the text related to the invalidityDate extension. The revised document will be issued as a PKIX ID, with the intent of publication as an informational RFC in the future. Slides may be available with more details on this presentation.


Son-of-RFC 2510
X.509 Copenhagen editing meeting Oct 27-29, 1999 Overview of major changes
Requirements for Technical Non-Repudiation
PKIX Roadmap
Validating certificates in case of a CA key compromise
EESSI : the European Electronic Signature Standardisation Initiative
The NR bit
Time Stamping Protocol (TSP)