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

NOTE: This charter is a snapshot of the 43rd IETF Meeting in Orlando, Florida. It may now be out-of-date. Last Modified: 25-Nov-98

Chair(s):

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

Security Area Director(s):

Jeffrey Schiller <jis@mit.edu>
Marcus Leech <mleech@nortel.ca>

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:

Many Internet protocols and applications which use the Internet employ public-key technology for security purposes and require a public-key infrastructure (PKI) to securely manage public keys for widely-distributed users or systems. The X.509 standard constitutes a widely-accepted basis for such an infrastructure, defining data formats and procedures related to distribution of public keys via certificates digitally signed by certification authorities (CAs). RFC 1422 specified the basis of an X.509-based PKI, targeted primarily at satisfying the needs of Internet Privacy Enhanced Mail (PEM). Since RFC 1422 was issued, application requirements for an Internet PKI have broadened tremendously, and the capabilities of X.509 have advanced with the development of standards defining the X.509 version 3 certificate and version 2 certificate revocation list (CRL).

The task of the working group will be to develop Internet standards needed to support an X.509-based PKI. The goal of this PKI will be to facilitate the use of X.509 certificates in multiple applications which make use of the Internet and to promote interoperability between different implementations choosing to make use of X.509 certificates. The resulting PKI is intended to provide a framework which will support a range of trust/hierarchy environments and a range of usage environments (RFC1422 is an example of one such model).

Candidate applications to be served by this PKI include, but are not limited to, PEM, MOSS, GSS-API mechanisms (e.g., SPKM), ipsec protocols, Internet payment protocols, and www protocols. This project will not preclude use of non-infrastructural public-key distribution techniques nor of non-X.509 PKIs by such applications. Efforts will be made to coordinate with the IETF White Pages (X.500/WHOIS++) project.

The group will focus on tailoring and profiling the features available in the v3 X.509 certificate to best match the requirements and characteristics of the Internet environment. Other topics to be addressed potentially include:

o Alternatives for CA-to-CA certification links and structures, including guidelines for constraints

o Revocation alternatives, including profiling of X.509 v2 CRL extensions

o Certificate and CRL distribution options (X.500-based, non-X.500-based)

o Guidelines for policy definition and registration

o Administrative protocols and procedures, including certificate generation, revocation notification, cross-certification, and key-pair updating

o Naming and name forms (how entities are identified, e.g., email address, URN, DN, misc.)

o Generation of client key pairs by the PKI

Goals and Milestones:

Oct 95

  

Agree on working group charter.

Nov 95

  

Complete initial strawman PKI specification.

Dec 95

  

First meeting at Dallas IETF.

Jul 96

  

Submit PKI (X.509) specification to IESG for consideration as a Proposed Standard.

Internet-Drafts:

No Request For Comments

Current Meeting Report

PKIX WG Meeting 12/8/98 & 12/9/98

Edited by Steve Kent (WG co-chair)

The PKIX WG met twice during the 43rd IETF and a approximately 190 individuals participated in these meetings.

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 Cert/CRL Profile (draft-ietf-pkix-ipki-part1-11.txt)
Approved for Proposed Standard

KEA Algorithms for Profile (draft-ietf-pkix-ipki-kea-02.txt)
In WG Chairs' hands - ready for publication as Informational RFC

ECDSA Algorithms for Profile (draft-ietf-pkix-ipki-ecdsa-01.txt)
In Editors' hands.

HTTP/FTP Operations (draft-ietf-pkix-opp-ftp-http-04.txt)
In WG Chairs'/Area Director's hands - ready for IESG

LDAP V2 Operational Protocols (draft-ietf-pkix-ipki2opp-08.txt)
Awaiting schema document and will be reviewed by IESG together.

LDAP V2 Schema (draft-ietf-pkix-ldapv2-schema-02.txt)
In Area Director's hands, will be forwarded to IESG very soon.

OCSP (draft-ietf-pkix-ocsp-07.txt)
In Area Director's hands

CMP (draft-ietf-pkix-ipki3cmp-08.txt) and CRMF (draft-ietf-pkix-crmf-01.txt)
About to be approved by IESG

CMC (draft-ietf-pkix-cmc-02.txt)
Under development.

CMMF (draft-ietf-pkix-cmmf-02.txt)
In WG last call, but probably will be deleted, due to subsumption by CMC.

Certificate Policy/Practices Guideline (draft-ietf-pkix-ipki-part4-03.txt)
In Area Director's hands - ready for publication as Informational RFC

