NOTE: This charter is a snapshot of the 42nd IETF Meeting in Chicago, Illinois. It may now be out-of-date. Last Modified: 23-Jul-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:
· Internet X.509 Public Key Infrastructure Certificate and CRL Profile
· Internet X.509 Public Key Infrastructure Certificate Management Protocols
· Internet X.509 Public Key Infrastructure Operational Protocols - LDAPv2
· Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework
· Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP
· X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP
· Internet X.509 Certificate Request Message Format
· Internet X.509 Public Key Infrastructure Certificate Management Message Formats
· Internet X.509 Certificate Management Messages over CMS
· Internet X.509 Public Key Infrastructure LDAPv2 Schema
· Internet Public Key Infrastructure Caching the Online Certificate Status Protocol
· WEB based Certificate Access Protocol-- WebCAP/1.0
· Internet X.509 Public Key Infrastructure ENHANCED CRL DISTRIBUTION OPTIONS
No Request For Comments
PKIX WG Meeting Minutes 8/26-27/98
The PKIX WG met twice during the 42nd 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 Certificate/CRL Profile (draft-ietf-pkix-ipki-part1-09.txt)
- IESG Last Call KEA Algorithm Profile (draft-ietf-pkix-ipki-kea-02.txt)
- Close to completion by Editors HTTP/FTP Operations
(draft-ietf-pkix-opp-ftp-http-04.txt)
- Ready for WG last call LDAP V2 Profile (March 98 draft)
- At IESG, pending WG delivery of V2 Schema LDAP V2 Schema
(draft-ietf-pkix-ldapv2-schema-01.txt)
- In WG last call OCSP (draft-ietf-pkix-ocsp-05.txt)
- In WG last call CMP (draft-ietf-pkix-ipki3cmp-08.txt) and
CRMF (draft-ietf-pkix-crmf-01.txt)
- In hands of IESG; pending IESG last call CMMF (draft-ietf-pkix-cmmf-02.txt)
and CMC (draft-ietf-pkix-cmc-01.txt)
- In WG last call Certificate Policy/Practices Guideline
(draft-ietf-pkix-ipki-part4-03.txt)
In SA Director's hands, pending publication as Informational RFC REVIEWS OF
ESTABLISHED PROJECTS:
PKIX Certificate and CRL Profile (Tim Polk) Ready for IESG ballot, after receipt of
minor editorial comments during IETF last call. Straw polls used to resolve last few
contentious issues, specifically mandating use of DNs for all Issuers, and mandating
use of strict subtrees for the NameConstraints extension.
Jeff Schiller noted that the IETF web site has pointers to the Entrust license required
for inclusion of CRL distribution point within this document. The license is easy to
execute; there is a reciprocity clause that requires licensing to Entrust any intellectual
property associated with CRL distribution, as a side effect of - KEA and ECDS
Algorithms (Tim Polk) Work on these algorithm ids continues, subject to resolution
of some intellectual property issues. - LDAP V2 Schema and Profile (Tim Moses,
Dave ???, Santosh Chokani)
Most of the schema are not controversial; outstanding issues is whether all
CAcertificates should appear in the cross certificate directory attribute, or whether
certificates that are internal to a domain should appear in the CA certificate attribute.
There is consensus that any self-signed CA certificates belong in the latter attribute.
The disagreement here revolves around alternative certificate validation algorithms;
both approaches have been implemented and both work, each favoring a different
PKI model. The CA certificate attribute has been a feature of X.509 for a long while,
so the proposal to move all (non- self-signed) CA certificates to the cross CA certificate
attribute represents a non-backward compatible change for systems not making use of
cross certificates. Still, this is the direction currently being pursued by the X.509
committee in resolving this ambiguity in the original standard. Performance analysis
of 6 different approaches, under varying assumptions of PKI models, shows that.
PKIX ROADMAP
Enhanced CRL Distribution Options
CMC/CMMF
OCSP
ECDSA Profile
KEA Profile
Certificate Profile Status Update
Web-based Integrated
CA services Protocol, ICAP
Qualified Certificates