クッキー： HTTP 状態管理の仕組み

【この訳に特有な表記規約】

いくつかの用語（外部の仕様に定義されるものなど）には、 ~linkを補完している。

2.1. 適合性の判定基準

この文書~内の~keyword "MUST" … 【以下、この段落の内容は`~IETF日本語訳 共通~page＠~IETFcommon#requirements-notation$に移譲。】 ◎ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

【 以下、この節の他の内容は `~IETF日本語訳 共通~page＠~IETFcommon#conformance-criteria$に移譲。 】

2.2. 構文の記法

この仕様は `RFC5234$r による~ABNF（ Augmented Backus-Naur Form ）記法を利用する。 ◎ This specification uses the Augmented Backus-Naur Form (ABNF) notation of [RFC5234].

次の中核~規則が `RFC 5234, Appendix B.1＠~RFCx/rfc5234#appendix-B.1$ にて定義されるものとして，参照される ⇒＃ `ALPHA^P （ `letters^en ）, `CR^P （ `carriage return^en ）, `CRLF^P （ CR LF ）, `CTL^P （制御文字）, `DIGIT^P （ 10 進数字 0-9 ）, `DQUOTE^P （二重引用符）, `HEXDIG^P （ 16 進数字 0-9/A-F/a-f ）, `LF^P （ `line feed^en ）, `NUL^P （ ~NULL ~octet ）, `OCTET^P （ `NUL^P 以外の任意の 8-bit ~data列）, `SP^P （ `space^en ）, `HTAB^P （ `horizontal tab^en ）, `CHAR^P （【 `NUL^P 以外の】任意の `USASCII$r 文字）, `VCHAR^P （任意の可視な `USASCII$r 文字）, `WSP^P （空白【 `SP^P と `HTAB^P 】） ◎ The following core rules are included by reference, as defined in [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF (CR LF), CTLs (controls), DIGIT (decimal 0-9), DQUOTE (double quote), HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), NUL (null octet), OCTET (any 8-bit sequence of data except NUL), SP (space), HTAB (horizontal tab), CHAR (any [USASCII] character), VCHAR (any visible [USASCII] character), and WSP (whitespace).

次の規則は、 `HTTPSEM$r に定義される ⇒＃ `OWS$P （省略可能な空白）, `BWS$P （不良な空白） ◎ The OWS (optional whitespace) and BWS (bad whitespace) rules are defined in Section 5.6.3 of [HTTPSEM].

2.3. 各種用語

次に挙げる用語の意味は、 `HTTPSEM$r に従う【~link先を見よ】 【！未利用：~proxy,】 ⇒＃ `~UA$, `~client$, `~server$, `生成元~server$ ◎ The terms "user agent", "client", "server", "proxy", and "origin server" have the same meaning as in the HTTP/1.1 specification ([HTTPSEM], Section 3).

`要請~host@ とは、 `~UA$が［ ~HTTP要請を送信している相手, あるいは それに対する~HTTP応答を受信した相手 ］として，~UAに既知な~host名を~~意味する。 ◎ The request-host is the name of the host, as known by the user agent, to which the user agent is sending an HTTP request or from which it is receiving an HTTP response (i.e., the name of the host to which it sent the corresponding HTTP request).

`要請~URI@ （ `request-uri^en ）は、 `~target~URI$ `HTTPSEM$r を指す。 ◎ The term request-uri refers to "target URI" as defined in Section 7.1 of [HTTPSEM].

2 個の［ ~octet列 ］は、 `RFC4790$r にて定義される `i;ascii-casemap collation＠~RFCx/rfc4790#section-9.2.1$en の下で等価であるとき, そのときに限り， `文字大小無視で合致する@ とされる。 【 `Infra$r に定義される`~byte大小無視$と同じ。】 ◎ Two sequences of octets are said to case-insensitively match each other if and only if they are equivalent under the i;ascii-casemap collation defined in [RFC4790].

`文字列@ とは、 `NUL^P を含まない~octet列を意味する。 ◎ The term string means a sequence of non-NUL octets.

【 したがって、語 “文字” も， 1 個の~octetを意味する。 また、空~文字列は，長さ 0 の`文字列$を意味する。 】【 文法において~ASCIIでない文字が許容される箇所は無いが、 それでも，それらの文字を［ （ `cookie-octet$p 内に）生成する~server／~supportする~UA ］は在る （`課題 #1073＠https://github.com/httpwg/http-extensions/issues/1073$）。 】

次に挙げる用語は、 `HTML$r にて定義される ⇒＃ `作動中な閲覧~文脈$nav, `作動中な文書$nav, `先祖~navigable群$, `容器~文書$nav, `内容~navigable$, `専用~worker$, `文書$, `広義-先祖~navigable群$, `~navigable$, `不透明な生成元$, `閲覧~文脈~sandbox化( 生成元 )~flag$, `共用~worker$, `the worker's Documents^en†【~workerの`所有者~集合$】, `~top-level辿可能$, `WorkerGlobalScope$dom ◎ The terms "active browsing context", "active document", "ancestor navigables", "container document", "content navigable", "dedicated worker", "Document", "inclusive ancestor navigables", "navigable", "opaque origin", "sandboxed origin browsing context flag", "shared worker", "the worker's Documents", "top-level traversable", and "WorkerGlobalScope" are defined in [HTML].

【 原文には挙げらていないが、 他にもある。 明確化するため，この訳では、 他の用語（例：`~node~navigable$）を利用して，等価に言い換えた箇所もある。 】【† この用語は， `HTML$r には定義されていない（廃されたと思われる）ので、 この訳では，代わる用語に置換する。 】

`~sw$は、 `SERVICE-WORKERS$r にて定義される。 ◎ "Service Workers" are defined in the Service Workers specification [SERVICE-WORKERS].

用語 `生成元@ および［ ~URIから生成元を導出する仕組み, 生成元~用の “同一-” 照合~algo ］は、 `RFC6454$r にて定義される。 ◎ The term "origin", the mechanism of deriving an origin from a URI, and the "the same" matching algorithm for origins are defined in [RFC6454].

【 ~web~platformの文脈では、 ~HTMLが定義する`生成元$o，および`同一-生成元$と見なすことになろう。 特に，この仕様に現れる［ 文書の`生成元$doc, `環境~設定群~obj$の`生成元$enV ］は、 その定義に基づく （加えて、`~URL$の`生成元$urlは `URL$r にて定義される）。 とは言え、 `生成元$o（`成分組~生成元$）の（~web~platformに特有な）~domain成分は， この仕様の中では取扱われない（常に ~NULL と見なして差し支えない？）。 】【 実際には`生成元~server$の略称を表すこともある。 】

`安全$な~HTTP~method（ `GET^m, `HEAD^m, `OPTIONS^m, `TRACE^m など）は、 `HTTPSEM$r に定義される。 ◎ "Safe" HTTP methods include GET, HEAD, OPTIONS, and TRACE, as defined in Section 9.2.1 of [HTTPSEM].

~domainの `公共~接尾辞@ （ `public suffix^en ）とは、 ~domainを成す部位のうち — 例： `com^s ／ `co.uk^s ／ `pvt.k12.wy.us^s など — 公共~registryにより制御されるものを指す。 ~domainの `登録-可能な~domain@ は、 ~domainの`公共~接尾辞$に，その直前にある~labelを足したものである。 ◎ A domain's "public suffix" is the portion of a domain that is controlled by a public registry, such as "com", "co.uk", and "pvt.k12.wy.us". A domain's "registrable domain" is the domain's public suffix plus the label to its left.＼

例えば， `https://www.site.example^s に対しては、その［ `公共~接尾辞$は `example^s, `登録-可能な~domain$は `site.example^s ］になる。 ~UAは、アリなときは，当日最新の公共~接尾辞~listを利用するベキである — Mozilla ~project により `PSL$r にて保守されているそれなど。 ◎ That is, for https://www.site.example, the public suffix is example, and the registrable domain is site.example. Whenever possible, user agents SHOULD use an up-to-date public suffix list, such as the one maintained by the Mozilla project at [PSL].

