Last Modified: 2005-06-30
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) | |
Done | Logotype Extension RFC | |
Done | Proxy Certificate RFC | |
Done | Cert Path Building approved as Informational RFC | |
Done | CRMFbis approved as PROPOSED Standard RFC | |
Done | CMPbis approved as PROPOSED Standard RFC | |
Done | Principal Identifier approved as PROPOSED Standard RFC | |
Done | Warranty Extensions approved as Informational RFC | |
Jun 05 | Certificate Store approved as Informational RFC | |
Jun 05 | PKIX Repository approved as Informational RFC | |
Jul 05 | ECC Algorithms approved as PROPOSED Standard RFC | |
Jul 05 | SCVP approved as PROPOSED Standard RFC | |
Sep 05 | Progression of CMC RFCs to DRAFT Standard | |
Sep 05 | Progression of Qualified Certificates Profile RFC to DRAFT Standard | |
Sep 05 | Progression of Certificate & CRL Profile RFC to DRAFT Standard | |
Sep 05 | Progression of Time Stamp Protocols RFC to DRAFT Standard | |
Sep 05 | Progression of Logotype RFC to DRAFT Standard | |
Sep 05 | Progression of Proxy Certificate RFC to DRAFT Standard | |
Sep 05 | Progression of Attribute Certificate Profile RFC to DRAFT standard | |
Sep 05 | OCXSPv2 Extensions approved as PROPOSED Standard RFC | |
Sep 05 | Subject Identification Method as Informational RFC | |
Jan 06 | Progression of CRMF, CMP, and CMP Transport to DRAFT Standard | |
Jan 06 | Progression of SCVP to Draft Standard |
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 | 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 |
RFC2560 | PS | X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP |
RFC2585 | PS | Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP |
RFC2587 | PS | Internet X.509 Public Key Infrastructure LDAPv2 Schema |
RFC2797 | PS | Certificate Management Messages over CMS |
RFC2875 | PS | Diffie-Hellman Proof-of-Possession Algorithms |
RFC3029 | E | Internet X.509 Public Key Infrastructure Data Validation and Certification Server Protocols |
RFC3039 | PS | Internet X.509 Public Key Infrastructure Qualified Certificates Profile |
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 |
RFC3709 | Standard | Internet X.509 Public Key Infrastructure: Logotypes in X.509 certificates |
RFC3739 | Standard | Internet X.509 Public Key Infrastructure: Qualified Certificates Profile |
RFC3770 | Standard | Certificate Extensions and Attributes Supporting Authentication in PPP and Wireless LAN |
RFC3779 | Standard | X.509 Extensions for IP Addresses and AS Identifiers |
RFC3820 | Standard | Internet X.509 Public Key Infrastructure Proxy Certificate Profile |
RFC3874 | I | A 224-bit One-way Hash Function: SHA-224 |
RFC4043 | Standard | Internet X.509 Public Key Infrastructure Permanent Identifier |
RFC4055 | Standard | Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile |
RFC4059 | I | Internet X.509 Public Key Infrastructure Warranty Certificate Extension |
PKIX WG Meeting 8/2/05
Edited by Steve Kent Chairs: Stephen Kent <kent@bbn.com> & Tim Polk <tim.polk@nist.gov> The PKIX WG met once during the 63nd IETF. A total of approximately 53 individuals participated in the meeting. Document status - Tim Polk (NIST) Two new RFCs (PK Algorithms and Permanent Identifier) have been issued since the last meeting. Four additional documents have been approved by the IESG and are in the RFC editor's queue (Certificate path building, warranty extension, 2510bis and 2511bis). Three documents are being reviewed by the ADs (AC policies, CertStire HTTP, and 3770bis). CRL AIA is in IESG last call. WG last call for SIM will be initiated after this IETF meeting. More detailed discussions of 3280bis and SCVP will follow. (see slides) PKIX WG Document Presentations SRV RR otherName - Stefan Santesson (Microsoft) This individual submission is being adopted by PKIX. The proposal specifies a way to embed a service name in a certificate, employing the syntax used to identify a service in DNS SRV records. The intent is to securely bind the DNS-specified service to a named entity, using the otherName type of GeneralName to carry the specified SRV RR query string. Denis noted that this proposal is a somewhat odd use of the subject alt name, in that the string is not the name of the certificate subject, but the name of a service provided by this subject. Instead he proposed use of the subject directory attributes extension. Others objected to this specific way of binding service authorization info to a certificate, vs. other approaches, e.g., EKU, or other subject alt name forms. There was general agreement that the proposal needs to be carefully vetted by DNS experts. (see slides) Simple Certificate Validation Protocol (SCVP) - Tim Polk (NIST) IPR issues have been resolved since the last IETF meeting. Russ Housely said that CoreStreet indicated that compliant SCVP implementations could be developed that would not infringe their patents. However, Russ also reminded attendees that ultimately each vendor needs to evaluate the formal, legal statements from CoreStreet. The base specification has not changed significantly since the -18 draft. The draft meets most of the requirements specified in RFC 3379, but return of (relayed) SCVP responses was not included. This will be fixed in the next draft. Also, the conformance requirements seem to impose undue burdens on all clients, contrary to the goal of supporting thin clients. Remaining open issues will be discussed on the list, e.g., syntax details. (see slides) SCVP Open Issues - Denis Pinkas (Bull) Denis emphasizes the need for thin clients, e.g., on cell phones, to be supported. Denis suggested that several OPTIONAL fields should be omitted to facilitate thin client support. However, because these are optional, it appears that the document can be worded to ensure that they impose no burden on a client that does not wish to invoke them. Denis would like to see a facility to allow per-trust anchor validation parameters, obviously not for thin clients, since only a sophisticated client would be able to take advantage of this facility. Denis also would like to represent both the validation policy and validation algorithm into a single OID. It was agreed that the URI pointer to a policy will be deleted. Is also was agreed that the terms "validation policy" and "validation algorithm" need to be better defined in the document. (see slides) 3280bis - Tim Polk (NIST) A new draft has been submitted with relatively minor enhancements. Several open issues remain to be resolved. In particular, questions involving name ambiguity have been raised, particularly as they impact CRL validation. We may deal with this issue by adding text in the security considerations section that discusses this issue. The text has been changed to clarify what conforming CAs MUST do in issuing a certificate, vs. what conforming RPs MUST do re certificate path processing. The path validation algorithm notes that it accepts paths that are X.509 compliant, but not PKIX compliant, in support of interoperability. Peter Sylvester asked whether there would be support to help him write a defect report against x.509 concerning the change of the name of the non-repudiation bit, since this change breaks applications that are based on standard ASN.1 compiler outputs (and it changes the XER encoding on the wire). (see slides) 3280bis Open Issues - Denis Pinkas (Bull) Denis reviewed seven topics that he considers open issues. He suggests that text on TA key update should be explicitly covered here, not just a reference to RFC 2510. He also suggests that we find a better compromise with the latest X.509 technical corrigendum, with respect to key usage. Denis reviewed the name ambiguity debate that has taken place on the list. He suggested that the private key usage extension not be deprecated universally, but rather be allowed in certain contexts, e.g., time stamp crypto modules. He proposed to soften the prohibition against private key usage or to delete annex D.1. (and thus annex D) which is the only section that addresses this topic. Denis asked for a simplified revocation status checking algorithm description, that addresses only the PKIX-mandated certificate extensions. He also suggests clarification of the text that says what CRLs are "available" in the local cache. Finally, Denis discussed several subtle issues associated with indirect CRLs. At the microphone a series of individuals responded to Denis's suggestions, most disagreed with one of more of his points. (see slides) Related Specifications & Liaison Presentations CMS Advanced Electronic Signatures (CAdES) - Denis Pinkas (on behalf of ETSI TC ESI) This document is based on RFC 3126 and is aligned with a re-issue of ETSI TS 101 733. CAdES is a new name, intended to distinguish it from the XML-based version spec. Denis said that the document now presents the basic electronic signature formats in the main body of the document while placing features to achieve the maintenance of long term signatures in informative annexes, thus the informative annexes may equally be interesting. (see slides) XKMS - Stephen Farrell (on behalf of W3C) This presentation noted that the XKMS specification in W3C was completed and multiple interoperable implementations have been tested. Interested PKIX members are encouraged to visit the W3C web site and review the spec. (no slides) |