Last Modifield: 05/20/2002
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||Complete data certification document|
|Done||Continue attribute certificate profile work|
|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||Production of revised certificate and CRL syntax and processing RFC (son-of-2459)|
|Done||INFORMATIONAL RFCs for X.509 PKI policies and practices, use of KEA|
|Done||Experimental RFC for Data Validation and Certification Server Protocols|
|MAR 02||Logotype Extension RFC|
|MAR 02||Proxy Certificate RFC|
|APR 02||Progression of CRMF, CMP, and CMP Transport to DRAFT Standard|
|APR 02||Production of revised CMC RFCs (updates and split of CMC into several parts)|
|APR 02||DPD/DVP Requirements RFC|
|APR 02||DPV/DPD Protocols WG last call|
|JUL 02||Progression of CMC RFCs to DRAFT Standard|
|DEC 02||DPV/DPD RFC(s)|
|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)|
|RFC3280||PS||Internet X.509 Public Key Infrastructure Certificate and CRL Profile|
|RFC3279||PS||Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and CRI Profile|
|RFC3281||PS||An Internet Attribute Certificate Profile for Authorization|
PKIX WG Meeting 11/20/02 Edited by Steve Kent Chairs: Stephen Kent <email@example.com>, Tim Polk <firstname.lastname@example.org> The PKIX WG met once during the 55rd IETF. A total of approximately 97 individuals participated in the meeting. Tim Polk began with a review of the agenda and document status. [see slides] Logotypes in X.509 Certificates - Stefan Santesson (AddTrust) Add specifications to require at least one logotype that fits within specified size ranges, and if audio files are present at least one should be within a specified time duration. Straw poll of attendees supports guidelines for these features, vs. compliance requirements relative to certificate contents. Will confirm this consensus via the list. Another observation is that these may be guidelines for certificate contents, but we ought to impose conformance requirements on the clients that consume certificates, to ensure that they can display logotypes (and play audio files) within some bounds. A suggestion was made that clients should be required to allow users to suppress playing audio files and suppress fetching the files that might be referenced by URIs in this extension, and the authors agreed to incorporate this requirement. [see slides] Discussion of competing protocols to become the standard protocol for DPD/DPV. CVP- Tim Polk (NIST) presenting for Denis Pinkas (Bull) Basically, this protocol is designed to be able to do more than meet the requirements defined in 3279, but Denis (as the author of that RFC) asserts that CVP is complaint with the requirements RFC. The slides compare CVP features with SCVP features. [see slides] SCVP Protocol - Russ Housely (Vigil Security) Now on draft 10, which has been discussed extensively on the list. Presentation addressed open issues raised in on-list discussion. [see slides] OCSP Mike Myers (TraceRoute Security) No slides. Strategy here is to use extension facility to support DPV/DPD requirements, building on OCSP. The document will be refreshed and reposted with the description of extensions to provide this support. DCVS is the fourth candidate. It is RFC 3029, an experimental track RFC. It is designed to provide a wide range of services, including those that we now characterize as DPV/DPD. Proxy Certificates Von Welch (Argonne Labs) Document is also being worked on in Global Grid Forum. The biggest residual problem is that the path validation algorithm rejects these certificates since the end users are not CAs. One suggestion is to validate the path up to but not including the proxy certificate, then invoke path validation only for the proxy certificate, with a temporary trust anchor based on the user certificate that acted as the issuer of the proxy certificate. This would be consistent with the RFC 3280 path validation process, and might be consistent with the need for the application to perform the additional checks specified for a proxy certificate. A possible concern is that one needs to ensure that the trust anchor inserted for this process is not retained and thus might inappropriately affect later path validation invocations. Audience comments support the principle of not modifying the RFC 3280 algorithm, though with varying rationales. The TLS WG chair suggests that this really should be done in the TLS context, i.e., using the IETF standard. [see slides] LDAP Schema - Peter Gietz (DASSI International) LDAP lacks matching rules support to allow selection of certificates and CRLs based on specifying values for fields in these data items (when multiple certificates or CRLs are stored in the same LDAP entry). This approach is a metadata solution; it extracts the data from certificates and CRLs and replicates the data as a set of new attributes in the LDAP database, making them suitable as search parameters. Clients need to be configured with the new schema, to allow searching based on this approach. This is a personal draft; the question is whether it belongs in PKIX? A cited concern here is that this schema approach We will take up the question on the list. [see slides] Attribute Certificate Chris Francis (WebSecure Technologies) A new extension for attribute certificates that explicitly states the policies employed on issuing the certificate, analogous to the certificatePolices extension in public key certificates, and uses similar syntax. Has policy qualifiers to allow an AA to specify that attributes were verified at a time that might be significantly earlier than the issuance date, implying that the attributes were not re-verified at the time of reissuance. (WS chair note: Is this a thing we wish to encourage by providing syntax for it?) Certificate Warranty Extension - Alice Sturgeon (Spyrus) This extension provides explicit data about warranties provided by the CA, including an explicit declaration of no warranty. It's a non-critical extension. This is important, because it allows one to include warranty info that can be ignored, while also putting in critical policy info. This combination of critical and non-critical "policy" info could not otherwise be accommodated. A revised ID will be posted soon. [see slides] OCSPv2 - Mike Myers (TraceRoute Security) Update of v1 document to add additional means of referring to a certificate and offers a means by which a client can provide a pointer to a CRL to check. Subject Identification Method - Park Jong-Wook - (Korean Information Security Agency) Goal is to provide a way to represent a personal ID value (e.g., national ID number) in a certificate in a way that does not disclose its value, for privacy reasons. The proposal also includes a protocol for transferring this data to the CA. The proposed virtual ID (VID), is computed by double hashing the personal ID value with a 160-bit random number (R), and symmetrically encrypting the result, using R as a key. Looking for feedback. [see slides] JNSA Challenge PKI 2002 -- An Approach to a Multi-Domain PKI Test Suite" - Ryu Inada (Japan Network Security Association) This is a report on the interoperability testing activities in Japan, in September. This is not a PKIX activity but the results of testing are of interest, e.g., in terms of uncovering interop/specification problems with PKIX standards. Test environment includes CAs and VAs capable of generating data for test cases, some of which intentionally do not conform to PKIX standards. We are awaiting an English translation of the underlying documents. [see slides]