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

NOTE: This charter is a snapshot of the 50th IETF Meeting in Minneapolis, Minnesota. It may now be out-of-date. Last Modified: 14-Mar-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

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

Internet-Drafts:
Request For Comments:

RFC

Status

Title

RFC2459

PS

Internet X.509 Public Key Infrastructure Certificate and CRL Profile

RFC2510

PS

Internet X.509 Public Key Infrastructure Certificate Management Protocols

RFC2511

PS

Internet 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

RFC2559

PS

Internet X.509 Public Key Infrastructure Operational Protocols - LDAPv2

RFC2585

PS

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

RFC2587

PS

Internet X.509 Public Key Infrastructure LDAPv2 Schema

RFC2560

PS

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

RFC2797

PS

Certificate Management Messages over CMS

RFC2875

PS

Diffie-Hellman Proof-of-Possession Algorithms

RFC3039

PS

Internet X.509 Public Key Infrastructure Qualified Certificates Profile

RFC3029

E

Internet X.509 Public Key Infrastructure Data Validation and Certification Server Protocols

Current Meeting Report

PKIX WG Meeting 3/20/01
Edited by Steve Kent (WG co-chairs)

The PKIX WG met once during the 50th IETF. A total of approximately 155 individuals participated in the meeting.

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

Two new RFCs:
RFC 3029 Data Validation and Certification Server (Experimental)
RFC 3039 Qualified Certificates (Proposed Standard)

In the IESG Review Process:
Timestamp Protocol (missing IANA considerations section)
Attribute Certificate Profile (missing IANA considerations section and another issue)

Soon to be Submitted to IESG:
PKIX Roadmap (Informational)
Permanent Identifier (Experimental?)
Repository Locator Service (Experimental)

In WG Last Call:
Son-of-RFC 2459
Public Algorithms and Identifiers
CRMF & CMP
CMP/CRMF Interoperability results?

Close to WG last call:
OCSPv1 bis

Evolving Specifications
Technical NR (being revised)
OCSPv2
Additional LDAP Schema
Attribute Certificate Acquisition Protocol
CP/CPS Framework
DPD/DPV requirements

New Work
Impersonation Certificates
Group Name

Status of RFC 2459bis- Russ Housley (RSA Labs)
After discussions with ITU-T counterparts, path length computation was fixed, in a fashion consistent with the existing PKIX documents. Also answered the question "who can issue CRLs," by allowing a CA certificate to contain EITHER the keyCertSign OR cRLSign bits OR BOTH. Thus only CAs (syntactically speaking) issue CRLs, bit it allows creation of an entity that is marked as a CA, but which is restricted to signing CRLs. (slides)

OCSPv1 - Ambarish Malpani (ValiCert)
Moving OCSPv1 to Draft Standard. Interoperability efforts going well, including PKI Forum work. Also some minor clarifications of the text. Make RSA mandatory, drop required support for DSA. (slides)

CMC - Jim Schaad (Soaring Hawk Consulting)
Updating document, symmetric key distribution ambiguity, minor editorial corrections. Hope to complete updates and get interoperability test data for progression to Draft in about 6 months. (no slides)

Impersonation Certificates - Stephen Tuecke (Argonne Labs)
Renamed proxy certificates. Motivation is single signon delegation support. Intent is to bind a new key pair to a subject alt name and to an extension that labels this as a proxy certificate. However, there are conflicts between this proposal and the existing and revised profile (and X.509). Specifically, the EE is acting like a CA, syntactically, but the EE certificate does not have the basicConstraints flag set to mark it as a CA. Thus the path validation algorithm would reject these proxy certificates. (slides)

DPD/DPV Requirements - Steve Kent (BBN)
Presentation described revised proposals for DPD and DPV requests and responses, using ASN.1 strawmen examples. Ended with a plan for progress on the topic, resulting in selection of a protocol before the next IETF meeting in August. Steve Farrell expressed concern that the DPD request is too complex, contains unnecessary controls, based on a model that does not require returned paths to be ones that will necessarily successfully validate for the client. (slides)

OCSPv2 - Michael Myers (VeriSign)
Expansion of OCSPv1 to create a candidate protocol for the DPD & DPV functions. Includes a facility to support nonce relay, by concatenating new nonces with old ones. Emphasis on reuse of OCSPv1 structures wherever possible, e.g., with regard to status responses. There are fewer controls on path construction for DPD vs. DPD, based on assumptions about relative capability of clients and on perception of likely complexity of certificate graphs. (slides)

DPD/DPV - Denis Pinkas (Bull)
For DPV, major focus is valid/invalid response, plus optional proof returned when needed, e.g., for NR. Can have a small response with Y/N response and hash as a link to the supporting info. Suggests just a single path and revocation status data should be returned. For DPD need a path returned always, unlike DPV. Suggests partial revocation status data might be returned, if complete data not available. (Both DPD + DPV specify the target by either supplying a certificate or an Issuer name and serial number.) Suggestion that CA and EE certificates may not want the same revocation status data, but Mike Myers disagrees with this distinction. Proposal for partial responses, e.g., incomplete paths. Argument against DPV support for a posteriori validation when the time frame is outside of the certificate validity period. Finally, argues for stateless servers, i.e., no retry facility in DPD. (slides)

SCVP - Ambarish Malpani (ValiCert)
Removed XML syntax, and will use CMS as secure enveloping mechanism. (one slide)

Group Name - Mike St. Johns (??)
Motivation is to support a commonly employed OS naming convention in EE certificates, instead of having to map from a DN. Possible uses in attribute certificates too. Currently proposed as an OtherName but open to suggestions for encoding. (slides)

Policy Requirements for TSAs - Denis Pinkas (Bull)
This is a new ETSI work item. Will complement existing ETSI standards on electronic signature formats, qualified certificates, and a document addressing policy for CAs issuing qualified certificates. TSA policy will be based on RFC 2527 and ETSI 456. Welcome participation and inputs from PKIX and SMIME WG members. (slides)

Slides

Son-Of-RFC2459 Status
DPV/DPD Highlights
'draft-ietf-pkix-ocspv2-02'
DPV & DPD
Policy requirements for TSAs
Internet X.509 Public Key Infrastructure Impersonation Proxy Certificate Profile
Certificate Validation How We Should Do It
Future Directions for OCSP