【 `URL$r に定義される［ `公共~接尾辞＠~URL1#host-public-suffix$／ `登録-可能な~domain＠~URL1#host-registrable-domain$ ］と同じ。 】【 “~URIの`登録-可能な~domain$” は、 ~URIを表現する`~URL$の`生成元$urlの`~host$oの`登録-可能な~domain$の略記である — ~hostが`~domain$でない場合（例：~IP~address）、定義されない（存在しない）。 】

次に挙げる用語は、 `FETCH$r にて定義される ⇒ `要請$, および その 【！未利用：`~method$rq, `~URL~list$rq】 【！廃：target browsing context】 ⇒＃ `~client$rq, `現在の~URL$rq ◎ The term "request", as well as a request's "client", "current url", "method", "target browsing context", and "url list", are defined in [FETCH].

用語 `非HTTP~API@ は、~cookieを［ 設定する／検索取得する ］ために利用される ~HTTP以外の仕組みを指す — ~scriptに~cookieを公開する~web~browser~APIなど。 【具体的には、 `document.cookie$dom 】 ◎ The term "non-HTTP APIs" refers to non-HTTP mechanisms used to set and retrieve cookies, such as a web browser API that exposes cookies to scripts.

用語 `~top-level~navi@ は、 `~top-level辿可能$に対する~naviを指す。 ◎ The term "top-level navigation" refers to a navigation of a top-level traversable.

【 “~top-level要請” という語も現れるが、 おそらく，`~top-level~navi$により為される要請を意味する。 】

この仕様における `~secureな接続@ （ `"secure" connection^en ）の~~意味は、 `~UA$により定義される。

注記： ~secureな接続の観念は、 この文書では定義されない。 ~UAは，概して、 ~transport層の~security — ~SSLや~TLS `RFC2818$r など — を用立てる接続を~secureであると見なす／ あるいは、 ~hostが信用-済みな場合もそう見なす。 例えば，ほとんどの~UAは、 "`https^c" を~secureな~protocolを表す~schemeと見なす／ "`localhost^c" を信用-済みな~hostであると見なす。 【！The notion of a "secure" connection ...】

【 ~secureな［ `生成元$／~URI ］は、 その~scheme成分が［ `~secureな接続$を利用する~protocolを表すものである ］ことを意味する。 】【 原文では “~secureな~channel” とも称される箇所もあるが、 実質的に同義なので，この訳では一律に “~secureな接続” と記す。 】【 `~secureな接続$に関する記述は， 原文では他の各所に散らばっているが、 集約するため，この訳では ここに与える。 】

3.1. 例

== ~server → ~UA ==

Set-Cookie: SID=31d4d96e407aad42

== ~UA → ~server ==

Cookie: SID=31d4d96e407aad42

== ~server → ~UA ==

Set-Cookie: SID=31d4d96e407aad42; Path=/; Domain=site.example

== ~UA → ~server ==

Cookie: SID=31d4d96e407aad42

== ~server → ~UA ==

Set-Cookie: SID=31d4d96e407aad42; Path=/; Secure; HttpOnly
Set-Cookie: lang=en-US; Path=/; Domain=site.example

== ~UA → ~server ==

Cookie: SID=31d4d96e407aad42; lang=en-US

== ~server → ~UA ==

Set-Cookie: lang=en-US; Expires=Wed, 09 Jun 2021 10:18:14 GMT

== ~UA → ~server ==

Cookie: SID=31d4d96e407aad42; lang=en-US

== ~server → ~UA ==

Set-Cookie: lang=; Expires=Sun, 06 Nov 1994 08:49:37 GMT

== ~UA → ~server ==

Cookie: SID=31d4d96e407aad42

3.2. どの要件を実装するか

下に与える［ `~server要件§, `~UA要件§ ］は、 別個な種別の実装~用の要件群を論じる。 この節は、 実装者が自身の目標に どちらの要件群が最も適するか決定する際の手引きとして意味される。 間違った要件群を選ぶと，他の~cookie実装との互換性を欠如する結果にもなり得る。 ◎ The upcoming two sections, Section 4 and Section 5, discuss the set of requirements for two distinct types of implementations. This section is meant to help guide implementers in determining which set of requirements best fits their goals. Choosing the wrong set of requirements could result in a lack of compatibility with other cookie implementations.

互換であることが何を意味するかは、 実装者の目標に依存して異なることに注意。 これらの相違点は、［ 意図的な仕様~変更, 意図的でない仕様~変更, 仕様の解釈, 歴史的な実装~間の相違点 ］に因り，時を経るに伴い築かれてきた。 ◎ It's important to note that being compatible means different things depending on the implementer's goals. These differences have built up over time due to both intentional and unintentional spec changes, spec interpretations, and historical implementation differences.

この節は、 概ね，~cookie仕様の実装者を 2 つの種別 — 生産器と消費器 — に分割0する。 これらは、 公式的な用語ではない — これらは、［ 読者が，利用事例に対する直感的な理解を養う ］ことを助けるためにあり，この節でしか利用されない。 ◎ This section roughly divides implementers of the cookie spec into two types, producers and consumers. These are not official terms and are only used here to help readers develop an intuitive understanding of the use cases.

4.1. `Set-Cookie^h ~header

`Set-Cookie^h ~HTTP応答~headerは、 ~serverから~UAへ~cookieを送信するときに利用される。 ◎ The Set-Cookie HTTP response header field is used to send cookies from the server to the user agent.

`set-cookie@p
	= `set-cookie-string$p
`set-cookie-string@p
	= `BWS$P `cookie-pair$p *( `BWS$P ";" `OWS$P `cookie-av$p )
`cookie-pair@p
	= `cookie-name$p `BWS$P "=" `BWS$P `cookie-value$p
`cookie-name@p
	= 1*`cookie-octet$p
`cookie-value@p
	= *`cookie-octet$p
	/ ( DQUOTE *`cookie-octet$p DQUOTE )
`cookie-octet@p
	= `%x21^_
	/ `%x23-2B^_
	/ `%x2D-3A^_
	/ `%x3C-5B^_
	/ `%x5D-7E^_
	; 
`CTL^P, `SP^P, `DQUOTE^P, `,^ch, `;^ch, `\^ch 以外の US-ASCII 文字
◎
US-ASCII characters excluding CTLs, whitespace, DQUOTE, comma, semicolon, and backslash

`cookie-av@p
	= `expires-av$p
	/ `max-age-av$p
	/ `domain-av$p
	/ `path-av$p
	/ `secure-av$p
	/ `httponly-av$p
	/ `samesite-av$p
	/ `extension-av$p
`expires-av@p
	= "Expires" `BWS$P "=" `BWS$P `sane-cookie-date$p
`sane-cookie-date@p
	= <`IMF-fixdate$p>
	; 
`HTTPSEM$r にて定義される
【しかしながら、閏秒は許容されていない（`日付§を見よ）】
◎
IMF-fixdate, defined in [HTTPSEM], Section 5.6.7

`max-age-av@p
	= "Max-Age" `BWS$P "=" `BWS$P `non-zero-digit$p *DIGIT
`non-zero-digit@p
	= `%x31-39^_
	; 
数字 1 〜 9
◎
digits 1 through 9


`domain-av@p
	= "Domain" `BWS$P "=" `BWS$P `domain-value$p
`domain-value@p
	= <`subdomain^p>
	; 
下に与える詳細を見よ
◎
see details below

`path-av@p
	= "Path" `BWS$P "=" `BWS$P `path-value$p
`path-value@p
	= *`av-octet$p
`secure-av@p
	= "Secure"
`httponly-av@p
	= "HttpOnly"
`samesite-av@p
	= "SameSite" `BWS$P "=" `BWS$P `samesite-value$p
`samesite-value@p
	= "Strict"
	/ "Lax"
	/ "None"
`extension-av@p
	= *`av-octet$p
`av-octet@p
	= `%x20-3A^_
	/ `%x3C-7E^_
	; 
`CTL^P, `;^ch を除く `CHAR^P
◎
any CHAR except CTLs or ";"

Set-Cookie: __Secure-SID=12345; Domain=site.example

Set-Cookie: __Secure-SID=12345; Domain=site.example; Secure

