NOTE: This charter is a snapshot of the 48th IETF Meeting in Pittsburgh, Pennsylvania. It may now be out-of-date. Last Modified: 17-Jul-00
Chair(s):
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 |
Internet-Drafts:
· Internet X.509 Public Key Infrastructure Time Stamp Protocols (TSP)
· Internet X.509 Public Key Infrastructure Data Validation and Certification Server Protocols
· Internet X.509 Public Key Infrastructure PKIX Roadmap
· An Internet AttributeCertificate Profile for Authorization
· Internet X.509 Public Key Infrastructure Operational Protocols - LDAPv3
· Simple Certificate Validation Protocol (SCVP)
· Internet X.509 Public Key Certificate Infrastructure and CRL Profile
· Internet X.509 Public Key Infrastructure Technical Requirements for a non-Repudiation Service
· Internet X.509 Public Key Infrastructure Qualified Certificates Profile
· Internet X.509 Public Key Infrastructure Certificate Management Protocols
· Internet X.509 Public Key Infrastructure Permanent Identifier
· Internet X.509 Public Key Infrastructure Additional LDAP Schema for PKIs and PMIs
· Internet X.509 Public Key Infrastructure Repository Locator Service
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 |
PKIX WG Meeting 8/1/00
Edited by Steve Kent (WG co-chair)
The PKIX WG met once during the 48th IETF and a total of approximately 180 individuals participated in this meeting.
The meeting began with the announcement that Tim Polk of NIST will take over from Warwick Ford as a co-chair of the WG. Warwick received a round of applause from the audience, for his service to the Wg since its inception.
Tim began the meeting with a review of the status of all of the WG documents. The following text summarizes the status of the documents:
PKIX COMPLETED DOCUMENTS (RFCs)
PKIX Cert/CRL Profile (RFC 2459)
HTTP/FTP Operations (RFC 2585)
LDAP V2 Operational Protocols (RFC 2559)
LDAP V2 Schema (RFC 2587)
OCSP (RFC 2560)
CMP (RFC 2510)
CRMF (RFC 2511)
CMC (RFC 2797)
Diffie-Hellman POP (RFC 2875)
Certificate Policy/Practices Guideline (RFC 2527)
KEA Algorithms for Profile (RFC 2528)
PKIX WORK IN PROGRESS (Internet Drafts)
Revised Profile (draft-ietf-pkix-new-part1-02.txt)
Algorithms for Profile (draft-ietf-pkix-ipki-pkalgs-00.txt)
Qualified Certificates (draft-ietf-pkix-qc-05.txt)
Time Stamp (draft-ietf-pkix-time-stamp-09.txt)
PKIX Roadmap (draft-ietf-pkix-roadmap-05.txt)
Revised CMP (draft-ietf-pkix-rfc2510bis.01)
CMP Transports (draft-ietf-pkix-cmp-transport-protocols-01.txt)
Operational Protocols - LDAPv3 (draft-ietf-pkix-ldap-v3-02.txt)
Additional LDAP Schema (draft-ietf-pkix-ldap-schema-00.txt)
Attribute Certificate Profile for Authorization (draft-ietf-pkix-ac509prof-04.txt)
Limited Attribute Cert Acquisition Prot (draft-ietf-pkix-laap-01.txt)
DCS (draft-ietf-pkix-dcs-05.txt)
Simple Certificate Validation Protocol (SCVP) (draft-ietf-pkix-scvp-03.txt)
Permanent Identifier (draft-ietf-pkix-pi-00.txt)
Repository Locator Service (draft-ietf-pkix-pkixrep-00.txt)
Tech. Rqmts. For Non-Repudiation (draft-ietf-pkix-technr-01.txt)
ACTIVE PROJECTS:
LDAP v3 Profile (D. Chadwick-U. of Salford)
Split profile into two pieces: protocol vs. schema. The protocol parts should be completed in the next 6-8 weeks and be ready for WG last call. (Suggestion that the LDAP WG also be included in this last call.) The schema work will take longer, as it is a new topic. A major change for the schema is to allow searching on certificate fields, rather than searching on the directory attributes extracted from the certificate. For now, plan to keep the schema work related to certificates in PKIX, not in an LDAP WG, with David acting as principal liaison between the two groups.
RFC 2459 evolution (T. Polk-NIST)
2459 has been split into algorithm profiles vs. certificate & CRL syntax and processing. This allows the algorithms document to be revised as algorithms change, without affecting the syntax and processing standard. There is little new material here, mostly clarifications, editorial revisions, etc. We will hold a straw poll on the list on naming mandatory algorithms, e.g., RSA and SHA-1. With the end of the RSA patent period, many other security WGs are taking similar steps. Also, if the WG decides to identify mandatory algorithms, we need to decide whether they are specified in the certificate and CRL processing document, or in the algorithms document. (See slides for more details.) We should be able to go to WG last call very soon on these documents.
Qualified Certificates (S. Santesson-AddTrust)
Discussions at this IETF meeting have resolved the few remaining points of contention with regard to this draft. Minor changes in wording will result in a new draft by the end of this week and this draft will be forwarded to the security area directors to proceed with the IESG last call.
Permanent Identifiers (D, Pinkas-Bull)
To be used only in certificates issued to individuals. Designed to track real world identity in the face of name changes, e.g., marriage or job changes within an organization. The ID is expressed as a new name type, with two components; an assigner authority and a name. The first component may be omitted, in which case the certificate Issuer is presumed to be the assigner authority. Note that a registered ID (from general name form) has the necessary property that it is globally unique, and permanent (although not directly meaningful). Thus, depending on which general name form is employed, one can compare names either within a CA domain, or globally, across all CAs. Plan for now is to proceed with it as a separate standards track document, not merged with the QC or son-of-RFC-2459 documents. (See slides for more details.)
Time Stamping Protocol (D. Pinkas-Bull)
Now on version 9. Several changes made after last call completed. Changes include definition of the serial number consistent with 2459 (can even be a hash of up to 160 bits!), change to SIA from AIA, etc. A number of minor wording changes were made, but the restriction on exclusive use of the TSA private key for signing responses has been preserved. Ready for forwarding to the IESG.
Preface to OCSPX and SCVP discussions:
As proposed at the Adelaide meeting, a small group was formed and generated a requirements document to characterize the motivations for remote validation services, to define the requirements for such services. The group did not compare the candidate protocols relative to these requirements.
OCSP Extensions (M. Myers-VeriSign)
Previous ID has expired, expunged from IETF web site. Mike argues that OCSP is the right choice for remote path processing (RPP), via the addition of extensions. Proposal is to revise RFC 2560, to fix minor problems, clarify OCPS role as a framework for remote validation services. Then, create separate documents to define extensions for remote path validation, remote path discovery, etc. So, there would not be an OCSPX document, but rather definitions for syntax and processing for standard extensions. (See slides for more details.)
D. Pinkas provided some slides addressing the parameters of remote path processing, e.g., how the requestor constrains the path processing or path construction operation. So, the format needs to be able to indicate whether the requestor wants CRLs or OCSP responses, what security policy to use in evaluating a certificate path, other constraints, etc. Denis argues that the requirements document needs to cover more of these details. However, Paul Hoffman noted that the group was not able to agree to a larger set of "requirements." (See slides for more details.)
SCVP (A. Malpani-ValiCert)
The speaker reviewed RPP requirements and what OCSP does to support part of the process. Ambarish argues that changes to OCSP to meet these extended requirements may break existing OCSP implementations, and that the code base for OCSP is small, so there is not much to leverage in building an RPP protocol. SCVP will support both ASN.1 and XML, consistent with perceived client requirements to retain data in this format. (See slides for more details.)
Attribute Certificates (S. Farrell-Baltimore)
Profile has been updated, synchronized with latest X.509 version, and has completed WG last call. It is suggested that this document reference the successor to 2459, which clears up the residual reference issues.
CMP (C. Adams-Entrust)
CMP RFC is being revised to reflect minor changes. Plan is to wait until completion of interoperability testing (in the PKI forum) to finalize changes to this document, to reflect any further clarifications that arise from this testing.
Repository Locator (P. Hallam-Baker-VeriSign)
Goal of this document is to specify a means by which one can map an RFC822 name for a user to the LDAP server where the user's certificates are stored. The proposed approach is to use the SRV record in the DNS to provide the necessary pointer. The SRV record is analogous to an MX record, but more general, supporting a list of services and matching addresses. Open questions include the internationalization of DNS (which the DNS WG will address), plus communicating conventions for access protocols (LDAP, HTTP, ...). The base document is a very small work item, because it is merely profiling the existing SRV record. Separate documents will be generated to describe each access protocol convention, e.g., LDAP, OCSP, and HTTP. Need to coordinate with LDAP WG and maybe DNS WGs on th eir plans for using SRV records for LDAP directory location. (See slides for more details.)
CMP Interoperability testing (R. Moskowitz-ICSA)
ICSA is working with PKI Forum to coordinate these interoperability tests. Three workshops have been conducted to date, with more scheduled for August and September. Various algorithms, transport protocols, POP mechanisms have been tested. A number vendors have participated. Planned public demo at NISSC in October. Experience shows that variants in CA-side implementations do cause interoperability problems, and further clarifications are needed in RFC 2510 to help resolve ambiguities. CMC interoperability testing may also be pursued in the future.
Agenda
(draft-ietf-pkix-ac509prof-04.txt)
CMP Interop Project
Certificate Profile and Public Key Algorithms Drafts
Remote Path Processing
Example of an Organisation OID
Remote Path Processing: How Should It be Done
Requirements for Remote Path Processing Services
Time Stamping Protocol (TSP)