Last Modified: 2004-02-18
PKIX has produced several informational and standards track documents in support of the original and revised scope of the WG. The first of these standards, RFC 2459, profiled X.509 version 3 certificates and version 2 CRLs for use in the Internet. Profiles for the use of Attribute Certificates (RFC XXXX [pending]), LDAP v2 for certificate and CRL storage (RFC 2587), the Internet X.509 Public Key Infrastructure Qualified Certificates Profile (RFC 3039), and the Internet X.509 Public Key Infrastructure Certificate Policy and certification Practices Framework (RFC 2527 - Informational) are in line with the initial scope.
The Certificate Management Protocol (CMP) (RFC 2510), the Online Certificate Status Protocol (OCSP) (RFC 2560), Certificate Management Request Format (CRMF) (RFC 2511), Time-Stamp Protocol (RFC 3161), Certificate Management Messages over CMS (RFC 2797), Internet X.509 Public Key Infrastructure Time Stamp Protocols (RFC 3161), and the use of FTP and HTTP for transport of PKI operations (RFC 2585) are representative of the expanded scope of PKIX, as these are new protocols developed in the working group, not profiles of ITU PKI standards.
A roadmap, providing a guide to the growing set of PKIX document, also has been developed as an informational RFC.
Ongoing PKIX Work items
An ongoing PKIX task is the progression of existing, standards track RFCs from PROPOSED to DRAFT. Also, to the extent that PKIX work relates to protocols from other areas, e.g., LDAP, it is necessary to track the evolution of the other protocols and produce updated RFCs. For example, the LDAP v2 documents from PKIX are evolving to address LDAP v3. Finally, since the profiling of X.509 standards for use in the Internet remains a major focus, the WG will continue to track the evolution of these standards and incorporate changes and additions as appropriate.
New Work items for PKIX
- production of a requirements RFC for delegated path discovery and path validation protocols (DPD/DPV) and subsequent production of RFCs for protocols that satisfy the requirements
- development of a logotype extension for certificates
- development of a proxy certificate extension and associated processing rules
- development of an informational document on PKI disaster recovery
These work items may become standards track, INFORMATIONAL or EXPERIMENTAL RFCs, or may not even be published as RFCs.
Other deliverables may be agreed upon as extensions are proposed. New deliverables must be approved by the Security Area Directors before inclusion on the charter or IETF meeting agendas.
|Done||Complete approval of CMC, and qualified certificates documents|
|Done||Complete time stamping document|
|Done||Continue attribute certificate profile work|
|Done||Complete data certification document|
|Done||Complete work on attribute certificate profile|
|Done||Standard RFCs for public key and attribute certificate profiles, CMP, OCSP, CMC, CRMF, TSP, Qualified Certificates, LDAP v2 schema, use of FTP/HTTP, Diffie-Hellman POP|
|Done||INFORMATIONAL RFCs for X.509 PKI policies and practices, use of KEA|
|Done||Experimental RFC for Data Validation and Certification Server Protocols|
|Done||Production of revised certificate and CRL syntax and processing RFC (son-of-2459)|
|Done||DPD/DVP Requirements RFC|
|Done||Certificate Policy & CPS Informational RFC (revision)|
|Dec 03||Progression of CMC RFCs to DRAFT Standard|
|Done||Logotype Extension RFC|
|Feb 04||Proxy Certificate RFC|
|Mar 04||SCVP proposed Standard RFC|
|Mar 04||Progression of Qualified Certificates Profile RFC to DRAFT Standard|
|Mar 04||Progression of Certificate & CRL Profile RFC to DRAFT Standard|
|Mar 04||Progression of Time Stamp Protocols RFC to DRAFT Standard|
|Mar 04||Progression of Logotype RFC to DRAFT Standard|
|Apr 04||Progression of CRMF, CMP, and CMP Transport to DRAFT Standard|
|Jun 04||Progression of Proxy Certificate RFC to DRAFT Standard|
|Jun 04||Progression of SCVP to Draft Standard|
|Jun 04||Progression of Attribute Certificate Profile RFC to DRAFT standard|
|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||I||Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework|
|RFC2528||I||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|
|RFC3161||PS||Internet X.509 Public Key Infrastructure Time Stamp Protocols (TSP)|
|RFC3279||PS||Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and CRI Profile|
|RFC3280||PS||Internet X.509 Public Key Infrastructure Certificate and CRL Profile|
|RFC3281||PS||An Internet Attribute Certificate Profile for Authorization|
|RFC3379||I||Delegated Path Validation and Delegated Path Discovery Protocol Requirements|
|RFC3628||I||Policy Requirements for Time-Stamping Authorities|
|RFC3647||I||Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework|
PKIX WG Meeting 3/1/04 Edited by Steve Kent Chairs: Stephen Kent <email@example.com> & Tim Polk <firstname.lastname@example.org> The PKIX WG met once during the 59th IETF. A total of approximately 49 individuals participated in the meeting. Agenda review and document status - Steve Kent (BBN) using slides from Tim Polk (NIST) The backlog of WG documents has subsided a bit. Several new RFCs have been issued, or will be issued soon. Logotypes was issued as RFC 3709. Proxy certificates is in the RFC editors queue as is the IP address and AS identifier document. Qualified certificates has been approved by the IESG. The warranty extension document requires revisions before being forwarded to the RFC editor. Several documents are in the hands of the ADs: permanent identifier, attribute certificate policies, extensions for wireless LANs, and repository locator service. CRMF and CMP require revisions before progressing. SCVP and PK algorithms are in WG last call. The path building and ECC (NIST curves) documents are ready for last call, and SIM is getting closer. LDAP specs, and OCSPv2 extensions are ongoing work items. Interoperability tests are being performed by several vendors, in preparation for progression of RFCs 3279/3280. Subject Identification Method - Jongwook Park (KISA) This presentation reviewed changes from previous draft, and responses to 21 comments received during WG last call. CRMF (RFC 2511bis) - Jim Schaad (Soaring Hawk Consulting) Jim took over as editor, and has made significant updates. He sees several outstanding issues yet to be resolved, that are blocking progress. Some of the POP methods appear to be vulnerable, and thus need to be dropped or fixed. Also, the DH-MAC POP algorithm should be made more algorithm generic, e.g., to accommodate ECC algorithms. Need to fix some underspecified parts of registration token, archival, and registration info features of the protocol. Will take this up on the list to determine how critical these features are, especially with regard to POP. Possible outcomes are: removal of some (or all) of these features, or fixes that address the problems. RFC 3039bis (Qualified Certificates) - Russ Housley (Vigil Security) Russ reviewed the sequence of events associated with a large number (38) of comments received from Denis Pinkas during the IETF Last Call for this document. At this point there are only five comments outstanding, and all are essentially editorial in nature. However, if the document is to be changed to accommodate these remaining changes, it will be necessary to reprocess the document through a 7-step process. Thus the WG has a choice: option 1: it can proceed with the document in its current form; option 2: it can make the suggested changes, and proceed with the 7-setp process Russ outlined. Russ asked for a show of hands from attendees as to which option was preferred. Russ invited comments from the floor on the choices, and several individuals expressed the opinion that the first three comments are trivial editorial changes that could be made during the RFC editor's 48-hour final revision interval. Several folks expressed the opinion that the security considerations text should appear in a more general document, e.g., RFC 3280. The show of hands indicated that the attendees strongly preferred the first option, although there were a few hands in support of option two.