Set-Cookie: __Host-SID=12345
Set-Cookie: __Host-SID=12345; Secure
Set-Cookie: __Host-SID=12345; Domain=site.example
Set-Cookie: __Host-SID=12345; Domain=site.example; Path=/
Set-Cookie: __Host-SID=12345; Secure; Domain=site.example; Path=/

Set-Cookie: __Host-SID=12345; Secure; Path=/

4.2. `Cookie^h ~header

`cookie@p
	= `cookie-string$p
`cookie-string@p
	= `cookie-pair$p *( ";" SP `cookie-pair$p )

5.1. 下位成分~algo

この節では、［ `Cookie^h ／ `Set-Cookie^h ］~headerを成す特定の下位成分を処理するために~UAが利用する，いくつかの~algoを定義する。 【これらの~algoは、後続の節から参照される。】 ◎ This section defines some algorithms used by user agents to process specific subcomponents of the Cookie and Set-Cookie header fields.

5.2. 同一-~site／非同一-~siteな要請

2 つの`生成元$が `同一-~site@ （ `same-site^en ）であるとは、 `SAMESITE$r にて定義される`同じ~site$（ `same site^en ）による判定基準を満足することをいう。 ◎ Two origins are same-site if they satisfy the "same site" criteria defined in [SAMESITE].＼

【 `非同一-~site@ （ `cross-site^en ）は、 `同一-~site$の否定を意味する。 】

所与の`要請$ %要請 は、［ ~OR↓ を満たすならば `同一-~site@rq ／ ~ELSE_ `非同一-~site@rq ］とされる： ◎ A request is "same-site" if＼

• ~AND↓： ◎ the following criteria are true:

  • %要請 は`~UI~reload~navi要請$ではない。 ◎ The request is not the result of a reload navigation triggered through a user interface element (as defined by the user agent; e.g., a request triggered by the user clicking a refresh button on a toolbar).

  • ~OR↓：

    • %要請 の`~client$rq ~EQ ~NULL【！has no client】
    • 次は`同一-~site$である ⇒＃ %要請 の`現在の~URL$rqの`生成元$url, %要請 の`~client$rqの`~cookie用~site$（それは、ある`生成元$を与える）
    ◎ The request's current url's origin is same-site with the request's client's "site for cookies" (which is an origin), or if the request has no client or the request's client is null.
• %要請 は`~UI~reload~navi要請$であって、 ~reloadされた文書は，元々は`同一-~site$な要請を介して`~navigate$されたものである。 ◎ Requests which are the result of a reload navigation triggered through a user interface element are same-site if the reloaded document was originally navigated to via a same-site request.＼ ↑↑A request that is not "same-site" is instead "cross-site".

`~UI~reload~navi要請@ とは、［ ~UAにより定義される，~UI要素を通して誘発される~reload~navi ］により生じる`要請$である（例：利用者が~toolbarの~refresh~buttonを~clickして誘発した要請）。 ◎ ↑

`要請$の`~client$rqの `~cookie用~site@ （ `site for cookies^en ）は，以下の下位~節に述べるように，`~client$rqの型†に依存して計算される`生成元$である。 【† すなわち、`~client$rqは，どの型の~objに`関連な設定群~obj$であるか。】 ◎ The request's client's "site for cookies" is calculated depending upon its client's type, as described in the following subsections:

5.3. `Set-Cookie^h ~headerの無視-法

`~UA$は、［ 応答の`状態s~code$は `100 番台$である場合 ］には，応答が包含する `Set-Cookie^h ~headerを無視してもヨイ。 加えて、自身の`~cookie施策$に基づいて無視してもヨイ（ `~cookie施策§ を見よ）。 ◎ User agents MAY ignore Set-Cookie header fields contained in responses with 100-level status codes or based on its cookie policy (see Section 7.2).

他のすべての `Set-Cookie^h ~headerは、 `5.5§ に則って処理するベキである。 すなわち，応答の`状態s~code$が`100 番台$以外（ `400 番台$, `500 番台$も含む）である場合、 応答に包含される `Set-Cookie^h ~headerを — `~UA$の`~cookie施策$に則って無視されないならば — 処理するベキである。 ◎ All other Set-Cookie header fields SHOULD be processed according to Section 5.5. That is, Set-Cookie header fields contained in responses with non-100-level status codes (including those in responses with 400- and 500-level status codes) SHOULD be processed unless ignored according to the user agent's cookie policy.

5.4. ~cookie名の接頭辞

`~UA$に課される~cookie名の接頭辞~用の要件は、 それと`~server$に課されるそれ（ `4.1.3§ ）とで少し相違する — `~UA$は、 【特定0の接頭辞の有無を検査する目的においては，】 接頭辞~文字列を文字大小無視で照合しなければナラナイ。 ◎ User agents' requirements for cookie name prefixes differ slightly from servers' (Section 4.1.3) in that UAs MUST match the prefix string case-insensitively.

接頭辞~用の規範的な要件の詳細は、 `保管~model§に与える~algo内で定義される。 ◎ The normative requirements for the prefixes are detailed in the storage model algorithm defined in Section 5.6.

このことは、 一部の`~server$が~cookie名【！~cookie】を文字大小無視で処理する結果，［ 意図的でなく接頭辞の文字大小を違える／ 文字大小が違えられた接頭辞を受容する ］ことになるからである。 ◎ This is because some servers will process cookie case-insensitively, resulting in them unintentionally miscapitalizing and accepting miscapitalized prefixes.

Set-Cookie: __SECURE-SID=12345

加えて， 接頭辞を文字大小区別で検査する`~UA$がある場合、 ~serverは，［ 接頭辞を伴う~cookieになりすますために，ある~cookie名の文字大小をわざと違える攻撃者 ］に対し脆弱になる。 ◎ Additionally the server is vulnerable to an attacker that purposefully miscapitalizes a cookie in order to impersonate a prefixed cookie.＼

Set-Cookie: __SeCuRe-SID=evil

Cookie: __Secure-SID=12345; __SeCuRe-SID=evil

これらの課題を防止するため、 `~UA$は，~cookie名の接頭辞を文字大小無視で照合しなければナラナイ。 ◎ To prevent these issues, UAs MUST match cookie name prefixes case-insensitive.

注記： それでも、 異なる名前を伴う~cookieどうしは，~UAにより別々なものと見なされる。 なので、［ `__Secure-foo=bar^c, `__secure-foo=baz^c ］は，別個な~cookieとして同時に存在し得る — どちらにも、 `__Secure-$l 接頭辞の要件が適用されることになる。 ◎ Note: Cookies with different names are still considered separate by UAs. So both __Secure-foo=bar and __secure-foo=baz can exist as distinct cookies simultaneously and both would have the requirements of the __Secure- prefix applied.

Set-Cookie: __Secure-SID=12345; Domain=site.example
Set-Cookie: __secure-SID=12345; Domain=site.example
Set-Cookie: __SECURE-SID=12345; Domain=site.example
Set-Cookie: __Host-SID=12345
Set-Cookie: __host-SID=12345; Secure
Set-Cookie: __host-SID=12345; Domain=site.example
Set-Cookie: __HOST-SID=12345; Domain=site.example; Path=/
Set-Cookie: __Host-SID=12345; Secure; Domain=site.example; Path=/
Set-Cookie: __host-SID=12345; Secure; Domain=site.example; Path=/
Set-Cookie: __HOST-SID=12345; Secure; Domain=site.example; Path=/

Set-Cookie: __Secure-SID=12345; Domain=site.example; Secure
Set-Cookie: __secure-SID=12345; Domain=site.example; Secure
Set-Cookie: __SECURE-SID=12345; Domain=site.example; Secure
Set-Cookie: __Host-SID=12345; Secure; Path=/
Set-Cookie: __host-SID=12345; Secure; Path=/
Set-Cookie: __HOST-SID=12345; Secure; Path=/

5.5. `Set-Cookie^h ~header

`~UA$は、 ~HTTP応答~内に受信した `Set-Cookie^h ~headerを まるごと無視してもヨイ （ `5.3§ を見よ）。 ◎ When a user agent receives a Set-Cookie header field in an HTTP response, the user agent MAY ignore the Set-Cookie header field in its entirety (see Section 5.3).