Reports on Established Projects:

OCSP (A. Malpani-ValiCert)
Announcement of an OCSP server available for interoperability testing.

CMC (J. Weinstein-Netscape)
Notable changes from last time, and new text makes explicit what requirements are being met. Given the extent of these changes, this I-D is NOT yet in WG last call. CMC is primarily based on PKCS 10, and CMRF, and CMS (PKCS 7 successor developed in S/MIME). Protocol is stateless, to make life easier for the server, optional for client. Features supported include client or CA generation of key pairs, optional key recovery, POP, realtime and staged delivery responses, and (local) RAs. Mandatory algorithms include DSA and D-H, with RSA as an option. Steve Kent, WG co-chair, asked that the document be revised to make explicit the security requirements imposed on CMC transactions and whether these requirements are met by CMC in all cases, or whether CMC optionally satisfies these requirements. In the latter case, there are security dependencies relative to the underlying protocol employed for transport. Such dependencies must be explicitly stated in the document. Jeff agreed to make the edits necessary to satisfy these concerns.

Carlisle Adams raised some concerns about the POP mechanisms contained in the protocol and raised issues about the need for more details, and some edits (e.g., OID values), to ensure interoperability. Carlislie was asked to send these issues to the list so that the CMC authors can address them prior to WG last call.

Diffie-Hellman POP Mechanisms (J. Schaad-Microsoft)
Jim provided an update on an informational document that will specify a means of proof of possession with non-fixed groups, consistent with S/MIME contexts. There was general agreement that the result of this work will be appropriate as a standards track (vs. informational) RFC.

PKIX Roadmap (A. Arsenault-NSA)
Al has received a few comments but is looking for more, and will continue to refine the document as the last of the mainline

X.509 PDAM Update (T. Polk- NIST)
Tim presented several slides provided by Sharon Boyen (Entrust), describing X.509 proposed changes from the September ITU-T meeting. The PDAM describes new extensions related to attribute certificate revocation, etc. Comments are requested from PKIX WG members. For more details, see the message to the WG from Hoyt Kesterson (Hoyt.Kesterson@bull.com), dated 11/23/98.

Reports on New(er) Topics:

Qualified Certificates (draft-ietf-santesson-qc-01.txt) (S. Santesson)
This I-D addresses profiling X.509 certificates for use in a particular application context, i.e., for generation of digital signatures that will be recognized as legal throughout the EU. These certificates are to be issued to individuals who will generate digital signatures that support non-repudiation. There is an assumption that these certificates will be used not only with custom applications, but also with standard IETF applications such as S/MIME, hence the relevance to this WG. Only four certificate fields are addressed by this: Issuer, Subject, Policy, and Key usage. Thus a primary focus of this document is on naming, both requiring support for specific DN attributes and specifying semantics for the names. The slides provide additional details.

ETSI Report on Electronic Signature Standardization (D. Pinkas)
Denis provided a brief report on "electronic" signature standardization. This is quite analogous to the previous presentation, with the further focus on signatures for high value transactions. Again, non-repudiation is essential, but here roles, not just individual identities, are relevant, as is the context in which the signature is applied, e.g., as indicated by policy. The ETSI group has identified a list of issues to be resolved in order to provide the necessary framework for such high value signature applications. See the slides for additional details. The report is available at: http://www.etsi.org/SEC/ESRep042.pdf

Timestamp (draft-ietf-pkix-time-stamp-00.txt)
Data Certification Server (draft-ietf-pkix-dcs-00.txt) C. Adams- Entrust Carlisle reviewed differences between the current drafts and the drafts reviewed at the previous IETF meeting. In particular, the new version of the timed stamp I-D offers finer granularity for time stamps and support for time stamping of just a nonce. It was suggested that we combine the services of time stamping and document "notarization" into a single protocol, where the object submitted could be a hash or the object itself. However, there was not agreement that such combination was beneficial in all cases, and a single server may offer both timestamping and data certification services with only slightly greater complexity. The CMP-derived status indications need to be "masked" to clarify the fact that some CMP error conditions are not relevant to this application.

The timestamp I-D appears to be ready to move to WG last call with the next version, however the data certification I-D needs more work. Also, the WG chairs need to co-ordinate with the Security AD to modify the charter to encompass both of these I-Ds.

Slides

Diffie-Hellman Signing Algorithm
Qualified Certificates Basic Characteristics
Electronic Signature Standardisation