Last Modified: 2005-09-20
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 2005 | Certificate Store approved as Informational RFC | |
Jun 2005 | PKIX Repository approved as Informational RFC | |
Jul 2005 | ECC Algorithms approved as PROPOSED Standard RFC | |
Jul 2005 | SCVP approved as PROPOSED Standard RFC | |
Sep 2005 | Progression of CMC RFCs to DRAFT Standard | |
Sep 2005 | Progression of Qualified Certificates Profile RFC to DRAFT Standard | |
Sep 2005 | Progression of Certificate & CRL Profile RFC to DRAFT Standard | |
Sep 2005 | Progression of Time Stamp Protocols RFC to DRAFT Standard | |
Sep 2005 | Progression of Logotype RFC to DRAFT Standard | |
Sep 2005 | Progression of Proxy Certificate RFC to DRAFT Standard | |
Sep 2005 | Progression of Attribute Certificate Profile RFC to DRAFT standard | |
Sep 2005 | OCXSPv2 Extensions approved as PROPOSED Standard RFC | |
Sep 2005 | Subject Identification Method as Informational RFC | |
Jan 2006 | Progression of CRMF, CMP, and CMP Transport to DRAFT Standard | |
Jan 2006 | 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 |
RFC4158 | I | Internet X.509 Public Key Infrastructure: Certification Path Building |
RFC4210 | Standard | Internet X.509 Public Key Infrastructure Certificate Management Protocols |
RFC4211 | Standard | Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF) |
PKIX WG Meeting
11/7/05 Edited by Steve Kent Chairs: Stephen Kent <kent@bbn.com> & Tim Polk
<tim.polk@nist.gov> The PKIX WG met once during the 64th IETF. A total of approximately
45 individuals participated in the meeting. Document status – Tim Polk (NIST) Three RFCs just issued: 4158, 4210, and
4211. Three documents in the RFC editorŐs
queue: CertStore HTTP, 3770bis, and CRL AIA. Two documents with the ADs: AC Policies
& PKIX Repository Locator. Other documents: -
SIM is undergoing revisions to address WG co-chair comments before being
forwarded to the IESG. -
The authors of SCVP are being asked to create a matrix. -
A new version of 3280bis will be submitted after this meeting. -
The WG chairs have requested a new version of the GOST algorithms to be posted,
before initiating a last call. (Slides) PKIX WG Document Presentations RFC
2797bis, CMC transport, and CMC Compliance - Jim Schaad (Soaring Hawk) Last
call will be initiated for all three after this meeting. Updates include
features to allow support for SIM certificate requests. (Slides) SCVP
rev 21- David Cooper (NIST) Text
was added to clarify conformance requirements. WantBack items were made optional.
New, optional items were added to allow an SCVP server to relay responses from
other SCVP servers, and to label responses with an identity specified by a
requestor, if the server has multiple identities. The reference to validation
policies was tightened, so that only OIDs, not URIs, are accepted. Policy
parameters, in addition to validation algorithm parameters, are now supported,
but the optional validation policy attributes were removed, since no examples
have been provided and the need for this facility was not well established. The
one remaining problem here is how to make this protocol agile with regard to
the hash algorithm employed for certificate references. Today SHA-1 is
hardwired. Updating the spec to specify another hash function does not satisfy
the new algorithm agility requirement. Steve Kent suggested that the hash
function can be an aspect of the serverŐs validation policy, to satisfy the
agility requirement. Russ Housley suggested that the OID of the hash employed
be explicitly returned, in case the serverŐs policy changes over time (but the
policy OID does not). A straw poll was conducted to get a sense of the room for
the two alternatives described in the last slide in this presentation. The
first alternative received 12 votes, vs. 0 for the second. (Slides) SHA-1
Collisions & OCSP - Russ Housley (Vigil Security) Based
on the recent NIST hash workshop, Russ suggests that we begin making plans to
move away from SHA-1, with a 2010
target for transition. NIST will begin work on a successor to SHA-256, but a
new algorithm may be 5 years away. The only good alternative now is SHA-256. From
an algorithm agility perspective, OCSP request/response exchange needs to
provide a way for the requestor to know which algorithms the responder (server)
supports. This could be supported by adding a new protocol to negotiate the
hash algorithm prior to entering into the OCSP exchange. Alternatively, the
responderŐs certificate could have an extension that specified supported hash
algorithms. This also might be addressed via configuration at the requestor,
although this is problematic given the intent of changing the algorithm twice
over the next 10 years. Russ suggests a request extension that allows the
requestor to specify which hash functions (and signature algorithms) it
supports. There is still a need to select one of the three approaches cited
above, to allow a requestor to determine which algorithms are supported by the
responder. Russ
suggests that the WG find volunteers to update OCSP, and to examine other PKIX
protocols to determine whether they exhibit similar problems and, if so, how to
fix them. Stephen Farrell asks whether there may be a way to solve this problem
more generically, rather than engineering a solution for each protocol in PKIX,
and in other WGs. (Slides) SHA-2
Support in PKIX – Tim Polk (NIST) We
currently specify how to use SHA-2 (SHA-256 & SHA-512) for RSA (RFC 4055),
but not for DSA or EC-DSA. Tim suggests that two new drafts be generated, one
for DSA and one for ECDSA, because the two algorithms are at different stages
of NIST publication. NIST has volunteered to write these two drafts, but
additional co-editors are welcome. (Slides) Service
Names as Subject Alt Names - Stefan Santesson (Microsoft) The
draft has been revised since its initial version. It no longer is bound as
tightly to the DNS SRV record example. The assumption here is that the user
(host) knows the service name and domain name and determines whether the server
to which it connects is appropriate, based on the serverŐs certificate. Steve
Kent suggests that we need to revisit the security implications of use of this
facility, given the revised definition of the use model. Stefan suggests that
use of name constraints for this extension may be appropriate. Since the string
comparison is against the locally configured service name, not the DNS SRV
string, UTF8 seems to be the right encoding choice. The WG Chairs and Russ
agreed, after the meeting, to assign an OID for this OtherName. (Slides) Related Specifications & Liaison
Presentations Carl
Wallace (Orion Security) – LTANS WG status LTANS
is meeting the same day (in the same room) at this IETF. Carl requests review
by PKIX WG members of the evidence record I-D and an archive protocol I-D from
LTANS. Note potential relationships between SCVP and LTNANS work. (no slides) |