draft-ietf-httpstate-cookie-16.txt   draft-ietf-httpstate-cookie-17.txt 
httpstate A. Barth httpstate A. Barth
Internet-Draft U.C. Berkeley Internet-Draft U.C. Berkeley
Obsoletes: 2965 (if approved) October 25, 2010 Obsoletes: 2965 (if approved) October 26, 2010
Intended status: Standards Track Intended status: Standards Track
Expires: April 28, 2011 Expires: April 29, 2011
HTTP State Management Mechanism HTTP State Management Mechanism
draft-ietf-httpstate-cookie-16 draft-ietf-httpstate-cookie-17
Abstract Abstract
This document defines the HTTP Cookie and Set-Cookie header fields. This document defines the HTTP Cookie and Set-Cookie header fields.
These header fields can be used by HTTP servers to store state These header fields can be used by HTTP servers to store state
(called cookies) at HTTP user agents, letting the servers maintain a (called cookies) at HTTP user agents, letting the servers maintain a
stateful session over the mostly stateless HTTP protocol. Although stateful session over the mostly stateless HTTP protocol. Although
cookies have many historical infelicities that degrade their security cookies have many historical infelicities that degrade their security
and privacy, the Cookie and Set-Cookie header fields are widely used and privacy, the Cookie and Set-Cookie header fields are widely used
on the Internet. on the Internet.
skipping to change at page 2, line 27 skipping to change at page 2, line 27
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 28, 2011. This Internet-Draft will expire on April 29, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 42 skipping to change at page 3, line 42
5.2.3. The Domain Attribute . . . . . . . . . . . . . . . . . 22 5.2.3. The Domain Attribute . . . . . . . . . . . . . . . . . 22
5.2.4. The Path Attribute . . . . . . . . . . . . . . . . . . 22 5.2.4. The Path Attribute . . . . . . . . . . . . . . . . . . 22
5.2.5. The Secure Attribute . . . . . . . . . . . . . . . . . 23 5.2.5. The Secure Attribute . . . . . . . . . . . . . . . . . 23
5.2.6. The HttpOnly Attribute . . . . . . . . . . . . . . . . 23 5.2.6. The HttpOnly Attribute . . . . . . . . . . . . . . . . 23
5.3. Storage Model . . . . . . . . . . . . . . . . . . . . . . 23 5.3. Storage Model . . . . . . . . . . . . . . . . . . . . . . 23
5.4. The Cookie Header . . . . . . . . . . . . . . . . . . . . 26 5.4. The Cookie Header . . . . . . . . . . . . . . . . . . . . 26
6. Implementation Considerations . . . . . . . . . . . . . . . . 29 6. Implementation Considerations . . . . . . . . . . . . . . . . 29
6.1. Limits . . . . . . . . . . . . . . . . . . . . . . . . . . 29 6.1. Limits . . . . . . . . . . . . . . . . . . . . . . . . . . 29
6.2. Application Programming Interfaces . . . . . . . . . . . . 29 6.2. Application Programming Interfaces . . . . . . . . . . . . 29
6.3. IDNA dependency and migration . . . . . . . . . . . . . . 29 6.3. IDNA dependency and migration . . . . . . . . . . . . . . 29
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 30 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 31
7.1. Third-Party Cookies . . . . . . . . . . . . . . . . . . . 30 7.1. Third-Party Cookies . . . . . . . . . . . . . . . . . . . 31
7.2. User Controls . . . . . . . . . . . . . . . . . . . . . . 30 7.2. User Controls . . . . . . . . . . . . . . . . . . . . . . 31
8. Security Considerations . . . . . . . . . . . . . . . . . . . 32 8. Security Considerations . . . . . . . . . . . . . . . . . . . 33
8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 32 8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 33
8.2. Ambient Authority . . . . . . . . . . . . . . . . . . . . 32 8.2. Ambient Authority . . . . . . . . . . . . . . . . . . . . 33
8.3. Clear Text . . . . . . . . . . . . . . . . . . . . . . . . 33 8.3. Clear Text . . . . . . . . . . . . . . . . . . . . . . . . 34
8.4. Session Identifiers . . . . . . . . . . . . . . . . . . . 33 8.4. Session Identifiers . . . . . . . . . . . . . . . . . . . 34
8.5. Weak Confidentiality . . . . . . . . . . . . . . . . . . . 34 8.5. Weak Confidentiality . . . . . . . . . . . . . . . . . . . 35
8.6. Weak Integrity . . . . . . . . . . . . . . . . . . . . . . 34 8.6. Weak Integrity . . . . . . . . . . . . . . . . . . . . . . 35
8.7. Reliance on DNS . . . . . . . . . . . . . . . . . . . . . 35 8.7. Reliance on DNS . . . . . . . . . . . . . . . . . . . . . 36
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37
9.1. Cookie . . . . . . . . . . . . . . . . . . . . . . . . . . 36 9.1. Cookie . . . . . . . . . . . . . . . . . . . . . . . . . . 37
9.2. Set-Cookie . . . . . . . . . . . . . . . . . . . . . . . . 36 9.2. Set-Cookie . . . . . . . . . . . . . . . . . . . . . . . . 37
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38
10.1. Normative References . . . . . . . . . . . . . . . . . . . 37 10.1. Normative References . . . . . . . . . . . . . . . . . . . 38
10.2. Informative References . . . . . . . . . . . . . . . . . . 37 10.2. Informative References . . . . . . . . . . . . . . . . . . 39
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 39 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 40
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 40 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 41
1. Introduction 1. Introduction
This document defines the HTTP Cookie and Set-Cookie header fields. This document defines the HTTP Cookie and Set-Cookie header fields.
Using the Set-Cookie header field, an HTTP server can pass name/value Using the Set-Cookie header field, an HTTP server can pass name/value
pairs and associated metadata (called cookies) to a user agent. When pairs and associated metadata (called cookies) to a user agent. When
the user agent makes subsequent requests to the server, the user the user agent makes subsequent requests to the server, the user
agent uses the metadata and other information to determine whether to agent uses the metadata and other information to determine whether to
return the name/value pairs in the Cookie header. return the name/value pairs in the Cookie header.
skipping to change at page 18, line 7 skipping to change at page 18, line 7
6. Let the parsed-cookie-date be the date whose day-of-month, month, 6. Let the parsed-cookie-date be the date whose day-of-month, month,
year, hour, minute, and second (in UTC) are the day-of-month- year, hour, minute, and second (in UTC) are the day-of-month-
value, the month-value, the year-value, the hour-value, the value, the month-value, the year-value, the hour-value, the
minute-value, and the second-value, respectively. If no such minute-value, and the second-value, respectively. If no such
date exists, abort these steps and fail to parse the cookie-date. date exists, abort these steps and fail to parse the cookie-date.
7. Return the parsed-cookie-date as the result of this algorithm. 7. Return the parsed-cookie-date as the result of this algorithm.
5.1.2. Canonicalized host names 5.1.2. Canonicalized host names
A canonicalized host name is the string generated by the following A canonicalized host name is the string generated by converting the
algorithm: host name to a sequence of individual domain name labels, and convert
each label that is not a NR-LDH label, to a A-label (see Section
1. Convert the host name to a sequence of NR-LDH labels (see Section 2.3.2.1 of [RFC5890] for the fomer and latter), or to a "punycode
2.3.2.2 of [RFC5890]) or a sequence of A-labels according to the label" (a label resulting from the "ToASCII" conversion in Section 4
appropriate IDNA specification [RFC5891] or [RFC3490] (see of [RFC3490]), as appropriate (see Section 6.3 of this
Section 6.3 of this specification) specification).
2. Concatenate the labels resulting from the previous step,
separating each label from the next with a %x2E (".") character.
5.1.3. Domain matching 5.1.3. Domain matching
A string domain-matches a given domain string if at least one of the A string domain-matches a given domain string if at least one of the
following conditions hold: following conditions hold:
o The domain string and the string are identical. o The domain string and the string are identical.
o All of the following conditions hold: o All of the following conditions hold:
skipping to change at page 29, line 46 skipping to change at page 29, line 46
problems. problems.
Instead of providing string-based APIs to cookies, platforms would be Instead of providing string-based APIs to cookies, platforms would be
well-served by providing more semantic APIs. It is beyond the scope well-served by providing more semantic APIs. It is beyond the scope
of this document to recommend specific API designs, but there are of this document to recommend specific API designs, but there are
clear benefits to accepting an abstract "Date" object instead of a clear benefits to accepting an abstract "Date" object instead of a
serialized date string. serialized date string.
6.3. IDNA dependency and migration 6.3. IDNA dependency and migration
IDNA2008 [RFC5890] supersedes IDNA2003 [RFC3490] but is not IDNA2008 [RFC5890] supersedes IDNA2003 [RFC3490]. However, there are
backwards-compatible. For this reason, there will be a transition differences between the two specifications, and thus there can be
period (possibly of a number of years). User agents SHOULD implement differences in processing (e.g. converting) domain name labels that
IDNA2008 [RFC5890] and MAY implement [Unicode Technical Standard #46 have been registered under one from those registered under the other.
<http://unicode.org/reports/tr46/>] in order to facilitate a smoother There will be a transition period of some time during which IDNA2003-
IDNA transition. If a user agent does not implement IDNA2008, the based domain name labels will exist in the wild. User agents SHOULD
user agent MUST implement IDNA2003 [RFC3490]. implement IDNA2008 [RFC5890] and MAY implement [Unicode Technical
Standard #46 (UTS46) <http://unicode.org/reports/tr46/>] or [RFC5895]
in order to facilitate their IDNA transition. If a user agent does
not implement IDNA2008, the user agent MUST implement IDNA2003
[RFC3490].
7. Privacy Considerations 7. Privacy Considerations
Cookies are often criticized for letting servers track users. For Cookies are often criticized for letting servers track users. For
example, a number of "web analytics" companies use cookies to example, a number of "web analytics" companies use cookies to
recognize when a user returns to a web site or visits another web recognize when a user returns to a web site or visits another web
site. Although cookies are not the only mechanism servers can use to site. Although cookies are not the only mechanism servers can use to
track users across HTTP requests, cookies facilitate tracking because track users across HTTP requests, cookies facilitate tracking because
they are persistent across user agent sessions and can be shared they are persistent across user agent sessions and can be shared
between hosts. between hosts.
skipping to change at page 37, line 46 skipping to change at page 38, line 46
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5890] Klensin, J., "Internationalized Domain Names for [RFC5890] Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Definitions and Document Framework", Applications (IDNA): Definitions and Document Framework",
RFC 5890, August 2010. RFC 5890, August 2010.
[RFC5895] Resnick, P. and P. Hoffman, "Mapping Characters for
Internationalized Domain Names in Applications (IDNA)
2008", RFC 5895, September 2010.
[RFC5891] Klensin, J., "Internationalized Domain Names in [RFC5891] Klensin, J., "Internationalized Domain Names in
Applications (IDNA): Protocol", RFC 5891, August 2010. Applications (IDNA): Protocol", RFC 5891, August 2010.
10.2. Informative References 10.2. Informative References
[RFC2109] Kristol, D. and L. Montulli, "HTTP State Management [RFC2109] Kristol, D. and L. Montulli, "HTTP State Management
Mechanism", RFC 2109, February 1997. Mechanism", RFC 2109, February 1997.
[RFC2965] Kristol, D. and L. Montulli, "HTTP State Management [RFC2965] Kristol, D. and L. Montulli, "HTTP State Management
Mechanism", RFC 2965, October 2000. Mechanism", RFC 2965, October 2000.
 End of changes. 8 change blocks. 
40 lines changed or deleted 45 lines changed or added

This html diff was produced by rfcdiff 1.40. The latest version is available from http://tools.ietf.org/tools/rfcdiff/