`~UA$は， `Set-Cookie^h ~headerをまるごと無視しない場合には、 以下で定義されるとおり， `Set-Cookie^h ~headerの値を `set-cookie-string$p として構文解析しなければナラナイ。 ◎ If the user agent does not ignore the Set-Cookie header field in its entirety, the user agent MUST parse the field-value of the Set-Cookie header field as a set-cookie-string (defined below).

注記： 以下に与える~algoは、 `Set-Cookie^h の文法よりも寛容である。 例えば、~algoでは，~cookieの［ 名前, 値 ］から頭部と尾部を成す空白~列は剥ぎ取られる（内部の空白は保守される）一方、 `Set-Cookie^h の文法（ `4.1.1§ ）では，そのような空白は禁止されている。 加えて，以下の~algoは、 `cookie-octet$p でない一部の文字を `4.1§ の文法に則って収容する。 ~UAは、 `~server要件§の推奨に従わない~serverと相互運用するために，この~algoを利用する。 ◎ NOTE: The algorithm below is more permissive than the grammar in Section 4.1. For example, the algorithm strips leading and trailing whitespace from the cookie name and value (but maintains internal whitespace), whereas the grammar in Section 4.1 forbids whitespace in these positions. In addition, the algorithm below accommodates some characters that are not cookie-octets according to the grammar in Section 4.1. User agents use this algorithm so as to interoperate with servers that do not follow the recommendations in Section 4.

注記： `set-cookie-string$p は`非HTTP~API$を出自にし得るので、 `CTL^P が無いことは保証されない。 よって，この~algoは、それらを明示的に取扱う。 ただし， `HTAB^P は、 空白と見なされるので［ `set-cookie-string$p を却下へ至らす `CTL^P ］からは除外され，別々に取扱われる。 ◎ NOTE: As set-cookie-string may originate from a non-HTTP API, it is not guaranteed to be free of CTL characters, so this algorithm handles them explicitly. Horizontal tab (%x09) is excluded from the CTL characters that lead to set-cookie-string rejection, as it is considered whitespace, which is handled separately.

注記： `set-cookie-string$p は、［ `RFC3986$r § 2.1 に従って~percent-符号化されたように現れる~octet列 ］を包含し得る。 しかしながら、 ~UAは，そのような~octet列を復号してはナラナイ — 代わりに、 個々の~octetを この~algoに指定されるとおり構文解析すること。 ◎ NOTE: The set-cookie-string may contain octet sequences that appear percent-encoded as per Section 2.1 of [RFC3986]. However, a user agent MUST NOT decode these sequences and instead parse the individual octets as specified in this algorithm.

5.6. 保管~model

~UAは、受信した~cookieを格納するための大域的な `~cookie保管庫@ （ `cookie store^en ）を保守する。 `~cookie保管庫$を成す各~cookieは、 次に挙げる~fieldからなる ⇒＃ `name@cK, `value@cK, `expiry-time@cK, `domain@cK, `path@cK, `creation-time@cK, `last-access-time@cK, `persistent-flag@cK, `host-only-flag@cK, `secure-only-flag@cK, `http-only-flag@cK, `same-site-flag@cK ◎ The user agent stores the following fields about each cookie: name, value, expiry-time, domain, path, creation-time, last-access-time, persistent-flag, host-only-flag, secure-only-flag, http-only-flag, and same-site-flag.

~cookieの有効期限が過去である／そうなったとき、 その~cookieは `失効した@ （ `expired^en ）とされる。 ◎ A cookie is "expired" if the cookie has an expiry date in the past.

どの時点であれ，~UAは、 `~cookie保管庫$内の~cookieのうち`失効した$ものすべてを保管庫から抹消しなければナラナイ。 ◎ The user agent MUST evict all expired cookies from the cookie store if, at any time, an expired cookie exists in the cookie store.

どの時点であれ，~UAは：

• 同じ `domain$cK ~field値を共有する~cookieの総数が， 実装~定義な何らかの~~上限（例： 50 ~cookie）を超えたときは、 `~cookie保管庫$から “超過~cookieを除去して” もヨイ。 ◎ At any time, the user agent MAY "remove excess cookies" from the cookie store if the number of cookies sharing a domain field exceeds some implementation-defined upper bound (such as 50 cookies).
• `~cookie保管庫$の容量が，実装~定義な何らかの~~上限（例えば 3000 ~cookie）を超えたときは、 `~cookie保管庫$から “超過~cookieを除去して” もヨイ。 ◎ At any time, the user agent MAY "remove excess cookies" from the cookie store if the cookie store exceeds some predetermined upper bound (such as 3000 cookies).

~UAが，`~cookie保管庫$から超過~cookieを除去するときは、 次の優先順位により，~cookieを抹消しなければナラナイ： ◎ When the user agent removes excess cookies from the cookie store, the user agent MUST evict cookies in the following priority order:

1. `失効した$もの ◎ Expired cookies.
2. 同じ `domain$cK ~field値を共有する, かつ［ `secure-only-flag$cK ~EQ ~F ］なる~cookieのうち，決められた個数を超えた分 ◎ Cookies whose secure-only-flag is false, and which share a domain field with more than a predetermined number of other cookies.

3. 同じ `domain$cK ~field値を共有する~cookieのうち、 決められた個数を超えた分

   【 共有する~cookieのうち，どれを抹消するかは、 次項に従うことになる。 また， “決められた個数” は、［ 前項のそれと異なる ／ `domain$cK に応じて異なる ］可能性も考えられる。 】

   ◎ Cookies that share a domain field with more than a predetermined number of other cookies.
4. `last-access-time$cK が最も過去の~cookie ◎ All cookies. ◎ If two cookies have the same removal priority, the user agent MUST evict the cookie with the earliest last-access-time first.

~UAは、 （自身が定義する）現在の~sessionの終了時に， `~cookie保管庫$から［ 次を満たす~cookie ］をすべて除去しなければナラナイ ⇒ `persistent-flag$cK ~EQ ~F ◎ When "the current session is over" (as defined by the user agent), the user agent MUST remove from the cookie store all cookies with the persistent-flag set to false.

5.7. 検索取得~model

この節は、 `~cookie保管庫$から~cookieを — `cookie-string$p の形で — どう検索取得するかを定義する。 `検索取得@ は、 `cookie-string$p を生成するよう要求する~eventである。 それは、例えば，［ ある~HTTP要請~用に `Cookie^h ~headerを築くために生じる ］ことも［ ~cookieへの~accessを供する`非HTTP~API$の~callに対し， `cookie-string$p を返すために要求される ］こともある。 各 `検索取得$には、［ `要請@rT, `~URI@rT, `同一-~site状態s@rT, `種別@rT ］が結付けられる。 これらは、以下に定義され，検索取得の`種別$rTに依存する。 ◎ This section defines how cookies are retrieved from a cookie store in the form of a cookie-string. A "retrieval" is any event which requires generating a cookie-string. For example, a retrieval may occur in order to build a Cookie header field for an HTTP request, or may be required in order to return a cookie-string from a call to a "non-HTTP" API that provides access to cookies. A retrieval has an associated URI, same-site status, and type, which are defined below depending on the type of retrieval.

【 `検索取得$の`要請$rTは、 明確化するための，この訳による追加。 条件［ `要請$rT ~EQ ε ］は、条件［ `種別$rT ~EQ `非~HTTP^i ］と同義になる。 】

6.1. 制限s

実用的な~UA実装には、 格納し得る~cookieの個数と~sizeに上限がある。 一般用~UAは、最小でも次に与える容量は供するベキである： ◎ Practical user agent implementations have limits on the number and size of cookies that they can store. General-use user agents SHOULD provide each of the following minimum capabilities:

• 1 ~domainあたり，少なくとも 50 個の~cookie ◎ At least 50 cookies per domain.
• 全部で少なくとも 3000 個の~cookie ◎ At least 3000 cookies total.

~UAは、 自身が格納する~cookieの最大~個数を制限してもヨイ。 ~UAは、 いつでも, どの~cookieを抹消してもヨイ （利用者からの要請に応じて，あるいは実装の制限に因り）。 ◎ User agents MAY limit the maximum number of cookies they store, and may evict any cookie at any time (whether at the request of the user or due to implementation limitations).

