idnits 2.17.1 draft-ietf-pkix-certstore-http-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 32. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1011. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 1014 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 426 instances of too long lines in the document, the longest one being 8 characters in excess of 72. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Line 202 has weird spacing: '... None emai...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 2006) is 6616 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'FIPS180' is mentioned on line 121, but not defined == Missing Reference: 'RFC2630' is mentioned on line 172, but not defined ** Obsolete undefined reference: RFC 2630 (Obsoleted by RFC 3369, RFC 3370) == Missing Reference: 'RFC3975' is mentioned on line 662, but not defined == Unused Reference: 'FIPS 180' is defined on line 908, but no explicit reference was found in the text == Unused Reference: 'RFC3875' is defined on line 989, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS 180' ** Obsolete normative reference: RFC 1866 (Obsoleted by RFC 2854) ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2440 (Obsoleted by RFC 4880) ** Obsolete normative reference: RFC 3280 (Obsoleted by RFC 5280) -- Obsolete informational reference (is this intentional?): RFC 3205 (Obsoleted by RFC 9205) Summary: 14 errors (**), 0 flaws (~~), 11 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Editor: Peter Gutmann 2 draft-ietf-pkix-certstore-http-09.txt University of Auckland 3 August 2005 4 Expires February 2006 6 Internet X.509 Public Key Infrastructure 7 Operational Protocols: Certificate Store Access via HTTP 9 Status of this memo 11 This document is an Internet-Draft and is subject to all provisions of Section 12 3 of RFC 3978. 14 Internet-Drafts are working documents of the Internet Engineering Task Force 15 (IETF), its areas, and its working groups. Note that other groups may also 16 distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months and may 19 be updated, replaced, or obsoleted by other documents at any time. It is 20 inappropriate to use Internet-Drafts as reference material or to cite them 21 other than a "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/1id-abstracts.html. 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 By submitting this Internet-Draft, each author represents that any applicable 30 patent or other IPR claims of which he or she is aware have been or will be 31 disclosed, and any of which he or she becomes aware will be disclosed, in 32 accordance with Section 6 of BCP 79. 34 Abstract 36 The protocol conventions described in this document satisfy some of the 37 operational requirements of the Internet Public Key Infrastructure (PKI). 38 This document specifies the conventions for using the Hypertext Transfer 39 Protocol (HTTP/HTTPS) as an interface mechanism to obtain certificates and 40 certificate revocation lists (CRLs) from PKI repositories. Additional 41 mechanisms addressing PKIX operational requirements are specified in separate 42 documents. 44 1. Introduction 46 This specification is part of a multi-part standard for the Internet Public 47 Key Infrastructure (PKI) using X.509 certificates and certificate revocation 48 lists (CRLs). This document specifies the conventions for using the Hypertext 49 Transfer Protocol (HTTP) or optionally HTTPS (throughout the remainder of this 50 document the generic term HTTP will be used to cover either option) as an 51 interface mechanism to obtain certificates or public keys, and certificate 52 revocation lists (CRLs), from PKI repositories. 54 Although RFC 2585 [RFC2585] covers fetching certificates via HTTP, this merely 55 mentions that certificates may be fetched from a static URL, which doesn't 56 provide any general-purpose interface capabilities to a certificate store. 57 The conventions described in this document allow HTTP to be used as a general- 58 purpose, transparent interface to any type of certificate or key store ranging 59 from flat files through to standard databases such as Berkeley DB and 60 relational databases, as well as traditional X.500/LDAP directories. Typical 61 applications would include use with web-enabled relational databases (which 62 most databases are) or simple {key,value} lookup mechanisms such as Berkeley 63 DB and its various descendants. 65 Additional mechanisms addressing PKIX operational requirements are specified 66 in separate documents. 68 The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", 69 "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as 70 described in [RFC2119]. 72 2. HTTP Certificate Store Interface 74 The GET method is used in combination with an HTTP query URI [RFC2616]: 76 http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]] 78 to retrieve certificates from the underlying certificate store. The 79 parameters for the query portion of the URI are a certificate or key 80 identifier consisting of an attribute type and a value that specifies one or 81 more certificates or public keys to be returned from the query: 83 query = attribute '=' value 85 Certificates and public keys are retrieved from one URI (the certificate URI) 86 and CRLs from another URI (the revocation URI). These may or may not 87 correspond to the same certificate store and/or server (the exact 88 interpretation is a local configuration issue). The query value MUST be 89 encoded using the form-urlencoded media type [RFC1866]. Further details of 90 URI construction, size limits, and other details are given in [RFC2616]. 92 Responses to unsuccessful queries (for example to indicate a non-match or an 93 error condition) are handled in the standard manner as per [RFC2616]. Clients 94 should in particular be aware that in some instances servers may return HTTP 95 type 3xx redirection requests to explicitly redirect queries to another 96 server. Obviously, implicit DNS-based redirection is also possible. 98 If more than one certificate matches a query, it MUST be returned as a 99 multipart/mixed response. The returned data MUST be returned verbatim; it 100 MUST NOT use any additional content- or transfer-encoding at the HTTP level 101 (for example it can't be compressed or encoded as base64 or quoted-printable 102 text). Implementations SHOULD NOT use chunked encoding in responses. 104 Other information such as naming conventions and MIME types are specified in 105 [RFC2585] (with additional MIME types for non-X.509 content in [RFC3156] and 106 [RFC3275]). 108 2.1 Converting Binary Blobs into Search Keys 110 Some fields (indicated by the "Process" column in the tables below) are of 111 arbitrary length and/or contain non-textual data. Both of these properties 112 make them unsuited for direct use in HTTP queries. In order to make them 113 usable, fields for which the processing option is "Hash" are first hashed down 114 to a fixed-length 160-bit value. Fields for which the processing option is 115 "Hash" or "Base64" are base64-encoded to transform the binary data into 116 textual forms: 118 Processing Processing step 119 option 121 "Hash" Hash the key value using SHA-1 [FIPS180] to produce a 160- 122 bit value, then continue with the base64 encoding step that 123 follows. 125 "Hash" Encode the binary value using base64 encoding to produce 126 "Base64" a 27-byte text-only value. Base64 encoding of the 20 byte 127 value will produce 28 bytes, and the last byte will always 128 be a '=' padding character. The 27-byte value is created 129 by dropping the trailing '=' character. 131 For cases where the binary value is smaller or larger than 132 the 20-byte SHA-1 output (for example with 64-bit/8 byte 133 PGP key IDs), the final value is created by removing any 134 trailing '=' padding from the encoding of the binary value 135 (this is a generalisation of the above case). 137 Implementations MUST verify that the base64-encoded values submitted in 138 requests contain only characters in the range 'a'-'z', 'A'-'Z', '0'-'9', '+', 139 and '/'. Queries containing any other character MUST be rejected (see the 140 implementation notes in section 2.5 and the security considerations in section 141 4 for more details on this requirement). 143 2.2 Attribute types: X.509 145 Permitted attribute types and associated values for use with X.509 146 certificates and CRLs are described below. Arbitrary-length binary values (as 147 indicated in the table below) are converted into a search key by the process 148 described in section 2.1. Note that the values are checked for an exact match 149 (after decoding of any form-urlencoded [RFC1866] portions if this is 150 necessary), and are therefore case-sensitive. 152 Attribute Process Value 153 --------- ------- ----- 154 certHash Hash Search key derived from the SHA-1 hash of the 155 certificate (sometimes called the certificate 156 fingerprint or thumbprint). 158 uri None Subject URI associated with the certificate, 159 without the (optional) scheme specifier. The URI 160 type depends on the certificate. For S/MIME 161 certificates it would be an email address, for 162 SSL/TLS certificates it would be the server's DNS 163 name (this is usually also specified as the 164 CommonName), for IPsec certificates it would be 165 the DNS name/IP address, and so on. 167 iHash Hash Search key derived from the DER-encoded issuer DN 168 as it appears in the certificate, CRL, or other 169 object. 171 iAndSHash Hash Search key derived from the certificate's 172 DER-encoded issuerAndSerialNumber [RFC2630]. 174 name None Subject CommonName contained in the certificate. 176 sHash Hash Search key derived from the DER-encoded subject 177 DN as it appears in the certificate or other 178 object. 180 sKIDHash Hash Search key derived from the certificate's 181 subjectKeyIdentifier (specifically the contents 182 octets of the KeyIdentifier OCTET STRING). 184 Certificate URIs MUST support retrieval by all of the above attribute types. 186 CRL URIs MUST support retrieval by the iHash and sKIDHash attribute types, 187 which identify the issuer of the CRL. In addition CRL URIs MAY support 188 retrieval by certHash and iAndSHash attribute types, for cases where this is 189 required by the use of the issuingDistributionPoint extension. A CRL query 190 MUST return the matching CRL with the greatest thisUpdate value (in other 191 words, the most recent CRL). 193 2.3 Attribute types: PGP 195 Permitted attribute types and associated values for use with PGP public keys 196 and key revocation information are described below. Binary values (as 197 indicated in the table below) are converted into a search key by the process 198 described in section 2.1. 200 Attribute Process Value 201 --------- ------- ----- 202 email None email address associated with the key. 204 fingerprint Base64 160-bit PGP key fingerprint [RFC2440]. 206 keyID Base64 64-bit PGP key ID [RFC2440]. 208 name None User name associated with the key. 210 Key URIs MUST support retrieval by all of the above attribute types. 212 Revocation URIs MUST support retrieval by the fingerprint and keyID attribute 213 types, which identify the issuer of the key revocation. 215 2.4 Attribute types: XML 217 Permitted attribute types and associated values for use with XML are as 218 specified in sections 2.2 and 2.3. Since XML allows arbitrary attributes to 219 be associated with the child element of [RFC3275], 220 there are no additional special requirements for use with XML. 222 2.5 Implementation Notes and Rationale 224 This informative section documents the rationale behind the design in section 225 2 and provides guidance for implementors. 227 2.5.1 Identification 229 The identifiers are taken from PKCS #15 [PKCS15], a standard that covers 230 (among other things) a transparent interface to a certificate/public key 231 store. These identifiers have been field proven through having been in common 232 use for a number of years, typically via PKCS #11 [PKCS11]. Certificate 233 stores and the identifiers that are required for typical certificate lookup 234 operations are analysed in some detail in [Gutmann]. 236 The URI identifier type specifies the identifier associated with the 237 certificate's intended usage with a given Internet security protocol. For 238 example an SSL/TLS server certificate would contain the server's DNS name 239 (this is traditionally also specified as the CommonName or CN), an S/MIME 240 certificate would contain the subject's email address, an IPsec certificate 241 would contain a DNS name or IP address, a SIP certificate would contain a SIP 242 URI, and so on. A modicum of common sense is assumed when deciding what an 243 appropriate URI field value should be. 245 For historical reasons going back to its primary use as a means of looking up 246 user's S/MIME email certificates, some clients may specify the URI attribute 247 name as "email" rather than "uri". Although not required by this 248 specification, servers may choose to allow the use of "email" as an alias for 249 "uri". 251 In addition it is common practice to use the Internet identifier associated 252 with the certificate's intended field of application as the CN for the 253 certificate when this is the most sensible name for the certificate subject. 254 For example a SSL/TLS server certificate will contain the server's DNS name in 255 the CN field. In web-enabled devices this may indeed be the only name that 256 exists for the device. It is therefore quite possible that the URI will 257 duplicate the CN, and may be the only identifier present (that is, there's no 258 full DN but only a single CN field). 260 By long-standing convention, URIs in certificates are given without a scheme 261 specifier. For example a SSL/TLS server certificate would contain 262 www.example.com rather than https://www.example.com, and an S/MIME certificate 263 would contain user@example.com rather than mailto:user@example.com. This 264 convention is extended to other URI types as well, so that a certificate 265 containing the (effective) URIs im:user@example.com and xmpp:user@example.com 266 would be queried using the single URI user@example.com. The certificate store 267 would then return all certificates containing this URI, leaving it to the 268 client to determine which one is most appropriate for its use. This approach 269 is taken both because for the most common URI types there's no schema 270 specifier (see the paragraphs above) and no easy way to determine what the 271 intended use is (an SSL/TLS server certificate is simply one presented by an 272 SSL/TLS server), and because the relying party/client is in a better position 273 to judge the certificate's most appropriate use than the certificate store 274 server. 276 Another possible identifier that has been suggested is an IP address or DNS 277 name, which will be required for web-enabled embedded devices. This is 278 necessary to allow for example a home automation controller to be queried for 279 certificates for the devices that it controls. Since this value is regarded 280 as the CN for the device, common practice is to use this value for the CN in 281 the same way that web server certificates set the CN to the server's DNS name, 282 so this option is already covered in a widely-accepted manner. 284 The name and email address are an exact copy of what is present in the 285 certificate, without any canonicalisation or rewriting (other than the 286 transport encoding required by HTTP). This follows standard implementation 287 practice, which transfers an exact copy of these data items in order to avoid 288 problems due to character set translation, handling of whitespace, and other 289 issues. 291 Hashes are used for arbitrary-length fields such as ones containing DNs in 292 place of the full field to keep the length manageable. In addition the use of 293 the hashed form emphasizes the fact that searching for structured name data 294 isn't a supported feature, since this is a simple interface to a {key,value} 295 certificate store rather than an HTTP interface to an X.500 directory. Users 296 specifically requiring an HTTP interface to X.500 may use technology such as 297 HTTP LDAP gateways for this purpose. 299 Although clients will always submit a fixed 160-bit value, servers are free to 300 use as many bits of this value as they require, for example a server may 301 choose to use only the first 40 or 64 or 80 or 128 bits for efficiency in 302 searching and maintaining indices. 304 PGP has traditionally encoded IDs using a C-style 0xABCDEF notation based on 305 the display format used for IDs in PGP 2.0. Unfortunately, strings in this 306 format are also valid strings in the base64 format, complicated further by the 307 fact that near-misses such as 0xABCDRF could be either a mistyped attempt at a 308 hex ID or a valid base64 ID. For this reason, and to ensure consistency, 309 base64 IDs are used throughout this specification. The search keys used 310 internally will be binary values, so whether these are converted from ASCII- 311 hex or base64 is immaterial in the long run. 313 The attributes are given shortened name forms (for example iAndSHash in place 314 of issuerAndSerialNumberHash) in order to keep the lengths reasonable, or 315 common name forms (for example email in place of rfc822Name, rfc822Mailbox, 316 emailAddress, mail, email, etc) where multiple name forms exist. 318 In some cases users may require additional, application-specific attribute 319 types. For example, a healthcare application that uses a healthcare ID as the 320 primary key for its databases may require the ability to perform certificate 321 lookups based on this healthcare ID. The formatting and use of such 322 application-specific identifiers is beyond the scope of this document, however 323 they should begin with 'x-' to ensure that they don't conflict with 324 identifiers that may be defined in future versions of this specification. 326 2.5.2 Checking of Input Values 328 The attribute value portion of the identifier should be carefully checked for 329 invalid characters since allowing raw data through presents a security risk. 330 Consider for example a certificate/public key store implemented using an RDBMS 331 in which the SQL query is built up as "SELECT certificate FROM certificates 332 WHERE iHash = " + . If is set to "ABCD;DELETE FROM 333 certificates" the results of the query will be quite different from what was 334 expected by the certificate store administrators. Even a read-only query can 335 be problematic, for example setting to "UNION SELECT password 336 FROM master.sysxlogins" will list all passwords in an SQL Server database (in 337 an easily-decrypted format) if the user is running under the sa (DBA) account. 338 For this reason only valid base64 encodings should be allowed. The same 339 checking applies to queries by name or email address. 341 Straightforward sanitisation of queries may not be sufficient to prevent all 342 attacks, for example a filter that removes the SQL query string "DELETE" can 343 be bypassed by submitting the string embedded in another instance of the 344 string. Removing "DELETE" from "DELDELETEETE" leaves the outer "DELETE" in 345 place. Abusing the truncation of over-long strings by filters can also be 346 used as a means of attack, with the attacker ensuring that the truncation 347 occurs in the middle of an escape sequence, bypassing the filtering. Although 348 in theory recursive filtering may help here, the use of parameterised queries 349 (often called placeholders) that aren't vulnerable to SQL injection should be 350 used to avoid these attacks. More information on securing database back-ends 351 may be found in [Birkholz], and more comments on sanitisation and safety 352 concerns may be found in the security considerations section. 354 2.5.3 URI Notes 356 Pre-constructed URIs that fetch a certificate/public key matching a fixed 357 search criterion may be useful for situations such as web pages or business 358 cards, or even for technical support/helpdesk staff to mail to users who can't 359 find the certificate themselves. These URIs may also be used to enforce 360 privacy measures when distributing certificates by perturbing the search key 361 in a manner known only to the certificate/public key store, or to the 362 certificate store and users (in other words by converting the URI into a 363 capability). For example a user with a newly-issued certificate could be 364 instructed to fetch it with a key of "x-encrCertHash=...", which is decrypted 365 by the certificate store to fetch the appropriate certificate, ensuring that 366 only the certificate owner can fetch their certificate immediately after 367 issue. Similarly, an organisation that doesn't want to make its certificates 368 available for public query might require a MAC on search keys (e.g. "x- 369 macCertHash=...") to ensure that only authorised users can search for 370 certificates (although a more logical place for access control, if a true web 371 server is being used to access the store, would obviously be at the HTTP 372 level). 374 The query types have been specifically chosen to be not just an HTTP interface 375 to LDAP but as a general-purpose retrieval mechanism that allows arbitrary 376 certificate/public key storage mechanisms (with a bias towards simple 377 {key,value} stores, which are deployed almost universally, whether as ISAM, 378 Berkeley DB, or an RDBMS) to be employed as back-ends. This specification has 379 been deliberately written to be technology-neutral, allowing the use of any 380 {key,value} lookup mechanism to be used. It doesn't matter if you choose to 381 have trained chimpanzees look up certificates in books of tables, as long as 382 your method can provide the correct response with reasonable efficiency. 384 Certificate/public key and CRL stores are allocated separate URIs because they 385 may be implemented using different mechanisms. A certificate store typically 386 contains large numbers of small items while a CRL store contains a very small 387 number of potentially large items, by providing independant URIs it's possible 388 to implement the two stores using mechanisms tailored to the data they 389 contain. 391 PGP combines key and revocation information into a single data object, so that 392 it's possible to return both public keys and revocation information from the 393 same URI. If distinct key and revocation servers are available, these can 394 provide a slight performance gain since fetching revocation information 395 doesn't require fetching the key that it applies to. If no separate servers 396 are available, a single server can be used to satisfy both types of queries 397 with a slight performance loss since fetching revocation information will also 398 fetch the public key data associated with the revocation data. 400 2.5.4 Responses 402 The disallowance of exotic encoding forms reflects the fact that most clients 403 (and many servers, particularly for embedded devices) are not general-purpose 404 web browsers or servers capable of handling an arbitrary range of encoding 405 forms and types, but simply basic HTTP engines attached to key management 406 applications. In other words the HTTP interface is a rudimentary add-on to a 407 key management application, rather than key-management being an add-on to a 408 general-purpose web client or server. Eliminating unnecessary choices 409 simplifies the implementation task and reduces code size and complexity, with 410 an accompanying decrease in the probability of security issues arising from 411 the added complexity. 413 The use of an "Accept-encoding: identity" header would achieve the same effect 414 as disallowing any additional encodings and may indeed be useful since section 415 14.3 of [RFC2616] indicates that the absence of this header may be taken to 416 mean that any encoding is permitted. However this unnecessarily bloats the 417 HTTP header in a potentially performance-affecting manner (see section 2.5.5), 418 whereas establishing a requirement that the response be returned without any 419 additional decoration avoids the need to specify this in each request. 420 Implementations should therefore omit the Accept-encoding header entirely or 421 if it's necessary to include it, include "identity" or the wildcard "*" as an 422 accepted content-encoding type. 424 Use of chunked encoding is given as a SHOULD NOT rather than a MUST NOT 425 because support for it is required by [RFC2616]. Nevertheless, this form of 426 encoding is strongly discouraged as the data quantities being transferred 427 (1-2kB) make it entirely unnecessary, and support for this encoding form is 428 vunerable to various implementation bugs, some of which may affect security. 429 However, implementors should be aware that many versions of the Apache web 430 server will unnecessarily use chunked encoding when returning responses. 431 Although it would be better to make this a MUST NOT, this would render clients 432 that rejected it incompatible with the world's most widely-used web server. 433 For this reason, support for chunked encoding is strongly discouraged, but 434 nevertheless permitted. Clients that choose not to support it should be aware 435 that they may run into problems when communicating with Apache-based HTTP 436 certificate stores. 438 Multiple responses are returned as multipart/mixed rather than an ASN.1 439 SEQUENCE OF Certificate or PKCS #7/CMS certificate chain (degenerate signed 440 data containing only certificates) because this is more straightforward to 441 implement with standard web-enabled tools. An additional advantage is that it 442 doesn't restrict this access mechanism to DER-based data, allowing it to be 443 extended to other certificate types such as XML, PGP, and SPKI. 445 2.5.5 Performance Issues 447 Where high throughput/performance under load is a critical issue, a main- 448 memory database that acts as a form of content cache may be interposed between 449 the on-disk database and the HTTP interface [Garcia-Molina]. A main-memory 450 database provides the same functionality as an on-disk database and is fully 451 transparent to the HTTP front-end, but offers buffer management and retrieval 452 facilities optimised for memory-resident data. Where further scalability is 453 required, the content-cacheing system could be implemented as a cluster of 454 main-memory databases [Ji]. 456 Various network efficiency considerations need to be taken into account when 457 implementing this certificate/public key distribution mechanism. For example, 458 a simplistic implementation that performs two writes (the HTTP header and the 459 certificate written seperately) followed by a read will interact badly with 460 TCP delayed-ACK and slow-start. This occurs because the TCP MSS is typically 461 1460 bytes on a LAN (Ethernet) or 512/536 bytes on a WAN, while HTTP headers 462 are ~200-300 bytes, far less than the MSS. When an HTTP message is first 463 sent, the TCP congestion window begins at one segment, with the TCP slow-start 464 then doubling its size for each ACK. Sending the headers separately will send 465 one short segment and a second MSS-size segment, whereupon the TCP stack will 466 wait for the responder's ACK before continuing. The responder gets both 467 segments, then delays its ACK for 200ms in the hopes of piggybacking it on 468 responder data, which is never sent since it's still waiting for the rest of 469 the HTTP body from the initiator. As a result, this results in a 200ms (+ 470 assorted RTT) delay in each message sent. 472 There are various other considerations that need to be taken into account in 473 order to provide maximum efficiency. These are covered in depth elsewhere 474 [Spero] [Heidemann] [Nielsen]. In addition, modifications to TCP's behaviour 475 such as the use of 4K initial windows [RFC3390] (designed to reduce small HTTP 476 transfer times to a single RTT) should also ameliorate some of these issues. 478 A rule of thumb for optimal performance is to combine the HTTP header and data 479 payload into a single write (any reasonable HTTP implementation will do this 480 anyway, thanks to the considerable body of experience that exists for HTTP 481 server performance tuning), and to keep the HTTP headers to a minimum to try 482 and fit data within the TCP MSS. For example since this protocol doesn't 483 involve a web browser, there's no need to include various common browser- 484 related headers such as ones detailing software versions, acceptable 485 languages, and so on. 487 2.5.6 Miscellaneous 489 The interface specified in this document is a basic read-only one of the type 490 that will be used by the majority of clients. The handling of updates (both 491 insertion and deletion) is a complex issue involving both technological issues 492 (a variety of fields used for indexing and information retrieval need to be 493 specified in a technology-neutral manner, or the certificate store needs to 494 perform its own parsing of the item being added, moving it from a near- 495 universal key=value lookup mechanism to a full public-key/certificate 496 processing system) and political ones (who can perform updates to the 497 certificate store, and under what conditions?). Because of this complexity, 498 the details of the any potential update mechanism are left as a local 499 configuration issue, although they may at some point be covered in a future 500 document if there is sufficient demand. 502 Concerns have been raised over the use of HTTP as a substrate [RFC3205]. The 503 mechanism described here, which implements a straightforward request/response 504 protocol with the same semantics as traditional HTTP requests, is unaffected 505 by these issues. Specifically, it does not implement any form of complex RPC 506 mechanism, does not require HTTP security measures, is not affected by 507 firewalls (since it uses only a basic HTTP GET rather than layering a new 508 protocol on top of HTTP), has well-defined MIME media types specified in 509 standards documents, and so on. As such, the concerns expressed in [RFC3205] 510 do not apply here. In addition although a number of servers still don't fully 511 support some of the more advanced features of HTTP 1.1 [Krishnamurthy], the 512 minimal subset used here is well-supported by the majority of servers and HTTP 513 implementations. 515 This access mechanism is similar to the PGP HKP protocol [HKP], however the 516 latter is almost entirely undocumented and requires that implementors reverse- 517 engineer other implementations. Because of this lack of standardisation, no 518 attempt has been made to ensure interoperability or compatibility with HKP- 519 based servers, although PGP developers provided much valuable input for this 520 document. One benefit that HKP does bring is extensive implementation 521 experience, which indicates that this is a very workable solution to the 522 problem of a simple certificate/public key retrieval mechanism. HKP servers 523 have been implemented using flat files, Berkeley DB, and various databases 524 such as Postgres and MySQL. 526 2.6 Examples 528 To convert the subject DN C=NZ, O=... CN=Fred Dagg into a search key: 530 Hash the DN, in the DER-encoded form it appears in the certificate, to 531 obtain: 533 96 4C 70 C4 1E C9 08 E5 CA 45 25 10 D6 C8 28 3A 1A C1 DF E2 535 base-64 encode this to obtain: 537 lkxwxB7JCOXKRSUQ1sgoOhrB3+I 539 (note the absence of trailing '=' padding). This is the search key to use in 540 the query URI. 542 To fetch all certificates useful for sending encrypted email to 543 foo@example.com: 545 GET /search.cgi?email=foo%40example.com HTTP/1.1 547 (for simplicity the additional Host: header required by [RFC2616] is omitted 548 here and in the following examples). In this case "/search.cgi" is the 549 abs_path portion of the query URI, and the request is submitted to the server 550 located at the net_loc portion of the query URI. Note the encoding of the '@' 551 symbol as per [RFC1866]. Remaining required headers such as the "Host" header 552 required by HTTP 1.1 have been omitted for the sake of clarity. 554 To fetch the CA certificate that issued the email certificate: 556 557 GET /search.cgi?sHash= HTTP/1.1 559 Alternatively, if chaining is by key identifier: 561 562 GET /search.cgi?sKIDHash= HTTP/1.1 564 To fetch other certificates belonging to the same user as the email 565 certificate: 567 568 GET /search.cgi?sHash= HTTP/1.1 570 To fetch the CRL for the certificate: 572 573 GET /search.cgi?iHash= HTTP/1.1 575 Note that since the differentiator is the URI base, the above two queries 576 appear identical (since the URI base isn't shown) but are in fact distinct. 578 To retrieve a key using XML methods, the (which contains the string 579 identifier for the key), used with the subject DN hash above, would be: 581 lkxwxB7JCOXKRSUQ1sgoOhrB3+I. 583 3. Locating HTTP Certificate Stores 585 In order to locate servers from which certificates may be retrieved, relying 586 parties can employ one or more of the following strategies: 588 Information contained in the certificate 589 Use of DNS SRV 590 Use of a "well-known" location 591 Manual configuration of the client software 593 The intent of the various options provided here is to make the certificate 594 store access as transparent as possible, only requiring manual user 595 configuration as a last resort. 597 3.1 Information in the Certificate 599 In order to convey to relying parties a well-known point of information 600 access, CAs SHOULD use the SubjectInfoAccess (SIA) and AuthorityInfoAccess 601 (AIA) extension [RFC3280] in certificates. The OID value for the accessMethod 602 is one of: 604 id-ad-http-certs OBJECT IDENTIFIER ::= { id-ad 6 } 605 id-ad-http-crls OBJECT IDENTIFIER ::= { id-ad 7 } 607 where: 609 id-ad OBJECT IDENTIFIER ::= { iso(1) 610 identified-organization(3) dod(6) 611 internet(1) security(5) mechanisms(5) 612 pkix(7) 48 } 614 and the corresponding accessLocation is the query URI. The use of this 615 facility provides a CA with a convenient, standard location to indicate where 616 further certificates may be found, for example for certification path 617 construction purposes. Note that it doesn't mean that the provision of 618 certificate store access services is limited to CAs only. 620 3.2 Use of DNS SRV 622 DNS SRV is a facility for specifying the location of the server(s) for a 623 specific protocol and domain [RFC2782]. For the certificate store interface, 624 the DNS SRV symbolic name for the certificate store interface SHALL be 625 "certificates". The name for the CRL store interface SHALL be "crls". The 626 name for the PGP public key store SHALL be "pgpkeys". The name for the PGP 627 revocation store SHALL be "pgprevocations". Handling of additional DNS SRV 628 facilities such as the priority and weight fields is as per [RFC2782]. 630 3.2.1 Example 632 If a CA with the domain example.com were to make its certificates available 633 via an HTTP certificate store interface, the server details could be obtained 634 by a lookup on: 636 _certificates._tcp.example.com 638 and 640 _crls._tcp.example.com 642 which would return the server(s) and port(s) for the service as specified in 643 [RFC2782]. 645 3.3 Use of a "well-known" Location 647 If no other location information is available, the certificate store interface 648 may be located at a "well-known" location constructed from the service 649 provider's domain name. In the usual case the URI is constructed by 650 prepending the type of information to be retrieved, either "certificates.", 651 "crls.", "pgpkeys.", or "pgprevocations." to the domain name to obtain the 652 net_loc portion of the URI and appending a fixed abs_path portion 653 "search.cgi". The URI form of the "well-known" location is therefore: 655 certificates./search.cgi 656 crls./search.cgi 657 pgpkeys./search.cgi 658 pgprevocations./search.cgi 660 Certificate store service providers SHOULD use these URIs in preference to 661 other alternatives. Note that the use of "search.cgi" does not imply the use 662 of CGI scripts [RFC3975] (this would be the exception rather than the rule, 663 since it would lead to a rather inefficient implementation), but merely 664 provides one possible (and relatively simple to set up) implementation 665 alternative (see the rationale for more on this). 667 A second case occurs when the certificate access service is being provided by 668 web-enabled embedded devices such as Universal Plug and Play devices [UPNP]. 669 These devices have a single, fixed net_loc (either an IP address or a DNS 670 name) and make services available via an HTTP interface. In this case the URI 671 is constructed by appending a fixed abs_path portion "certificates/search.cgi" 672 for certificates, "crls/search.cgi" for CRLs, "pgpkeys/search.cgi" for PGP 673 public keys, and "pgprevocations/search.cgi" for PGP revocation information to 674 the net_loc. The URI form of the "well-known" location is therefore: 676 /certificates/search.cgi 677 /crls/search.cgi 678 /pgpkeys/search.cgi 679 /pgprevocations/search.cgi 681 If certificate access as described in this document is implemented by the 682 device then it SHOULD use these URIs in preference to other alternatives (see 683 the rationale for more on this requirement). 685 3.3.1 Examples 687 If a CA with the domain example.com were to make its certificates available 688 via an HTTP certificate store interface, the "well-known" query URIs for 689 certificates and CRLs would be: 691 http://certificates.example.com/search.cgi 692 http://crls.example.com/search.cgi 694 A home automation controller with IP address 192.0.2.1 (a control point in 695 UPnP terminology) would make certificates for devices such as HVAC 696 controllers, lighting and appliance controllers, and fire and physical 697 intrusion detection devices available as: 699 http://192.0.2.1/certificates/search.cgi 700 http://192.0.2.1/crls/search.cgi 702 A print server with DNS name "printspooler" would make certificates for web- 703 enabled printers that it communicates with available as: 705 http://printspooler/certificates/search.cgi 706 http://printspooler/crls/search.cgi 708 3.4 Manual Configuration of the Client Software 710 The accessLocation for the HTTP certificate/public key/CRL store MAY be 711 configured locally at the client. This can be used if no other information is 712 available, or if it is necessary to override other information. 714 3.5 Implementation Notes and Rationale 716 This informative section documents the rationale behind the design in section 717 3 and provides guidance for implementors. 719 3.5.1 DNS SRV 721 The optimal solution for the problem of service location would be DNS SRV, 722 unfortunately the operating system used by the user group most desperately in 723 need of this type of handholding has no support for anything beyond the most 724 basic DNS address lookups, making it impossible to use DNS SRV with anything 725 but very recent Win2K and XP systems. To make things even more entertaining, 726 several of the function names and some of the function parameters changed at 727 various times during the Win2K phase of development, and the behaviour of 728 portions of the Windows sockets API changed in undocumented ways to match. 729 This leads to the unfortunate situation in which a Unix sysadmin can make use 730 of DNS SRV to avoid having to deal with technical configuration issues, but a 731 Windows'95 user can't. Because of these problems, an alternative to DNS SRV 732 is provided for situations where it's not possible to use this. 734 The SRV or well-known location option can frequently be automatically derived 735 by user software from currently-known parameters. For example if the 736 recipient's email address is @example.com, the user software would query 737 _certificates._tcp.example.com or go to certificates.example.com and request 738 the certificate. In addition user software may maintain a list of known 739 certificate sources in the way that known CA lists are maintained by web 740 browsers. The specific mention of support for redirection in section 2 741 emphasises the fact that many sites will outsource the certificate-storage 742 task. At worst all that will be required is the addition of a single static 743 web page pointing to the real server. Alternatives such as DNS CNAME RRs are 744 also possible, but may not be as easy to set up as HTTP redirects (corporate 745 policies tend to be more flexible in regard to web page contents than 746 modifying DNS configurations). 748 3.5.2 Well-known Locations 750 The well-known location URI is designed to make hosting options as flexible as 751 possible. Locating the service at www. would generally require 752 it to be handled by the provider's main web server, while using a distinct 753 server URI allows it to handled as desired by the provider. Although there 754 will no doubt be servers that implement the interface using Apache and Perl 755 scripts, a more logical implementation would consist of a simple network 756 interface to a key-and-value lookup mechanism such as Berkeley DB. The URI 757 form presented in section 3.3 allows for maximum flexibility, since it will 758 work with both web servers/CGI scripts and non-web-server-based network front- 759 ends for certificate stores. 761 3.5.3 Information in the Certificate 763 Implementations that require the use of nonstandard locations or ports or 764 HTTPS rather than HTTP in combination with well-known locations should use an 765 HTTP redirect at the well-known location to point to the nonstandard location. 766 For example if the print spooler in section 3.3 used an SSL-protected server 767 named printspooler-server with an abs_path portion of cert_access, it would 768 use an HTTP 302 redirect to https://printspooler-server/cert_access. This 769 combines the plug-and-play capability of well-known locations with the ability 770 to use nonstandard locations and ports. 772 The SIA and AIA extensions are used to indicate the location for the CRL store 773 interface rather than the CRLDistributionPoint (CRLDP) extension since the two 774 perform entirely different functions. A CRLDP contains "a pointer to the 775 current CRL", a fixed location containing a CRL for the current certificate, 776 while the SIA/AIA extension indicates "how to access CA information and 777 services for the subject/issuer of the certificate in which the extension 778 appears", in this case the CRL store interface that provides CRLs for any 779 certificates issued by the CA. In addition CRLDP associates other attribute 780 information with a query that is incompatible with the simple query mechanisms 781 presented in this document. 783 A single server can be used to handle both CRLDP and AIA/SIA queries provided 784 the CRLDP form uses an HTTP URI. Since CRLDP points to a single static 785 location for a CRL, a query can be pre-constructed and stored in the CRLDP 786 extension. Software that uses the CRLDP will retrieve the single CRL that 787 applies to the certificate from the server, and software that uses the AIA/SIA 788 can retrieve any CRL from the server. Similar pre-constructed URIs may also 789 be useful in other circumstances, for example for links on web pages, to place 790 in appropriate locations like the issuerAltName, or even for technical 791 support/helpdesk staff to email to users who can't find the certificate 792 themselves, as described in section 2.5. The resulting certstore URL, when 793 clicked on by the user, will directly access the certificate when used in 794 conjunction with any certificate-aware application such as a browser or mail 795 program. 797 3.5.4 Miscellaneous 799 Web-enabled (or more strictly HTTP-enabled) devices are intended to be plug- 800 and-play, with minimal (or no) user configuration necessary. The "well-known" 801 URI allows any known device (for example one discovered via UPNP's Simple 802 Service Discovery Protocol, SSDP) to be queried for certificates without 803 requiring further user configuration. Note that in practice no embedded 804 device would ever use the address given in the example (the de facto standard 805 address for web-enabled embedded devices is 192.168.1.x and not 192.0.2.x), 806 however IETF policy requires the use of this non-address for examples. 808 Protocols such as UPnP have their own means of disseminating device and 809 protocol information. For example, UPnP uses SOAP, which provides a 810 GetPublicKeys action for pulling device keys and a PresentKeys action for 811 pushing control point keys. The text in section 3.3 is not meant to imply 812 that this document overrides the existing UPnP mechanism, but merely that if a 813 device implements the mechanism described here, it should use the naming 814 scheme in section 3.3 rather than using arbitrary names. 816 4. Security Considerations 818 HTTP caching proxies are common on the Internet, and some proxies may not 819 check for the latest version of an object correctly. [RFC2616] specifies that 820 responses to query URLs should not be cached, and most proxies and servers 821 correctly implement the "Cache-Control: no-cache" mechanism, which can be used 822 to override cacheing ("Pragma: no-cache" for HTTP 1.0). However in the rare 823 instance in which an HTTP request for a certificate or CRL goes through a 824 misconfigured or otherwise broken proxy, the proxy may return an out-of-date 825 response. 827 Care should be taken to ensure that only valid queries are fed through to the 828 back-end used to retrieve certificates. Allowing an attacker to submit 829 arbitrary queries may allow them to manipulate the certificate store in 830 unexpected ways if the back-end tries to interpret the query contents. For 831 example if a certificate store is implemented using an RDBMS for which the 832 calling application assembles a complete SQL string to perform the query, and 833 the SQL query is built up as "SELECT certificate FROM certificates WHERE iHash 834 = " + , and is set to "X;DELETE FROM certificates" 835 the results of the query will be quite different from what was expected by the 836 certificate store administrator. The same applies to queries by name and 837 email address. Even a read-only query can be problematic, for example setting 838 to "UNION SELECT password FROM master.sysxlogins" will list all 839 passwords in an SQL Server database (in an easily-decrypted format) if the 840 user is running under the sa (DBA) account. Straightforward sanitisation of 841 queries may not be sufficient to prevent all attacks, for example a filter 842 that removes the SQL query string "DELETE" can be bypassed by submitting the 843 string embedded in another instance of the string. Removing "DELETE" from 844 "DELDELETEETE" leaves the outer "DELETE" in place. Abusing the truncation of 845 over-long strings by filters can also be used as a means of attack, with the 846 attacker ensuring that the truncation occurs in the middle of an escape 847 sequence, bypassing the filtering. The use of parameterised queries (often 848 called placeholders) that aren't vulnerable to SQL injection should be used to 849 avoid these attacks. 851 In addition since some query data may be en/decoded before being sent to the 852 back-end, applications should check both the en- and de-coded form for valid 853 data. A simple means of avoiding these problems is to use parameterised 854 commands rather than hand-assembling SQL strings for use in queries (this is 855 also more efficient for most database interfaces). The use of parameterised 856 commands means that the query value is never present in any position where it 857 could be interpreted as a portion of the query command. 859 Alongside filtering of queries, the back-end should be configured to disable 860 any form of update access via the web interface. For Berkeley DB this 861 restriction can be imposed by opening the certificate store in read-only mode 862 from the web interface. For relational databases, it can be imposed through 863 the SQL GRANT/REVOKE mechanism, for example "REVOKE ALL ON certificates FROM 864 webuser; GRANT SELECT ON certificates TO webuser" will allow read-only access 865 of the appropriate kind for the web interface. Server-specific security 866 measures may also be employed, for example SQL Server provides the built-in 867 db_datareader account which only allows read access to tables (but see the 868 note above about what can be done even with read-only access), and the ability 869 to run the server under a dedicated low-privilege account (a standard feature 870 of Unix systems). 872 The mechanism described in this document is not intended to function as a 873 trusted directory/database. In particular, users should not assume that just 874 because they fetched a public key or certificate from an entity claiming to be 875 X, that X has made any statement about the veracity of the public key or 876 certificate - the use of a signed representation of the items stored removes 877 the need to depend on the certificate store for any security service other 878 than availability. Although it's possible to implement a trusted 879 directory/database using HTTPS or some other form if secured/trusted link, 880 this is a local policy/configuration issue, and in the absence of such 881 additional security measures users should apply appropriate levels of 882 verification to any keys or certificates fetched before they take them into 883 use. 885 5. IANA Considerations 887 No action by IANA is needed. The AIA/SIA accessMethod types are identified by 888 object identifiers (OIDs) from an arc managed by the PKIX working group. 889 Should additional accessMethods be introduced (for example for attribute 890 certificates or non-X.509 certificate types), the advocates for such 891 accessMethods are expected to assign the necessary OIDs from their own arcs. 893 Acknowledgements 895 Anders Rundgren, Blake Ramsdell, Jeff Jacoby, David Shaw, and members of the 896 ietf-pkix working group provided useful input and feedback on this document. 898 Author Address 900 Peter Gutmann 901 University of Auckland 902 Private Bag 92019 903 Auckland, New Zealand 904 pgut001@cs.auckland.ac.nz 906 References (Normative) 908 [FIPS 180] Federal Information Processing Standards Publication (FIPS PUB) 909 180-1, Secure Hash Standard, 17 April 1995. 911 [RFC1866] "Hypertext Markup Language - 2.0", RFC 1866, T. Berners-Lee and D. 912 Connolly, November 1995. 914 [RFC2616] "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, R. Fielding, 915 J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, and 916 T. Berners-Lee, June 1999. 918 [RFC2119] "Key Words for Use in RFCs to Indicate Requirement Levels", 919 RFC 2119, S.Bradner, March 1997. 921 [RFC2440] "OpenPGP Message Format", RFC 2440, J. Callas, L. Donnerhacke, 922 H. Finney, and R. Thayer, November 1998. 924 [RFC2585] "Internet X.509 Public Key Infrastructure: Operational Protocols: 925 FTP and HTTP", RFC 2585, R. Housley and P. Hoffman, May 1999 927 [RFC2782] "A DNS RR for specifying the location of services (DNS SRV)", 928 RFC 2782, A.Gulbrandsen, P.Vixie, and L.Esibov, February 2000. 930 [RFC3156] "MIME Security with OpenPGP", M. Elkins, D. Del Torto, 931 R. Levien, and T. Roessler, August 2001. 933 [RFC3275] "XML-Signature Syntax and Processing", D. Eastlake 3rd, J. 934 Reagle, D. Solo, March 2002. 936 [RFC3280] "Internet X.509 Public Key Infrastructure: Certificate and CRL 937 Profile", RFC 3280, R. Housley, W. Ford, W. Polk, and D. Solo, 938 April 2002. 940 References (Informative) 942 [Birkholz] "Special Ops: Host and Network Security for Microsoft, Unix, 943 and Oracle", Erik Birkholz et al, Syngress Publishing, 944 November 2002. 946 [Garcia-Molina] "Main Memory Database Systems", Hector Garcia-Molina and 947 Kenneth Salem, IEEE Transactions on Knowledge and Data 948 Engineering, Vol.4, No.6 (December 1992), p.509. 950 [Gutmann] "A Reliable, Scalable General-purpose Certificate Store", P. 951 Gutmann, Proceedings of the 16th Annual Computer Security 952 Applications Conference, December 2000. 954 [Heidemann] "Performance Interactions Between P-HTTP and TCP 955 Implementations", J.Heidemann, ACM Computer Communications 956 Review, April 1997. 958 [HKP] "A PGP Public Key Server", Marc Horowitz, 2000, 959 http://www.mit.edu/afs/net.mit.edu/project/pks/thesis/paper/thesis.html. 960 A more complete and up-to-date overview of HKP may be obtained from 961 the source code of an open-source OpenPGP implementation such as GPG. 963 [Ji] "Affinity-based Management of Main Memory Database Clusters", Minwen 964 Ji, ACM Transactions on Internet Technology, Vol.2, No.4 (November 965 2002), p.307. 967 [Krishnamurthy] "PRO-COW: Protocol Compliance on the Web - A Longitudinal 968 Survey", Balachander Krishnamurthy and Martin Arlitt, 969 Proceedings of the 3rd Usenix Symposium on Internet 970 Technologies and Systems (USITS'01), March 2001, p.109. 972 [Nielsen] "Network Performance Effects of HTTP/1.1, CSS1, and PNG", 973 H.Nielsen, J.Gettys, A.Baird-Smith, E.Prud'hommeaux, H.Wium Lie, 974 and C.Lilley, 24 June 1997, 975 http://www.w3.org/Protocols/HTTP/1.0/Performance/Pipeline.html. 977 [PKCS11] PKCS #11 Cryptographic Token Interface Standard, RSA Laboratories, 978 December 1999. 980 [PKCS15] PKCS #15 Cryptographic Token Information Syntax Standard, RSA 981 Laboratories, June 2000. 983 [RFC3205] "On the use of HTTP as a substrate", RFC 3205, K.Moore, 984 February 2002. 986 [RFC3390] "Increasing TCP's Initial Window", RFC 3390, M.Allman, S.Floyd, 987 and C.Partridge, October 2002. 989 [RFC3875] "The Common Gateway Interface (CGI) Version 1.1", RFC 3875, 990 David Robinson and Ken Coar, October 2004. 992 [Spero] "Analysis of HTTP Performance Problems", S.Spero, July 1994, 993 http://www.w3.org/Protocols/HTTP/1.0/HTTPPerformance.html. 995 [UPNP] "Universal Plug and Play Device Architecture, Version 1.0", UPnP 996 Forum, 8 June 2000. 998 Full Copyright Statement 1000 Copyright (C) The Internet Society (2005). 1002 This document is subject to the rights, licenses and restrictions contained in 1003 BCP 78, and except as set forth therein, the authors retain all their rights. 1005 This document and the information contained herein are provided on an "AS IS" 1006 basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED 1007 BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE 1008 DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 1009 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS 1010 OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR 1011 PURPOSE.