Internet Draft Editor: Peter Gutmann draft-ietf-pkix-certstore-http-00.txt University of Auckland November 10, 2001 Expires May 2002 Internet X.509 Public Key Infrastructure Operational Protocols: Certificate Store Access via HTTP Status of this memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract The protocol conventions described in this document satisfy some of the operational requirements of the Internet Public Key Infrastructure (PKI). This document specifies the conventions for using the Hypertext Transfer Protocol (HTTP) as an interface mechanism to obtain certificates and certificate revocation lists (CRLs) from PKI repositories (although RFC 2585 covers fetching certificates via HTTP, this merely mentions that certificates may be fetched from a static URL, which doesn't provide a general-purpose interface to a certificate store). Additional mechanisms addressing PKIX operational requirements are specified in separate documents. 1. Introduction This specification is part of a multi-part standard for the Internet Public Key Infrastructure (PKI) using X.509 certificates and certificate revocation lists (CRLs). This document specifies the conventions for using the Hypertext Transfer Protocol (HTTP) as an interface mechanism to obtain certificates and certificate revocation lists (CRLs) from PKI repositories. Although RFC 2585 [RFC2585] covers fetching certificates via HTTP, this merely mentions that certificates may be fetched from a static URL, which doesn't provide any general-purpose interface capabilities to a certificate store. The conventions described in this document allows HTTP to be used as a general- purpose, transparent interface to any type of certificate store ranging from flat files through to standard databases such as Berkeley DB and relational databases, as well as traditional X.500/LDAP directories. Typical applications would include use with web-enabled relational databases (which most current databases are) or simple key/data lookup mechanisms such as Berkeley DB and its various descendants. Additional mechanisms addressing PKIX operational requirements are specified in separate documents. The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. This draft is being discussed on the "ietf-pkix" mailing list. To join the list, send a message to with the single word "subscribe" in the body of the message. Also, there is a Web site for the mailing list at . 2. HTTP Certificate Store Interface The GET method is used in combination with a query URI to retrieve certificates from the underlying certificate store [RFC2068]. The parameters for the query URI are a certificate identifier consisting of an attribute type and a value which specifies one or more certificates to be returned from the query. The query URI may be specified in a certificate AuthorityInfoAccess extension or configured at the client (see section 3). Permitted attribute types and associated values are: Attribute Value --------- ----- email Email address contained in the certificate, typically as an rfc882Name attribute. iHash base64-encoded SHA-1 hash of the certificate's issuerName. iAndSHash base64-encoded SHA-1 hash of the certificate's issuerAndSerialNumber [RFC2630]. name CommonName contained in the certificate. sHash base64-encoded SHA-1 hash of the certificate's subjectName. sKID base64-encoded certificate subjectKeyIdentifier. [Another possible identifier is the SHA-1 cert hash ("fingerprint") which isn't required directly to find a cert but may be required by some ancillary PKI protocols which identify certs in this manner] The full URI is formed by concatenating the query URI and the attribute and value. Certificates are retrieved from one query URI (the certificate URI) and CRLs from another query URI (the CRL URI). These may or may not correspond to the same certificate store (the exact interpretation is a local configuration issue). The form of the complete URI is therefore: '?' '=' Certificate URIs MUST support retrieval by all of the above attribute types. CRL URIs MUST support retrival by the iHash and sKID attribute types, which identify the issuer of the CRL. If more than one certificate matches a query, it MUST be returned as a multipart response. [Or a SEQUENCE OF Certificate? This has the advantage that it takes a lot less code to parse, OTOH it may be harder to produce if what you're using is a web-enabled RDBMS, which is what most of them are] In some instances servers may return HTTP type 3xx redirection requests to redirect queries to another server. Clients receiving this response SHOULD use the returned URI to replace their existing one and resubmit the query to the new server. Other information such as naming conventions and MIME types are specified in [RFC2585]. 2.1 Examples To fetch all certificates useful for sending encrypted email to foo@bar.com: GET /search-cgi?email=foo@bar.com HTTP/1.0 (in this case "/search-cgi" is the abs_path portion of the query URI, and the request is submitted to the server located at the net_loc portion of the query URI). To fetch the CA certificate which issued the email certificate: GET /search-cgi?iHash= HTTP/1.0 Alternatively, if chaining is by key identifier: GET /search-cgi?sHash= HTTP/1.0 To fetch other certificates belonging to the same user as the email certificate: GET /search-cgi?sHash= HTTP/1.0 To fetch the CRL for the certificate: GET /search-cgi?iHash= HTTP/1.0 2.2 Rationale The identifiers are taken from PKCS #15 [PKCS15], a standard which covers (among other things) a transparent interface to a certificate store. These identifiers have been field proven through having been in common use for a number of years, typically via PKCS #11 [PKCS11]. Certificate stores and the identifiers which are required for typical certificate lookup operations are analysed in some detail in [Gutmann]. The query types have been specifically chosen to be not just an HTTP interface to LDAP but as a general-purpose retrieval mechanism which allows arbitrary certificate storage mechanisms (with a bias towards simple key/data stores, which are deployed almost universally, whether as ISAM, Berkeley DB, or an RDBMS) to be employed as back-ends. Hashes are used for arbitrary-length fields such as ones containing DNs in place of the full field to keep the length manageable. In addition the use of the hashed form emphasizes the fact that searching for structured name data isn't a supported feature, since this is a simple interface to a key/data certificate store rather than an HTTP interface to an X.500 directory. Users specifically requiring an HTTP interface to X.500 may use technology such as web2ldap for this purpose. The attributes are given shortened name forms (for example iAndSHash in place of issuerAndSerialNumberHash) in order to keep the lengths reasonable, or common name forms (for example email in place of rfc822Name, rfc822Mailbox, emailAddress, mail, email, etc etc) where multiple name forms exist. Certificate and CRL stores are allocated separate URIs because they may be implemented using different mechanisms. A certificate store typically contains large numbers of small items while a CRL store contains a very small number of potentially large items, by providing independant URIs it's possible to implement the two stores using mechanisms tailored to the data they contain. This access mechanism is similar to the PGP HKP protocol, however the latter is almost entirely undocumented and requires implementors to reverse-engineer other implementations. Because of this lack of standardisation, no attempt has been made to ensure interoperability or compatibility with HKP-based servers. One benefit which HKP brings is extensive implementation experience, which indicates that this is a very workable solution to the problem of a simple key/certificate retrieval mechanism. HKS servers have been implemented using flat files, Berkeley DB, and various databases such as Postgres and MySQL. 3. Locating HTTP Certificate Stores In order to convey to relying parties a well-known point of information access, CAs SHALL provide the capability to include the AuthorityInfoAccess extension [RFC2459] in certificates. Alternatively, the accessLocation for the HTTP certificate store MAY be configured locally at the client. The OID value for the accessMethod is one of: id-ad-http-certs OBJECT IDENTIFIER ::= { id-ad 3 } id-ad-http-crls OBJECT IDENTIFIER ::= { id-ad 4 } [NB: These are provisional values] and the corresponding accessLocation is the query URI. This provides a CA with a convenient place to indicate where further certificates may be found, for example for path construction. Note that it doesn't mean that this service is limited to CAs only. 4. Security Considerations HTTP caching proxies are common on the Internet, and some proxies may not check for the latest version of an object correctly. [RFC2068] specifies that responses to query URLs should not be cached, and most proxies and servers correctly implement the "Cache-Control: no-cache" mechanism which can be used to override cacheing, however in the rare instance in which an HTTP request for a certificate or CRL goes through a misconfigured or otherwise broken proxy, the proxy may return an out-of-date response. Author Address Peter Gutmann University of Auckland Private Bag 92019 Auckland, New Zealand pgut001@cs.auckland.ac.nz References Gutmann A Reliable, Scalable General-purpose Certificate Store, P.Gutmann, Proceedings of the 16th Annual Computer Security Applications Conference, December 2000. PKCS11 Cryptographic Token Interface Standard, RSA Laboratories, December 1999. PKCS15 Cryptographic Token Information Syntax Standard, RSA Laboratories, June 2000. RFC2068 Hypertext Transfer Protocol -- HTTP/1.1, J. Gettys, J. Mogul, H. Frystyk, and T. Berners-Lee, January 1997. RFC2119 Key Words for Use in RFCs to Indicate Requirement Levels, S.Bradner, March 1997. RFC2459 Internet X.509 Public Key Infrastructure: Certificate and CRL Profile, R. Housley, W. Ford, W. Polk, and D. Solo, January 1999. RFC2585, Internet X.509 Public Key Infrastructure: Operational Protocols: FTP and HTTP, R. Housley and P. Hoffman, May 1999 Full Copyright Statement Copyright (C) The Internet Society 2001. All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.