NOTE: This charter is a snapshot of the 44th IETF Meeting in Minneapolis, Minnesota. It may now be out-of-date. Last Modified: 06-Jan-99
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 Operational Protocols - LDAPv2
· 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 Public Key Infrastructure Certificate Management Message Formats
· 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
· Internet X.509 Public Key Infrastructure Time Stamp Protocols
· Internet X.509 Public Key Infrastructure Data Certification Server Protocols
· Internet X.509 Public Key Infrastructure PKIX Roadmap
· Internet X.509 Public Key Infrastructure Qualified Certificates
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 | |
PKIX WG Meeting 3/17/99
Edited by Steve Kent (WG co-chair)
The PKIX WG met only once during the 44th IETF and a approximately 200 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 COMPLETED DOCUMENTS
PKIX Cert/CRL Profile (RFC 2459)
- Approved as Proposed Standard
KEA Algorithms for Profile (RFC 2528)
- Approved as Informational RFC
HTTP/FTP Operations (draft-ietf-pkix-opp-ftp-http-04.txt)
- Approved as Proposed Standard
LDAP V2 Operational Protocols (draft-ietf-pkix-ipki2opp-08.txt)
- Approved as Proposed Standard
LDAP V2 Schema (draft-ietf-pkix-ldapv2-schema-01.txt)
- Approved as Proposed Standard
OCSP (draft-ietf-pkix-ocsp-05.txt)
- 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
PKIX WORK IN PROGRESS
ECDSA Algorithms for Profile (draft-ietf-pkix-ipki-ecdsa-01.txt)
- New draft to be issued for WG last call shortly
CMC (draft-ietf-pkix-cmc-02.txt)
- Under WG review
Diffie-Hellman POP (draft-ietf-pkix-dhpop-00.txt)
- Under WG review
Qualified Certificates (draft-ietf-santesson-qc-01.txt)
- Under WG review
CMMF (draft-ietf-pkix-cmmf-02.txt)
- This item to be dropped from the program
Time Stamp (draft-ietf-pkix-time-stamp-00.txt)
- Under WG review
DCS (draft-ietf-pkix-dcs-00.txt)
- Under WG review
Web-Based Integrated CA Services Protocol (draft-sakurai-pkix-icap-01.txt)
- Submitted for WG consideration
Reports on Established Projects:
A new WG charter was presented, in draft form, which shortly will be posted to the mailing list. The expanded charter encompasses attribute certificates, time stamping and notarization services, and qualified certificates.
CMC and Diffie-Hellman POP (J. Schaad-Microsoft)
- The CMC draft did not meet submission deadline, but was made available to the list. The D-H POP draft is undergoing revision. CMC has been revised to accommodate comments from Carlisle from the last meeting. Additional changes are planned, including removal of the key archival and recovery features, and clarification of RA operations.
PKIX Roadmap (A. Arsenault-NSA)
- Missed submission deadline. Undergoing revision to deal with terminology inconsistencies, POP, adding a history of PKIX, new work items (e.g., qualified certificates and time stamping), explanation of name constraints for alt name forms, path validation, etc.
Qualified Certificates (S. Santesson)
- Goals of qualified certificates were reviewed. The fundamental thrust of this work is the development of a new SubjectAltName type, for "unmistakable identity" ID information. Attribute semantics represents the top-level structure for the SubjectaltName, making it clear what form of ID is being provided, e.g., national ID card or driver license. Also, this extension will contain a registration authority field, as required by German law. A pointer to a web site for additional info was provided (http://www.accurata.se/QC/). Suggestion was made to consider splitting this work into two document: one for the new name form, and another (informational?) to explain the context for which this new name form was devised. However, to the extent that a qualified certificate imposes constraints on other certificate fields, it is not clear
Data Certification and Time Stamping (R. Zuccherato-Entrust)
- Data certification server I-D not recently updated, but will be soon, to respond to comments, e.g., ASN.1 corrections and more explanatory text. The time stamping document also has not been updated recently, but will undergo minor revisions, e.g., to allow for issuance of a time stamp without submission of a hash. Unfortunately, the topics of time stamping and data certification are rife with intellectual property claims, which may interfere with progression of these documents. Specifically, a lawsuit has been filed by patent holders against a company that has implemented a prior version of this protocol. The WG chairs will work with the authors of the documents to help resolve these issues.
Other Topics:
Progressing RFC 2459 to Draft Status (T. Polk-NIST)
Collecting inputs for (mostly) minor corrections and clarifications to this document in anticipation of progressing this work.
OCSP Clarification (S. Kent-BBN)
- Two sections of OCSP will be revised to clarify what is required of compliant clients and servers with respect to what keys can be used to sign OCSP responses. Specifically, an OCSP response must be signed by either the CA who issued the certificate in question, by an entity who has been explicitly delegated this authority by that CA (through direct issuance and inclusion of a specified EKU extension), or by an entity who has been selected as authoritative by the client. Compliant OCSP servers and clients MUST be able to support all three of these options.(Satisfying the third option is largely trivial for the server, but requires a configuration capability for clients.)
Will End-Entity Certificates be Fat or Low Fat? (D. Pinkas-Bull)
- Proposal to minimize the addition of extensions to EE certificates, by moving as much of this sort of information to CA certificates, from EE certificates. Examples of such extension data are pointers to OCSP responders and CRL servers, where applicable to all certificates issued by a CA.
Attribute Certificates (S. Farrell-SSE)
- A kickoff announcement of this new work item. Providing pointers to work on attribute certificates for use with TLS, as an example.
OCSP Interoperability Testing (A. Malparni-ValiCert)
- Reported on tests of seven independent implementations. All made use of HTTP and direct, DER encoding (not base 64). Discovered some problems, e.g., in hash computation.
Server-based Certificate Validation (A. Malparni-ValiCert)
- A suggestion to explore "outsourcing" certificate validation to a server, from a client. Proposal is to develop a protocol between a client and the validation server, which might be attractive when the client is not computationally capable, or to help by centralizing administration of certificate validation management. There are security concerns here, because of the centralization of security function in servers.
MISPC Reference Implementation (T. Polk-NIST)
- CDROM contains CA, RA, and client executable code. Represents a profile of 2459, CMP, and CRMF. Available via web site: http://crscnist.gov/pki/mispc/
Are We Building Fat or Low-Fat Leaf-Certificates ?
Diffie-Hellman POP Algorithm