~cookieの最大~個数に対する上限は、 格納される全~cookieの総~sizeも制限することに注意 — 各~cookieには、 `5.5§ にて施行しなければナラナイ長さ制限sがあるので。 ◎ Note that a limit on the maximum number of cookies also limits the total size of the stored cookies, due to the length limits which MUST be enforced in Section 5.5.

~serverは、 これらの実装~制限sに達しないように, かつ［ 各 要請に `Cookie^h ~headerが内包されることによる，~network帯域幅を最小限にする ］ために，できるだけ少数かつ小容量の~cookieを利用するベキである。 ◎ Servers SHOULD use as few and as small cookies as possible to avoid reaching these implementation limits and to minimize network bandwidth due to the Cookie header field being included in every request.

~UAは~cookieをいつでも抹消し得るので、 ~serverは，［ ~UAが `Cookie^h ~header内に 1 個以上の~cookieを返すことに失敗したとき ］には “上品に退行する（ `gracefull degrade^en ）”ベキである。 ◎ Servers SHOULD gracefully degrade if the user agent fails to return one or more cookies in the Cookie header field because the user agent might evict any cookie at any time.

6.2. ~API

`Cookie^h と `Set-Cookie^h ~headerが，このような込み入った構文を利用する理由の一つは、 多くの~platform（~serverと~UAのいずれも）が， ~cookieに対する文字列に基づく~API【！`application programming interface^en】を供する結果、 応用~層の~programmerたちに，［ `Cookie^h, `Set-Cookie^h ］~headerに利用される構文を生成したり構文解析することを要求するからである。 その結果、 多くの~programmerから正しく実装されず，相互運用能の問題が生じている。 ◎ One reason the Cookie and Set-Cookie header fields use such esoteric syntax is that many platforms (both in servers and user agents) provide a string-based application programming interface (API) to cookies, requiring application-layer programmers to generate and parse the syntax used by the Cookie and Set-Cookie header fields, which many programmers have done incorrectly, resulting in interoperability problems.

~platformが、 ~cookieに対し文字列に基づく~APIを供する代わりに，より意味論上の~APIを供するなら、 きちんと~serveされることになろう。 特定の~API設計を推奨することは，この文書の視野を超えるが、 直列化された日付~文字列に代えて，抽象- “Date” ~objを受容することには、 明瞭な便益がある。 ◎ Instead of providing string-based APIs to cookies, platforms would be well-served by providing more semantic APIs. It is beyond the scope of this document to recommend specific API designs, but there are clear benefits to accepting an abstract "Date" object instead of a serialized date string.

6.3. ~IDNAへの依存関係と移行

IDNA2008 `RFC5890$r は IDNA2003 に `RFC3490$r 取って代わる。 しかしながら，この 2 つの仕様には相違点があるため、 一方の下に登録された~domain名~labelと，もう一方の下に登録されたそれとの間で、 処理に違いが生じ得る（例：変換-法）。 IDNA2003 に基づく~domain名~labelが残り続ける間，ある程度の移行期間を要する。 ~UAは、 その~IDNAの移行を手助けするために， IDNA2008 `RFC5890$r を実装するベキであり、 また， `UTS46$r または `RFC5895$r を実装してもヨイ。 IDNA2008 を実装しない~UAは、 IDNA2003 `RFC3490$r を実装しなければナラナイ。 ◎ IDNA2008 [RFC5890] supersedes IDNA2003 [RFC3490]. However, there are differences between the two specifications, and thus there can be differences in processing (e.g., converting) domain name labels that have been registered under one from those registered under the other. There will be a transition period of some time during which IDNA2003-based domain name labels will exist in the wild. User agents SHOULD implement IDNA2008 [RFC5890] and MAY implement [UTS46] 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.1. 第三者-主体~cookie

“第三者-主体（ `third-party^en ）” ~cookie（ “非同一-~site（ `cross-site^en ）” ~cookieとも称される）とは、［ 埋込まれた内容（~script, 画像, ~stylesheet, ~frameなど）のうち， 首な資源（通例的に，利用者が見ている~web~page）を~hostする~serverとは異なる~serverから得されたもの ］に結付けられた~cookieである。 第三者-主体~cookieは、 異なる各~siteにおける利用者の活動を相関するために利用されることが多い。 ◎ A "third-party" or cross-site cookie is one that is associated with embedded content (such as scripts, images, stylesheets, frames) that is obtained from a different server than the one that hosts the primary resource (usually, the Web page that the user is viewing). Third-party cookies are often used to correlate users' activity on different sites.

第三者-主体~cookieには，内来的に~privacyの課題があるので、 今や ほとんどの~UAは，それらを多様な仕方で制限する。 ある~UAは、［ 第三者-主体による `Set-Cookie^h ~headerを処理すること, 第三者-主体による `Cookie^h ~headerを送信すること ］どちらも拒否することにより，第三者-主体~cookieを完全に阻止する。 ある~UAは、 当事者-主体の文脈に基づいて — 閲覧されている~siteに依存して異なる~cookieが送信されるよう — ~cookieを仕分ける。 ある~UAは、［ 自身の~cookie施策や利用者-制御 ］に基づいて，~cookieを阻止する。 ◎ Because of their inherent privacy issues, most user agents now limit third-party cookies in a variety of ways. Some completely block third-party cookies by refusing to process third-party Set-Cookie header fields and refusing to send third-party Cookie header fields. Some partition cookies based upon the first-party context, so that different cookies are sent depending on the site being browsed. Some block cookies based upon user agent cookie policy and/or user controls.

この文書は， 特定の~approachを承認するものでも要求するものでもないが、 ~UAには，第三者-主体~cookie用の施策として［ 互換性の拘束が許可する限り，制約的なもの ］を採用することが`推奨される^2119。 その帰結として、 少なくとも当面の間は，資源は［ 第三者-主体~cookieが，各~UAにより一貫して扱われること ］には依拠し得ないものと見込まれる。 ◎ While this document does not endorse or require a specific approach, it is RECOMMENDED that user agents adopt a policy for third-party cookies that is as restrictive as compatibility constraints permit. Consequently, resources cannot rely upon third-party cookies being treated consistently by user agents for the foreseeable future.

7.2. ~cookie施策

`~UA$は、 ~cookie施策を施行してもヨイ — それは、~cookieをどう［ 利用し得る／無視し得る ］かについての制約からなる（ `5.3§ を見よ）。 ◎ User agents MAY enforce a cookie policy consisting of restrictions on how cookies may be used or ignored (see Section 5.3).

~cookie施策は、 どの~domain, あるいは どの主体に対し — 後者は当事者-主体, 第三者-主体どちらなのかに応じて（`第三者-主体~cookie§を見よ） — ［ ~UAが~cookie~accessを許容するかどうか ］を統治し得る。 施策は、 ~cookieの［ ~size, 有効期限（ `Expires§a, `Max-Age§a を見よ）, ~domainごとの個数 ／ 【全~domainにわたる】総数 ］に対しても制限sを定義し得る。 ◎ A cookie policy may govern which domains or parties, as in first and third parties (see Section 7.1), for which the user agent will allow cookie access. The policy can also define limits on cookie size, cookie expiry (see Section 4.1.2.1 and Section 4.1.2.2), and the number of cookies per domain or in total.

推奨される~cookie有効期限の上限は 400日t後である。 ~UAは： ◎ The recommended cookie expiry upper limit is 400 days. User agents may＼

• より短い~data維持~時列線を施行するためとして， より短い上限に設定してもよい。 ◎ set a lower limit to enforce shorter data retention timelines, or＼
• 適切なときには、 より長い維持を~supportするためとして， より長い上限に設定してもよい （例：~serverから~serverへの~HTTPS越しの通信）。 ◎ set the limit higher to support longer retention when appropriate (e.g., server-to-server communication over HTTPS).

制約的な~cookie施策は、［ ~security／~privacy ］を改善することを目標とすることが多い。 ~UAは、 ~cookie施策を変更することを利用者に許容することが多い（`利用者-制御§を見よ）。 ◎ The goal of a restrictive cookie policy is often to improve security or privacy. User agents often allow users to change the cookie policy (see Section 7.3).

