to implement the two stores using mechanisms tailored to the data theycontain.This access mechanism is similar to the PGP HKP protocol, however the latteris almost entirely undocumented and requires implementors to reverse-engineerother implementations.  Because of this lack of standardisation, no attempthas been made to ensure interoperability or compatibility with HKP-basedservers.  One benefit that HKP brings is extensive implementation experience,which indicates that this is a very workable solution to the problem of asimple key/certificate retrieval mechanism.  HKP servers have been implementedusing flat files, Berkeley DB, and various databases such as Postgres andMySQL.3. Locating HTTP Certificate StoresIn order to locate servers from which certificates may be retrieved, relyingparties can employ one or more of the following strategies:  Information contained in the certificate  Use of a "well-known" location  Manual configuration of the client softwareThe intent of the various options provided here is to make the certificatestore access as transparent as possible, only requiring manual userconfiguration as a last resort.3.1 Information in the CertificateIn order to convey to relying parties a well-known point of informationaccess, CAs MAY use of the SubjectInfoAccess (SIA) and AuthorityInfoAccess(AIA) extension [RFC3280] in certificates.  The OID value for the accessMethodis one of:  id-ad-http-certs     OBJECT IDENTIFIER ::= { id-ad 6 }  id-ad-http-crls      OBJECT IDENTIFIER ::= { id-ad 7 }and the corresponding accessLocation is the query URI.This provides a CA with a convenient place to indicate where furthercertificates may be found, for example for path construction purposes.  Notethat it doesn't mean that the provision of certificate store access servicesis limited to CAs only.3.2 Use of a "well-known" LocationIf no other location information is available, the certificate store interfacemay be located at a "well-known" location constructed from the serviceprovider's domain name.  In the usual case the URI is constructed byprepending the type of information to be retrieved, either "certificates." or"crls.", to the domain name to obtain the net_loc portion of the URI andappending a fixed abs_path portion "search.cgi".  The URI form of the "well-known" location is therefore:  certificates.<domain_name>/search.cgi  crls.<domain_name>/search.cgiService providers SHOULD use these URIs in preference to other alternatives.A second case occurs when the certificate access service is being provided byweb-enabled embedded devices such as Universal Plug and Play devices [UPNP].These devices have a single, fixed net_loc (either an IP address or a DNSname) and makes services available via an HTTP interface.  In this case theURI is constructed by appending a fixed abs_path portion"certificates/search.cgi" for certificates and "crls/search.cgi" for CRLs tothe net_loc.  The URI form of the "well-known" location is therefore:  <net_loc>/certificates/search.cgi  <net_loc>/crls/search.cgiIf certificate access as described in this document is implemented by thedevice then it SHOULD use these URIs in preference to other alternatives (seethe rationale for more on this requirement).3.2.1 ExamplesIf a CA with the domain kiwisign.com were to make its certificates availablevia an HTTP certificate store interface, the "well-known" query URIs forcertificates and CRLs would be:  certificates.kiwisign.com/search.cgi  crls.kiwisign.com/search.cgiA home automation controller with IP address 192.168.1.1 (a control point inUPNP terminology) would make certificates for devices such as HVACcontrollers, lighting and appliance controllers, and fire and physicalintrusion detection devices available as:  192.168.1.1/certificates/search.cgi  192.168.1.1/crls/search.cgiA print server with DNS name "printspooler" would make certificates for web-enabled printers that it communicates with available as:  printspooler/certificates/search.cgi  printspooler/crls/search.cgi3.3 Manual Configuration of the Client SoftwareThe accessLocation for the HTTP certificate/CRL store MAY be configuredlocally at the client.  This can be used if no other information is available,or if it is necessary to override other information.3.4 Implementation NotesThe well-known location option can frequently be automatically derived by usersoftware from currently-known parameters.  For example if the recipient'semail address is @hotmail.com, the user software would go tocertificates.hotmail.com and request the certificate.  If the recipient workedfor a government department, the certificate would be requested atcertificates.departmentname.gov.  In addition user software may maintain alist of known certificate sources in the way that known CA lists aremaintained by web browsers.  The specific mention of support for redirectionin section 2 emphasises the fact that many sites will outsource thecertificate-storage task.  At worst all that will be required is the additionof a single static web page pointing to the real server.  Alternatives such asDNS CNAME RRs are obviously also possible, but aren't quite as easy to set upas HTTP redirects and won't work well across domains.Implementations that require the use of nonstandard locations or ports orHTTPS rather than HTTP in combination with well-known locations should use anHTTP redirect at the well-known location to point to the nonstandard location.For example if the print spooler in section 3.2 used an SSL-protected servernamed printspooler-server with an abs_path portion of cert_access, it woulduse an HTTP 302 redirect to https://printspooler-server/cert_access.  Thiscombines the plug-and-play capability of well-known locations with the abilityto use nonstandard locations and ports.A single server can be used to handle both CRLDP and AIA/SIA queries providedthe CRLDP form uses an HTTP URI.  Since CRLDP points to a single staticlocation for a CRL, a query can be pre-constructed and stored in the CRLDPextension.  Software that uses the CRLDP will retrieve the single CRL thatapplies to the certificate from the server, and software that uses theAIA/SIA can retrieve any CRL from the server.  Similar pre-constructed URIsmay also be useful in other circumstances, for example for links on web pages,to place in appropriate locations like the issuerAltName, or even for techsupport staff to email to users who can't find the certificate themselves.3.5 RationaleThe SIA and AIA extensions are used to indicate the location for the CRL storeinterface rather than the CRLDistributionPoint (CRLDP) extension since the twoperform entirely different functions.  A CRLDP contains "a pointer to thecurrent CRL", a fixed location containing a CRL for the current certificate,while the SIA/AIA extension indicates "how to access CA information andservices for the subject/issuer of the certificate in which the extensionappears", in this case the CRL store interface that provides CRLs for anycertificates issued by the CA.  In addition CRLDP associates other attributeinformation with a query that is incompatible with the simple query mechanismspresented in this document.The well-known location URI is designed to make hosting options as flexible aspossible.  Locating the service at www.<domain name> would generally requireit to be handled by the provider's main web server, while using a distinctserver URI allows it to handled as desired by the provider.  Although therewill no doubt be servers that implement the interface using Apache and Perlscripts, a more logical implementation would consist of a simple networkinterface to a key-and-value lookup mechanism such as Berkeley DB.  The URIform presented in section 3.2 allows for maximum flexibility, since it willwork with both web servers/CGI scripts and non-web-server-based network front-ends for certificate stores.Web-enabled (or more strictly HTTP-enabled) devices are intended to be plug-and-play, with minimal (or no) user configuration necessary.  The "well-known"URI allows any known device (for example one discovered via UPNP's SimpleService Discovery Protocol) to be queried for certificates without requiringfurther user configuration.Protocols such as UPnP have their own means of disseminating device andprotocol information.  For example, UPnP uses SOAP, which provides aGetPublicKeys action for pulling device keys and a PresentKeys action forpushing control point keys.  The text in section 3.2 is not meant to implythat this document overrides the existing UPnP mechanism, but merely that if adevice implements the mechanism describe here, it should use the naming schemein section 3.2 rather than using arbitrary names.4. Security ConsiderationsHTTP caching proxies are common on the Internet, and some proxies may notcheck for the latest version of an object correctly.  [RFC2068] specifies thatresponses to query URLs should not be cached, and most proxies and serverscorrectly implement the "Cache-Control: no-cache" mechanism that can be usedto override cacheing ("Pragma: no-cache" for HTTP 1.0), however in the rareinstance in which an HTTP request for a certificate or CRL goes through amisconfigured or otherwise broken proxy, the proxy may return an out-of-dateresponse.Care should be taken to ensure that only valid queries are fed through to thebackend used to retrieve certificates.  Allowing an attacker to submitarbitrary queries may allow them to manipulate the certificate store inunexpected ways if the backend tries to interpret the query contents.  Forexample if a certificate store is implemented using an RDBMS in which the SQLquery is built up as "SELECT certificate FROM certificates WHERE iHash = " +<search key> and <search key> is set to "X;DELETE FROM certificates" theresults of the query will be quite different from what was expected by thecertificate store administrator.  The same applies to queries by name andemail address.Alongside filtering of queries, the backend should be configured to disableany form of update access via the web interface.  For Berkeley DB thisrestriction can be imposed by opening the certificate store in read-only modefrom the web interface.  For relational databases, it can be imposed throughthe SQL GRANT/REVOKE mechanism, for example "REVOKE ALL ON certificates FROMwebuser; GRANT SELECT ON certificates TO webuser" will allow read-only accessof the appropriate kind for the web interface.4. IANA ConsiderationsThe AIA/SIA accessMethod types are identified by object identifiers (OIDs).OIDs were assigned from an arc contributed to the PKIX Working Group by RSASecurity.  Should additional accessMethods be introduced (for example forattribute certificates or non-X.509 certificate types), the advocates for suchaccessMethods are expected to assign the necessary OIDs from their own arcs.No action by the IANA is necessary for this document or any anticipatedupdates.Author AddressPeter GutmannUniversity of AucklandPrivate Bag 92019Auckland, New Zealandpgut001@cs.auckland.ac.nzReferences  [Gutmann] "A Reliable, Scalable General-purpose Certificate Store", P.            Gutmann, Proceedings of the 16th Annual Computer Security            Applications Conference, December 2000.  [Heidemann] "Performance Interactions Between P-HTTP and TCP              Implementations", J.Heidemann, ACM Computer Communications              Review, April 1997.  [Nielsen] "Network Performance Effects of HTTP/1.1, CSS1, and PNG",            H.Nielsen, J.Gettys, A.Baird-Smith, E.Prud'hommeaux, H.Wium Lie,            and C.Lilley, 24 June 1997,            http://www.w3.org/Protocols/HTTP/1.0/Performance/Pipeline.html.  [PKCS11] PKCS #11 Cryptographic Token Interface Standard, RSA Laboratories,           December 1999.  [PKCS15] PKCS #15 Cryptographic Token Information Syntax Standard, RSA           Laboratories, June 2000.  [RFC1866] "Hypertext Markup Language - 2.0", RFC 1866, T. Berners-Lee and D.            Connolly, November 1995.  [RFC2068] "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, J. Gettys, J.            Mogul, H. Frystyk, and T. Berners-Lee, January 1997.  [RFC2119] "Key Words for Use in RFCs to Indicate Requirement Levels",            RFC 2119, S.Bradner, March 1997.  [RFC3280] "Internet X.509 Public Key Infrastructure: Certificate and CRL            Profile", RFC 3280, R. Housley, W. Ford, W. Polk, and D. Solo,            April 2002.  [RFC2585] "Internet X.509 Public Key Infrastructure: Operational Protocols:            FTP and HTTP", RFC 2585, R. Housley and P. Hoffman, May 1999  [Spero] "Analysis of HTTP Performance Problems", S.Spero, July 1994,          http://www.w3.org/Protocols/HTTP/1.0/HTTPPerformance.html.  [UPNP] "Universal Plug and Play Device Architecture, Version 1.0", UPnP         Forum, 8 June 2000.Full Copyright StatementCopyright (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 itsimplementation may be prepared, copied, published and distributed, in whole orin part, without restriction of any kind, provided that the above copyrightnotice and this paragraph are included on all such copies and derivativeworks. However, this document itself may not be modified in any way, such asby removing the copyright notice or references to the Internet Society orother Internet organizations, except as needed for the purpose of developingInternet standards in which case the procedures for copyrights defined in theInternet Standards process must be followed, or as required to translate itinto languages other than English.The limited permissions granted above are perpetual and will not be revoked bythe 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 FORCEDISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANYWARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTSOR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULARPURPOSE.