draft-ietf-pkix-certstore-http-03.txt

PKIX的RFC英文文档

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 that 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.  HKP 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 locate servers from which certificates may be retrieved, relying
parties 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 software

The intent of the various options provided here is to make the certificate
store access as transparent as possible, only requiring manual user
configuration as a last resort.

3.1 Information in the Certificate

In order to convey to relying parties a well-known point of information
access, CAs MAY use of the SubjectInfoAccess (SIA) and AuthorityInfoAccess
(AIA) extension [RFC3280] in certificates.  The OID value for the accessMethod
is 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 further
certificates may be found, for example for path construction purposes.  Note
that it doesn't mean that the provision of certificate store access services
is limited to CAs only.

3.2 Use of a "well-known" Location

If no other location information is available, the certificate store interface
may be located at a "well-known" location constructed from the service
provider's domain name.  In the usual case the URI is constructed by
prepending the type of information to be retrieved, either "certificates." or
"crls.", to the domain name to obtain the net_loc portion of the URI and
appending 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.cgi

Service providers SHOULD use these URIs in preference to other alternatives.

A second case occurs when the certificate access service is being provided by
web-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 DNS
name) and makes services available via an HTTP interface.  In this case the
URI is constructed by appending a fixed abs_path portion
"certificates/search.cgi" for certificates and "crls/search.cgi" for CRLs to
the net_loc.  The URI form of the "well-known" location is therefore:

  <net_loc>/certificates/search.cgi
  <net_loc>/crls/search.cgi

If certificate access as described in this document is implemented by the
device then it SHOULD use these URIs in preference to other alternatives (see
the rationale for more on this requirement).

3.2.1 Examples

If a CA with the domain kiwisign.com were to make its certificates available
via an HTTP certificate store interface, the "well-known" query URIs for
certificates and CRLs would be:

  certificates.kiwisign.com/search.cgi
  crls.kiwisign.com/search.cgi

A home automation controller with IP address 192.168.1.1 (a control point in
UPNP terminology) would make certificates for devices such as HVAC
controllers, lighting and appliance controllers, and fire and physical
intrusion detection devices available as:

  192.168.1.1/certificates/search.cgi
  192.168.1.1/crls/search.cgi

A 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.cgi

3.3 Manual Configuration of the Client Software

The accessLocation for the HTTP certificate/CRL store MAY be configured
locally 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 Notes

The well-known location option can frequently be automatically derived by user
software from currently-known parameters.  For example if the recipient's
email address is @hotmail.com, the user software would go to
certificates.hotmail.com and request the certificate.  If the recipient worked
for a government department, the certificate would be requested at
certificates.departmentname.gov.  In addition user software may maintain a
list of known certificate sources in the way that known CA lists are
maintained by web browsers.  The specific mention of support for redirection
in section 2 emphasises the fact that many sites will outsource the
certificate-storage task.  At worst all that will be required is the addition
of a single static web page pointing to the real server.  Alternatives such as
DNS CNAME RRs are obviously also possible, but aren't quite as easy to set up
as HTTP redirects and won't work well across domains.

Implementations that require the use of nonstandard locations or ports or
HTTPS rather than HTTP in combination with well-known locations should use an
HTTP 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 server
named printspooler-server with an abs_path portion of cert_access, it would
use an HTTP 302 redirect to https://printspooler-server/cert_access.  This
combines the plug-and-play capability of well-known locations with the ability
to use nonstandard locations and ports.

A single server can be used to handle both CRLDP and AIA/SIA queries provided
the CRLDP form uses an HTTP URI.  Since CRLDP points to a single static
location for a CRL, a query can be pre-constructed and stored in the CRLDP
extension.  Software that uses the CRLDP will retrieve the single CRL that
applies to the certificate from the server, and software that uses the
AIA/SIA can retrieve any CRL from the server.  Similar pre-constructed URIs
may also be useful in other circumstances, for example for links on web pages,
to place in appropriate locations like the issuerAltName, or even for tech
support staff to email to users who can't find the certificate themselves.

3.5 Rationale

The SIA and AIA extensions are used to indicate the location for the CRL store
interface rather than the CRLDistributionPoint (CRLDP) extension since the two
perform entirely different functions.  A CRLDP contains "a pointer to the
current CRL", a fixed location containing a CRL for the current certificate,
while the SIA/AIA extension indicates "how to access CA information and
services for the subject/issuer of the certificate in which the extension
appears", in this case the CRL store interface that provides CRLs for any
certificates issued by the CA.  In addition CRLDP associates other attribute
information with a query that is incompatible with the simple query mechanisms
presented in this document.

The well-known location URI is designed to make hosting options as flexible as
possible.  Locating the service at www.<domain name> would generally require
it to be handled by the provider's main web server, while using a distinct
server URI allows it to handled as desired by the provider.  Although there
will no doubt be servers that implement the interface using Apache and Perl
scripts, a more logical implementation would consist of a simple network
interface to a key-and-value lookup mechanism such as Berkeley DB.  The URI
form presented in section 3.2 allows for maximum flexibility, since it will
work 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 Simple
Service Discovery Protocol) to be queried for certificates without requiring
further user configuration.

Protocols such as UPnP have their own means of disseminating device and
protocol information.  For example, UPnP uses SOAP, which provides a
GetPublicKeys action for pulling device keys and a PresentKeys action for
pushing control point keys.  The text in section 3.2 is not meant to imply
that this document overrides the existing UPnP mechanism, but merely that if a
device implements the mechanism describe here, it should use the naming scheme
in section 3.2 rather than using arbitrary names.

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 that can be used
to override cacheing ("Pragma: no-cache" for HTTP 1.0), 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.

Care should be taken to ensure that only valid queries are fed through to the
backend used to retrieve certificates.  Allowing an attacker to submit
arbitrary queries may allow them to manipulate the certificate store in
unexpected ways if the backend tries to interpret the query contents.  For
example if a certificate store is implemented using an RDBMS in which the SQL
query is built up as "SELECT certificate FROM certificates WHERE iHash = " +
<search key> and <search key> is set to "X;DELETE FROM certificates" the
results of the query will be quite different from what was expected by the
certificate store administrator.  The same applies to queries by name and
email address.

Alongside filtering of queries, the backend should be configured to disable
any form of update access via the web interface.  For Berkeley DB this
restriction can be imposed by opening the certificate store in read-only mode
from the web interface.  For relational databases, it can be imposed through
the SQL GRANT/REVOKE mechanism, for example "REVOKE ALL ON certificates FROM
webuser; GRANT SELECT ON certificates TO webuser" will allow read-only access
of the appropriate kind for the web interface.

4. IANA Considerations

The AIA/SIA accessMethod types are identified by object identifiers (OIDs).
OIDs were assigned from an arc contributed to the PKIX Working Group by RSA
Security.  Should additional accessMethods be introduced (for example for
attribute certificates or non-X.509 certificate types), the advocates for such
accessMethods are expected to assign the necessary OIDs from their own arcs.
No action by the IANA is necessary for this document or any anticipated
updates.

Author Address

Peter Gutmann
University of Auckland
Private Bag 92019
Auckland, New Zealand
[e-mail]

References

  [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 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.