source: draft-ietf-httpbis/orig/rfc2818.html

Last change on this file was 2564, checked in by julian.reschke@…, 6 years ago

update rfc2617.xml (ABNF alignment was off from published version), regen all HTML

  • Property svn:eol-style set to native
  • Property svn:mime-type set to text/html
File size: 31.1 KB
Line 
1<!DOCTYPE html
2  PUBLIC "-//W3C//DTD HTML 4.01//EN">
3<html lang="en">
4   <head profile="http://dublincore.org/documents/2008/08/04/dc-html/">
5      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
6      <title>HTTP Over TLS</title><style type="text/css" title="Xml2Rfc (sans serif)">
7a {
8  text-decoration: none;
9}
10a.smpl {
11  color: black;
12}
13a:hover {
14  text-decoration: underline;
15}
16a:active {
17  text-decoration: underline;
18}
19address {
20  margin-top: 1em;
21  margin-left: 2em;
22  font-style: normal;
23}
24body {
25  color: black;
26  font-family: cambria, helvetica, arial, sans-serif;
27  font-size: 11pt;
28  margin-right: 2em;
29}
30cite {
31  font-style: normal;
32}
33dl {
34  margin-left: 2em;
35}
36ul.empty {
37  list-style-type: none;
38}
39ul.empty li {
40  margin-top: .5em;
41}
42dl p {
43  margin-left: 0em;
44}
45dt {
46  margin-top: .5em;
47}
48h1 {
49  font-size: 130%;
50  line-height: 21pt;
51  page-break-after: avoid;
52}
53h1.np {
54  page-break-before: always;
55}
56h2 {
57  font-size: 120%;
58  line-height: 15pt;
59  page-break-after: avoid;
60}
61h3 {
62  font-size: 110%;
63  page-break-after: avoid;
64}
65h4, h5, h6 {
66  page-break-after: avoid;
67}
68h1 a, h2 a, h3 a, h4 a, h5 a, h6 a {
69  color: black;
70}
71img {
72  margin-left: 3em;
73}
74li {
75  margin-left: 2em;
76}
77ol {
78  margin-left: 2em;
79}
80ol.la {
81  list-style-type: lower-alpha;
82}
83ol.ua {
84  list-style-type: upper-alpha;
85}
86ol p {
87  margin-left: 0em;
88}
89p {
90  margin-left: 2em;
91}
92pre {
93  margin-left: 3em;
94  background-color: lightyellow;
95  padding: .25em;
96  page-break-inside: avoid;
97}
98pre.text2 {
99  border-style: dotted;
100  border-width: 1px;
101  background-color: #f0f0f0;
102  width: 69em;
103}
104pre.inline {
105  background-color: white;
106  padding: 0em;
107}
108pre.text {
109  border-style: dotted;
110  border-width: 1px;
111  background-color: #f8f8f8;
112  width: 69em;
113}
114pre.drawing {
115  border-style: solid;
116  border-width: 1px;
117  background-color: #f8f8f8;
118  padding: 2em;
119}
120table {
121  margin-left: 2em;
122}
123table.header {
124  border-spacing: 1px;
125  width: 95%;
126  font-size: 11pt;
127  color: white;
128}
129td.top {
130  vertical-align: top;
131}
132td.topnowrap {
133  vertical-align: top;
134  white-space: nowrap;
135}
136table.header td {
137  background-color: gray;
138  width: 50%;
139}
140td.reference {
141  vertical-align: top;
142  white-space: nowrap;
143  padding-right: 1em;
144}
145thead {
146  display:table-header-group;
147}
148ul.toc, ul.toc ul {
149  list-style: none;
150  margin-left: 1.5em;
151  padding-left: 0em;
152}
153ul.toc li {
154  line-height: 150%;
155  font-weight: bold;
156  margin-left: 0em;
157}
158ul.toc li li {
159  line-height: normal;
160  font-weight: normal;
161  font-size: 10pt;
162  margin-left: 0em;
163}
164li.excluded {
165  font-size: 0pt;
166}
167ul p {
168  margin-left: 0em;
169}
170.title, .filename, h1, h2, h3, h4 {
171  font-family: candara, helvetica, arial, sans-serif;
172}
173samp, tt, code, pre {
174  font: consolas, monospace;
175}
176ul.ind, ul.ind ul {
177  list-style: none;
178  margin-left: 1.5em;
179  padding-left: 0em;
180  page-break-before: avoid;
181}
182ul.ind li {
183  font-weight: bold;
184  line-height: 200%;
185  margin-left: 0em;
186}
187ul.ind li li {
188  font-weight: normal;
189  line-height: 150%;
190  margin-left: 0em;
191}
192.avoidbreak {
193  page-break-inside: avoid;
194}
195.bcp14 {
196  font-style: normal;
197  text-transform: lowercase;
198  font-variant: small-caps;
199}
200.comment {
201  background-color: yellow;
202}
203.center {
204  text-align: center;
205}
206.error {
207  color: red;
208  font-style: italic;
209  font-weight: bold;
210}
211.figure {
212  font-weight: bold;
213  text-align: center;
214  font-size: 10pt;
215}
216.filename {
217  color: #333333;
218  font-size: 75%;
219  font-weight: bold;
220  line-height: 21pt;
221  text-align: center;
222}
223.fn {
224  font-weight: bold;
225}
226.left {
227  text-align: left;
228}
229.right {
230  text-align: right;
231}
232.title {
233  color: green;
234  font-size: 150%;
235  line-height: 18pt;
236  font-weight: bold;
237  text-align: center;
238  margin-top: 36pt;
239}
240.warning {
241  font-size: 130%;
242  background-color: yellow;
243}
244
245
246@media print {
247  .noprint {
248    display: none;
249  }
250
251  a {
252    color: black;
253    text-decoration: none;
254  }
255
256  table.header {
257    width: 90%;
258  }
259
260  td.header {
261    width: 50%;
262    color: black;
263    background-color: white;
264    vertical-align: top;
265    font-size: 110%;
266  }
267
268  ul.toc a:nth-child(2)::after {
269    content: leader('.') target-counter(attr(href), page);
270  }
271
272  ul.ind li li a {
273    content: target-counter(attr(href), page);
274  }
275
276  .print2col {
277    column-count: 2;
278    -moz-column-count: 2;
279    column-fill: auto;
280  }
281}
282
283@page {
284  @top-left {
285       content: "RFC 2818";
286  }
287  @top-right {
288       content: "May 2000";
289  }
290  @top-center {
291       content: "HTTP Over TLS";
292  }
293  @bottom-left {
294       content: "Rescorla";
295  }
296  @bottom-center {
297       content: "Informational";
298  }
299  @bottom-right {
300       content: "[Page " counter(page) "]";
301  }
302}
303
304@page:first {
305    @top-left {
306      content: normal;
307    }
308    @top-right {
309      content: normal;
310    }
311    @top-center {
312      content: normal;
313    }
314}
315</style><link rel="Contents" href="#rfc.toc">
316      <link rel="Author" href="#rfc.authors">
317      <link rel="Copyright" href="#rfc.copyright">
318      <link rel="Index" href="#rfc.index">
319      <link rel="Chapter" title="1 Introduction" href="#rfc.section.1">
320      <link rel="Chapter" title="2 HTTP Over TLS" href="#rfc.section.2">
321      <link rel="Chapter" title="3 Endpoint Identification" href="#rfc.section.3">
322      <link rel="Chapter" href="#rfc.section.4" title="4 References">
323      <link rel="Appendix" title="A Security Considerations" href="#rfc.section.A">
324      <link rel="Alternate" title="Authorative ASCII Version" href="http://www.ietf.org/rfc/rfc2818.txt">
325      <link rel="Help" title="RFC-Editor's Status Page" href="http://www.rfc-editor.org/info/rfc2818">
326      <link rel="Help" title="Additional Information on tools.ietf.org" href="http://tools.ietf.org/html/rfc2818">
327      <meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.611, 2013/11/27 12:23:51, XSLT vendor: SAXON 8.9 from Saxonica http://www.saxonica.com/">
328      <link rel="schema.dct" href="http://purl.org/dc/terms/">
329      <meta name="dct.creator" content="Rescorla, E.">
330      <meta name="dct.identifier" content="urn:ietf:rfc:2818">
331      <meta name="dct.issued" scheme="ISO8601" content="2000-05">
332      <meta name="dct.abstract" content="This memo describes how to use TLS to secure HTTP connections over the Internet. Current practice is to layer HTTP over SSL (the predecessor to TLS), distinguishing secured traffic from insecure traffic by the use of a different server port. This document documents that practice using TLS. A companion document describes a method for using HTTP/TLS over the same port as normal HTTP [RFC2817].">
333      <meta name="dct.isPartOf" content="urn:issn:2070-1721">
334      <meta name="description" content="This memo describes how to use TLS to secure HTTP connections over the Internet. Current practice is to layer HTTP over SSL (the predecessor to TLS), distinguishing secured traffic from insecure traffic by the use of a different server port. This document documents that practice using TLS. A companion document describes a method for using HTTP/TLS over the same port as normal HTTP [RFC2817].">
335   </head>
336   <body>
337      <table class="header">
338         <tbody>
339            <tr>
340               <td class="left">Network Working Group</td>
341               <td class="right">E. Rescorla</td>
342            </tr>
343            <tr>
344               <td class="left">Request for Comments: 2818</td>
345               <td class="right">RTFM, Inc.</td>
346            </tr>
347            <tr>
348               <td class="left">Category: Informational</td>
349               <td class="right">May 2000</td>
350            </tr>
351         </tbody>
352      </table>
353      <p class="title">HTTP Over TLS</p>
354      <div id="rfc.status">
355         <h1><a href="#rfc.status">Status of This Memo</a></h1>
356         <p>This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution
357            of this memo is unlimited.
358         </p>
359      </div>
360      <div id="rfc.copyrightnotice">
361         <h1><a href="#rfc.copyrightnotice">Copyright Notice</a></h1>
362         <p>Copyright © The Internet Society (2000). All Rights Reserved.</p>
363      </div>
364      <h1 id="rfc.abstract"><a href="#rfc.abstract">Abstract</a></h1>
365      <p>This memo describes how to use TLS to secure HTTP connections over the Internet. Current practice is to layer HTTP over SSL
366         (the predecessor to TLS), distinguishing secured traffic from insecure traffic by the use of a different server port. This
367         document documents that practice using TLS. A companion document describes a method for using HTTP/TLS over the same port
368         as normal HTTP [RFC2817].
369      </p>
370      <hr class="noprint">
371      <h1 class="np" id="rfc.toc"><a href="#rfc.toc">Table of Contents</a></h1>
372      <ul class="toc">
373         <li><a href="#rfc.section.1">1.</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.1">Introduction</a><ul>
374               <li><a href="#rfc.section.1.1">1.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.1.1">Requirements Terminology</a></li>
375            </ul>
376         </li>
377         <li><a href="#rfc.section.2">2.</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.2">HTTP Over TLS</a><ul>
378               <li><a href="#rfc.section.2.1">2.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.2.1">Connection Initiation</a></li>
379               <li><a href="#rfc.section.2.2">2.2</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.2.2">Connection Closure</a><ul>
380                     <li><a href="#rfc.section.2.2.1">2.2.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.2.2.1">Client Behavior</a></li>
381                     <li><a href="#rfc.section.2.2.2">2.2.2</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.2.2.2">Server Behavior</a></li>
382                  </ul>
383               </li>
384               <li><a href="#rfc.section.2.3">2.3</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.2.3">Port Number</a></li>
385               <li><a href="#rfc.section.2.4">2.4</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.2.4">URI Format</a></li>
386            </ul>
387         </li>
388         <li><a href="#rfc.section.3">3.</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.3">Endpoint Identification</a><ul>
389               <li><a href="#rfc.section.3.1">3.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.3.1">Server Identity</a></li>
390               <li><a href="#rfc.section.3.2">3.2</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.3.2">Client Identity</a></li>
391            </ul>
392         </li>
393         <li><a href="#rfc.section.4">4.</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.references">References</a></li>
394         <li><a href="#rfc.authors">Author's Address</a></li>
395         <li><a href="#rfc.section.A">A.</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.A">Security Considerations</a></li>
396         <li><a href="#rfc.index">Index</a></li>
397         <li><a href="#rfc.ipr">Intellectual Property and Copyright Statements</a></li>
398      </ul>
399      <div>
400         <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a>&nbsp;Introduction
401         </h1>
402         <p id="rfc.section.1.p.1">HTTP <a href="#RFC2616"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a> was originally used in the clear on the Internet. However, increased use of HTTP for sensitive applications has required security
403            measures. SSL, and its successor TLS <a href="#RFC2246"><cite title="The TLS Protocol Version 1.0">[RFC2246]</cite></a> were designed to provide channel-oriented security. This document describes how to use HTTP over TLS.
404         </p>
405         <div>
406            <h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a>&nbsp;Requirements Terminology
407            </h2>
408            <p id="rfc.section.1.1.p.1">Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and "MAY" that appear in this document are to be interpreted
409               as described in <a href="#RFC2119"><cite title="Key words for use in RFCs to Indicate Requirement Levels">[RFC2119]</cite></a>.
410            </p>
411         </div>
412      </div>
413      <div>
414         <h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;HTTP Over TLS
415         </h1>
416         <p id="rfc.section.2.p.1">Conceptually, HTTP/TLS is very simple. Simply use HTTP over TLS precisely as you would use HTTP over TCP.</p>
417         <div>
418            <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a>&nbsp;Connection Initiation
419            </h2>
420            <p id="rfc.section.2.1.p.1">The agent acting as the HTTP client should also act as the TLS client. It should initiate a connection to the server on the
421               appropriate port and then send the TLS ClientHello to begin the TLS handshake. When the TLS handshake has finished. The client
422               may then initiate the first HTTP request. All HTTP data <em class="bcp14">MUST</em> be sent as TLS "application data". Normal HTTP behavior, including retained connections should be followed.
423            </p>
424         </div>
425         <div>
426            <h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a>&nbsp;Connection Closure
427            </h2>
428            <p id="rfc.section.2.2.p.1">TLS provides a facility for secure connection closure. When a valid closure alert is received, an implementation can be assured
429               that no further data will be received on that connection. TLS implementations <em class="bcp14">MUST</em> initiate an exchange of closure alerts before closing a connection. A TLS implementation <em class="bcp14">MAY</em>, after sending a closure alert, close the connection without waiting for the peer to send its closure alert, generating an
430               "incomplete close". Note that an implementation which does this <em class="bcp14">MAY</em> choose to reuse the session. This <em class="bcp14">SHOULD</em> only be done when the application knows (typically through detecting HTTP message boundaries) that it has received all the
431               message data that it cares about.
432            </p>
433            <p id="rfc.section.2.2.p.2">As specified in <a href="#RFC2246"><cite title="The TLS Protocol Version 1.0">[RFC2246]</cite></a>, any implementation which receives a connection close without first receiving a valid closure alert (a "premature close") <em class="bcp14">MUST NOT</em> reuse that session. Note that a premature close does not call into question the security of the data already received, but
434               simply indicates that subsequent data might have been truncated. Because TLS is oblivious to HTTP request/response boundaries,
435               it is necessary to examine the HTTP data itself (specifically the Content-Length header) to determine whether the truncation
436               occurred inside a message or between messages.
437            </p>
438            <div>
439               <h3 id="rfc.section.2.2.1"><a href="#rfc.section.2.2.1">2.2.1</a>&nbsp;Client Behavior
440               </h3>
441               <p id="rfc.section.2.2.1.p.1">Because HTTP uses connection closure to signal end of server data, client implementations <em class="bcp14">MUST</em> treat any premature closes as errors and the data received as potentially truncated. While in some cases the HTTP protocol
442                  allows the client to find out whether truncation took place so that, if it received the complete reply, it may tolerate such
443                  errors following the principle to "[be] strict when sending and tolerant when receiving" [RFC1958], often truncation does
444                  not show in the HTTP protocol data; two cases in particular deserve special note:
445               </p>
446               <ul class="empty">
447                  <li>A HTTP response without a Content-Length header. Since data length in this situation is signalled by connection close a premature
448                     close generated by the server cannot be distinguished from a spurious close generated by an attacker.
449                  </li>
450                  <li>A HTTP response with a valid Content-Length header closed before all data has been read. Because TLS does not provide document
451                     oriented protection, it is impossible to determine whether the server has miscomputed the Content-Length or an attacker has
452                     truncated the connection.
453                  </li>
454               </ul>
455               <p id="rfc.section.2.2.1.p.3">There is one exception to the above rule. When encountering a premature close, a client <em class="bcp14">SHOULD</em> treat as completed all requests for which it has received as much data as specified in the Content-Length header.
456               </p>
457               <p id="rfc.section.2.2.1.p.4">A client detecting an incomplete close <em class="bcp14">SHOULD</em> recover gracefully. It <em class="bcp14">MAY</em> resume a TLS session closed in this fashion.
458               </p>
459               <p id="rfc.section.2.2.1.p.5">Clients <em class="bcp14">MUST</em> send a closure alert before closing the connection. Clients which are unprepared to receive any more data <em class="bcp14">MAY</em> choose not to wait for the server's closure alert and simply close the connection, thus generating an incomplete close on
460                  the server side.
461               </p>
462            </div>
463            <div>
464               <h3 id="rfc.section.2.2.2"><a href="#rfc.section.2.2.2">2.2.2</a>&nbsp;Server Behavior
465               </h3>
466               <p id="rfc.section.2.2.2.p.1">RFC 2616 permits an HTTP client to close the connection at any time, and requires servers to recover gracefully. In particular,
467                  servers <em class="bcp14">SHOULD</em> be prepared to receive an incomplete close from the client, since the client can often determine when the end of server data
468                  is. Servers <em class="bcp14">SHOULD</em> be willing to resume TLS sessions closed in this fashion.
469               </p>
470               <p id="rfc.section.2.2.2.p.2">Implementation note: In HTTP implementations which do not use persistent connections, the server ordinarily expects to be
471                  able to signal end of data by closing the connection. When Content-Length is used, however, the client may have already sent
472                  the closure alert and dropped the connection.
473               </p>
474               <p id="rfc.section.2.2.2.p.3">Servers <em class="bcp14">MUST</em> attempt to initiate an exchange of closure alerts with the client before closing the connection. Servers <em class="bcp14">MAY</em> close the connection after sending the closure alert, thus generating an incomplete close on the client side.
475               </p>
476            </div>
477         </div>
478         <div>
479            <h2 id="rfc.section.2.3"><a href="#rfc.section.2.3">2.3</a>&nbsp;Port Number
480            </h2>
481            <p id="rfc.section.2.3.p.1">The first data that an HTTP server expects to receive from the client is the Request-Line production. The first data that
482               a TLS server (and hence an HTTP/TLS server) expects to receive is the ClientHello. Consequently, common practice has been
483               to run HTTP/TLS over a separate port in order to distinguish which protocol is being used. When HTTP/TLS is being run over
484               a TCP/IP connection, the default port is 443. This does not preclude HTTP/TLS from being run over another transport. TLS only
485               presumes a reliable connection-oriented data stream.
486            </p>
487         </div>
488         <div>
489            <div id="rfc.iref.h.1"></div>
490            <div id="rfc.iref.u.1"></div>
491            <h2 id="rfc.section.2.4"><a href="#rfc.section.2.4">2.4</a>&nbsp;URI Format
492            </h2>
493            <p id="rfc.section.2.4.p.1">HTTP/TLS is differentiated from HTTP URIs by using the 'https' protocol identifier in place of the 'http' protocol identifier.
494               An example URI specifying HTTP/TLS is:
495            </p>
496            <div id="rfc.figure.u.1"></div><pre class="text">
497  https://www.example.com/~smith/home.html
498</pre></div>
499      </div>
500      <div>
501         <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a>&nbsp;Endpoint Identification
502         </h1>
503         <div>
504            <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a>&nbsp;Server Identity
505            </h2>
506            <p id="rfc.section.3.1.p.1">In general, HTTP/TLS requests are generated by dereferencing a URI. As a consequence, the hostname for the server is known
507               to the client. If the hostname is available, the client <em class="bcp14">MUST</em> check it against the server's identity as presented in the server's Certificate message, in order to prevent man-in-the-middle
508               attacks.
509            </p>
510            <p id="rfc.section.3.1.p.2">If the client has external information as to the expected identity of the server, the hostname check <em class="bcp14">MAY</em> be omitted. (For instance, a client may be connecting to a machine whose address and hostname are dynamic but the client knows
511               the certificate that the server will present.) In such cases, it is important to narrow the scope of acceptable certificates
512               as much as possible in order to prevent man in the middle attacks. In special cases, it may be appropriate for the client
513               to simply ignore the server's identity, but it must be understood that this leaves the connection open to active attack.
514            </p>
515            <p id="rfc.section.3.1.p.3">If a subjectAltName extension of type dNSName is present, that <em class="bcp14">MUST</em> be used as the identity. Otherwise, the (most specific) Common Name field in the Subject field of the certificate <em class="bcp14">MUST</em> be used. Although the use of the Common Name is existing practice, it is deprecated and Certification Authorities are encouraged
516               to use the dNSName instead.
517            </p>
518            <p id="rfc.section.3.1.p.4">Matching is performed using the matching rules specified by <a href="#RFC2459"><cite title="Internet X.509 Public Key Infrastructure Certificate and CRL Profile">[RFC2459]</cite></a>. If more than one identity of a given type is present in the certificate (e.g., more than one dNSName name, a match in any
519               one of the set is considered acceptable.) Names may contain the wildcard character * which is considered to match any single
520               domain name component or component fragment. E.g., *.a.com matches foo.a.com but not bar.foo.a.com. f*.com matches foo.com
521               but not bar.com.
522            </p>
523            <p id="rfc.section.3.1.p.5">In some cases, the URI is specified as an IP address rather than a hostname. In this case, the iPAddress subjectAltName must
524               be present in the certificate and must exactly match the IP in the URI.
525            </p>
526            <p id="rfc.section.3.1.p.6">If the hostname does not match the identity in the certificate, user oriented clients <em class="bcp14">MUST</em> either notify the user (clients <em class="bcp14">MAY</em> give the user the opportunity to continue with the connection in any case) or terminate the connection with a bad certificate
527               error. Automated clients <em class="bcp14">MUST</em> log the error to an appropriate audit log (if available) and <em class="bcp14">SHOULD</em> terminate the connection (with a bad certificate error). Automated clients <em class="bcp14">MAY</em> provide a configuration setting that disables this check, but <em class="bcp14">MUST</em> provide a setting which enables it.
528            </p>
529            <p id="rfc.section.3.1.p.7">Note that in many cases the URI itself comes from an untrusted source. The above-described check provides no protection against
530               attacks where this source is compromised. For example, if the URI was obtained by clicking on an HTML page which was itself
531               obtained without using HTTP/TLS, a man in the middle could have replaced the URI. In order to prevent this form of attack,
532               users should carefully examine the certificate presented by the server to determine if it meets their expectations.
533            </p>
534         </div>
535         <div>
536            <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a>&nbsp;Client Identity
537            </h2>
538            <p id="rfc.section.3.2.p.1">Typically, the server has no external knowledge of what the client's identity ought to be and so checks (other than that the
539               client has a certificate chain rooted in an appropriate CA) are not possible. If a server has such knowledge (typically from
540               some source external to HTTP or TLS) it <em class="bcp14">SHOULD</em> check the identity as described above.
541            </p>
542         </div>
543      </div>
544      <h1 id="rfc.references"><a href="#rfc.section.4" id="rfc.section.4">4.</a> References
545      </h1>
546      <table>
547         <tr>
548            <td class="reference"><b id="RFC2459">[RFC2459]</b></td>
549            <td class="top"><a href="mailto:housley@spyrus.com" title="SPYRUS">Housley, R.</a>, <a href="mailto:wford@verisign.com" title="VeriSign, Inc.">Ford, W.</a>, <a href="mailto:wpolk@nist.gov" title="NIST">Polk, T.</a>, and <a href="mailto:david.solo@citicorp.com" title="Citicorp">D. Solo</a>, “<a href="http://tools.ietf.org/html/rfc2459">Internet X.509 Public Key Infrastructure Certificate and CRL Profile</a>”, RFC&nbsp;2459, January&nbsp;1999.
550            </td>
551         </tr>
552         <tr>
553            <td class="reference"><b id="RFC2616">[RFC2616]</b></td>
554            <td class="top"><a href="mailto:fielding@ics.uci.edu" title="University of California, Irvine">Fielding, R.</a>, <a href="mailto:jg@w3.org" title="W3C">Gettys, J.</a>, <a href="mailto:mogul@wrl.dec.com" title="Compaq Computer Corporation">Mogul, J.</a>, <a href="mailto:frystyk@w3.org" title="MIT Laboratory for Computer Science">Frystyk, H.</a>, <a href="mailto:masinter@parc.xerox.com" title="Xerox Corporation">Masinter, L.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.</a>, and <a href="mailto:timbl@w3.org" title="W3C">T. Berners-Lee</a>, “<a href="http://tools.ietf.org/html/rfc2616">Hypertext Transfer Protocol -- HTTP/1.1</a>”, RFC&nbsp;2616, June&nbsp;1999.
555            </td>
556         </tr>
557         <tr>
558            <td class="reference"><b id="RFC2119">[RFC2119]</b></td>
559            <td class="top"><a href="mailto:sob@harvard.edu" title="Harvard University">Bradner, S.</a>, “<a href="http://tools.ietf.org/html/rfc2119">Key words for use in RFCs to Indicate Requirement Levels</a>”, BCP&nbsp;14, RFC&nbsp;2119, March&nbsp;1997.
560            </td>
561         </tr>
562         <tr>
563            <td class="reference"><b id="RFC2246">[RFC2246]</b></td>
564            <td class="top"><a href="mailto:tdierks@certicom.com" title="Certicom">Dierks, T.</a> and <a href="mailto:callen@certicom.com" title="Certicom">C. Allen</a>, “<a href="http://tools.ietf.org/html/rfc2246">The TLS Protocol Version 1.0</a>”, RFC&nbsp;2246, January&nbsp;1999.
565            </td>
566         </tr>
567         <tr>
568            <td class="reference"><b id="RFC2817">[RFC2817]</b></td>
569            <td class="top">Khare, R. and S. Lawrence, “<a href="http://tools.ietf.org/html/rfc2817">Upgrading to TLS Within HTTP/1.1</a>”, RFC&nbsp;2817, May&nbsp;2000.
570            </td>
571         </tr>
572      </table>
573      <div class="avoidbreak">
574         <h1 id="rfc.authors"><a href="#rfc.authors">Author's Address</a></h1>
575         <p><b>Eric Rescorla</b><br>RTFM, Inc.<br>30 Newell Road, #16<br>East Palo Alto, CA&nbsp;94303<br>Phone: <a href="tel:(650)328-8631">(650) 328-8631</a><br>Email: <a href="mailto:ekr@rtfm.com">ekr@rtfm.com</a></p>
576      </div>
577      <div>
578         <h1 id="rfc.section.A" class="np"><a href="#rfc.section.A">A.</a>&nbsp;Security Considerations
579         </h1>
580         <p id="rfc.section.A.p.1">This entire document is about security.</p>
581      </div>
582      <h1 id="rfc.index"><a href="#rfc.index">Index</a></h1>
583      <p class="noprint"><a href="#rfc.index.H">H</a> <a href="#rfc.index.U">U</a> 
584      </p>
585      <div class="print2col">
586         <ul class="ind">
587            <li><a id="rfc.index.H" href="#rfc.index.H"><b>H</b></a><ul>
588                  <li>https URI scheme&nbsp;&nbsp;<a href="#rfc.iref.h.1"><b>2.4</b></a></li>
589               </ul>
590            </li>
591            <li><a id="rfc.index.U" href="#rfc.index.U"><b>U</b></a><ul>
592                  <li>URI scheme&nbsp;&nbsp;
593                     <ul>
594                        <li>https&nbsp;&nbsp;<a href="#rfc.iref.u.1"><b>2.4</b></a></li>
595                     </ul>
596                  </li>
597               </ul>
598            </li>
599         </ul>
600      </div>
601      <div id="rfc.copyright">
602         <h1><a href="#rfc.copyright">Full Copyright Statement</a></h1>
603         <p>Copyright © The Internet Society (2000). All Rights Reserved.</p>
604         <p>This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise
605            explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without
606            restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative
607            works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references
608            to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards
609            in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to
610            translate it into languages other than English.
611         </p>
612         <p>The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.</p>
613         <p>This document and the information contained herein is provided on an “AS IS” basis and THE INTERNET SOCIETY AND THE INTERNET
614            ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE
615            OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
616            PURPOSE.
617         </p>
618      </div>
619      <div id="rfc.ipr">
620         <h1><a href="#rfc.ipr">Intellectual Property</a></h1>
621         <p>The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed
622            to pertain to the implementation or use of the technology described in this document or the extent to which any license under
623            such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights.
624            Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be
625            found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available,
626            or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors
627            or users of this specification can be obtained from the IETF Secretariat.
628         </p>
629         <p>The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary
630            rights which may cover technology that may be required to practice this standard. Please address the information to the IETF
631            Executive Director.
632         </p>
633      </div>
634      <div>
635         <h1>Acknowledgement</h1>
636         <p>Funding for the RFC Editor function is currently provided by the Internet Society.</p>
637      </div>
638   </body>
639</html>
Note: See TracBrowser for help on using the repository browser.