7.3. 利用者-制御

`~UA$は、 `~cookie保管庫$に格納されている~cookieを管理するための仕組みを， 利用者に供するベキである。 例えば、 ~cookieのうち［ 指定された期間内に受信されたもの ／ 特定0の~domainに関係するもの ］すべてを，利用者が削除できるようにするなど。 多くの~UAは、 利用者が`~cookie保管庫$に格納されている~cookieを精査できるような~UIを備えている。 ◎ User agents SHOULD provide users with a mechanism for managing the cookies stored in the cookie store. For example, a user agent might let users delete all cookies received during a specified time period or all the cookies related to a particular domain. In addition, many user agents include a user interface element that lets users examine the cookies stored in their cookie store.

`~UA$は、 ~cookieを不能化する仕組みを，利用者に供するベキである。 ~cookieが不能化されている場合、~UAは ⇒＃ ~serverへの~HTTP要請に `Cookie^h ~headerを内包してはナラナイ／ ~serverからの~HTTP応答~内の `Set-Cookie^h ~headerを処理してはナラナイ ◎ User agents SHOULD provide users with a mechanism for disabling cookies. When cookies are disabled, the user agent MUST NOT include a Cookie header field in outbound HTTP requests and the user agent MUST NOT process Set-Cookie header fields in inbound HTTP responses.

`~UA$は、 `~cookie施策$を変更する仕方を提供してもヨイ（ `~cookie施策§を見よ）。 ◎ User agents MAY offer a way to change the cookie policy (see Section 7.2).

`~UA$は、［ 複数~sessionにわたる~cookieの持続的な保管を防ぐ~option ］を利用者に供してもヨイ。 そのように環境設定されている場合、 ~UAは，受信したすべての~cookieを［ その `persistent-flag$cK は ~F にされていた ］かのように扱わなければナラナイ。 一部の普及している~UAは、 この機能性を “私的~閲覧~mode” を介して公開している `Aggarwal2010$r 。 ◎ User agents MAY provide users the option of preventing persistent storage of cookies across sessions. When configured thusly, user agents MUST treat all received cookies as if the persistent-flag were set to false. Some popular user agents expose this functionality via "private browsing" mode [Aggarwal2010].

7.4. 有効期限

`~server$は，~cookieの有効期限を遠い未来に設定できるが、 ほとんどの`~UA$は，実際に~cookieを何十年も維持することはない。 `~server$は、 各~cookieに対し — 無用に長い有効期間を設定せずに — その目的に基づいた適度な有効期間を設定することにより， 利用者の~privacyを促進するベキである。 例えば、 ~session識別子の代表的な期限は， 2 週間くらいが適度であろう。 ◎ Although servers can set the expiration date for cookies to the distant future, most user agents do not actually retain cookies for multiple decades. Rather than choosing gratuitously long expiration periods, servers SHOULD promote user privacy by selecting reasonable cookie expiration periods based on the purpose of the cookie. For example, a typical session identifier might reasonably be set to expire in two weeks.

8.1. 概観

~cookieには、~security上の陥穽がいくつかある。 この節では、 その中で少数の，特に際立つ課題を概観する。 ◎ Cookies have a number of security pitfalls. This section overviews a few of the more salient issues.

~cookieは特に、 認証における`~ambient権限$に依拠するよう開発者に促す結果， `~CSRF攻撃$ `CSRF$r に対する脆弱性に転じることが多い。 また，~session識別子を~cookieに格納する際に、 開発者は，~session固定化の脆弱性を生み出すことが多い。 【！ http://security.c-inf.com/index.php?Session%20Fixation】 ◎ In particular, cookies encourage developers to rely on ambient authority for authentication, often becoming vulnerable to attacks such as cross-site request forgery [CSRF]. Also, when storing session identifiers in cookies, developers often create session fixation vulnerabilities.

【 `~ambient権限@ — 環境から暗黙的に（一律に）与えられる権限： `参考＠https://en.wikipedia.org/wiki/Ambient_authority$ 】【 `~CSRF攻撃@ （ `Cross-Site Request Forgery^en ／ ~siteをまたがる要請の偽造）： `参考＠https://ja.wikipedia.org/wiki/Cross_site_request_forgery$ 】【 ~session固定化（ `session fixation^en ）： `参考＠https://en.wikipedia.org/wiki/Session_fixation$ 】

~cookie~protocolには，それ自体に様々な脆弱性があるので （`機密性の弱点§, `完全性の弱点§を見よ）、 ~HTTPSに使役されるような［ ~transport層の暗号化 ］は， ~network攻撃者が被害者の~cookieを［ 得する／改める ］のを防ぐには不足である。 加えて、 ~cookieは，既定では — ~HTTPSと併用されているときであっても — ~network攻撃者に抗する機密性や完全性を供さない。 ◎ Transport-layer encryption, such as that employed in HTTPS, is insufficient to prevent a network attacker from obtaining or altering a victim's cookies because the cookie protocol itself has various vulnerabilities (see "Weak Confidentiality" and "Weak Integrity", below). In addition, by default, cookies do not provide confidentiality or integrity from network attackers, even when used in conjunction with HTTPS.

8.2. ~ambient権限

利用者の認証に~cookieを利用する~serverは、 一部の~UAが［ ~remote主体が， ~UAから~HTTP要請を発行させること （例：~HTTP~redirectや~HTML~formを介して） ］を~~放任するので，~securityの脆弱性に悩まされることになる。 そのような~UAは、 それらの要請を発行するときに — ~remote主体が当の~cookieの内容を知らなくとも — ~cookieを付してしまう。 その結果、 騙され易い~serverは，~remote主体から権限を行使され得ることになる。 【~remote主体 — おそらく，第三者-主体と同義。】 ◎ A server that uses cookies to authenticate users can suffer security vulnerabilities because some user agents let remote parties issue HTTP requests from the user agent (e.g., via HTTP redirects or HTML forms). When issuing those requests, user agents attach cookies even if the remote party does not know the contents of the cookies, potentially letting the remote party exercise authority at an unwary server.

この~securityの懸念には，いくつか呼称があるが （例：`~CSRF攻撃$や “`confused deputy^en” † ）、 その課題は，~cookieが`~ambient権限$の一形態である所から端を発する。 ~cookieは、 （~URLの形をとる）対象の指名（ `designation^en ）と（~cookieの形をとる）対象への権限付与（ `authorization^en ）との分離を， ~serverの運用者たちに促してしまう。 その結果、 ~UAは，攻撃者が指名する資源に権限を給するかもしれず、 ~serverや~clientは，攻撃者により指名された行為を — 彼らが利用者から権限付与されたかのように — 引き受けてしまう可能性がある。 ◎ Although this security concern goes by a number of names (e.g., cross-site request forgery, confused deputy), the issue stems from cookies being a form of ambient authority. Cookies encourage server operators to separate designation (in the form of URLs) from authorization (in the form of cookies). Consequently, the user agent might supply the authorization for a resource designated by the attacker, possibly causing the server or its clients to undertake actions designated by the attacker as though they were authorized by the user.

~serverの運用者たちは、 権限付与に~cookieを利用する代わりに， ~URLを能力（ `capabilities^en ††）として扱うことにより、 対象の指名と対象への権限付与とを絡めたいと考えるかもしれない。 この~approachは、 秘匿情報を~cookieに格納する代わりに~URLに格納して†††， ~remote主体【！entity】が秘匿情報~自体を給することを要求する。 この~approachは万能ではないが、 この原理を~~思慮深く応用すれば，より堅牢な~securityへ導き得る。 ◎ Instead of using cookies for authorization, server operators might wish to consider entangling designation and authorization by treating URLs as capabilities. Instead of storing secrets in cookies, this approach stores secrets in URLs, requiring the remote entity to supply the secret itself. Although this approach is not a panacea, judicious application of these principles can lead to more robust security.

