diff options
Diffstat (limited to 'doc/rfc/rfc4387.txt')
| -rw-r--r-- | doc/rfc/rfc4387.txt | 1403 |
1 files changed, 1403 insertions, 0 deletions
diff --git a/doc/rfc/rfc4387.txt b/doc/rfc/rfc4387.txt new file mode 100644 index 0000000..a97a980 --- /dev/null +++ b/doc/rfc/rfc4387.txt @@ -0,0 +1,1403 @@ + + + + + + +Network Working Group P. Gutmann, Ed. +Request for Comments: 4387 University of Auckland +Category: Standards Track February 2006 + + + Internet X.509 Public Key Infrastructure + Operational Protocols: Certificate Store Access via HTTP + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2006). + +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/HTTPS) as an interface + mechanism to obtain certificates and certificate revocation lists + (CRLs) from PKI repositories. Additional mechanisms addressing PKIX + operational requirements are specified in separate documents. + + + + + + + + + + + + + + + + + + + + + + +Gutmann Standards Track [Page 1] + +RFC 4387 Certificate Store Access via HTTP February 2006 + + +Table of Contents + + 1. Introduction ....................................................2 + 2. HTTP Certificate Store Interface ................................3 + 2.1. Converting Binary Blobs into Search Keys ...................4 + 2.2. Attribute Types: X.509 .....................................5 + 2.3. Attribute Types: PGP .......................................6 + 2.4. Attribute Types: XML .......................................6 + 2.5. Implementation Notes and Rationale .........................6 + 2.5.1. Identification ......................................7 + 2.5.2. Checking of Input Values ............................9 + 2.5.3. URI Notes ..........................................10 + 2.5.4. Responses ..........................................11 + 2.5.5. Performance Issues .................................12 + 2.5.6. Miscellaneous ......................................13 + 2.6. Examples ..................................................14 + 3. Locating HTTP Certificate Stores ...............................15 + 3.1. Information in the Certificate ............................15 + 3.2. Use of DNS SRV ............................................16 + 3.2.1. Example ............................................16 + 3.3. Use of a "well-known" Location ............................16 + 3.3.1. Examples ...........................................17 + 3.4. Manual Configuration of the Client Software ...............18 + 3.5. Implementation Notes and Rationale ........................18 + 3.5.1. DNS SRV ............................................18 + 3.5.2. "well-known" Locations .............................19 + 3.5.3. Information in the Certificate .....................19 + 3.5.4. Miscellaneous ......................................20 + 4. Security Considerations ........................................20 + 5. IANA Considerations ............................................22 + 6. Acknowledgements ...............................................22 + 7. References .....................................................22 + 7.1. Normative References ......................................22 + 7.2. Informative References ....................................23 + +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), or + optionally, HTTPS as an interface mechanism to obtain certificates or + public keys, and certificate revocation lists (CRLs), from PKI + repositories. Throughout the remainder of this document the generic + term HTTP will be used to cover either option. + + + + + + +Gutmann Standards Track [Page 2] + +RFC 4387 Certificate Store Access via HTTP February 2006 + + + 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 + allow HTTP to be used as a general-purpose, transparent interface to + any type of certificate or key store including flat files, standard + databases such as Berkeley DB and relational databases, and + traditional X.500/LDAP directories. Typical applications would + include use with web-enabled relational databases (which most + databases are) or simple {key,value} 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]. + +2. HTTP Certificate Store Interface + + The GET method is used in combination with an HTTP query URI + [RFC2616] to retrieve certificates from the underlying certificate + store: + + http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]] + + The parameters for the query portion of the URI are a certificate or + key identifier consisting of an attribute type and a value that + specifies one or more certificates or public keys to be returned from + the query: + + query = attribute '=' value + + Certificates and public keys are retrieved from one URI (the + certificate URI) and CRLs from another URI (the revocation URI). + These may or may not correspond to the same certificate store and/or + server (the exact interpretation is a local configuration issue). + The query value MUST be encoded using the form-urlencoded media type + [RFC2854]. Further details of URI construction, size limits, and + other factors are given in [RFC2616]. + + Responses to unsuccessful queries (for example, to indicate a non- + match or an error condition) are handled in the standard manner as + per [RFC2616]. Clients should in particular be aware that in some + instances servers may return HTTP type 3xx redirection requests to + explicitly redirect queries to another server. Obviously, implicit + DNS-based redirection is also possible. + + + +Gutmann Standards Track [Page 3] + +RFC 4387 Certificate Store Access via HTTP February 2006 + + + If more than one certificate matches a query, it MUST be returned as + a multipart/mixed response. The returned data MUST be returned + verbatim; it MUST NOT use any additional content- or transfer- + encoding at the HTTP level (for example, it can't be compressed or + encoded as base64 or quoted-printable text). Implementations SHOULD + NOT use chunked encoding in responses. + + The query component of the URI MAY optionally contain additional + attribute/value pairs separated by the standard ampersand delimiter + '&' that specify further actions to be taken by the certificate + store. Certificate stores SHOULD ignore any additional unrecognised + attribute/value pairs present in the URI. + + Other information, such as naming conventions and MIME types, is + specified in [RFC2585] (with additional MIME types for non-X.509 + content in [RFC3156] and [RFC3275]). + +2.1. Converting Binary Blobs into Search Keys + + Some fields (indicated by the "Process" column in the tables below) + are of arbitrary length and/or contain non-textual data. Both of + these properties make them unsuited for direct use in HTTP queries. + In order to make them usable, fields for which the processing option + is "Hash" are first hashed down to a fixed-length 160-bit value. + Fields for which the processing option is "Hash" or "Base64" are + base64-encoded to transform the binary data into textual forms: + + Processing Processing step + option + + "Hash" Hash the key value using SHA-1 [FIPS180] to produce a + 160-bit value, then continue with the base64 encoding + step that follows. + + "Hash" Encode the binary value using base64 encoding to produce + "Base64" a 27-byte text-only value. Base64 encoding of the 20 + byte value will produce 28 bytes, and the last byte will + always be a '=' padding character. The 27-byte value is + created by dropping the trailing '=' character. + + For cases where the binary value is smaller or larger than the 20- + byte SHA-1 output (for example, with 64-bit/8 byte PGP key IDs), the + final value is created by removing any trailing '=' padding from the + encoding of the binary value (this is a generalisation of the above + case). + + + + + + +Gutmann Standards Track [Page 4] + +RFC 4387 Certificate Store Access via HTTP February 2006 + + + Implementations MUST verify that the base64-encoded values submitted + in requests contain only characters in the ranges 'a'-'z', 'A'-'Z', + '0'-'9', '+', and '/'. Queries containing any other character MUST + be rejected. (See the implementation notes in Section 2.5 and the + security considerations in Section 4 for more details on this + requirement.) + +2.2. Attribute Types: X.509 + + Permitted attribute types and associated values for use with X.509 + certificates and CRLs are described below. Arbitrary-length binary + values (as indicated in the table below) are converted into a search + key by the process described in Section 2.1. Note that the values + are checked for an exact match (after decoding of any form-urlencoded + [RFC2854] portions if this is necessary) and are therefore case + sensitive. + + Attribute Process Value + --------- ------- ----- + certHash Hash Search key derived from the SHA-1 hash of the + certificate (sometimes called the certificate + fingerprint or thumbprint). + + uri None Subject URI associated with the certificate, + without the (optional) scheme specifier. The URI + type depends on the certificate. For S/MIME + certificates, it would be an email address; for + SSL/TLS certificates, it would be the server's DNS + name (this is usually also specified as the + CommonName); for IPsec certificates, it would be + the DNS name/IP address; and so on. + + iHash Hash Search key derived from the DER-encoded issuer DN + as it appears in the certificate, CRL, or other + object. + + iAndSHash Hash Search key derived from the certificate's + DER-encoded issuerAndSerialNumber [RFC3852]. + + name None Subject CommonName contained in the certificate. + + sHash Hash Search key derived from the DER-encoded subject + DN as it appears in the certificate or other + object. + + sKIDHash Hash Search key derived from the certificate's + subjectKeyIdentifier (specifically the contents + octets of the KeyIdentifier OCTET STRING). + + + +Gutmann Standards Track [Page 5] + +RFC 4387 Certificate Store Access via HTTP February 2006 + + + Certificate URIs MUST support retrieval by all the above attribute + types. + + CRL URIs MUST support retrieval by the iHash and sKIDHash attribute + types, which identify the issuer of the CRL. In addition, CRL URIs + MAY support retrieval by certHash and iAndSHash attribute types, for + cases where this is required by the use of the + issuingDistributionPoint extension. A CRL query MUST return the + matching CRL with the greatest thisUpdate value (in other words, the + most recent CRL). + +2.3. Attribute Types: PGP + + Permitted attribute types and associated values for use with PGP + public keys and key revocation information are described below. + Binary values (as indicated in the table below) are converted into a + search key by the process described in Section 2.1. + + Attribute Process Value + --------- ------- ----- + email None email address associated with the key. + + fingerprint Base64 160-bit PGP key fingerprint [RFC2440]. + + keyID Base64 64-bit PGP key ID [RFC2440]. + + name None User name associated with the key. + + Key URIs MUST support retrieval by all of the above attribute types. + + Revocation URIs MUST support retrieval by the fingerprint and keyID + attribute types, which identify the issuer of the key revocation. + +2.4. Attribute Types: XML + + Permitted attribute types and associated values for use with XML are + as specified in sections 2.2 and 2.3. Since XML allows arbitrary + attributes to be associated with the <RetrievalMethod> child element + of <KeyInfo> [RFC3275], there are no additional special requirements + for use with XML. + +2.5. Implementation Notes and Rationale + + This informative section documents the rationale behind the design in + Section 2 and provides guidance for implementors. + + + + + + +Gutmann Standards Track [Page 6] + +RFC 4387 Certificate Store Access via HTTP February 2006 + + +2.5.1. Identification + + The identifiers are taken from PKCS #15 [PKCS15], a standard that + covers (among other things) a transparent interface to a + certificate/public key store. These identifiers have been field + proven, as they have been in common use for a number of years, + typically via PKCS #11 [PKCS11]. Certificate stores and the + identifiers that are required for typical certificate lookup + operations are analysed in some detail in [Gutmann]. + + The URI identifier type specifies the identifier associated with the + certificate's intended usage with a given Internet security protocol. + For example, an SSL/TLS server certificate would contain the server's + DNS name (this is traditionally also specified as the CommonName or + CN) an S/MIME certificate would contain the subject's email address; + an IPsec certificate would contain a DNS name or IP address; and a + SIP certificate would contain a SIP URI. A modicum of common sense + is assumed when deciding upon an appropriate URI field value. + + For historical reasons going back to its primary use as a means of + looking up users' S/MIME email certificates, some clients may specify + the URI attribute name as "email" rather than "uri". Although not + required by this specification, servers may choose to allow the use + of "email" as an alias for "uri". + + In addition, it is common practice to use the Internet identifier + associated with the certificate's intended field of application as + the CN for the certificate when this is the most sensible name for + the certificate subject. For example, an SSL/TLS server certificate + will contain the server's DNS name in the CN field. In web-enabled + devices, this may indeed be the only name that exists for the device. + It is therefore quite possible that the URI will duplicate the CN, + and that it may be the only identifier present (that is, there's no + full DN but only a single CN field). + + By long-standing convention, URIs in certificates are given without a + scheme specifier. For example, an SSL/TLS server certificate would + contain www.example.com rather than https://www.example.com, and an + S/MIME certificate would contain user@example.com rather than + mailto:user@example.com. This convention is extended to other URI + types as well, so that a certificate containing the (effective) URIs + im:user@example.com and xmpp:user@example.com would be queried using + the single URI user@example.com. The certificate store would then + return all certificates containing this URI, leaving it to the client + to determine which one is most appropriate for its use. This + approach is taken both because for the most common URI types there's + no schema specifier (see the paragraphs above) and no easy way to + determine what the intended use is (an SSL/TLS server certificate is + + + +Gutmann Standards Track [Page 7] + +RFC 4387 Certificate Store Access via HTTP February 2006 + + + simply one presented by an SSL/TLS server), and because the relying + party/client is in a better position to judge the certificate's most + appropriate use than the certificate store server. + + Another possible identifier that has been suggested is an IP address + or DNS name, which will be required for web-enabled embedded devices. + This is necessary to allow for example a home automation controller + to be queried for certificates for the devices that it controls. + Since this value is regarded as the CN for the device, common + practice is to use this value for the CN in the same way that web + server certificates set the CN to the server's DNS name, so this + option is already covered in a widely-accepted manner. + + The name and email address are an exact copy of what is present in + the certificate, without any canonicalisation or rewriting (other + than the transport encoding required by HTTP). This follows standard + implementation practice, which transfers an exact copy of these data + items in order to avoid problems due to character set translation, + handling of whitespace, and other issues. + + 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 that searching for + structured name data isn't a supported feature, since this is a + simple interface to a {key,value} 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 HTTP LDAP + gateways for this purpose. + + Although clients will always submit a fixed 160-bit value, servers + are free to use as many bits of this value as they require. For + example, a server may choose to use only the first 40, 64, 80, or 128 + bits for efficiency in searching and maintaining indices. + + PGP has traditionally encoded IDs using a C-style 0xABCDEF notation + based on the display format used for IDs in PGP 2.0. Unfortunately, + strings in this format are also valid strings in the base64 format, + complicated further by the fact that near-misses such as 0xABCDRF + could be either a mistyped attempt at a hex ID or a valid base64 ID. + For this reason, and to ensure consistency, base64 IDs are used + throughout this specification. The search keys used internally will + be binary values, so whether these are converted from ASCII-hex or + base64 is immaterial in the long run. + + 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 + + + + +Gutmann Standards Track [Page 8] + +RFC 4387 Certificate Store Access via HTTP February 2006 + + + rfc822Name, rfc822Mailbox, emailAddress, mail, or email) where + multiple name forms exist. + + In some cases, users may require additional, application-specific + attribute types. For example, a healthcare application that uses a + healthcare ID as the primary key for its databases may require the + ability to perform certificate lookups based on this healthcare ID. + The formatting and use of such application-specific identifiers is + beyond the scope of this document. However, they should begin with + 'x-' to ensure that they don't conflict with identifiers that may be + defined in future versions of this specification. + +2.5.2. Checking of Input Values + + The attribute value portion of the identifier should be carefully + checked for invalid characters since allowing raw data presents a + security risk. Consider, for example, a certificate/public key store + implemented using an RDBMS in which the SQL query is built up as + "SELECT certificate FROM certificates WHERE iHash = " + <search key>. + If <search key> is set to "ABCD;DELETE FROM certificates", the + results of the query will be quite different from what was expected + by the certificate store administrators. 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. For this reason, only valid + base64 encodings should be allowed. The same checking applies to + queries by name or email address. + + 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, with the attacker ensuring that the truncation + occurs in the middle of an escape sequence, bypassing the filtering. + Although in theory recursive filtering may help here, the use of + parameterised queries (often called placeholders) that aren't + vulnerable to SQL injection should be used to avoid these attacks. + More information on securing database back-ends may be found in + [Birkholz], and more comments on sanitisation and safety concerns may + be found in the security considerations section. + + + + + + + + +Gutmann Standards Track [Page 9] + +RFC 4387 Certificate Store Access via HTTP February 2006 + + +2.5.3. URI Notes + + Pre-constructed URIs that fetch a certificate/public key matching a + fixed search criterion may be useful for items such as web pages or + business cards, or even for technical support/helpdesk staff who want + to mail to users but can't find the certificate themselves. These + URIs may also be used to enforce privacy measures when distributing + certificates by perturbing the search key in a manner known only to + the certificate/public key store, or to the certificate store and + users (in other words, by converting the URI into a capability). For + example, a user with a newly-issued certificate could be instructed + to fetch it with a key of "x-encrCertHash=...", which is decrypted by + the certificate store to fetch the appropriate certificate, ensuring + that only the certificate owner can fetch their certificate + immediately after issue. Similarly, an organisation that doesn't + want to make its certificates available for public query might + require a MAC on search keys (e.g., "x-macCertHash=...") to ensure + that only authorised users can search for certificates (although a + more logical place for access control, if a true web server is being + used to access the store, would obviously be at the HTTP level). + + The query types have been specifically chosen to be not just an HTTP + interface to LDAP but a general-purpose retrieval mechanism that + allows arbitrary certificate/public key storage mechanisms (with a + bias towards simple {key,value} stores, which are deployed almost + universally, whether as ISAM, Berkeley DB, or an RDBMS) to be + employed as back-ends. This specification has been deliberately + written to be technology neutral, allowing any {key,value} lookup + mechanism to be used. It doesn't matter if you choose to have + trained chimpanzees look up certificates in books of tables, as long + as your method can provide the correct response with reasonable + efficiency. + + Certificate/public key 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 independent URIs, it's possible to implement the + two stores using mechanisms tailored to the data they contain. + + PGP combines key and revocation information into a single data object + so that it's possible to return both public keys and revocation + information from the same URI. If distinct key and revocation + servers are available, these can provide a slight performance gain + since fetching revocation information doesn't require fetching the + key that it applies to. If no separate servers are available, a + + + + + +Gutmann Standards Track [Page 10] + +RFC 4387 Certificate Store Access via HTTP February 2006 + + + single server can be used to satisfy both types of queries with a + slight performance loss, since fetching revocation information will + also fetch the public key data associated with the revocation data. + +2.5.4. Responses + + The disallowance of exotic encoding forms reflects the fact that most + clients (and many servers, particularly for embedded devices) are not + general-purpose web browsers or servers capable of handling an + arbitrary range of encoding forms and types, but simply basic HTTP + engines attached to key management applications. In other words, the + HTTP interface is a rudimentary add-on to a key management + application, rather than key-management being an add-on to a + general-purpose web client or server. Eliminating unnecessary + choices simplifies the implementation task and reduces code size and + complexity, with an accompanying decrease in the probability of + 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 + + + +Gutmann Standards Track [Page 11] + +RFC 4387 Certificate Store Access via HTTP February 2006 + + + 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, + + + +Gutmann Standards Track [Page 12] + +RFC 4387 Certificate Store Access via HTTP February 2006 + + + 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. + + + + + + + +Gutmann Standards Track [Page 13] + +RFC 4387 Certificate Store Access via HTTP February 2006 + + +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 + + + + + + + +Gutmann Standards Track [Page 14] + +RFC 4387 Certificate Store Access via HTTP February 2006 + + + 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 } + + + + + + +Gutmann Standards Track [Page 15] + +RFC 4387 Certificate Store Access via HTTP February 2006 + + + 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 + + + +Gutmann Standards Track [Page 16] + +RFC 4387 Certificate Store Access via HTTP February 2006 + + + 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 + + + + + + + + +Gutmann Standards Track [Page 17] + +RFC 4387 Certificate Store Access via HTTP February 2006 + + + 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 + + + +Gutmann Standards Track [Page 18] + +RFC 4387 Certificate Store Access via HTTP February 2006 + + + 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 + + + +Gutmann Standards Track [Page 19] + +RFC 4387 Certificate Store Access via HTTP February 2006 + + + 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 + + + +Gutmann Standards Track [Page 20] + +RFC 4387 Certificate Store Access via HTTP February 2006 + + + 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 + provides the built-in db_datareader account that only allows read + access to tables (but see the note above about what can be done even + with read-only access) and the ability to run the server under a + dedicated low-privilege account (a standard feature of Unix systems). + + The mechanism described in this document is not intended to function + as a trusted directory/database. In particular, users should not + assume that just because they fetched a public key or certificate + from an entity claiming to be X, that X has made any statement about + the veracity of the public key or certificate. The use of a signed + + + +Gutmann Standards Track [Page 21] + +RFC 4387 Certificate Store Access via HTTP February 2006 + + + representation of the items stored removes the need to depend on the + certificate store for any security service other than availability. + Although it's possible to implement a trusted directory/database + using HTTPS or some other form of secured/trusted link, this is a + local policy/configuration issue, and in the absence of such + additional security measures users should apply appropriate levels of + verification to any keys or certificates fetched before they take + them into use. + +5. IANA Considerations + + No action by IANA is needed. The AIA/SIA accessMethod types are + identified by object identifiers (OIDs) from an arc managed by the + PKIX working group. 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. + +6. Acknowledgements + + Anders Rundgren, Blake Ramsdell, Jeff Jacoby, David Shaw, and members + of the ietf-pkix working group provided useful input and feedback on + this document. + +7. References + +7.1. Normative References + + [FIPS180] Federal Information Processing Standards Publication + (FIPS PUB) 180-1, Secure Hash Standard, 17 April + 1995. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2440] Callas, J., Donnerhacke, L., Finney, H., and R. + Thayer, "OpenPGP Message Format", RFC 2440, November + 1998. + + [RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public + Key Infrastructure Operational Protocols: FTP and + HTTP", RFC 2585, May 1999. + + [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., + Masinter, L., Leach, P., and T. Berners-Lee, + "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, + June 1999. + + + + +Gutmann Standards Track [Page 22] + +RFC 4387 Certificate Store Access via HTTP February 2006 + + + [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR + for specifying the location of services (DNS SRV)", + RFC 2782, February 2000. + + [RFC2854] Connolly, D. and L. Masinter, "The 'text/html' Media + Type", RFC 2854, June 2000. + + [RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. + Roessler, "MIME Security with OpenPGP", RFC 3156, + August 2001. + + [RFC3275] Eastlake 3rd, D., Reagle, J., and D. Solo, + "(Extensible Markup Language) XML-Signature Syntax + and Processing", RFC 3275, March 2002. + + [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, + "Internet X.509 Public Key Infrastructure Certificate + and Certificate Revocation List (CRL) Profile", RFC + 3280, April 2002. + + [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", + RFC 3852, July 2004. + +7.2. Informative References + + [Birkholz] "Special Ops: Host and Network Security for + Microsoft, Unix, and Oracle", Erik Birkholz et al, + Syngress Publishing, November 2002. + + [Garcia-Molina] "Main Memory Database Systems", Hector Garcia-Molina + and Kenneth Salem, IEEE Transactions on Knowledge and + Data Engineering, Vol.4, No.6 (December 1992), p.509. + + [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. + + [HKP] "A PGP Public Key Server", Marc Horowitz, 2000, + http://www.mit.edu/afs/net.mit.edu/project/pks/ + thesis/paper/thesis.html. A more complete and up- + to-date overview of HKP may be obtained from the + source code of an open-source OpenPGP implementation + such as GPG. + + + +Gutmann Standards Track [Page 23] + +RFC 4387 Certificate Store Access via HTTP February 2006 + + + [Ji] "Affinity-based Management of Main Memory Database + Clusters", Minwen Ji, ACM Transactions on Internet + Technology, Vol.2, No.4 (November 2002), p.307. + + [Krishnamurthy] "PRO-COW: Protocol Compliance on the Web - A + Longitudinal Survey", Balachander Krishnamurthy and + Martin Arlitt, Proceedings of the 3rd Usenix + Symposium on Internet Technologies and Systems + (USITS'01), March 2001, p.109. + + [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/ + 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. + + [RFC3205] Moore, K., "On the use of HTTP as a Substrate", BCP + 56, RFC 3205, February 2002. + + [RFC3390] Allman, M., Floyd, S., and C. Partridge, "Increasing + TCP's Initial Window", RFC 3390, October 2002. + + [RFC3875] Robinson, D. and K. Coar, "The Common Gateway + Interface (CGI) Version 1.1", RFC 3875, October 2004. + + [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. + +Author's Address + + Peter Gutmann + University of Auckland + Private Bag 92019 + Auckland, New Zealand + + EMail: pgut001@cs.auckland.ac.nz + + + + + +Gutmann Standards Track [Page 24] + +RFC 4387 Certificate Store Access via HTTP February 2006 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2006). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM 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. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + + + + +Gutmann Standards Track [Page 25] + |