Cookies: HTTP State Management Mechanism （日本語訳）

◎要約

この文書は~HTTP `Cookie^h と `Set-Cookie^h ~headerを定義する。これらの~headerは、（~cookieと呼ばれる）状態~情報を~HTTP~UA側に格納させるために， ~HTTP~serverにより利用され得るものであり、ほぼ状態~情報がない~HTTP~protocol越しに， ~serverが状態を保つ~sessionを保守できるようにする。 ~cookieには，~securityと~privacyを退行させる多くの歴史的な欠陥があるが、 `Cookie^h と `Set-Cookie^h ~headerは~internet上で広く利用されている。この文書は `RFC6265$r を廃用にする。 ◎ This document defines the HTTP Cookie and Set-Cookie header fields. These header fields can be used by HTTP servers to store state (called cookies) at HTTP user agents, letting the servers maintain a stateful session over the mostly stateless HTTP protocol. Although cookies have many historical infelicities that degrade their security and privacy, the Cookie and Set-Cookie header fields are widely used on the Internet. This document obsoletes RFC 6265.

1. 序論

この文書は、 ~HTTPの `Cookie^h と `Set-Cookie^h ~headerを定義する。 ~HTTP~serverは、 `Set-Cookie^h ~headerを利用して，~cookieと呼ばれる［ ( 名前, 値 ) が成す~pairと, それに結付けられた~metadata ］を~UAに渡すことができる。 ~UAは、~serverへ後続な要請を為す際に，その~metadataと他の情報を利用して ( 名前, 値 ) が成す~pairを `Cookie^h ~header内に返すかどうか決定する。 ◎ This document defines the HTTP Cookie and Set-Cookie header fields. Using the Set-Cookie header field, an HTTP server can pass name/value pairs and associated metadata (called cookies) to a user agent. When the user agent makes subsequent requests to the server, the user agent uses the metadata and other information to determine whether to return the name/value pairs in the Cookie header field.

【 “~header” ：正式には “~header~field（ `header field^en ）” だが、この訳では一律に “~header” と略記する。】

見かけの単純さに反し、 ~cookieには，いくつかの複階性がある。例えば，~serverは、 ~UAに向けて送信する各~cookieごとに，その視野を指示する。この視野は、当の~cookieを［ ~UAが返すべき期間, ~UAが返すべき~server, 適用-可能な接続~種別【`~secureな接続$か否か】］を指示する。 ◎ Although simple on their surface, cookies have a number of complexities. For example, the server indicates a scope for each cookie when sending it to the user agent. The scope indicates the maximum amount of time in which the user agent should return the cookie, the servers to which the user agent should return the cookie, and the connection types for which the cookie is applicable.

歴史的な理由から、 ~cookieには，~securityと~privacyに関わるいくつかの欠陥がある。例えば，~serverは、 `Secure$a 属性により［当の~cookieは、 `~secureな接続$用に意図される］ことを指示できるが、それは，能動的~network攻撃者が居る下で完全性（ `integrity^en ）を供するものではない。同様に、 ~web~browserに利用される通例の “同一-生成元~施策” （ `same-origin policy^en ）により，異なる~portを介して検索取得される内容は互いに隔離されるにも関わらず、所与の~host用の~cookieは，同じ~host上のすべての~portにわたって共有される。 ◎ For historical reasons, cookies contain a number of security and privacy infelicities. For example, a server can indicate that a given cookie is intended for "secure" connections, but the Secure attribute does not provide integrity in the presence of an active network attacker. Similarly, cookies for a given host are shared across all the ports on that host, even though the usual "same-origin policy" used by web browsers isolates content retrieved via different ports.

この仕様は、［ ~cookieを生産する~server, ~cookieを消費する~UA ］どちらの開発者にも適用される。 `3.2§ にて、これら各~実装~種別に意図される対象読者を明確化する助けを与える。 ◎ This specification applies to developers of both cookie-producing servers and cookie-consuming user agents. Section 3.2 helps to clarify the intended target audience for each implementation type.

~UAとの相互運用能を最大化するため、 ~serverは，自らを`~server要件§にて定義される~well-behaved-profileに制限する下で~cookieを生成するベキである。 ◎ To maximize interoperability with user agents, servers SHOULD limit themselves to the well-behaved profile defined in Section 4 when generating cookies.

~UAは、 `~server要件§にて定義される~well-behaved-profileに適合しない既存の~serverとの相互運用能を最大化するため、 `~UA要件§にて定義されるより~~寛容な処理~規則を実装しなければナラナイ。 ◎ User agents MUST implement the more liberal processing rules defined in Section 5, in order to maximize interoperability with existing servers that do not conform to the well-behaved profile defined in Section 4.

この文書は、これらの~headerの構文と意味論を，~internetにおける実際の利用に沿うように指定する。特に、この文書は，今日利用-中にあるものを超える新たな構文や意味論を創出するものではない。 `~server要件§に与える，~cookie生成についての推奨は、現在の~serverの挙動を成す好ましい~subsetを表現する。 `~UA要件§にて与える，より~~寛容な~cookie処理~algoは、今日利用-中にある［構文や意味論の~variation ］を成すすべてを推奨するものではない。この文書では、一部の既存の~softwareにおける，推奨される~protocolとの有意な差異についても説明する。 ◎ This document specifies the syntax and semantics of these header fields as they are actually used on the Internet. In particular, this document does not create new syntax or semantics beyond those in use today. The recommendations for cookie generation provided in Section 4 represent a preferred subset of current server behavior, and even the more liberal cookie processing algorithm provided in Section 5 does not recommend all of the syntactic and semantic variations in use today. Where some existing software differs from the recommended protocol in significant ways, the document contains a note explaining the difference.

この文書は `RFC6265$r を廃用にする。 ◎ This document obsoletes [RFC6265].

2. 表記規約

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

◎表記記号

いくつかの用語（外部の仕様にて定義されるものなど）には、 ~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).