【† “`confused deputy^en” （混乱した使節の~~問題）： `参考＠https://ja.wikipedia.org/wiki/Confused_deputy_problem$ 】【†† `capability^en — 能力に基づく~security（`~ambient権限$に対立する概念）： `参考＠https://ja.wikipedia.org/wiki/Capability-based_security$ 】【††† `参考（能力~URL）＠~CAPABILITY-URLS#dfn-capability-urls$ 】

8.3. 平文~text

`~secureな接続$越しに送信されていない限り、 `Cookie^h と `Set-Cookie^h ~header内の情報は，平文のまま伝送される。 ◎ Unless sent over a secure channel (such as TLS), the information in the Cookie and Set-Cookie header fields is transmitted in the clear.

1. これらの~headerにより運ばれる，~securityに敏感な情報すべてが、 盗聴者に公開される。 ◎ All sensitive information conveyed in these header fields is exposed to an eavesdropper.
2. 悪意的な中継点は，いずれの方向へ流れる~headerも改めれるため、 予測-不能な結果になる。 ◎ A malicious intermediary could alter the header fields as they travel in either direction, with unpredictable results.
3. 悪意的な~clientは， `Cookie^h ~headerを その伝送-前に改めれるため、 予測-不能な結果になる。 ◎ A malicious client could alter the Cookie header fields before transmission, with unpredictable results.

~serverは、 ~UAに向けて~cookieの内容を伝送する際には （~cookieを`~secureな接続$越しに送信するときでも）、 （自身が欲する何らかの形式で） 暗号化して署名するベキである。 しかしながら，それだけでは、 攻撃者による，~UAから別の~UAへの~cookieの植え付け（ `transplanting^en ）や, 後の時点における~cookieの再現を防ぐことにはならない。 ◎ Servers SHOULD encrypt and sign the contents of cookies (using whatever format the server desires) when transmitting them to the user agent (even when sending the cookies over a secure channel). However, encrypting and signing cookie contents does not prevent an attacker from transplanting a cookie from one user agent to another or from replaying the cookie at a later time.

各~cookieごとに内容を暗号化して署名することに加えて、 高~levelの~securityを要する~serverは、 `~secureな接続$越しに限り `Cookie^h, `Set-Cookie^h ~headerを利用した上で， どの~cookieにも `Secure$a 属性（`4.1.2.5§）を設定するベキである。 ~serverが `Secure$a 属性を設定しない場合、 `~secureな接続$により供される保護は，ほぼ無意味と化すことになる。 ◎ In addition to encrypting and signing the contents of every cookie, servers that require a higher level of security SHOULD use the Cookie and Set-Cookie header fields only over a secure channel. When using cookies over a secure channel, servers SHOULD set the Secure attribute (see Section 4.1.2.5) for every cookie. If a server does not set the Secure attribute, the protection provided by the secure channel will be largely moot.

例えば、 ~cookieの中に~session識別子を格納する~web~mail~serverがあって， 概して ~HTTPS越しに~accessされるとする。 ~serverがその~cookieに `Secure$a 属性を設定しなかった場合、 能動的~network攻撃者は、 ~UAからの任意の outbound ~HTTP要請を傍受して， ~web~mail~serverに向けて， その要請を~HTTP越しに~redirectさせることが可能になる。 ~web~mail~serverが~HTTP接続を~listenしていなくても、 依然として，~UAは 【~redirectにおける】 要請の中に~cookieを内包することになる。 能動的~network攻撃者は、［ これらの~cookieを傍受して，~serverに向けてそれらを再現する ］ことにより，利用者の~mail内容を読むことが可能になる。 ~serverが `Secure$a 属性をその~cookieに設定していたなら、 ~UAはその~cookieを平文~textの要請の中に内包させはしないであろう。 ◎ For example, consider a webmail server that stores a session identifier in a cookie and is typically accessed over HTTPS. If the server does not set the Secure attribute on its cookies, an active network attacker can intercept any outbound HTTP request from the user agent and redirect that request to the webmail server over HTTP. Even if the webmail server is not listening for HTTP connections, the user agent will still include cookies in the request. The active network attacker can intercept these cookies, replay them against the server, and learn the contents of the user's email. If, instead, the server had set the Secure attribute on its cookies, the user agent would not have included the cookies in the clear-text request.

8.4. ~session識別子

~serverが、 ~session情報を（攻撃者に公開されたり, 再現され得る）~cookieに直に格納する代わりに， ~nonce （ “`number used once^en （使い捨ての番号）” — ~~別名 “~session識別子” ） を~cookieに格納することが、 共通的に行われている。 ~serverは，~nonceを伴う~HTTP要請を受信したとき、 その~nonceを~keyに，当の~cookieに結付けられた状態~情報を検索できる。 ◎ Instead of storing session information directly in a cookie (where it might be exposed to or replayed by an attacker), servers commonly store a nonce (or "session identifier") in a cookie. When the server receives an HTTP request with a nonce, the server can look up state information associated with the cookie using the nonce as a key.

~session識別子~cookieの利用-下では、 攻撃者に~cookieの内容を読まれたときの被害が制限される — ~nonceが有用になるのは， （それ自身が~securityに敏感である，非~nonceの~cookieを成す内容と違って） ~serverとヤリトリするときに限られるので。 更に，使い捨て~nonceを利用すれば、［ 攻撃者が、 ~serverとの 2 回のヤリトリから~cookieの内容を “継ぎ接ぎ” して， ~serverの挙動を期待されないものにする ］ことも防がれる。 ◎ Using session identifier cookies limits the damage an attacker can cause if the attacker learns the contents of a cookie because the nonce is useful only for interacting with the server (unlike non-nonce cookie content, which might itself be sensitive). Furthermore, using a single nonce prevents an attacker from "splicing" together cookie content from two interactions with the server, which could cause the server to behave unexpectedly.

