security issues arising from the added complexity.
The use of an "Accept-encoding: identity" header would achieve the
same effect as disallowing any additional encodings and may indeed be
useful since section 14.3 of [RFC2616] indicates that the absence of
this header may be taken to mean that any encoding is permitted.
However, this unnecessarily bloats the HTTP header in a potentially
performance-affecting manner (see Section 2.5.5), whereas
establishing a requirement that the response be returned without any
additional decoration avoids the need to specify this in each
request. Implementations should therefore omit the Accept-encoding
header entirely or if it has to be included, include "identity" or
the wildcard "*" as an accepted content-encoding type.
Use of chunked encoding is given as a SHOULD NOT rather than a MUST
NOT because support for it is required by [RFC2616]. Nevertheless,
this form of encoding is strongly discouraged, as the data quantities
being transferred (1-2kB) make it entirely unnecessary, and support
for this encoding form is vulnerable to various implementation bugs,
some of which may affect security. However, implementors should be
aware that many versions of the Apache web server will unnecessarily
use chunked encoding when returning responses. Although it would be
better to make this a MUST NOT, this would render clients that
rejected it incompatible with the world’s most widely used web
server. For this reason, support for chunked encoding is strongly
discouraged but is nevertheless permitted. Clients that choose not
to support it should be aware that they may run into problems when
communicating with Apache-based HTTP certificate stores.
Multiple responses are returned as multipart/mixed rather than an
ASN.1 SEQUENCE OF Certificate or PKCS #7/CMS certificate chain
(degenerate signed data containing only certificates) because this is
more straightforward to implement with standard web-enabled tools.
An additional advantage is that it doesn’t restrict this access
mechanism to DER-based data, allowing it to be extended to other
certificate types, such as XML, PGP, and SPKI.
2.5.5. Performance Issues
Where high throughput/performance under load is a critical issue, a
main-memory database that acts as a form of content cache may be
interposed between the on-disk database and the HTTP interface
[Garcia-Molina]. A main-memory database provides the same
functionality as an on-disk database and is fully transparent to the
HTTP front-end, but offers buffer management and retrieval facilities
optimised for memory-resident data. Where further scalability is
required, the content-caching system could be implemented as a
cluster of main-memory databases [Ji].
Various network efficiency considerations need to be taken into
account when implementing this certificate/public key distribution
mechanism. For example, a simplistic implementation that performs
two writes (the HTTP header and the certificate, written separately)
followed by a read will interact badly with TCP delayed-ACK and
slow-start. This occurs because the TCP MSS is typically 1460 bytes
on a LAN (Ethernet) or 512/536 bytes on a WAN, while HTTP headers are
~200-300 bytes, far less than the MSS. When an HTTP message is first
sent, the TCP congestion window begins at one segment, with the TCP
slow-start then doubling its size for each ACK. Sending the headers
separately will send one short segment and a second MSS-size segment,
whereupon the TCP stack will wait for the responder’s ACK before
continuing. The responder gets both segments, then delays its ACK
for 200ms in the hopes of piggybacking it on responder data, which is
never sent, since it’s still waiting for the rest of the HTTP body
from the initiator. As a result, there is a 200ms (+assorted RTT)
delay in each message sent.
There are various other considerations that need to be taken into
account to provide maximum efficiency. These are covered in depth
elsewhere [Spero] [Heidemann] [Nielsen]. In addition, modifications
to TCP’s behaviour, such as the use of 4K initial windows [RFC3390]
(designed to reduce small HTTP transfer times to a single RTT),
should also ameliorate some of these issues.
A rule of thumb for optimal performance is to combine the HTTP header
and data payload into a single write (any reasonable HTTP
implementation will do this anyway, thanks to the considerable body
of experience that exists for HTTP server performance tuning), and to
keep the HTTP headers to a minimum to try to fit data within the TCP
MSS. For example, since this protocol doesn’t involve a web browser,
there’s no need to include various common browser-related headers
such as ones detailing software versions or acceptable languages.
2.5.6. Miscellaneous
The interface specified in this document is a basic read-only type
that will be used by the majority of clients. The handling of
updates (both insertion and deletion) is a complex issue involving
both technological issues (a variety of fields used for indexing and
information retrieval need to be specified in a technology-neutral
manner, or the certificate store needs to perform its own parsing of
the item being added, moving it from a near-universal key=value
lookup mechanism to a full public-key/certificate processing system)
and political ones (who can perform updates to the certificate store,
and under what conditions?). Because of this complexity, the details
of any potential update mechanism are left as a local configuration
issue, although they may at some point be covered in a future
document if there is sufficient demand.
Concerns have been raised over the use of HTTP as a substrate
[RFC3205]. The mechanism described here, which implements a
straightforward request/response protocol with the same semantics as
traditional HTTP requests, is unaffected by these issues.
Specifically, it does not implement any form of complex RPC
mechanism, does not require HTTP security measures, is not affected
by firewalls (since it uses only a basic HTTP GET rather than
layering a new protocol on top of HTTP), and has well-defined MIME
media types specified in standards documents. As such, the concerns
expressed in [RFC3205] do not apply here. In addition, although a
number of servers still don’t fully support some of the more advanced
features of HTTP 1.1 [Krishnamurthy], the minimal subset used here is
well supported by the majority of servers and HTTP implementations.
This access mechanism is similar to the PGP HKP protocol [HKP];
however, the latter is almost entirely undocumented and requires that
implementors reverse-engineer other implementations. Because of this
lack of standardisation, no attempt has been made to ensure
interoperability or compatibility with HKP-based servers, although
PGP developers provided much valuable input for this document. One
benefit that HKP does bring is extensive implementation experience,
which indicates that this is a very workable solution to the problem
of a simple certificate/public key retrieval mechanism. HKP servers
have been implemented using flat files, Berkeley DB, and various
databases, such as Postgres and MySQL.
2.6. Examples
To convert the subject DN C=NZ, O=... CN=Fred Dagg into a search key:
Hash the DN, in the DER-encoded form it appears in the
certificate, to obtain
96 4C 70 C4 1E C9 08 E5 CA 45 25 10 D6 C8 28 3A 1A C1 DF E2
Base-64 encode this to obtain:
lkxwxB7JCOXKRSUQ1sgoOhrB3+I
(Note the absence of trailing ’=’ padding.) This is the search key
to use in the query URI.
To fetch all certificates useful for sending encrypted email to
foo@example.com:
GET /search.cgi?email=foo%40example.com HTTP/1.1
(For simplicity, the additional Host: header required by [RFC2616] is
omitted here and in the following examples.) 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. Note the encoding of the ’@’ symbol as per [RFC2854].
Remaining required headers, such as the "Host" header required by
HTTP 1.1, have been omitted for the sake of clarity.
To fetch the CA certificate that issued the email certificate:
<Convert the issuer DN to a search key>
GET /search.cgi?sHash=<search key> HTTP/1.1
Alternatively, if chaining is by key identifier:
<Extract the keyIdentifier from the authorityKeyIdentifier>
GET /search.cgi?sKIDHash=<search key> HTTP/1.1
To fetch other certificates belonging to the same user as the email
certificate:
<Convert the subject DN to a search key>
GET /search.cgi?sHash=<search key> HTTP/1.1
To fetch the CRL for the certificate:
<Convert the issuer DN to a search key>
GET /search.cgi?iHash=<search key> HTTP/1.1
Note that since the differentiator is the URI base, the above two
queries appear identical (since the URI base isn’t shown) but are in
fact distinct.
To retrieve a key using XML methods, the <KeyName> (which contains
the string identifier for the key), used with the subject DN hash
above, would be:
<KeyName KeyID="sHash">lkxwxB7JCOXKRSUQ1sgoOhrB3+I</KeyName>.
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 DNS SRV
- 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 a well-known point of information access to
relying parties, CAs SHOULD use 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 }
where:
id-ad OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5)
pkix(7) 48 }
The corresponding accessLocation is the query URI. The use of this
facility provides a CA with a convenient, standard location to
indicate where further certificates may be found, for example, for
certification 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 DNS SRV
DNS SRV is a facility for specifying the location of the server(s)
for a specific protocol and domain [RFC2782]. For the certificate
store interface, the DNS SRV symbolic name for the certificate store
interface SHALL be "certificates". The name for the CRL store
interface SHALL be "crls". The name for the PGP public key store
SHALL be "pgpkeys". The name for the PGP revocation store SHALL be
"pgprevocations". Handling of additional DNS SRV facilities, such as
the priority and weight fields, is as per [RFC2782].
3.2.1. Example
If a CA with the domain example.com were to make its certificates
available via an HTTP certificate store interface, the server details
could be obtained by a lookup on:
_certificates._tcp.example.com
and
_crls._tcp.example.com
This would return the server(s) and port(s) for the service as
specified in [RFC2782].
3.3. 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
("certificates.", "crls.", "pgpkeys.", or "pgprevocations.") to the
domain name to obtain the net_loc portion of the URI, and by
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
pgpkeys.<domain_name>/search.cgi
pgprevocations.<domain_name>/search.cgi
Certificate store service providers SHOULD use these URIs in
preference to other alternatives. Note that the use of "search.cgi"
does not imply the use of CGI scripts [RFC3875]. This would be the
exception rather than the rule, since it would lead to a rather
inefficient implementation; it merely provides one possible (and
relatively simple to set up) implementation alternative (see the
rationale for more on this).
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 make 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,
"crls/search.cgi" for CRLs, "pgpkeys/search.cgi" for PGP public keys,
and "pgprevocations/search.cgi" for PGP revocation information to the
net_loc. The URI form of the "well-known" location is therefore:
<net_loc>/certificates/search.cgi
<net_loc>/crls/search.cgi
<net_loc>/pgpkeys/search.cgi
<net_loc>/pgprevocations/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.3.1. Examples
If a CA with the domain example.com were to make its certificates
available via an HTTP certificate store interface, the "well-known"
query URIs for certificates and CRLs would be:
http://certificates.example.com/search.cgi
http://crls.example.com/search.cgi
A home automation controller with the IP address 192.0.2.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:
http://192.0.2.1/certificates/search.cgi
http://192.0.2.1/crls/search.cgi
A print server with DNS name "printspooler" would make certificates
for web-enabled printers that it communicates with available as:
http://printspooler/certificates/search.cgi
http://printspooler/crls/search.cgi
3.4. Manual Configuration of the Client Software
The accessLocation for the HTTP certificate/public key/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.5. Implementation Notes and Rationale
This informative section documents the rationale behind the design in
Section 3 and provides guidance for implementors.
3.5.1. DNS SRV
The optimal solution for the problem of service location would be DNS
SRV. Unfortunately, the operating system used by the user group most
desperately in need of this type of handholding has no support for
anything beyond the most basic DNS address lookups, making it
impossible to use DNS SRV with anything but very recent Win2K and XP
systems. To make things even more entertaining, several of the
function names and some of the function parameters changed at various
times during the Win2K phase of development, and the behaviour of
portions of the Windows sockets API changed in undocumented ways to
match. This leads to an unfortunate situation in which a Unix
sysadmin can make use of DNS SRV to avoid having to deal with
technical configuration issues, but a Windows’95 user can’t. Because
of these problems, an alternative to DNS SRV is provided for
situations where it’s not possible to use this.
The SRV or "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
@example.com, the user software would query
_certificates._tcp.example.com or go to certificates.example.com and
request the certificate. 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 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 also possible but may not be
as easy to set up as HTTP redirects (corporate policies tend to be
more flexible in regard to web page contents than modifying DNS
configurations would be).
3.5.2. "well-known" Locations
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 that it be handled by the provider’s main web
server, while using a distinct server URI allows for it be 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.3 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.
3.5.3. Information in the Certificate
Implementations that require the use of nonstandard locations, 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.3 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.
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.
A single server can be used to handle both CRLDP and AIA/SIA queries
provided that 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 technical
support/helpdesk staff to email to users who can’t find the
certificate themselves, as described in Section 2.5. The resulting
certstore URL, when clicked on by the user, will directly access the
certificate when used in conjunction with any certificate-aware
application, such as a browser or mail program.
3.5.4. Miscellaneous
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, SSDP) to be
queried for certificates without requiring further user
configuration. Note that in practice no embedded device would ever
use the address given in the example (the de facto standard address
for web-enabled embedded devices is 192.168.1.x and not 192.0.2.x);
however, IETF policy requires the use of this non-address for
examples.
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.3 is not meant to imply that this document overrides the
existing UPnP mechanism, but merely that, if a device implements the
mechanism described here, it should use the naming scheme in Section
3.3 rather than use 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. [RFC2616]
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 caching ("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 back-end used to retrieve certificates. Allowing
attackers to submit arbitrary queries may allow them to manipulate
the certificate store in unexpected ways if the back-end tries to
interpret the query contents. For example, if a certificate store is
implemented using an RDBMS for which the calling application
assembles a complete SQL string to perform the query, and 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. Even a read-only query
can be problematic; for example, setting <search key> to "UNION
SELECT password FROM master.sysxlogins" will list all passwords in an
SQL Server database (in an easily decrypted format) if the user is
running under the sa (DBA) account. Straightforward sanitisation of
queries may not be sufficient to prevent all attacks; for example, a
filter that removes the SQL query string "DELETE" can be bypassed by
submitting the string embedded in another instance of the string.
Removing "DELETE" from "DELDELETEETE" leaves the outer "DELETE" in
place. Abusing the truncation of over-long strings by filters can
also be used as a means of attack, in which the attacker ensures that
the truncation occurs in the middle of an escape sequence, bypassing
the filtering. The use of parameterised queries (often called
placeholders) that aren’t vulnerable to SQL injection should be used
to avoid these attacks.
In addition, since some query data may be encoded/decoded before
being sent to the back-end, applications should check both the
encoded and decoded form for valid data. A simple means of avoiding
these problems is to use parameterised commands rather than hand-
assembling SQL strings for use in queries (this is also more
efficient for most database interfaces). The use of parameterised
commands means that the query value is never present in any position
where it could be interpreted as a portion of the query command.
Alongside filtering of queries, the back-end 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. Server-specific
security measures may also be employed; for example, the SQL Server