次に挙げる規則は、 `HTTP$r にて定義される ⇒＃【`IMF-fixdate$p,】【`token$p,】 `OWS$p （省略可能な空白）, `BWS$p （不良な空白） ◎ The OWS (optional whitespace) and BWS (bad whitespace) rules are defined in Section 5.6.3 of [HTTP].

2.3. 各種用語

次に挙げる用語の意味は、 `HTTP$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 ([HTTP], 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$ `HTTP$r を指す。 ◎ The term request-uri refers to "target URI" as defined in Section 7.1 of [HTTP].

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，および`同一-生成元$ ］と見なすことになろう（加えて、 `~URL$の`生成元$urlは `URL$r にて定義される）。特に，この仕様に現れる［文書の`生成元$doc, `環境~設定群~obj$の`生成元$enV ］は、その定義 — ~web~platformに特有な`~domain成分＠~ORIGIN#concept-origin-domain$で拡張された定義 — に基づく。この~domain成分は、この仕様においては，用語 `同一-~site$の中に組入れられる。また、 `RFC6454$r における GUID は，~HTMLにおける`不透明な生成元$に対応する。】【生成元は、文脈によっては，`生成元~server$の略称を表すこともある。】

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

~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. 概観

この節では、［ `生成元~server$が，ある状態~情報を`~UA$に向けて送信する仕方］および［ ~UAが，当の状態~情報を生成元~serverへ返す仕方］について要旨する。 ◎ This section outlines a way for an origin server to send state information to a user agent and for the user agent to return the state information to the origin server.

`生成元~server$は、 `~UA$に状態を格納させるために， ~HTTP応答に `Set-Cookie^h ~headerを内包する。 ~UAは、後続な要請において，［以前に `Set-Cookie^h ~headerにて受信した~cookieを包含する `Cookie^h 要請~header ］を生成元~serverへ返す。生成元~serverは、その `Cookie^h ~headerを無視しても, その内容を応用が定義する目的に利用してもかまわない。 ◎ To store state, the origin server includes a Set-Cookie header field in an HTTP response. In subsequent requests, the user agent returns a Cookie request header field to the origin server. The Cookie header field contains cookies the user agent received in previous Set-Cookie header fields. The origin server is free to ignore the Cookie header field or use its contents for an application-defined purpose.

`生成元~server$は、どの応答にも `Set-Cookie^h 応答~headerを送信してヨイ。生成元~serverは、単独の応答に複数個の `Set-Cookie^h ~headerを内包できる。 `Cookie^h や `Set-Cookie^h ~headerが在っても，~HTTP~cacheが応答を格納したり再利用する~~妨げにはならない。 ◎ Origin servers MAY send a Set-Cookie response header field with any response. An origin server can include multiple Set-Cookie header fields in a single response. The presence of a Cookie or a Set-Cookie header field does not preclude HTTP caches from storing and reusing a response.

`生成元~server$は、単独の~header内に，複数個の `Set-Cookie^h ~header値を畳込むベキでない。 ~headerを畳込む通例の仕組み（ `HTTP$r `~headerの結合-法$にて定義される）は、 `Set-Cookie^h における `,^ch の利用と競合するので， `Set-Cookie^h ~headerの意味論を変更し得る。 ◎ Origin servers SHOULD NOT fold multiple Set-Cookie header fields into a single header field. The usual mechanism for folding HTTP headers fields (i.e., as defined in Section 5.3 of [HTTP]) might change the semantics of the Set-Cookie header field because the %x2C (",") character is used by Set-Cookie in a way that conflicts with such folding.

`~UA$は、 `Set-Cookie^h ~headerを［応答の`状態s~code$／自身の`~cookie施策$ ］に基づいて，無視してもヨイ（ `5.3§ を見よ）。 ◎ User agents MAY ignore Set-Cookie header fields based on response status codes or the user agent's cookie policy (see Section 5.3).

3.1. 例

~serverは、 `~UA$への~HTTP応答に `Set-Cookie^h ~headerを利用して，短い`文字列$を送信できる — ~UAは、その~cookieの視野に入る未来の~HTTP要請において，その文字列を返すことになる。例えば，~serverは、 `SID^s と命名された “~session識別子” として値 `31d4d96e407aad42^s を~UAへ送信できる。 ~UAは、後続な要請にて，その~session識別子を返すことになる： ◎ Using the Set-Cookie header field, a server can send the user agent a short string in an HTTP response that the user agent will return in future HTTP requests that are within the scope of the cookie. For example, the server can send the user agent a "session identifier" named SID with the value 31d4d96e407aad42. The user agent then returns the session identifier in subsequent requests.

== ~server → ~UA ==

Set-Cookie: SID=31d4d96e407aad42

== ~UA → ~server ==

Cookie: SID=31d4d96e407aad42

~serverは、［ `Path$a ／ `Domain$a ］属性を利用して，~cookieの既定の視野を改めれる。例えば，~serverは、 `site.example^s の［どの~path, どの下位domain ］に対しても，その~cookieを返すよう~UAに指図できる： ◎ The server can alter the default scope of the cookie using the Path and Domain attributes. For example, the server can instruct the user agent to return the cookie to every path and every subdomain of site.example.

== ~server → ~UA ==

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

== ~UA → ~server ==

Cookie: SID=31d4d96e407aad42

次の例に示されるとおり、 ~serverは，複数個の~cookieを~UAに格納させれる。例えば，~serverは、 2 個の `Set-Cookie^h ~headerを返すことにより， ~session識別子と同時に利用者が選好する言語も格納させれる。 ~serverは、より~securityに敏感な~session識別子~用には，追加的な保護を供する［ `Secure$a, `HttpOnly$a ］`属性$（ § 4.1.2 ）を利用することに注意： ◎ As shown in the next example, the server can store multiple cookies at the user agent. For example, the server can store a session identifier as well as the user's preferred language by returning two Set-Cookie header fields. Notice that the server uses the Secure and HttpOnly attributes to provide additional security protections for the more sensitive session identifier (see Section 4.1.2).

== ~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

上の `Cookie^h ~headerは、 2 個の~cookie — `SID^s と命名されたもの, `lang^s と命名されたもの — を包含していることに注意。 ~UAの “複数~session” 越しに（例：~UAの再起動を挟んで）~cookieを持続させたいと望むなら、 ~serverは， `Expires$a 属性にその有効期限を指定できる。 ~UAは、自身の`~cookie保管庫$の総容量が割当分を超過した場合や，利用者が手動で~serverの~cookieを削除した場合など、有効期限が過ぎる前に~cookieを削除し得ることに注意。 ◎ Notice that the Cookie header field above contains two cookies, one named SID and one named lang. If the server wishes the user agent to persist the cookie over multiple "sessions" (e.g., user agent restarts), the server can specify an expiration date in the Expires attribute. Note that the user agent might delete the cookie before the expiration date if the user agent's cookie store exceeds its quota or if the user manually deletes the server's cookie.

== ~server → ~UA ==

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

== ~UA → ~server ==

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

最後に，~cookieを除去するためには、 ~serverは，有効期限を過去にした `Set-Cookie^h ~headerを返す。これが成功するのは、 `Set-Cookie^h ~header内の［ `Path$a, `Domain$a ］両~属性とも，~cookieの作成-時に利用した値に合致するときに限られる。 ◎ Finally, to remove a cookie, the server returns a Set-Cookie header field with an expiration date in the past. The server will be successful in removing the cookie only if the Path and the Domain attribute in the Set-Cookie header field match the values used when the cookie was created.

== ~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. ~serverに課される要件

この節では、［ `Cookie^h ／ `Set-Cookie^h ］~headerの構文と意味論を成す ~well-behaved-profile 【既存の~server, ~UAの挙動から導出された， “きちんとした挙動” を成す描像】を述べる。 ◎ This section describes the syntax and semantics of a well-behaved profile of the Cookie and Set-Cookie header fields.

5. ~UAに課される要件

この節では、 `Cookie^h と `Set-Cookie^h ~headerについて、これらの要件を精確に実装する~UAが（~serverが`~server要件§に述べた~well-behaved-profileに適合しなくても），既存の~serverと相互運用できるに足る詳細を指定する。 ◎ This section specifies the Cookie and Set-Cookie header fields in sufficient detail that a user agent implementing these requirements precisely can interoperate with existing servers (even those that do not conform to the well-behaved profile described in Section 4).

~UAは、ここで指定されるものより多くの制約（例：~UAの`~cookie施策$）を施行し得る。しかしながら，そのような追加の制約は、既存の~serverとの相互運用能を抑制するものにもなり得る。 ◎ A user agent could enforce more restrictions than those specified herein (e.g., restrictions specified by its cookie policy, described in Section 7.2). However, such additional restrictions may reduce the likelihood that a user agent will be able to interoperate with existing servers.

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.1.2. 正準-化された~host名

`~host名を正準-化する@ ときは、所与の ( %~host名 ) に対し，次の~algoにより生成される`文字列$を返す： ◎ A canonicalized host name is the string generated by the following algorithm:

%~label群 ~LET 空な~list ◎ ↓
%~host名を成す ~EACH( ~domain名~label %~label ) に対し，現れる順に：
1. ~IF［ %~label は `Non-Reserved LDH^en （ NR-LDH ）~labelでない］ ⇒ %~label ~SET %~label を次のうち適切な方に変換した結果（ `6.3§ を見よ） ⇒＃ `A-label^en （ `5890/2.3.2.1$rfc ）／ “`punycode^en ~label” （ `3490/4$rfc による， “`ToASCII^en” 変換による結果の~label）
2. %~label群に %~label を付加する
◎ Convert the host name to a sequence of individual domain name labels. ◎ Convert each label that is not a Non-Reserved LDH (NR-LDH) label, to an A-label (see Section 2.3.2.1 of [RFC5890] for the former and latter), or to a "punycode label" (a label resulting from the "ToASCII" conversion in Section 4 of [RFC3490]), as appropriate (see Section 6.3 of this specification).
~RET %~label群を成すすべての~labelを，文字 `.^ch で分離して順に連結した結果 ◎ Concatenate the resulting labels, separated by a %x2E (".") character.

5.1.3. ~domainの照合-法

所与の ( `文字列$ %文字列, `文字列$ %~domain文字列 ) が `~domain合致して@ いるとは、 ~OR↓ が満たされることをいう（この時点では、 %~domain文字列, %文字列は，どちらも小文字に正準-化済みであることに注意）： ◎ A string domain-matches a given domain string if at least one of the following conditions hold:

%~domain文字列 ~EQ %文字列 ◎ The domain string and the string are identical. (Note that both the domain string and the string will have been canonicalized to lower case at this point.)
~AND↓： ◎ All of the following conditions hold:
- %文字列の尾部は［ %~domain文字列の先頭に文字 `.^ch を付加した結果］に一致する ◎ The domain string is a suffix of the string. ◎ The last character of the string that is not included in the domain string is a %x2E (".") character.
- %文字列は~host名である（すなわち，~IP~addressではない） ◎ The string is a host name (i.e., not an IP address).

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$の否定を意味する。】

所与の`要請$ %要請が［ `同一-~site@rq ／ `非同一-~site@rq ］であるとは、 ~OR↓ を［満たす／満たさない］ことをいう： ◎ 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.
~AND↓：
- %要請は`~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.2.1. 文書に基づく要請

~UAの~URL~bar内に表示される~URIは，利用者に直に公開される唯一の~security文脈であり、したがって，利用者が特定0の~web~siteを信用するかどうか決定するにあたって適度に依拠できる唯一の~~情報である。その~URIの`生成元$は、［利用者が，自身がヤリトリしているとおよそ信じるであろう文脈］を表現する。 `~top-level生成元@ とは、この`生成元$ — すなわち`~top-level辿可能$にて`作動中な文書$navの`生成元$ — として定義される。 ◎ The URI displayed in a user agent's address bar is the only security context directly exposed to users, and therefore the only signal users can reasonably rely upon to determine whether or not they trust a particular website. The origin of that URI represents the context in which a user most likely believes themselves to be interacting. We'll define this origin, the top-level traversable's active document's origin, as the "top-level origin".

`文書$の`~cookie用~site$は、 `文書$の`~node~navigable$に応じて【これは、規範的な定義ではない】： ◎ ↓

`~top-level辿可能$である場合、 `~top-level生成元$になる。 ◎ For a document displayed in a top-level traversable, we can stop here: the document's "site for cookies" is the top-level origin.
`子~navigable$である場合【！For `容器~文書$nav】、 `7034/4$rfc に述べられるように “~~複数階に入子にされた局面” を織り込むため，文書の`先祖~navigable群$を成す各`~navigable$にて`作動中な文書$navの`生成元$を聴取する必要がある ⇒ ［文書, その各~先祖~文書］を成すどの文書に対しても， ( その`生成元$, `~top-level生成元$ ) は`同一-~site$である場合, そのときに限り，`~top-level生成元$になり、他の場合は，`不透明な生成元$【！に設定される`生成元$】になる。 ◎ For container documents, we need to audit the origins of each of a document's ancestor navigables' active documents in order to account for the "multiple-nested scenarios" described in Section 4 of [RFC7034]. A document's "site for cookies" is the top-level origin if and only if the top-level origin is same-site with the document's origin, and with each of the document's ancestor documents' origins. Otherwise its "site for cookies" is an origin set to an opaque origin.

所与の ( `文書$ %文書 ) の`~cookie用~site$は、次の~algoにより決定される： ◎ Given a Document (document), the following algorithm returns its "site for cookies":

%~top文書 ~LET %文書の`~node~navigable$の`~top-level辿可能$navにて`作動中な文書$nav ◎ Let top-document be the active document in document's navigable's top-level traversable.
%~top生成元 ~LET ［次が満たされるならば %~top文書の~URIの`生成元$ ／ ~ELSE_ %~top文書の`生成元$ ］ ⇒ `閲覧~文脈~sandbox化( 生成元 )~flag$ ~IN %~top文書にて`作動中な~sandbox法~flag集合$ ◎ Let top-origin be the origin of top-document's URI if top-document's sandboxed origin browsing context flag is set, and top-document's origin otherwise.
［ %文書の`広義-先祖~navigable群$を成す ~EACH( `~navigable$ %~navigable ) に対し： ◎ Let documents be a list consisting of the active documents of document's inclusive ancestor navigables. ◎ For each item in documents:
1. %文書~item ~LET %~navigable にて`作動中な文書$nav ◎ ↑
2. %生成元 ~LET ［次が満たされるならば %文書~item の~URIの`生成元$ ／ ~ELSE_ %文書~item の`生成元$ ］ ⇒ `閲覧~文脈~sandbox化( 生成元 )~flag$ ~IN %文書~item にて`作動中な~sandbox法~flag集合$ ◎ Let origin be the origin of item's URI if item's sandboxed origin browsing context flag is set, and item's origin otherwise.
3. ~IF［ ( %生成元, %~top生成元 ) は`同一-~site$でない］ ⇒ ~RET `不透明な生成元$ ◎ If origin is not same-site with top-origin, return an origin set to an opaque origin.
~RET %~top生成元 ◎ Return top-origin.

注記：この~algoは、［ %~top文書から %文書までの連鎖~全体を成す，すべての文書が作動中【`全部的に作動中$】である］ときに限り，適用される。【したがって、 %文書~item が ~NULL になることはない。】 ◎ Note: This algorithm only applies when the entire chain of documents from top-document to document are all active.

5.2.2. ~workerに基づく要請

~worker駆動な`要請$は、文書~駆動な要請ほどには明瞭に~~区切れない — `~top-level辿可能$と~workerとの間には明瞭な~linkは無いので。このことは、とりわけ，`~sw$ `SERVICE-WORKERS$r に該当する — ~swは、可視な文書がまったく無くとも，裏で~codeを実行し得るので。 ◎ Worker-driven requests aren't as clear-cut as document-driven requests, as there isn't a clear link between a top-level traversable and a worker. This is especially true for Service Workers [SERVICE-WORKERS], which may execute code in the background, without any document visible at all.

注記：以下の記述は、 ~workerはそれを~instance化した文書と`同一-生成元$であると見做す必要がある。これが成り立たなくなる場合、 ~workerの~scriptの~URI【`~script~URL$sw？】も織り込む下で，その地位を決定する必要があることになる。 ◎ Note: The descriptions below assume that workers must be same-origin with the documents that instantiate them. If this invariant changes, we'll need to take the worker's script's URI into account when determining their status.

5.2.2.1. 専用／共用~worker

`専用~worker$【 `DedicatedWorkerGlobalScope^dom 】は、単純である — 各~専用~workerには、それを束縛する文書が一つだけあるので。専用~workerから生成される`要請$ （例： `importScripts()$dom, `XMLHttpRequest$dom, `fetch()$dom, 等々を介するものなど）の`~cookie用~site$は、その文書の`~cookie用~site$になる。 ◎ Dedicated workers are simple, as each dedicated worker is bound to one and only one document. Requests generated from a dedicated worker (via importScripts, XMLHttpRequest, fetch(), etc) define their "site for cookies" as that document's "site for cookies".

`共用~worker$【 `SharedWorkerGlobalScope^dom 】は、同時に複数個の文書に束縛され得る。共用~workerの`~cookie用~site$は、［共用~workerの`生成元$が, それらの文書~すべての`~cookie用~site$と`同一-~site$である場合はそれ／ ~ELSE_（~~普通にあり得る）`不透明な生成元$ ］になる。【前~段落, この段落は、規範的な定義ではない。】 ◎ Shared workers may be bound to multiple documents at once. As it is quite possible for those documents to have distinct "site for cookies" values, the worker's "site for cookies" will be an origin set to an opaque origin in cases where the values are not all same-site with the worker's origin, and the worker's origin in cases where the values agree.

所与の ( `WorkerGlobalScope$dom ~obj %~worker ) の`~cookie用~site$は、次の~algoの結果になる： ◎ Given a WorkerGlobalScope (worker), the following algorithm returns its "site for cookies":

%~site ~LET %~worker 【に`関連な設定群~obj$】の`生成元$ ◎ Let site be worker's origin.
%~worker の`所有者~集合$†を成す ~EACH( %~item ) に対し： ◎ For each document in worker's Documents:
1. %~item~site ~LET %~item の`~cookie用~site$ — これは、 %~item に応じて ⇒＃ `文書$である場合，`文書に基づく要請§に従う／ `WorkerGlobalScope$dom ~objである場合，この~algoを再帰的に呼出して決定される†† ◎ Let document-site be document's "site for cookies" (as defined in Section 5.2.1).
2. ~IF［ ( %~item~site, %~site ) は`同一-~site$でない］ ⇒ ~RET `不透明な生成元$【！に設定された`生成元$】 ◎ If document-site is not same-site with site, return an origin set to an opaque origin.
【† `所有者~集合$は、原文では “`worker's Documents^en” という未定義な（または現在は廃された？）用語で記されている。】【†† %~worker は別の~workerに入子にされ得るので、 `所有者~集合$ （それは、`文書$を一つも含まないかもしれない）は再帰的にたどる必要があろう。】
~RET %~site ◎ Return site.

5.2.2.2. ~sw

`~sw$は、もっと複雑になる。それは，完全に別々な実行~文脈の下で動作し、それを登録した`文書$との関係性は，かするほどしかないので。 ◎ Service Workers are more complicated, as they act as a completely separate execution context with only tangential relationship to the Document which registered them.

~UAが`~sw$をどう取扱うかは，~UA間で相違し得るが、 ~UAは， `SERVICE-WORKERS$r 仕様に合致するベキである。 ◎ How user agents handle Service Workers may differ, but user agents SHOULD match the [SERVICE-WORKERS] specification.

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.6§ に則って処理するベキである。すなわち，応答の`状態s~code$が`100 番台$以外（ `400 番台$, `500 番台$も含む）である場合、応答に包含される `Set-Cookie^h ~headerを — `~UA$の`~cookie施策$に則って無視されないならば — 処理するベキである。 ◎ All other Set-Cookie header fields SHOULD be processed according to Section 5.6. 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.7.

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

例えば、ある~serverが，次の `Set-Cookie^h ~headerを送信したとする： ◎ For example, if a server sends the following Set-Cookie header field

Set-Cookie: __SECURE-SID=12345

接頭辞を文字大小区別で検査する~UAは、この~cookieを【 `Secure$a 属性が無くても】受容することになる — その結果、当の~serverは，この~cookieが【~UAから返されたとき】［ `__Secure-$l と綴られるものと同じ保証の~subjectになる【すなわち、 `Secure$a 属性を伴っていた】］ものと不正に予見することになろう。 ◎ to a UA which checks prefixes case-sensitively it will accept this cookie and the server would incorrectly believe the cookie is subject the same guarantees as one spelled __Secure-.

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

例えば、ある~site用の~cookie `__Secure-SID=12345^c がすでに設定された下で，攻撃者が — 何らかの手段により — 当の~site用に次の `Set-Cookie^h ~headerをそのような~UAへ送信したとする： ◎ For example, a site already has a cookie __Secure-SID=12345 and by some means an attacker sends the following Set-Cookie header field for the site to a UA which checks prefixes case-sensitively.

Set-Cookie: __SeCuRe-SID=evil

利用者が次回に当の~siteに訪問したとき、そのような~UAは，どちらの~cookieも送信することになる： ◎ The next time a user visits the site the UA will send both cookies:

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

文字大小無視で処理している~serverは、この 2 つの~cookieの相違がわからないので，当の~siteを弱体化することを攻撃者に許容することになる。 ◎ The server, being case-insensitive, won't be able to tell the difference between the two cookies allowing the attacker to compromise the site.

これらの課題を防止するため、 `~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^h ~headerは、適合tな~UAにおいては却下されることになろう。 ◎ The following are examples of Set-Cookie header fields that would be rejected by a conformant user agent.

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^h ~headerは、ある~secureな生成元から設定されたなら，受容されることになろう。 ◎ Whereas the following Set-Cookie header fields would be accepted if set from a secure origin.

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.7. 保管~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.

~UAは、 `要請~URI$から ( 名前: %~cookie名, 値: %~cookie値, 属性~list: %~cookie属性~list ) を伴う`~cookieを受信した$ときは、その~cookieを，以下に従って処理しなければナラナイ（この~algoの最後の段に達する前に現れる ~RET は、受信した~cookieをまるごと無視することを意味する）： ◎ When the user agent "receives a cookie" from a request-uri with name cookie-name, value cookie-value, and attributes cookie-attribute-list, the user agent MUST process the cookie as follows:

~UAは次をしてもヨイ（ `5.3§を見よ） ⇒ ~RET ◎ A user agent MAY ignore a received cookie in its entirety. See Section 5.3.
~IF［ %~cookie名 ~EQ 空~文字列］~AND［ %~cookie値 ~EQ 空~文字列］ ⇒ ~RET ◎ If cookie-name is empty and cookie-value is empty, abort these steps and ignore the cookie entirely.
~IF［ %~cookie名は `HTAB^P 以外の `CTL^P を包含する］~OR［ %~cookie値は `HTAB^P 以外の `CTL^P を包含する］ ⇒ ~RET ◎ If the cookie-name or the cookie-value contains a %x00-08 / %x0A-1F / %x7F character (CTL characters excluding HTAB), abort these steps and ignore the cookie entirely.
~IF［ %~cookie名の長さ ~PLUS %~cookie値の長さ ~GT 4096 ］ ⇒ ~RET ◎ If the sum of the lengths of cookie-name and cookie-value is more than 4096 octets, abort these steps and ignore the cookie entirely.
%要請~host ~LET `~host名を正準-化する$( `要請~host$ ) ◎ ↓
%新~cookie ~LET 新たな~cookie — その ⇒＃ `name$cK ~SET %~cookie名, `value$cK ~SET %~cookie値, `expiry-time$cK ~SET ~UAが表現-可能な最も~~未来の日付, `domain$cK ~SET %要請~host, `path$cK ~SET `要請~URI$の`既定の~path$, `creation-time$cK ~SET 現在の日時, `last-access-time$cK ~SET 現在の日時, `persistent-flag$cK ~SET ~F, `host-only-flag$cK ~SET ~T, `secure-only-flag$cK ~SET ~F, `http-only-flag$cK ~SET ~F, `same-site-flag$cK ~SET `Default$l ◎ Create a new cookie with name cookie-name, value cookie-value. Set the creation-time and the last-access-time to the current date and time. ◎ ↓↓

【 ~logicを単純化するため，この訳では、予め，~cookieの全~fieldを “既定の値” に初期化する。】
~IF［ %~cookie属性~list 内に名前 `Max-Age$a の属性は在る］ ⇒＃ %新~cookie の `persistent-flag$cK ~SET ~T； %新~cookie の `expiry-time$cK ~SET ［該当する属性のうち %~cookie属性~list 内で最後のもの］の値 ◎ If the cookie-attribute-list contains an attribute with an attribute-name of "Max-Age": • Set the cookie's persistent-flag to true. • Set the cookie's expiry-time to attribute-value of the last attribute in the cookie-attribute-list with an attribute-name of "Max-Age".
~ELIF［ %~cookie属性~list 内に名前 `Expires$a の属性は在る］ ⇒＃ %新~cookie の `persistent-flag$cK ~SET ~T； %新~cookie の `expiry-time$cK ~SET ［該当する属性のうち %~cookie属性~list 内で最後のもの］の値 ◎ Otherwise, if the cookie-attribute-list contains an attribute with an attribute-name of "Expires" (and does not contain an attribute with an attribute-name of "Max-Age"): • Set the cookie's persistent-flag to true. • Set the cookie's expiry-time to attribute-value of the last attribute in the cookie-attribute-list with an attribute-name of "Expires". ◎ ↑↑Otherwise: • Set the cookie's persistent-flag to false. • Set the cookie's expiry-time to the latest representable date.
%~domain ~LET 空~文字列 ◎ ↓
~IF［ %~cookie属性~list 内に名前 `Domain$a の属性であって［その値の長さ ~LTE 1024 ］を満たすものは在る］ ⇒ %~domain ~SET ［該当する属性のうち %~cookie属性~list 内で最後のもの］の値

（ %~domain の先頭の `.^ch は、在っても無視されることに注意 — その文字は許可されてないが，それでも）
◎ If the cookie-attribute-list contains an attribute with an attribute-name of "Domain": • Let the domain-attribute be the attribute-value of the last attribute in the cookie-attribute-list with both an attribute-name of "Domain" and an attribute-value whose length is no more than 1024 octets. (Note that a leading %x2E ("."), if present, is ignored even though that character is not permitted.) ◎ ↑Otherwise: • Let the domain-attribute be the empty string.
~IF［ %~domain は `USASCII$r 範囲に入らない文字を包含する］ ⇒ ~RET ◎ If the domain-attribute contains a character that is not in the range of [USASCII] characters, abort these steps and ignore the cookie entirely.
~IF［ ~UAは`公共~接尾辞$を却下するように環境設定されている］~AND［ %~domain は`公共~接尾辞$である］： ◎ If the user agent is configured to reject "public suffixes" and the domain-attribute is a public suffix:
1. ~IF［ %~domain ~NEQ %要請~host ］ ⇒ ~RET ◎ ↑If the domain-attribute is identical to the canonicalized request-host: • Let the domain-attribute be the empty string. ◎ Otherwise: • Abort these steps and ignore the cookie entirely.
2. %~domain ~SET 空~文字列 ◎ ↑
注記：この段は、下位domainに居る攻撃者（例： `attacker.example^s ）が［その`公共~接尾辞$（例： `example^s ）を値にとる `Domain$a 属性］を伴う~cookieを設定することにより［別の下位domain（例： `site.example^s ）の完全性を侵害すること］を防ぐために本質的である。 ◎ NOTE: This step prevents attacker.example from disrupting the integrity of site.example by setting a cookie with a Domain attribute of "example".
~IF［ %~domain ~NEQ 空~文字列］：
1. ~IF［ ( %要請~host, %~domain ) は`~domain合致して$いない］ ⇒ ~RET
2. %新~cookie の `host-only-flag$cK ~SET ~F
3. %新~cookie の `domain$cK ~SET %~domain
◎ If the domain-attribute is non-empty: • If the canonicalized request-host does not domain-match the domain-attribute: •• Abort these steps and ignore the cookie entirely. • Otherwise: •• Set the cookie's host-only-flag to false. •• Set the cookie's domain to the domain-attribute. ◎ ↑↑Otherwise: • Set the cookie's host-only-flag to true. • Set the cookie's domain to the canonicalized request-host.
~IF［ %~cookie属性~list 内に名前 `Path$a の属性であって［その値の長さ ~LTE 1024 ］を満たすものは在る］ ⇒ %新~cookie の `path$cK ~SET ［該当する属性のうち %~cookie属性~list 内で最後のもの］の値 ◎ If the cookie-attribute-list contains an attribute with an attribute-name of "Path", set the cookie's path to attribute-value of the last attribute in the cookie-attribute-list with both an attribute-name of "Path" and an attribute-value whose length is no more than 1024 octets.＼ ↑↑Otherwise, set the cookie's path to the default-path of the request-uri.
%~secureか ~LET ~IS［ `要請~URI$は`~secureな接続$を表す］ ◎ ↓
~IF［ %~cookie属性~list 内に名前 `Secure$a の属性は在る］：
1. ~IF［ %~secureか ~EQ ~F ］ ⇒ ~RET
2. %新~cookie の `secure-only-flag$cK ~SET ~T
◎ If the cookie-attribute-list contains an attribute with an attribute-name of "Secure", set the cookie's secure-only-flag to true.＼ ↑↑Otherwise, set the cookie's secure-only-flag to false. ◎ If the request-uri does not denote a "secure" connection (as defined by the user agent), and the cookie's secure-only-flag is true, then abort these steps and ignore the cookie entirely.
%非~HTTP~APIか ~LET ~IS［ %新~cookie は`非HTTP~API$から受信された【~UAは、非HTTP~APIを介して設定された`~cookieを受信した$かのように挙動している】］ ◎ ↓
~IF［ %~cookie属性~list 内に名前 `HttpOnly$a の属性は在る］：
1. ~IF［ %非~HTTP~APIか ~EQ ~T ］ ⇒ ~RET
2. %新~cookie の `http-only-flag$cK ~SET ~T
◎ If the cookie-attribute-list contains an attribute with an attribute-name of "HttpOnly", set the cookie's http-only-flag to true.＼ ↑↑Otherwise, set the cookie's http-only-flag to false. ◎ If the cookie was received from a "non-HTTP" API and the cookie's http-only-flag is true, abort these steps and ignore the cookie entirely.
~IF［ %新~cookie の `secure-only-flag$cK ~EQ ~F ］~AND［ %~secureか ~EQ ~F ］~AND［ `~cookie保管庫$内に ~AND↓ を満たす~cookieは在る］… ◎ If the cookie's secure-only-flag is false, and the request-uri does not denote a "secure" connection, then abort these steps and ignore the cookie entirely if the cookie store contains one or more cookies that meet all of the following criteria:
- その `name$cK ~EQ【！matches】 %新~cookie の `name$cK ◎ Their name matches the name of the newly-created cookie.
- その `secure-only-flag$cK ~EQ ~T ◎ Their secure-only-flag is true.
- ［ ( その `domain$cK, %新~cookie の `domain$cK ) は`~domain合致して$いる］~OR［ ( %新~cookie の `domain$cK, その `domain$cK ) は`~domain合致して$いる］ ◎ Their domain domain-matches the domain of the newly-created cookie, or vice-versa.
- ( %新~cookie の `path$cK, その `path$cK ) は`~path合致して$いる ◎ The path of the newly-created cookie path-matches the path of the existing cookie.
…ならば ⇒ ~RET

注記： ~pathの比較が対称でないのは、［ %新~cookie が~secureでない場合は、既存の~secureな~cookie 【のうち~pathの視野が %新~cookie 以上であるもの】を上塗りしない］ことを確保して，［ ~cookieを固定化する攻撃に抗する，いくぶんの軽減］を供するためである。すなわち，既存の~secureな~cookieに［ `path$cK に `/login^l を伴うもの］が在る場合、同じ `name$cK を有する新たな~cookieとして［ `path$cK に `/^l や `/foo^l を伴うもの］は設定できても，［ `path$cK に `/login^l や `/login/en^l を伴うもの］は設定できない。【ここでの~secureとは、 `secure-only-flag$cK ~EQ ~T を意味する。】 ◎ Note: The path comparison is not symmetric, ensuring only that a newly-created, non-secure cookie does not overlay an existing secure cookie, providing some mitigation against cookie-fixing attacks. That is, given an existing secure cookie named 'a' with a path of '/login', a non-secure cookie named 'a' could be set for a path of '/' or '/foo', but not for a path of '/login' or '/login/en'.
~IF［ %~cookie属性~list 内に名前 `SameSite$a の属性は在る］：
1. %same-site ~LET 該当する属性のうち %~cookie属性~list 内で最後のものの値
2. ~IF［ %same-site ~IN { `Strict$l, `Lax$l, `None$l } ］ ⇒ %新~cookie の `same-site-flag$cK ~SET %same-site
◎ If the cookie-attribute-list contains an attribute with an attribute-name of "SameSite", and an attribute-value of "Strict", "Lax", or "None", set the cookie's same-site-flag to the attribute-value of the last attribute in the cookie-attribute-list with an attribute-name of "SameSite".＼ ↑↑Otherwise, set the cookie's same-site-flag to "Default".
~IF［ %新~cookie の `same-site-flag$cK ~NEQ `None$l ］： ◎ If the cookie's same-site-flag is not "None":
1. ~IF［ %非~HTTP~APIか ~EQ ~T ］~AND［その~APIは、ある`~navigable$にて`作動中な文書$navから~callされていて， ( その文書の`~cookie用~site$, `~top-level生成元$ ) は`同一-~site$でない］ ⇒ ~RET ◎ If the cookie was received from a "non-HTTP" API, and the API was called from a navigable's active document whose "site for cookies" is not same-site with the top-level origin, then abort these steps and ignore the newly created cookie entirely.
2. ~IF［ ~NOT ~OR↓ ］…
  - %新~cookie は`同一-~site$rqな要請から受信された【！(as defined in Section 5.2)】
  - %新~cookie は，ある`~top-level辿可能$を`~navigate$している`要請$から受信された `HTML$r
    
    （例：要請の`予約-済み~client$rqは、 ~NULL または［ `環境$であって、その`~target閲覧~文脈$enVは，ある`~top-level辿可能$にて`作動中な閲覧~文脈$navである］）
  …ならば ⇒ ~RET
  
  注記： `~top-level~navi$は、どの `SameSite$a 値を伴う~cookieも作成し得る — %新~cookie が `wouldn't have been^en 要請に伴って送信され `had it^en ~naviに先立って存在していた場合でも。【？】
  ◎ If the cookie was received from a "same-site" request (as defined in Section 5.2), skip the remaining substeps and continue processing the cookie. ◎ If the cookie was received from a request which is navigating a top-level traversable [HTML] (e.g. if the request's "reserved client" is either null or an environment whose "target browsing context"'s navigable is a top-level traversable), skip the remaining substeps and continue processing the cookie. ◎ Note: Top-level navigations can create a cookie with any SameSite value, even if the new cookie wouldn't have been sent along with the request had it already existed prior to the navigation. ◎ Abort these steps and ignore the newly created cookie entirely.
~IF［ %~cookie の `same-site-flag$cK ~EQ `None$l ］~AND［ %~cookie の `secure-only-flag$cK ~NEQ ~T ］ ⇒ ~RET ◎ If the cookie's "same-site-flag" is "None", abort these steps and ignore the cookie entirely unless the cookie's secure-only-flag is true.
~IF［ %~cookie名の頭部は文字列 `__Secure-$l に文字大小無視で合致している］~AND［ %新~cookie の `secure-only-flag$cK ~EQ ~F ］ ⇒ ~RET ◎ If the cookie-name begins with a case-insensitive match for the string "__Secure-", abort these steps and ignore the cookie entirely unless the cookie's secure-only-flag is true.
~IF［ %~cookie名の頭部は文字列 `__Host-$l に文字大小無視で合致している］~AND［ ~OR↓ ］… ◎ If the cookie-name begins with a case-insensitive match for the string "__Host-", abort these steps and ignore the cookie entirely unless the cookie meets all the following criteria:
- %新~cookie の `secure-only-flag$cK ~EQ ~F ◎ The cookie's secure-only-flag is true.
- %新~cookie の `host-only-flag$cK ~EQ ~F ◎ The cookie's host-only-flag is true.
- %~cookie属性~list 内に名前 `Path$a の属性は無い ◎ The cookie-attribute-list contains an attribute with an attribute-name of "Path", and＼
- %新~cookie の `path$cK ~NEQ `/^ch ◎ the cookie's path is /.
…ならば ⇒ ~RET
~IF［ %~cookie名 ~EQ 空~文字列］~AND［ %~cookie名の頭部は文字列［ `__Secure-$l, `__Host-$l ］いずれかに文字大小無視で合致している］ ⇒ ~RET ◎ If the cookie-name is empty and either of the following conditions are true, abort these steps and ignore the cookie entirely: • the cookie-value begins with a case-insensitive match for the string "__Secure-" • the cookie-value begins with a case-insensitive match for the string "__Host-"
~IF［ `~cookie保管庫$内に［ `name$cK, `domain$cK, `host-only-flag$cK, `path$cK ］すべてが %新~cookie と一致する~cookie %旧~cookie が在る］： ◎ If the cookie store contains a cookie with the same name, domain, host-only-flag, and path as the newly-created cookie: • Let old-cookie be the existing cookie with the same name, domain, host-only-flag, and path as the newly-created cookie.＼

（この~algoは、［そのような~cookieは在っても 1 個に限られる，という不変則］を常に保守することに注意） ◎ (Notice that this algorithm maintains the invariant that there is at most one such cookie.)
1. ~IF［ %非~HTTP~APIか ~EQ ~T ］~AND［ %旧~cookie の `http-only-flag$cK ~EQ ~T ］ ⇒ ~RET ◎ If the newly-created cookie was received from a "non-HTTP" API and the old-cookie's http-only-flag is true, abort these steps and ignore the newly created cookie entirely.
2. %新~cookie の `creation-time$cK ~SET %旧~cookie の `creation-time$cK ◎ Update the creation-time of the newly-created cookie to match the creation-time of the old-cookie.
3. `~cookie保管庫$から %旧~cookie を除去する ◎ Remove the old-cookie from the cookie store.
`~cookie保管庫$に %新~cookie を挿入する ◎ Insert the newly-created cookie into the cookie store.

~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:

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

【共有する~cookieのうち，どれを抹消するかは、次項に従うことになる。また， “決められた個数” は、［前項のそれと異なる／ `domain$cK に応じて異なる］かもしれない。】
◎ Cookies that share a domain field with more than a predetermined number of other cookies.
`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.8. 検索取得~model

この節は、 `~cookie保管庫$から~cookieを — `cookie-string$p の形で — どう検索取得するかを定義する。 `検索取得@ （ `retrieval^en ）は、 `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 ］と同義になる。】

5.8.2. 非~HTTP~API

`~UA$は、格納した~cookieに~accessするために利用できる`非HTTP~API$を実装してもヨイ。 ◎ The user agent MAY implement "non-HTTP" APIs that can be used to access stored cookies.

`~UA$は、ある種の文脈においては，【`非HTTP~API$が】空な `cookie-string$p を返すようにしてもヨイ — 第三者-主体~文脈の中で`検索取得$が生じたときなど（`第三者-主体~cookie§を見よ）。 ◎ A user agent MAY return an empty cookie-string in certain contexts, such as when a retrieval occurs within a third-party context (see Section 7.1).

`~UA$は、 `非HTTP~API$の~callに対し~cookieを返す場合には，その `cookie-string$p を次に従って算出しなければナラナイ：

%文書 ~LET 当の~APIに結付けられた`文書$
%同一-~siteか ~LET ［次が満たされるならば `同一-~site^i ／ ~ELSE_ `非同一-~site^i ］ ⇒ ( %文書の`~cookie用~site$, `~top-level生成元$ ) は`同一-~site$である
%検索取得 ~LET 新たな`検索取得$ — その ⇒＃ `要請$rT ~SET ε, `~URI$rT ~SET ~call元により定義されるもの（ `document.cookie$dom `DOM-DOCUMENT-COOKIE$r を見よ）, `同一-~site状態s$rT ~SET %同一-~siteか, `種別$rT ~SET `非~HTTP^i
~RET `~cookieを検索取得する$( %検索取得 )

◎ If a user agent does return cookies for a given call to a "non-HTTP" API with an associated Document, then the user agent MUST compute the cookie-string following the algorithm defined in Section 5.8.3, where＼ the retrieval's URI is defined by the caller (see [DOM-DOCUMENT-COOKIE]),＼ the retrieval's same-site status is "same-site" if the Document's "site for cookies" is same-site with the top-level origin as defined in Section 5.2.1 (otherwise it is "cross-site"),＼ and the retrieval's type is "non-HTTP".

5.8.3. 検索取得~algo

`~cookieを検索取得する@ ときは、所与の ( `検索取得$ %検索取得 ) に対し，`~cookie保管庫$から `cookie-string$p を返す： ◎ Given a cookie store and a retrieval, the following algorithm returns a cookie-string from a given cookie store.

%~URI~host ~LET `~host名を正準-化する$( %検索取得の`~URI$rT ) ◎ ↓
%~cookie~list ~LET 空~list ◎ ↓
`~cookie保管庫$を成す ~EACH( %~cookie ) に対し： ◎ Let cookie-list be the set of cookies from the cookie store that meets all of the following requirements:
1. ~IF［ %~cookie の `host-only-flag$cK ~EQ ~T ］ ⇒ ~IF［ %~cookie の `domain$cK ~NEQ %~URI~host ］ ⇒ ~CONTINUE ◎ Either: • The cookie's host-only-flag is true and the canonicalized host of the retrieval's URI is identical to the cookie's domain.
2. ~ELIF［ ( %~URI~host, %~cookie の `domain$cK ) は`~domain合致して$いない］ ⇒ ~CONTINUE ◎ Or: • The cookie's host-only-flag is false and the canonicalized host of the retrieval's URI domain-matches the cookie's domain.
  
  注記（`公共~接尾辞$を却下するよう環境設定された~UA向け）：公共~接尾辞~listは、 ~cookieが作成されてから変更されることもあり得る。この変更による結果，ある~cookieの~domainが`公共~接尾辞$になった場合、当の~cookieは，作成の間に却下したかのように（`保管~model§における`該当する段＠#_reject-public-suffix$を見よ）無効と見なされる。 `~UA$は、 `検索取得$の`~URI$rTの~hostに`~domain合致して$いる場合でも，そのような無効な~cookieを検索取得するのは避けるよう気を付けるべきである。 ◎ NOTE: (For user agents configured to reject "public suffixes") It's possible that the public suffix list was changed since a cookie was created. If this change results in a cookie's domain becoming a public suffix then that cookie is considered invalid as it would have been rejected during creation (See Section 5.7 step 9). User agents should be careful to avoid retrieving these invalid cookies even if they domain-match the host of the retrieval's URI.
3. ~IF［ ( %検索取得の`~URI$rTの~path, %~cookie の `path$cK ) は`~path合致して$いない］ ⇒ ~CONTINUE ◎ The retrieval's URI's path path-matches the cookie's path.
4. ~IF［ %~cookie の `secure-only-flag$cK ~EQ ~T ］~AND［ %検索取得の`~URI$rTは`~secureな接続$を表さない］ ⇒ ~CONTINUE ◎ If the cookie's secure-only-flag is true, then the retrieval's URI must denote a "secure" connection (as defined by the user agent). ◎ （§ 各種用語に集約） NOTE: The notion of a "secure" connection is not defined by this document. Typically, user agents consider a connection secure if the connection makes use of transport-layer security, such as SSL or TLS, or if the host is trusted. For example, most user agents consider "https" to be a scheme that denotes a secure protocol and "localhost" to be trusted host.
5. ~IF［ %~cookie の `http-only-flag$cK ~EQ ~T ］~AND［ %検索取得の`種別$rT ~EQ `非~HTTP^i ］ ⇒ ~CONTINUE ◎ If the cookie's http-only-flag is true, then exclude the cookie if the retrieval's type is "non-HTTP".
6. ~IF［ %~cookie の `same-site-flag$cK ~NEQ `None$l ］~AND［ %検索取得の`同一-~site状態s$rT ~EQ `非同一-~site^i ］~AND［ ~NOT ~AND↓ ］…
  - %検索取得の`種別$rT ~EQ `~HTTP^i
  - %~cookie の `same-site-flag$cK ~IN { `Lax$l, `Default$l }
  - %検索取得の`要請$rTの~methodは`安全$である
  - %検索取得の`要請$rTの~target閲覧~文脈は、［ `the^en 作動中な閲覧~文脈 `or a^en ~top-level辿可能］である
    
    【この条件は、次を意味するものと推定される：当の要請の`予約-済み~client$rqは`環境$であって、その`~target閲覧~文脈$enVは，ある`~top-level辿可能$にて`作動中な閲覧~文脈$navである。】
  …ならば ⇒ ~CONTINUE
  ◎ If the cookie's same-site-flag is not "None" and the retrieval's same-site status is "cross-site", then exclude the cookie unless all of the following conditions are met: • The retrieval's type is "HTTP". • The same-site-flag is "Lax" or "Default". • The HTTP request associated with the retrieval uses a "safe" method. • The target browsing context of the HTTP request associated with the retrieval is the active browsing context or a top-level traversable.
7. %~cookie~list に %~cookie を付加する ◎ ↑↑
%~cookie~list は、次を満たす順序に~sortするベキである： ◎ The user agent SHOULD sort the cookie-list in the following order:
- `path$cK が長い~cookieほど，前に現れる ◎ Cookies with longer paths are listed before cookies with shorter paths.
- `path$cK の長さが互いに等しい~cookieに対しては、 `creation-time$cK がより過去のものほど，前に現れる ◎ Among cookies that have equal-length path fields, cookies with earlier creation-times are listed before cookies with later creation-times.
注記：すべての~UAが %~cookie~list をこの順序に~sortするわけではないが、この順序は，この文書が書かれた時点での慣行を反映するものである。歴史的に、（誤って）この順序に依存する~serverが~~存在してきた。 ◎ NOTE: Not all user agents sort the cookie-list in this order, but this order reflects common practice when this document was written, and, historically, there have been servers that (erroneously) depended on this order.
%~cookie~list を成す ~EACH( %~cookie ) に対し ⇒ %~cookie の `last-access-time$cK ~SET 現在の日時 ◎ Update the last-access-time of each cookie in the cookie-list to the current date and time.
%cookie-string ~LET 空~文字列 ◎ ↓
%~cookie~list を成す ~EACH( %~cookie ) に対し： ◎ Serialize the cookie-list into a cookie-string by processing each cookie in the cookie-list in order:
1. ~IF［ %~cookie の `name$cK ~NEQ 空~文字列］ ⇒ %cookie-string に次を順に付加する ⇒＃ %~cookie の `name$cK, `=^ch, ◎ If the cookies' name is not empty, output the cookie's name followed by the %x3D ("=") character.
2. ~IF［ %~cookie の `value$cK ~NEQ 空~文字列］ ⇒ %cookie-string に %~cookie の `value$cK を付加する ◎ If the cookies' value is not empty, output the cookie's value.
3. ~IF［ %~cookie は %~cookie~list 内の最後の~cookieでない］ ⇒ %cookie-string に次を順に付加する ⇒＃ `;^ch, ` ^ch ◎ If there is an unprocessed cookie in the cookie-list, output the characters %x3B and %x20 ("; ").
~RET %cookie-string ◎ ↑

6. 実装-時の考慮点

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.6§ にて施行しなければナラナイ長さ制限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.6.

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

~UAは~cookieをいつでも抹消し得るので、 ~serverは，［ ~UAが `Cookie^h ~header内に 1 個以上の~cookieを返すことに失敗したとき］には上品に退行する（ `gracefully 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. ~privacyの考慮点

~cookieの首な~privacy~riskは、利用者の活動を相関する，その能である。これは，単独の~site上でも起こり得るが、最も問題になり得るのは，利用者の~profileを築くために［互いに~~無関係に見える複数の~web~siteにまたがって，活動が追跡される］ときである。 ◎ Cookies' primary privacy risk is their ability to correlate user activity. This can happen on a single site, but is most problematic when activity is tracked across different, seemingly unconnected Web sites to build a user profile.

時を経て，この能力は、（ `RFC2109$r, およびそのすべての後継にて，明示的に警告されたが）次に挙げるものなど，様々な理由で広く利用されるようになった： ◎ Over time, this capability (warned against explicitly in [RFC2109] and all of its successors) has become widely used for varied reasons including:

複数~siteにまたがって，利用者を認証する ◎ authenticating users across sites,
利用者についての情報を組立てる ◎ assembling information on users,
詐欺行為や他の［望ましくない流通を形成するもの］に抗して，保護する ◎ protecting against fraud and other forms of undesirable traffic,
［特定の利用者／指定された属性を伴う利用者］を~targetにする広告 ◎ targeting advertisements at specific users or at users with specified attributes,
広告が利用者に示された回数や~~頻度を測定する ◎ measuring how often ads are shown to users, and
広告がいつ利用者の挙動における変化をもらしたかを認識する ◎ recognizing when an ad resulted in a change in user behavior.

~cookieの利用は，~privacyの問題になり得るものばかりではないが、その濫用の~~可能性は，［ ~internet~communityや，より幅広い社会］に広まった懸念になった。 ~UAは、これらの懸念に呼応して， ~cookieの機能性を様々な仕方で能動的に拘束した（以前の各~仕様にて許容され, 奨励されたとおり） — ~Webの健康に望ましいものと~UAが判定する特能に対する妨害は、避けながら。 ◎ While not every use of cookies is necessarily problematic for privacy, their potential for abuse has become a widespread concern in the Internet community and broader society. In response to these concerns, user agents have actively constrained cookie functionality in various ways (as allowed and encouraged by previous specifications), while avoiding disruption to features they judge desirable for the health of the Web.

~cookieによる~privacyへの影響iを軽減するために利用されるべき特定の仕組みについて，総意を宣言するのは、まだ早過ぎる。それらがどう取扱われるかについての，~UAによる進行中な変更点は、その最終的な総意への入力を供し得る実験にはなるが，それを超えるものではない。 ◎ It is too early to declare consensus on which specific mechanism(s) should be used to mitigate cookies' privacy impact; user agents' ongoing changes to how they are handled are best characterised as experiments that can provide input into that eventual consensus.

代わりに，この文書は、［ ~cookieに結付けられる~privacy~riskに抗して，~cookieの広い配備を享受する］ための，限定的かつ一般的な — これを書いている時点における — 軽減策を述べる。実装には、実験を継続して，時を経るに伴い［ ~cookieに対し，より［厳密かつきちんと定義された］制限を課す］ことが期待される。この文書の将来~versionは、それらの仕組みを配備~経験に基づいて成文化するものにもなろう。現在，~cookieに依拠している機能を［それを~targetにする別々な仕組み］により~supportできるならば、それらを別々な仕様にて文書化することにより，~cookieに対するより厳密な制限が実現可能になるかもしれない。 ◎ Instead, this document describes limited, general mitigations against the privacy risks associated with cookies that enjoy wide deployment at the time of writing. It is expected that implementations will continue to experiment and impose stricter, more well-defined limitations on cookies over time. Future versions of this document might codify those mechanisms based upon deployment experience. If functions that currently rely on cookies can be supported by separate, targeted mechanisms, they might be documented in separate specifications and stricter limitations on cookies might become feasible.

~cookieは，複数~siteにまたがって利用者を追跡するために利用できる唯一の仕組みではないので、これらの軽減策は — ~Web~privacyを改善するために必要yであるとしても — それだけで足るものにはならないことに注意。 ◎ Note that cookies are not the only mechanism that can be used to track users across sites, so while these mitigations are necessary to improve Web privacy, they are not sufficient on their own.

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.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. ~securityの考慮点

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.

これらの~headerにより運ばれる，~securityに敏感な情報すべてが、盗聴者に公開される。 ◎ All sensitive information conveyed in these header fields is exposed to an eavesdropper.
悪意的な`媒介者$は，いずれの方向へ流れる~headerも改めれるため、予測-不能な結果になる。 ◎ A malicious intermediary could alter the header fields as they travel in either direction, with unpredictable results.
悪意的な~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 ~~段階を経る： ◎ 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.＼

攻撃者は、ある~session識別子 %~session識別子を自身の~UAで~~取得してから，被害者の~UAに植え付ける†。 ◎ First, the attacker transplants a session identifier from his or her user agent to the victim's user agent.＼
被害者は、 %~session識別子を~serverとのヤリトリに利用する（場合によっては、利用者の資格証（ `credentials^en ）や機密（ `confidential^en ）に関する情報も伴わせて）。 ◎ 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.＼
攻撃者は、 %識別子を利用して~serverと直にヤリトリする（場合によっては、利用者の権限（ `authority^en ）や機密に関する情報が奪われる）。 ◎ 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

8.8.1. 多層防御

~cookieを配備するにあたって， `SameSite$a を `Strict$l ~modeに設定した場合、 `~client$rqがそれを~supportするならば，`~CSRF攻撃$に抗する堅牢な防御を提供する。しかしながら，それだけでは、 `~CSRF攻撃$に抗する~siteの防御~すべてを成すには至らない — `同一-~site$rqな［ ~navi／~form提出］は、他の攻撃~行路 — ~XSSや~page~redirectionの濫用など — を併用すれば，間違いなく実行できるので。 ◎ "SameSite" cookies offer a robust defense against CSRF attack when deployed in strict mode, and when supported by the client. It is, however, prudent to ensure that this designation is not the extent of a site's defense against CSRF, as same-site navigations and submissions can certainly be executed in conjunction with other attack vectors such as cross-site scripting or abuse of page redirections.

要請がいつ, どうやって`同一-~site$rqであると見なされるかを理解することは、 ~siteを `SameSite$a ~cookie用に適正に設計するためにも重要になる。例えば、 `非同一-~site$rqな`~top-level要請$が，ある敏感な~page — 要請は`非同一-~site$rqであると見なされ， `SameSite$a が `Strict$l に設定された【！SameSite=Strict】~cookieは送信されなくなる~page — へ為された場合でも、その~pageの下位-資源への要請は`同一-~site$rqになり， `SameSite$a が `Strict$l に設定された~cookieを受信することになろう。 ~siteは、初期~pageへの要請が適切な~cookieを内包しない場合には， ~errorを返すことにより［これらの下位-資源への~accessを不作為に許容する］ことを避けれる。 ◎ Understanding how and when a request is considered same-site is also important in order to properly design a site for SameSite cookies. For example, if a cross-site top-level request is made to a sensitive page that request will be considered cross-site and SameSite=Strict cookies won’t be sent; that page’s sub-resources requests, however, are same-site and would receive SameSite=Strict cookies. Sites can avoid inadvertently allowing access to these sub-resources by returning an error for the initial page request if it doesn’t include the appropriate cookies.

~riskをもっと全部的に軽減するため、開発者には，通例の~server側~防御（［ `安全$な~HTTP~methodは`冪等$になることを確保するための，~CSRF~token ］, 等々）を配備することが強く奨励される。 ◎ Developers are strongly encouraged to deploy the usual server-side defenses (CSRF tokens, ensuring that "safe" HTTP methods are idempotent, etc) to mitigate the risk more fully.

加えて，~client側の技法には — `app-isolation$r 【 “~appどうしの隔離” 】に述べられるものなど — `~CSRF攻撃$に抗して有効果なことを立証できるものもあり、当然ながら， `SameSite$a ~cookieとの組合nで探求するに価しよう。 ◎ Additionally, client-side techniques such as those described in [app-isolation] may also prove effective against CSRF, and are certainly worth exploring in combination with "SameSite" cookies.

8.8.2. ~top-level~navi

`SameSite$a 属性を `Strict$l ~modeに設定することは，`~CSRF攻撃$に抗する堅牢な多層防御を供するが、 ~siteの開発者が［ ~cookieに基づく~session管理~systemが，`~top-level~navi$を適度にきちんと処すること］を注意深く確保していない限り，利用者を惑わす~~可能性がある。 ◎ Setting the SameSite attribute in "strict" mode provides robust defense in depth against CSRF attacks, but has the potential to confuse users unless sites' developers carefully ensure that their cookie-based session management systems deal reasonably well with top-level navigations.

~MegaCorp社が `https://site.example/^s にて~web~mail~serviceを供していて，利用者がそこで~emailを読んでいる局面を考える。利用者は，［ ~email内にある `https://projects.example/secret/project^s への~linkを~clickしたなら，~~閲覧権限がある秘匿情報（ “`secret project^en” ）を示す］ものと期待するかもしれないが、 `https://projects.example^s が~session~cookieの `SameSite$a 属性に `Strict$l を伴わせていた場合，［この~navi用に送信する`非同一-~site$rqな要請には、その~cookieは伴われない］ことになる。 `https://projects.example^s は，秘匿情報の漏洩ngを避けるべく `404$st ~errorを具現化することになり、利用者は惑わされることになろう。 ◎ Consider the scenario in which a user reads their email at MegaCorp Inc's webmail provider https://site.example/. They might expect that clicking on an emailed link to https://projects.example/secret/project would show them the secret project that they're authorized to see, but if https://projects.example has marked their session cookies as SameSite=Strict, then this cross-site navigation won't send them along with the request. https://projects.example will render a 404 error to avoid leaking secret information, and the user will be quite confused.

開発者は、 ~session管理~systemとして，~cookieに依拠するものを 1 つでなく 2 つ — 概念的に 2 種の~access［ “読取n”, “書込n” ］を是認するもの — を採用することにより，この惑いを避けれる： ◎ Developers can avoid this confusion by adopting a session management system that relies on not one, but two cookies: one conceptually granting "read" access, another granting "write" access.＼

“書込n” 用には、 `SameSite$a 属性に `Strict$l を伴わせることもできる — それが無いときは［冪等でない動作を実行する前に，認証し直す］よう促すことになる。 ◎ The latter could be marked as SameSite=Strict, and its absence would prompt a reauthentication step before executing any non-idempotent action.＼
“読取n” 用には、 `SameSite$a 属性に次のどちらを伴わせることもできる：
- `Lax$l： `~top-level~navi$を介する~dataに対し利用者からの~accessを許容するためには
- `None$l：すべての文脈（非同一-~site埋込d文脈も含む）において~accessを許可するためには
◎ The former could be marked as SameSite=Lax, in order to allow users access to data via top-level navigation, or SameSite=None, to permit access in all contexts (including cross-site embedded contexts).

8.8.3. ~mashup／~widget

`SameSite$a 属性~用の［ `Lax$l ／ `Strict$l ］値は、いくつかの重要な利用事例においては，不適切になる。特に，`非同一-~site$な文脈に埋込むことが意図された内容（例として，~SNS用の~widgetや~comment欄）は、 `同一-~siteな~cookie$に~accessできなくなることに注意。これらの状況に要求される~cookieは、 `SameSite$a に `None$l を伴わせて，`非同一-~site$な文脈にも~accessを許容するべきである。 ◎ The Lax and Strict values for the SameSite attribute are inappropriate for some important use-cases. In particular, note that content intended for embedding in cross-site contexts (social networking widgets or commenting services, for instance) will not have access to same-site cookies. Cookies which are required in these situations should be marked with SameSite=None to allow access in cross-site contexts.

同様に，ある形の `Single-Sign-On^en 【一回の認証で，複数の文脈にわたって認証されるようにすること】は、 `非同一-~site$な文脈において，~cookieに基づく認証を要求するかもしれない。これらの仕組みは、 `同一-~siteな~cookie$では意図されるように機能しないので， `SameSite$a に `None$l を要することになる。 ◎ Likewise, some forms of Single-Sign-On might require cookie-based authentication in a cross-site context; these mechanisms will not function as intended with same-site cookies and will also require SameSite=None.

8.8.4. ~serverにより制御されるもの

`SameSite$a ~cookieそれ自体には、［ `第三者-主体~cookie§【！`6265/7.1$rfc】にて要旨された，一般的な~privacyの懸念］に取組むものは何もない。 `SameSite$a 属性は、 ~serverにより設定され，~serverが心配するある種の攻撃による~riskを軽減するよう~serveする。この裁定には、利用者は~~介入できない。さらには、［ ~cookieが無いときでも，別個な要請どうしを~linkすることを~serverに許容し得る］ような，いくつかの~side-channelが存在する（例えば，`同一-~site$rqな要請と`非同一-~site$rqな要請の間での `connection^en や `socket pooling^en ）。 ◎ SameSite cookies in and of themselves don't do anything to address the general privacy concerns outlined in Section 7.1 of [RFC6265]. The "SameSite" attribute is set by the server, and serves to mitigate the risk of certain kinds of attacks that the server is worried about. The user is not involved in this decision. Moreover, a number of side-channels exist which could allow a server to link distinct requests even in the absence of cookies (for example, connection and/or socket pooling between same-site and cross-site requests).

8.8.5. ~reload~navi

`~UI~reload~navi要請$が`同一-~site$rqになるのは、 ~reloadされた文書が元々`同一-~site$な要請を介して`~navigate$された場合に限られる。これは、他の~reload~naviの取扱いと相違する。後者は、 `~top-level~navi$ならば — `~navi~algo$に渡す %~source文書【！~source~navigableにて`作動中な文書$nav】は，精確に~reloadされている文書になるので — 常に`同一-~site$になる。 ◎ Requests issued for reloads triggered through user interface elements (such as a refresh button on a toolbar) are same-site only if the reloaded document was originally navigated to via a same-site request. This differs from the handling of other reload navigations, which are always same-site if top-level, since the source navigable's active document is precisely the document being reloaded.

`~UI~reload~navi要請$に対する，この特別な取扱いは、利用者が起動した~reloadに対し，`同一-~siteな~cookie$【！`SameSite$a ~cookie（以下同様）】の送信を避ける — 元の~naviに対し，それが差止められた場合には（すなわち，初期~naviによる要請は`非同一-~site$rqであった場合）。代わりに、当の~reload~naviを`同一-~site$と見なして，初期~時に差止めた`同一-~siteな~cookie$をすべて送信した場合、当初に差止めたことによる~securityの便益は，無に帰すことになろう。これが，とりわけ重要になるのは、［ `非同一-~site$rqな~navi要請に対し，`同一-~siteな~cookie$を差止めること］は，~siteの可視な非互換化に至ることもあり、その結果，~reloadを誘発するよう利用者を促すことになるときである。 ◎ This special handling of reloads triggered through a user interface element avoids sending SameSite cookies on user-initiated reloads if they were withheld on the original navigation (i.e., if the initial navigation were cross-site). If the reload navigation were instead considered same-site, and sent all the initially withheld SameSite cookies, the security benefits of withholding the cookies in the first place would be nullified. This is especially important given that the absence of SameSite cookies withheld on a cross-site navigation request may lead to visible site breakage, prompting the user to trigger a reload.

例えば、利用者が攻撃者の~site `https://attacker.example/^s から被害者の~site `https://victim.example/^s を~~指す~linkを~clickしたとする。これは，`非同一-~site$rqな要請になるので、 `同一-~siteな~cookie$（ `Strict$l ）は差止められる。これが被害者の~siteが非互換化されるよう現れる原因になるとする — 被害者の~siteは、特定0の`同一-~siteな~cookie$が要請~内に在る場合に限り，敏感な内容を表示することにしていたので。利用者が予期しない~siteの破損にいらついて，~browserの~toolbarの~refreshを~clickすると、今や，~reload要請は`同一-~site$と見なされ，初期~時に差止めた`同一-~siteな~cookie$を送信することになる結果、当初の目的を打破することになろう — 当の`~UI~reload~navi要請$は、元の（悪意的にもなり得る）要請を再現し得るので。したがって，`~UI~reload~navi要請$は、初期~時に~pageへ`~navigate$した要請と同様に， `非同一-~site$rqな要請と見なされるべきである。 ◎ For example, suppose the user clicks on a link from https://attacker.example/ to https://victim.example/. This is a cross-site request, so SameSite=Strict cookies are withheld. Suppose this causes https://victim.example/ to appear broken, because the site only displays its sensitive content if a particular SameSite cookie is present in the request. The user, frustrated by the unexpectedly broken site, presses refresh on their browser's toolbar. To now consider the reload request same-site and send the initially withheld SameSite cookie would defeat the purpose of withholding it in the first place, as the reload navigation triggered through the user interface may replay the original (potentially malicious) request. Thus, the reload request should be considered cross-site, like the request that initially navigated to the page.

~reload用に発行された要請が利用者が起動したものでない場合，どれも `SameSite$a ~cookieを付するので、開発者は，`~CSRF攻撃$を避けるよう［ ~reloadをいつ起動するかについて，注意深くかつ思慮深くある］べきである。例えば、 ~pageは，［初期~要請に~CSRF~tokenが在る場合に限り，~reloadを起動する］こともできる。 ◎ Because requests issued for, non-user initiated, reloads attach all SameSite cookies, developers should be careful and thoughtful about when to initiate a reload in order to avoid a CSRF attack. For example, the page could only initiate a reload if a CSRF token is present on the initial request.

8.8.6. 安全でない~methodを伴う`~top-level要請$

`5.6.7.1§ に述べた `Lax$l 施行~modeは、［ `安全$な~HTTP~methodを伴う`~top-level~navi$である］場合, そのときに限り，［ ~cookieが`非同一-~site$rqな~HTTP要請に伴って送信される］ことを許容する。実装~経験により、これを既定の挙動として適用するのは，困難であることが示されている — 一部の~site（ `SameSite$a 属性が導入される以前から在る~siteなど）は、次のような~cookieに依拠するので ⇒ ［ `SameSite$a 属性を明示的に指定していない］~AND［それを含んでいる要請は、次を満たす］ ⇒ ［ `~top-level~navi$である］~AND［ `非同一-~site$rqである］~AND［その~HTTP~methodは`安全$でない］ ◎ The "Lax" enforcement mode described in Section 5.6.7.1 allows a cookie to be sent with a cross-site HTTP request if and only if it is a top-level navigation with a "safe" HTTP method. Implementation experience shows that this is difficult to apply as the default behavior, as some sites may rely on cookies not explicitly specifying a SameSite attribute being included on top-level cross-site requests with "unsafe" HTTP methods (as was the case prior to the introduction of the SameSite attribute).

例えば，ある~login~flowを締めくくる段は、ある端点への［ `非同一-~site$rqな~top-level `POST$m 要請］を孕んでいて，この端点は［近過去に作成された~loginを~secureに完了するために必要yな，~transaction上の状態~情報］を包含している~cookieを期待することもある。そのような~cookie用には、 `Lax$l の施行は適切でない — そうすると、要請~methodが`安全$でないことに因り，当の~cookieは除外され、その結果，当の~login~flowは回復-不能な失敗になる。 ◎ For example, the concluding step of a login flow may involve a cross-site top-level POST request to an endpoint; this endpoint expects a recently created cookie containing transactional state information, necessary to securely complete the login. For such a cookie, "Lax" enforcement is not appropriate, as it would cause the cookie to be excluded due to the unsafe HTTP request method, resulting in an unrecoverable failure of the whole login flow.

【！`5.6.7.2§ にて述べた】 `Lax-allowing-unsafe$l 施行~modeは， `Lax$l の施行を成す保護の一部を（ `None$l に比較して）維持するが、それでも，［近過去に作成された~cookieが［ `非同一-~site$rqな`安全$でない`~top-level要請$ ］に伴って送信される］ことを許容する。 ◎ The "Lax-allowing-unsafe" enforcement mode described in Section 5.6.7.2 retains some of the protections of "Lax" enforcement (as compared to "None") while still allowing recently created cookies to be sent cross-site with unsafe top-level requests.

`Lax-allowing-unsafe$l ~modeは， `Lax$l ~modeの［より許可的な変種］であり、 `~CSRF攻撃$に抗する保護を少なくすることが必要yである。そのような施行~modeの供給は、究極的には，［既定では `Lax$l 施行~modeにすること］の採用を容易にするための［一時的かつ過渡的な措置］と見るべきである。 ◎ As a more permissive variant of "Lax" mode, "Lax-allowing-unsafe" mode necessarily provides fewer protections against CSRF. Ultimately, the provision of such an enforcement mode should be seen as a temporary, transitional measure to ease adoption of "Lax" enforcement by default.

9. IANA 考慮点

9.1. `Cookie^h

~HTTP~field名~registry `HttpFieldNameRegistry$r は、以下の登録により更新される必要がある。 ◎ The HTTP Field Name Registry (see [HttpFieldNameRegistry]) needs to be updated with the following registration:

~header名	`Cookie^h
適用-可能な~protocol	http
位置付け	standard
著作者	IETF
変更~制御者	IETF
仕様~文書	この仕様の `5.8.1§

◎ Header field name: • Cookie Applicable protocol: • http Status: • standard Author/Change controller: • IETF Specification document: • this specification (Section 5.8.1)

9.2. `Set-Cookie^h

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

~header名	`Set-Cookie^h
位置付け	standard
著作者	IETF
変更~制御者	IETF
仕様~文書	この仕様の `5.6§

◎ Header field name: • Set-Cookie Applicable protocol: • http Status: • standard Author/Change controller: • IETF Specification document: • this specification (Section 5.6)

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.

9.3.1. 手続-

登録される各属性の名前には、記述, および次への参照が結付けられる ⇒ 属性が［どう処理され, 格納されるか］の詳細 ◎ Each registered attribute name is associated with a description, and a reference detailing how the attribute is to be processed and stored.

新たな登録は、 `RFC8126$r `~RFCが要求される＠~RFCx/rfc8126#section-4.7§ に基づいて行われる。登録される属性は、 `extension-av$p 構文に合致しなければナラナイ。属性の名前は、一般には `CamelCase^en で定義されるが，技術的には文字大小無視として受容されることに注意。 ◎ New registrations happen on a "RFC Required" basis (see Section 4.7 of [RFC8126]). The attribute to be registered MUST match the extension-av syntax defined in Section 4.1.1. Note that attribute names are generally defined in CamelCase, but technically accepted case-insensitively.

9.3.2. 登録

“~cookie属性~registry” は、以下の登録を伴って作成されるべきである： ◎ The "Cookie Attribute Registry" should be created with the registrations below:

名前	参照
`Domain^a	この文書の `4.1.2.3§
`Expires^a	この文書の `4.1.2.1§
`HttpOnly^a	この文書の `4.1.2.6§
`Max-Age^a	この文書の `4.1.2.2§
`Path^a	この文書の `4.1.2.4§
`SameSite^a	この文書の `4.1.2.7§
`Secure^a	この文書の `4.1.2.5§

◎ Name Reference Domain Section 4.1.2.3 of this document Expires Section 4.1.2.1 of this document HttpOnly Section 4.1.2.6 of this document Max-Age Section 4.1.2.2 of this document Path Section 4.1.2.4 of this document SameSite Section 4.1.2.7 of this document Secure Section 4.1.2.5 of this document

~RFC 6265 からの変更点

`同一-~site$の概念と `SameSite$a 属性を追加した。（ `5.2§, `4.1.2.7§ 【, `8.8§ 】） ◎ Adds the same-site concept and the SameSite attribute. (Section 5.2 and Section 4.1.2.7)
~cookie接頭辞を導入した。名前を伴わない~cookieがそのような接頭辞を真似る値を設定することを禁制した。（ `4.1.3§, `5.7§ ） ◎ Introduces cookie prefixes and prohibits nameless cookies from setting a value that would mimic a cookie prefix. (Section 4.1.3 and Section 5.7)
~secureでない生成元が［新たな／既存の］~cookieの `secure-only-flag$cK【！Secure flag】を ~T に［設定する／上書する］ことを禁制した。（ `5.7§ ） ◎ Prohibits non-secure origins from setting cookies with a Secure flag or overwriting cookies with this flag. (Section 5.7)
~cookie~sizeの最大を制限した。（ `5.7§ ） ◎ Limits maximum cookie size. (Section 5.7)
［ `Max-Age$a, `Expires$a ］用の最大な値を制限した。（ `5.6.1§, `5.6.2§ ） ◎ Limits maximum values for max-age and expire. (Section 5.6.1 and Section 5.6.2)
`host-only-flag$cK も【`~cookie保管庫$における】~cookieの一意~性を成す~keyとして含めるようにした。（ `5.7§ ） ◎ Includes the host-only-flag as part of a cookie’s uniqueness computation. (Section 5.7)
信用に価し得る生成元は “~secureである” ものと見なすようにした。（ `5.7§ 【この訳においては、`~secureな接続$に関する注記】） ◎ Considers potentially trustworthy origins as "secure". (Section 5.7)
~cookie構文を改善した： ◎ Improves cookie syntax
- Set-Cookie: %token は、 ( 名前: 空~文字列, 値: %token ) を伴う~cookieを作成するものとして扱うようにした。（ `5.6§ ） ◎ Treats Set-Cookie: token as creating the cookie ("", "token"). (Section 5.6)
- 名前, 値どちらも伴わない~cookieを却下するようにした。（ `5.7§ ） ◎ Rejects cookies without a name nor value. (Section 5.7)
- 名前, 値どちらかを伴わない~cookieを直列化する方法を指定した。（ `5.8.3§ ） ◎ Specifies how to serialize a nameless/valueless cookie. (Section 5.8.3)
- ［ `cookie-pair$p, `set-cookie-string$p 【！the Cookie header production】］用の~ABNFを~space【 `BWS$p 】を許容するよう調整した。（ `4.1.1§ ） ◎ Adjusts ABNF for cookie-pair and the Cookie header production to allow for spaces. (Section 4.1.1)
- 制御~文字【 `CTL^P 】を明示的に取扱うようにした。（ `5.6§, `5.7§ ） ◎ Explicitly handle control characters. (Section 5.6 and Section 5.7)
- 空な `Domain$a 属性を取扱う方法を指定した。（ `5.7§ ） ◎ Specifies how to handle empty domain attributes. (Section 5.7)
- `Domain$a 属性には~ASCII文字が要求されるものとした。（ `5.7§ ） ◎ Requires ASCII characters for the domain attribute. (Section 5.7)
~cookie検索取得~algoを非~HTTP~APIを~supportするよう~~再構成した。（ `5.8.2§ ） ◎ Refactors cookie retrieval algorithm to support non-HTTP APIs. (Section 5.8.2)
`Set-Cookie^h 行l【を成す~percent-符号化された~octet列】は復号するべきでないものと指定した。（ `5.6§ ） ◎ Specifies that the Set-Cookie line should not be decoded. (Section 5.6)
実装者がどの要件を実装するか裁定することを支援するための助言的な節を追加した。（ `3.2§ ） ◎ Adds an advisory section to assist implementers in deciding which requirements to implement. (Section 3.2)
公共~接尾辞~listの変更に因り無効になった~cookieの送信を止めるよう勧めた。（ `5.8.3§ ） ◎ Advises against sending invalid cookies due to public suffix list changes. (Section 5.8.3)
`Cookie^h ~headerは 1 個までとする要件を除去した。（ `5.8.1§ ） ◎ Removes the single cookie header requirement. (Section 5.8.1)
正誤表に取組んだ：
- `正誤表 3444＠https://www.rfc-editor.org/errata/eid3444$： `path-value$p, `extension-av$p の文法を更新することにより。
- `正誤表 4148＠https://www.rfc-editor.org/errata/eid4148$： `day-of-month$p, `year$p, `time$p の文法を更新することにより。
- `正誤表 3663＠https://www.rfc-editor.org/errata/eid3663$：要請された注記を追加することにより。
（ `4.1§, `5.1.4§ ）
◎ Address errata 3444 by updating the path-value andextension-av grammar, errata 4148 by updating the day-of-month, year, and time grammar, and errata 3663 by adding the requested note. (Section 4.1 and Section 5.1.4)

謝辞

RFC 6265 は、 `Adam Barth^en 氏により書かれた。この文書は、 RFC 6265 に対し，特能を追加してその仕様を今日の配備の実態に揃うようにした更新である。この仕様の大半を成す~textは氏によるものであり、我々は，その巨人の肩の上に乗っている。 ◎ RFC 6265 was written by Adam Barth. This document is an update of RFC 6265, adding features and aligning the specification with the reality of today’s deployments. Here, we’re standing upon the shoulders of a giant since the majority of the text is still Adam’s.

以前の編集者 `Lily Chen^en 氏, `Steven Englehardt^en 氏による，この草案を改善する有意な貢献に感謝する。 ◎ Thank you to both Lily Chen and Steven Englehardt, editors emeritus, for their significant contributions improving this draft.

この文書について

このメモの位置付け

著作権の告知

1. 序論

2. 表記規約

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

2.1. 適合性の判定基準

2.2. 構文の記法

2.3. 各種用語

3. 概観

3.1. 例

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

3.2.1. ~cookieを生産している実装

3.2.2. ~cookieを消費している実装

3.2.2.1. ~programming言語と~software~framework

4. ~serverに課される要件

4.1. `Set-Cookie^h ~header

4.1.1. 構文

4.1.2. 意味論（規範的でない）

4.1.2.1. `Expires^a 属性

4.1.2.2. `Max-Age^a 属性

4.1.2.3. `Domain^a 属性

4.1.2.4. `Path^a 属性

4.1.2.5. `Secure^a 属性

4.1.2.6. `HttpOnly^a 属性

4.1.2.7. `SameSite^a 属性

4.1.3. ~cookie名の接頭辞

4.1.3.1. `__Secure-^l 接頭辞

4.1.3.2. `__Host-^l 接頭辞

4.2. `Cookie^h ~header

4.2.1. 構文

4.2.2. 意味論

5. ~UAに課される要件

5.1. 下位成分~algo

5.1.1. 日付

5.1.2. 正準-化された~host名

5.1.3. ~domainの照合-法

5.1.4. ~pathと~path合致-

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

5.2.1. 文書に基づく要請

5.2.2. ~workerに基づく要請

5.2.2.1. 専用／共用~worker

5.2.2.2. ~sw

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

5.4. ~cookie名の接頭辞

5.5. ~cookieの存続期間の上限

5.6. `Set-Cookie^h ~header

5.6.1. `Expires^a 属性

5.6.2. `Max-Age^a 属性

5.6.3. `Domain^a 属性

5.6.4. `Path^a 属性

5.6.5. `Secure^a 属性

5.6.6. `HttpOnly^a 属性

5.6.7. `SameSite^a 属性

5.6.7.1. `Strict^l ／ `Lax^l の施行

5.6.7.2. `Lax-allowing-unsafe^l の施行