~session識別子の利用には~riskが伴う。 例えば、 ~serverは， “~session固定化（~session強制）” の脆弱性を避けるべく注意を払うベキである。 ~session固定化の攻撃は 3 段階を経て行われる。 最初の段階では、 攻撃者は，~session識別子を自身の~UAで~~取得してから，被害者の~UAに植え付ける。 次の段階では、 被害者がその~session識別子を~serverとのヤリトリに利用する （~session識別子には，利用者の資格証（ `credentials^en ）や機密（ `confidential^en ）に関する情報も伴われている可能性がある）。 最後の段階では、 攻撃者は，その~session識別子を利用して~serverと直にヤリトリする （利用者の権限（ `authority^en ）や機密に関する情報が奪われる可能性がある）。 ◎ Using session identifiers is not without risk. For example, the server SHOULD take care to avoid "session fixation" vulnerabilities. A session fixation attack proceeds in three steps. First, the attacker transplants a session identifier from his or her user agent to the victim's user agent. Second, the victim uses that session identifier to interact with the server, possibly imbuing the session identifier with the user's credentials or confidential information. Third, the attacker uses the session identifier to interact with server directly, possibly obtaining the user's authority or confidential information.

【 植え付ける（ `transplant^en ）： （訳者による解釈）何らかの方法で（具体的な手段は`多岐にわたる＠https://www.google.co.jp/search?q=session+fixation$）、 被害者を “攻撃者が~session識別子により， 一定の権限を有する状態で~serverに~accessできる状況” と同一の状況に誘導する（しかる後， “体を入れ替える” — 攻撃者が用意した “合鍵” を被害者に利用させ、 しかる後，同じ鍵で侵入する — したがって、 “~login” 時に鍵を別の鍵に交換することが有効果な対策になると考えられる）。 】

8.5. 機密性の弱点

~cookieは~portによる隔離を供さない。 ~cookieが，ある~port上で稼働している~serviceで読取れるならば、 その~cookieは，同じ~serverの別~port上の~serviceでも読取れる。 ~cookieが，ある~port上の~serviceで書込めるならば、 その~cookieは，同じ~serverの別~port上の~serviceでも書込める。 この理由から、~serverは、［ 同じ~hostの異なる~port上で，互いに信用し合っていない~serviceを同時に稼働しているとき ］は，~securityに敏感な情報を~cookieを利用して格納するベキでない。 ◎ Cookies do not provide isolation by port. If a cookie is readable by a service running on one port, the cookie is also readable by a service running on another port of the same server. If a cookie is writable by a service on one port, the cookie is also writable by a service running on another port of the same server. For this reason, servers SHOULD NOT both run mutually distrusting services on different ports of the same host and use cookies to store security-sensitive information.

~cookieは~schemeによる隔離を供さない。 ~cookieは `http^c と `https^c ~schemeで最も共通的に利用されるが、 所与の~host用の~cookieは， `ftp^c や `gopher^c などの他の~schemeでも可用になり得る。 この，~schemeによる隔離の欠如は、 ~cookieへの~accessを許可する`非HTTP~API$ （例：~HTMLの `document.cookie$dom ~API） において顕著に見られるが、 ~schemeによる隔離の欠如はまた， ~cookieの処理~要件にも実際に在る （例：~HTTPを介して `gopher^c ~scheme~URIから検索取得することを考えてみよ）。 【~web~platform（~browser）においては、 `gopher^c はすでに廃されている ／ `ftp^c は廃されつつある。】 ◎ Cookies do not provide isolation by scheme. Although most commonly used with the http and https schemes, the cookies for a given host might also be available to other schemes, such as ftp and gopher. Although this lack of isolation by scheme is most apparent in non-HTTP APIs that permit access to cookies (e.g., HTML's document.cookie API), the lack of isolation by scheme is actually present in requirements for processing cookies themselves (e.g., consider retrieving a URI with the gopher scheme via HTTP).

~cookieは~pathによる隔離を常に供するものではない。 ~network~levelの~protocolでは、 ある~pathに対応して格納された~cookieが，別の~pathに向けて送信されることはないが、 一部の~UAは，［ ~HTMLの `document.cookie^dom ~APIなどの`非HTTP~API$ ］を介して~cookieを公開する。 これらの~UAの一部（例：~web~browser）は，異なる~pathから受信した資源を隔離しないので、 ある~pathから検索取得された資源から，別の~pathに対応して格納された~cookieに~accessし得る。 ◎ Cookies do not always provide isolation by path. Although the network-level protocol does not send cookies stored for one path to another, some user agents expose cookies via non-HTTP APIs, such as HTML's document.cookie API. Because some of these user agents (e.g., web browsers) do not isolate resources received from different paths, a resource retrieved from one path might be able to access cookies stored for another path.

8.6. 完全性の弱点

~cookieは、 同胞~domain（およびそれらの下位domain）に対する完全性（ `integrity^en ）を保証しない。 例えば, `foo.site.example^s と `bar.site.example^s を考える。 `foo.site.example^s の~serverは、 `Domain$a 属性 `site.example^l の~cookieを設定できる （既存の `site.example^l ~cookieを上書する可能性もある）。 ~UAは、 その~cookieを `bar.site.example^s へ向けた~HTTP要請に内包することになる。 最悪の場合、 `bar.site.example^s は，この~cookieと 自身が設定した~cookieとを判別できなくなる。 `foo.site.example^s ~serverは、 この能を利用して `bar.site.example^s への攻撃を仕掛けるかもしれない。 ◎ Cookies do not provide integrity guarantees for sibling domains (and their subdomains). For example, consider foo.site.example and bar.site.example. The foo.site.example server can set a cookie with a Domain attribute of "site.example" (possibly overwriting an existing "site.example" cookie set by bar.site.example), and the user agent will include that cookie in HTTP requests to bar.site.example. In the worst case, bar.site.example will be unable to distinguish this cookie from a cookie it set itself. The foo.site.example server might be able to leverage this ability to mount an attack against bar.site.example.

`Set-Cookie^h ~headerが `Path$a 属性を~supportしていても， ~UAは `Set-Cookie^h ~header内の任意の `Path$a 属性を受容するので、 `Path$a 属性は，いかなる完全性の保護も供さない。 例えば， `http://site.example/foo/bar^s に向けた要請に対する~HTTP応答は、 `Path$a 属性 `/qux^l の~cookieを設定できる。 したがって~serverは、［ 同じ~hostの異なる~path上で，互いに信用し合っていない~serviceを同時に稼働しているとき ］は，~securityに敏感な情報を~cookieを利用して格納するベキでない。 ◎ Even though the Set-Cookie header field supports the Path attribute, the Path attribute does not provide any integrity protection because the user agent will accept an arbitrary Path attribute in a Set-Cookie header field. For example, an HTTP response to a request for http://site.example/foo/bar can set a cookie with a Path attribute of "/qux". Consequently, servers SHOULD NOT both run mutually distrusting services on different paths of the same host and use cookies to store security-sensitive information.

能動的~network攻撃者は、 `http://site.example/^s からの応答になりすまして `Set-Cookie^h ~headerを注入することにより， `https://site.example/^s に向けて送信される `Cookie^h ~headerに~cookieを注入できる。 `site.example^s にある~HTTPS~serverは、 ~HTTPS応答の中のこれらの~cookieと 自身が設定した~cookieとを判別できない。 `site.example^s が~HTTPSを排他的に利用していたとしても、 能動的~network攻撃者は， この能を利用して `site.example^s への攻撃を仕掛けるかもしれない。 ◎ An active network attacker can also inject cookies into the Cookie header field sent to https://site.example/ by impersonating a response from http://site.example/ and injecting a Set-Cookie header field. The HTTPS server at site.example will be unable to distinguish these cookies from cookies that it set itself in an HTTPS response. An active network attacker might be able to leverage this ability to mount an attack against site.example even if site.example uses HTTPS exclusively.

~serverは、 自身の~cookieを［ その内容を暗号化して署名するか， `__Secure-$l 接頭辞を伴うよう命名する ］ことにより，これらの攻撃を部分的に軽減できる。 しかしながら，［ 攻撃者は、 自身が真正な `site.example^s ~serverから受信した~cookieを， 利用者の~sessionの中で再現できる ］ので、 暗号の利用は この課題を根本から払拭するものではなく，予測-不能な結果になる。 ◎ Servers can partially mitigate these attacks by encrypting and signing the contents of their cookies, or by naming the cookie with the __Secure- prefix. However, using cryptography does not mitigate the issue completely because an attacker can replay a cookie he or she received from the authentic site.example server in the user's session, with unpredictable results.

最後に，攻撃者は、 多数の~cookieを格納させることにより， ~cookieを削除するよう~UAに強制するかもしれない。 ~UAは，自身の保管~上限に達したとき、 何らかの~cookieを抹消するよう強制されることになる。 ~serverは、 ~UAが~cookieを維持することに依拠するベキでない。 ◎ Finally, an attacker might be able to force the user agent to delete cookies by storing a large number of cookies. Once the user agent reaches its storage limit, the user agent will be forced to evict some cookies. Servers SHOULD NOT rely upon user agents retaining cookies.

8.7. ~DNSへの依拠

~cookieの~securityは、 ~DNS（ `Domain Name System^en ）に依拠する。 ~DNSが部分的または全部的に弱体化された場合、 ~cookie~protocolは，応用が要する~securityを供するのに失敗するであろう。 ◎ Cookies rely upon the Domain Name System (DNS) for security. If the DNS is partially or fully compromised, the cookie protocol might fail to provide the security properties required by applications.

8.8. `SameSite^a ~cookie

9.1. `Cookie^h

恒久的~message~header~registry（ `RFC3864$r を見よ）は、 以下の登録により更新される必要がある。 ◎ The permanent message header field registry (see [RFC3864]) needs to be updated with the following registration:

9.2. `Set-Cookie^h

恒久的~message~header~registry（ `RFC3864$r を見よ）は、 以下の登録により更新される必要がある。 ◎ The permanent message header field registry (see [RFC3864]) needs to be updated with the following registration:

9.3. ~cookie属性~registry

~IANAには、 “~cookie属性~registry” を作成することが要請される。 この~registryは、［ ~cookieの挙動を制御するために利用される属性たち ］が成す名前空間を定義する。 この~registryは、 `~IANA-a/cookie-attribute-names＠~IANA-a/cookie-attribute-names$ にて保守されるべきである。 【~link先は、まだ存在しない。】 ◎ IANA is requested to create the "Cookie Attribute Registry", defining the name space of attribute used to control cookies' behavior. The registry should be maintained at https://www.iana.org/assignments/cookie-attribute-names.