1. 序論
~HTTPは、［ `内容$／`表現$ ］を成す~dataの完全性を保護するための手段は定義しない。 ~HTTP`~message$が端点~間で転送されるとき、 より低~層な特能や特質 — ~TCP~checksumや~TLS~record `TLS$r など — は，何らかの完全性~保護を供し得る。 しかしながら，~transport指向な完全性が供する有用性は制限される — それは，応用~層からは不透明であり、 それが受持つのは，単独の接続までに限られるので。 ~HTTP~messageは，別々な接続の連鎖~越しに旅することが多く、 接続どうしの合間にて~data破損を~~被るアリ性がある。 ~HTTPによる完全性の仕組みは、［ 端点／~HTTPを利用している応用 ］用に［ ~data破損を検出して，それに対し動作する方法について選ぶ ］ための手段を供せる。 利用事例の例として、 ~system境界にまたがる欠陥~検出とその診断を援助することが挙げられる。 ◎ HTTP does not define the means to protect the data integrity of content or representations. When HTTP messages are transferred between endpoints, lower-layer features or properties such as TCP checksums or TLS records [TLS] can provide some integrity protection. However, transport-oriented integrity provides a limited utility because it is opaque to the application layer and only covers the extent of a single connection. HTTP messages often travel over a chain of separate connections. In between connections, there is a possibility for data corruption. An HTTP integrity mechanism can provide the means for endpoints, or applications using HTTP, to detect data corruption and make a choice about how to act on it. An example use case is to aid fault detection and diagnosis across system boundaries.
この文書は、 ~HTTP用の~digest完全性の仕組みとして，次に挙げる 2 つを定義する： ◎ This document defines two digest integrity mechanisms for HTTP.＼
- 内容の完全性は、 伝達される`内容$に対し動作する。 ◎ First, content integrity, which acts on conveyed content (Section 6.4 of [HTTP]).＼
- 表現~dataの完全性は、 `表現~data$に対し動作する。 これは、 高度な利用事例を~supportする — ［ 複数の［ 要請／接続 ］を利用して検索取得された各部から構築し直された資源 ］に対し，その完全性を検証することなど。 ◎ Second, representation data integrity, which acts on representation data (Section 8.1 of [HTTP]). This supports advanced use cases, such as validating the integrity of a resource that was reconstructed from parts retrieved using multiple requests or connections.
この文書は、 `RFC3230$r — したがって［ `Digest^h, `Want-Digest^h ］`~field$も — を廃用にする。 `1.3§ を見よ。 ◎ This document obsoletes [RFC3230] and therefore the Digest and Want-Digest HTTP fields; see Section 1.3.
1.1. この文書の構成
この文書の構成は： ◎ This document is structured as follows:
- 次に挙げる新たな【！［要請／応答］［~header／~trailer］】~fieldを定義する ⇒＃ `2§） `Content-Digest$h, `3§） `Repr-Digest$h, `4§） `Want-Content-Digest$h, `Want-Repr-Digest$h ◎ New request and response header and trailer field definitions. • Section 2 (Content-Digest), • Section 3 (Repr-Digest), and • Section 4 (Want-Content-Digest and Want-Repr-Digest).
-
表現~dataの完全性に特有な考慮点： ◎ Considerations specific to representation data integrity.
- `3.1§）状態変更~要請における `Repr-Digest$h の利用-法 ◎ Section 3.1 (State-changing requests),
- `3.2§）応答~内の `Repr-Digest$h と `Content-Location$h ◎ Section 3.2 (Content-Location),
- `A§）~message交換における`表現~data$の用例 ◎ Appendix A contains worked examples of representation data in message exchanges, and
- `B§, `C§） ~message交換における［ `Repr-Digest$h ／ `Want-Repr-Digest$h ］~fieldの用例 ◎ Appendixes B and C contain worked examples of Repr-Digest and Want-Repr-Digest fields in message exchanges.
- `5§） ~hash~algo用に新たな~IANA~registryを確立して，初期~登録を与える。 将来の~entry用の登録~手続-を定義する。 ◎ Section 5 bootstraps a new IANA registry hash algorithms and defines registration procedures for future entries.
1.2. 概念の概観
この文書にて定義される`~field$は、 ~HTTP完全性のために利用できる。 `送信者$は、 ある`~hashing~algo$を選んで， 当の~HTTP`~message$に関係する入力から~digestを計算する。 当の~algoの識別子と結果の~digestは、 `~field$内に伝送される。 `受信者$は、 完全性の目的で，その~digestを検証できる。 `~hashing~algo$は、 `~HTTP~digest~field用~hash~algo~registry$cite 内に登録される（ `7.2§ を見よ）。 ◎ The HTTP fields defined in this document can be used for HTTP integrity. Senders choose a hashing algorithm and calculate a digest from an input related to the HTTP message. The algorithm identifier and digest are transmitted in an HTTP field. Receivers can validate the digest for integrity purposes. Hashing algorithms are registered in the "Hash Algorithms for HTTP Digest Fields" registry (see Section 7.2).
~digestを どの~dataに対し計算するか選定することは、 ~HTTP~messageの利用事例に依存する。 この文書は、 ~HTTPの`表現~data$用と`内容$用に異なる~fieldを供する。 ◎ Selecting the data on which digests are calculated depends on the use case of the HTTP messages. This document provides different fields for HTTP representation data and HTTP content.
`内容$を成す~byte列の単純な~digestが要求される利用事例もある。 `Content-Digest$h 【！［要請／応答］［~header／~trailer］】~fieldは， `内容$の~digestを~supportするために定義される。 `2§ を見よ。 ◎ There are use cases where a simple digest of the HTTP content bytes is required. The Content-Digest request and response header and trailer field is defined to support digests of content (Section 6.4 of [HTTP]); see Section 2.
より高度な利用事例~用には、 `Repr-Digest$h 【！［要請／応答］［~header／~trailer］】~fieldが定義される（ `3§ ）。 それは、［ `選定された表現~data$に対し，ある`~hashing~algo$を適用する ］ことにより算出された~digest値を包含する。 `Repr-Digest$h を`選定された表現$に基づくようにすることは、 次に挙げる利用事例に，それを適用することを単直にする： ◎ For more advanced use cases, the Repr-Digest request and response header and trailer field (Section 3) is defined. It contains a digest value computed by applying a hashing algorithm to selected representation data (Section 8.1 of [HTTP]). Basing Repr-Digest on the selected representation makes it straightforward to apply it to use cases where＼
- `内容$が`資源$の`表現$と見なされるものに何らかの類の操作を要求する所 ◎ the message content requires some sort of manipulation to be considered as representation of the resource＼
- `内容$が`資源$の部分的な表現を伝達する所 — `範囲~要請$ `HTTP$r【！§ 14】 など ◎ or the content conveys a partial representation of a resource, such as range requests (see Section 14 of [HTTP]).
［ `Content-Digest$h ／ `Repr-Digest$h ］~fieldは、 `~hashing~algo$の即応性【 `6.6§ 】を~supportする。 ［ `Want-Content-Digest$h ／ `Want-Repr-Digest$h ］~fieldは、［ `Content-Digest$h ／ `Repr-Digest$h ］に対する関心, および［ どの~algoを選好するか ］を表出することを端点に許容する。 ◎ Content-Digest and Repr-Digest support hashing algorithm agility. The Want-Content-Digest and Want-Repr-Digest fields allow endpoints to express interest in Content-Digest and Repr-Digest respectively, and to express algorithm preferences in either.
［ `Content-Digest$h ／ `Repr-Digest$h ］を総称して， `完全性~field@ （ `Integrity field^en ）という。 ［ `Want-Content-Digest$h ／ `Want-Repr-Digest$h ］を総称して， `完全性~選好~field@ （ `Integrity preference field^en ）という。 ◎ Content-Digest and Repr-Digest are collectively termed Integrity fields. Want-Content-Digest and Want-Repr-Digest are collectively termed Integrity preference fields.
`完全性~field$の計算は、［ `Content-Encoding$h, `Content-Type$h ］~headerに束ねられる。 したがって、所与の`資源$が~HTTPで転送されるとき，複数個の異なる~digest値があり得る。 ◎ Integrity fields are tied to the Content-Encoding and Content-Type header fields. Therefore, a given resource may have multiple different digest values when transferred with HTTP.
`完全性~field$は、 ~HTTP［ `内容$／`表現$ ］に適用され，~HTTP［ `~message$／`~field$ ］には適用されない。 しかしながら，それは、 ~HTTP交換に欲される各部を［ 一体として／各部ごとに ］保護するためとして，［ ~metadataを保護する他の仕組み ］を成す各~相 — ~digital署名など — と組合できる。 例えば、 `~HTTP~message署名^cite `SIGNATURES$r を利用して， `完全性~field$を署名する — したがって，［ `内容$／`表現~data$ ］用に~~保険をかける — こともできる。 ◎ Integrity fields apply to HTTP message content or HTTP representations. They do not apply to HTTP messages or fields. However, they can be combined with other mechanisms that protect metadata, such as digital signatures, in order to protect the phases of an HTTP exchange in whole or in part. For example, HTTP Message Signatures [SIGNATURES] could be used to sign Integrity fields, thus providing coverage for HTTP content or representation data.
この仕様は、［ 認証／権限付与／~privacy ］用の手段は定義しない。 ◎ This specification does not define means for authentication, authorization, or privacy.
1.3. ~RFC 3230 の廃用~化
`RFC3230$r は ~HTTP完全性~用に 2 つの~field — `Digest^h, `Want-Digest^h — を定義した。 それはまた、 `選定された表現~data$などの概念を説明するために，用語［ “~instance”, “~instance操作” ］も新造した。 ◎ [RFC3230] defined the Digest and Want-Digest HTTP fields for HTTP integrity. It also coined the terms "instance" and "instance manipulation" in order to explain concepts, such as selected representation data (Section 8.1 of [HTTP]), that are now more universally defined and implemented as HTTP semantics.
`RFC3230$r の実装は、 “~instance” の意味をどう解釈するか一貫性がなかったため，相互運用能の課題へ至らすことが経験から示された。 最も共通的な課題は、 ~digestを計算する際に — 元々意図された，`表現~data$（と今や称されるもの）ではなく — ~messageの`内容$（と今や称されるもの）を利用するものと誤解していたことに関係する。 興味深いことに、 時を経て，［ `内容$の~digestも，一部の利用-事例では有益になる ］ことも示されたので、 `RFC3230$r に適合しないことが意図的かそうでないのか検出するのは，困難である。 ◎ Experience has shown that implementations of [RFC3230] have interpreted the meaning of "instance" inconsistently, leading to interoperability issues. The most common issue relates to the mistake of calculating the digest using (what we now call) message content, rather than using (what we now call) representation data as was originally intended. Interestingly, time has also shown that a digest of message content can be beneficial for some use cases, so it is difficult to detect if non-conformance to [RFC3230] is intentional or unintentional.
［ `Digest^h ／ `Want-Digest^h ］の各~実装にまたがる非-一貫性と多義性に取組むため、 この文書は， `RFC3230$r を廃用する。 この文書にて定義される各種［ `完全性~field$（ `2§, `3§ ）／ `完全性~選好~field$（ `4§ ） ］は、 現在の~HTTP意味論にもっと良く倣うようにされ， 意図される用法を もっと明瞭に表すよう命名された。 ◎ In order to address potential inconsistencies and ambiguity across implementations of Digest and Want-Digest, this document obsoletes [RFC3230]. The Integrity fields (Sections 2 and 3) and Integrity preference fields (Section 4) defined in this document are better aligned with current HTTP semantics and have names that more clearly articulate the intended usages.
1.4. 表記規約
この文書~内の~keyword "MUST" … 【以下、この段落の内容は`~IETF日本語訳 共通~page＠~IETFcommon#requirements-notation$に移譲。】 ◎ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
この文書は、 `RFC5234$r に定義され， `RFC7405$r にて更新された~ABNFを利用する。 これには、 規則［ `CR$P, `LF$P, `CRLF$P ］も含まれる。 ◎ This document uses the Augmented BNF defined in [RFC5234] and updated by [RFC7405]. This includes the rules CR (carriage return), LF (line feed), and CRLF (CR LF).
この文書は、 構文と構文解析-法を指定するため， 次に挙げる型を利用する【！terminology from Section 3 of】 `STRUCTURED-FIELDS$r ⇒＃ `~sf真偽値$, `~sf~byte列$, `~sf辞書$, `~sf整数$, `~sf~list$ ◎ This document uses the following terminology from Section 3 of [STRUCTURED-FIELDS] to specify syntax and parsing: Boolean, Byte Sequence, Dictionary, Integer, and List.
この文書における次に挙げる用語は、 `HTTP$r に述べられるとおりに解釈すること ⇒＃ `表現$, `選定される表現$, `表現~data$, `表現~metadata$, `~UA$, `内容$ ◎ The definitions "representation", "selected representation", "representation data", "representation metadata", "user agent", and "content" in this document are to be interpreted as described in [HTTP].
【 用語 `選定された表現~data@ （ `selected representation data^en ）も［ `選定された表現$の`表現~data$ ］の略記として利用される。 】
この文書は、 `FOLDING$r にて述べられる行l折返し法を利用する†。 ◎ This document uses the line folding strategies described in [FOLDING].
【† 一部の~code例の最初の行lに出現する `~SBS-ST^c により指示される。 それは、 `FOLDING$r `7＠~RFCx/rfc8792#section-7§ に則って［ 長過ぎる行lが折返されたことを指示するためとして、 行lの末尾に "`\^c" が利用されている ］ことを表す （それら （ "`NOTE:…^c" および "`\^c" （と後続する改行文字, 字下げ）） は、 当の~codeの一部を成さない）。 】
`~hashing~algo$の名前は、 それらを定義する文書に利用される文字大小-法を尊重する （例： `SHA-1$i, `CRC32c$i ）。 ◎ Hashing algorithm names respect the casing used in their definition document (e.g., SHA-1, CRC32c).
~HTTP`~message$は、 `~algo~key$を利用して，`~hashing~algo$を指示する。 文書の注釈文において`~algo~key$を指す所では、 引用符で括られる （例： "`sha$c", "`crc32c$c" ）。 ◎ HTTP messages indicate hashing algorithms using an Algorithm Key (algorithms). Where the document refers to an Algorithm Key in prose, it is quoted (e.g., "sha", "crc32c").
用語 `~checksum^dfn は、 ~byte列に ある~algoを適用した結果の出力を述べる。 一方で，用語 `~digest^dfn は、 【~checksumと同様であるが，】 当の`~field$に包含される値に関係する所に限り利用される。 ◎ The term "checksum" describes the output of applying an algorithm to a sequence of bytes, whereas "digest" is only used in relation to the value contained in the fields.
用語 `完全性~field$は、［ `Content-Digest$h ／ `Repr-Digest$h ］の総称である。 ◎ "Integrity fields" is the collective term for Content-Digest and Repr-Digest.
用語 `完全性~選好~field$は、［ `Want-Content-Digest$h ／ `Want-Repr-Digest$h ］の総称である。 ◎ "Integrity preference fields" is the collective term for Want-Repr-Digest and Want-Content-Digest.
2. `Content-Digest^h ~field
`Content-Digest^h `~field$は、 要請, 応答どちらにも利用でき， 実際の`内容$に`~hashing~algo$を適用して計算された~digestを通信する。 ◎ The Content-Digest HTTP field can be used in requests and responses to communicate digests that are calculated using a hashing algorithm applied to the actual message content (see Section 6.4 of [HTTP]).＼
`Content-Digest^h は、 `有構造~field$であり，`~sf辞書$を値にとる — 各~memberの： ◎ It is a Dictionary (see Section 3.2 of [STRUCTURED-FIELDS]), where each:
- ~keyは、 当の~digestを算出するときに利用された`~hashing~algo$を伝達する （ `5§ を見よ）。 ◎ key conveys the hashing algorithm (see Section 5) used to compute the digest;
- 値は、 `~sf~byte列$であり，［ ~digest計算により生産された~byte出力 ］を符号化した~versionを伝達する。 ◎ value is a Byte Sequence (Section 3.3.5 of [STRUCTURED-FIELDS]) that conveys an encoded version of the byte output produced by the digest calculation.
例えば： ◎ For example:
`~SBS-ST$ Content-Digest: \ sha-512=:YMAam51Jz/jOATT6/zvHrLVgOYTGFy1d6GJiOHTohq4yP+pgk4vf2aCs\ yRZOtw8MjkM7iw7yZ/WkppmM44T3qg==:
この`~sf辞書$型を利用すれば、 例えば，能力が［ 相異なる／発展している ］様々な端点を~supportするために［ 異なる`~hashing~algo$を利用して計算された，複数の~digest ］を添えれる。 そのような~approachは、 より弱い~algoから離れるよう移行tすることも~supportし得る （ `6.6§ を見よ）。 ◎ The Dictionary type can be used, for example, to attach multiple digests calculated using different hashing algorithms in order to support a population of endpoints with different or evolving capabilities. Such an approach could support transitions away from weaker algorithms (see Section 6.6).
`~SBS-ST$ Content-Digest: \ sha-256=:d435Qo+nKZ+gLcUHn7GQtQ72hiBVAgqoLsZnZPiTGPk=:,\ sha-512=:YMAam51Jz/jOATT6/zvHrLVgOYTGFy1d6GJiOHTohq4yP+pgk4vf2aCs\ yRZOtw8MjkM7iw7yZ/WkppmM44T3qg==:
`受信者$は、 受信した各~digestに対し，どれを無視してもヨイ。 応用に特有な挙動や局所的な施策は、 伝達された~digestの処理や検証の実施に対し，追加的な拘束を設定してもヨイ。 ~securityの考慮点は、［ ~digestを無視すること／複数の~digestを検証すること ］に関係する課題のうち一部を受持つ （［ `6.6§ ／ `6.7§ ］を見よ）。 ◎ A recipient MAY ignore any or all digests. Application-specific behavior or local policy MAY set additional constraints on the processing and validation practices of the conveyed digests. The security considerations cover some of the issues related to ignoring digests (see Section 6.6) and validating multiple digests (see Section 6.7).
`送信者$は、 所与の`~hashing~algo$を`受信者$が［ ~supportするかどうか知らなくても, 無視することを知っていても ］，~digestを送信してヨイ。 ◎ A sender MAY send a digest without knowing whether the recipient supports a given hashing algorithm. A sender MAY send a digest if it knows the recipient will ignore it.
`Content-Digest^h は、 `~trailer節$内にも送信できる。 この事例では、 `Content-Digest^h は`~header節$の中へ併合してもヨイ — `HTTP$r `~trailerの利用に対する制限＠~HTTPinfra#trailers.limitations§を見よ。 ◎ Content-Digest can be sent in a trailer section. In this case, Content-Digest MAY be merged into the header section; see Section 6.5.1 of [HTTP].
3. `Repr-Digest^h ~field
`Repr-Digest^h `~field$は、 要請, 応答どちらにも利用でき， `選定された表現~data$全体に`~hashing~algo$を適用して計算された~digestを通信する。 【 "Repr" は `Representation^en（表現）の略称。】 ◎ The Repr-Digest HTTP field can be used in requests and responses to communicate digests that are calculated using a hashing algorithm applied to the entire selected representation data (see Section 8.1 of [HTTP]).
`表現$は、 ~messageに対する~HTTP意味論の効果も織り込む。 例えば、 `内容$は，［ `範囲~要請$／ `HEAD$m などの~method ］により影響され得ることに加え、 内容が “伝送路” 上で転送される仕方は，他の`形式変換$に依存する （例： ~HTTP11用の`転送~符号法$ — `HTTP/1.1$r `Transfer-Encoding§h を見よ）。 `A§ にて、 `表現$の概念を~~説明する例がいくつか供される。 ◎ Representations take into account the effect of the HTTP semantics on messages. For example, the content can be affected by range requests or methods, such as HEAD, while the way the content is transferred "on the wire" is dependent on other transformations (e.g., transfer codings for HTTP/1.1; see Section 6.1 of [HTTP/1.1]). To help illustrate HTTP representation concepts, several examples are provided in Appendix A.
~messageに`表現~data$が無いときでも、 空~文字列から~digestを算出して，［ `表現~data$は送信されなかったことを表明する ］ことはアリである （ `6.3§ を見よ）。 ◎ When a message has no representation data, it is still possible to assert that no representation data was sent by computing the digest on an empty string (see Section 6.3).
`Repr-Digest^h は、 `有構造~field$であり，`~sf辞書$を値にとる — 各~memberの： ◎ Repr-Digest is a Dictionary (see Section 3.2 of [STRUCTURED-FIELDS]), where each:
- ~keyは、 当の~digestを算出するときに利用した`~hashing~algo$を伝達する （ `5§ を見よ）。 ◎ key conveys the hashing algorithm (see Section 5) used to compute the digest;
- 値は、 `~sf~byte列$であり，［ ~digest計算により生産された~byte出力 ］を符号化した~versionを伝達する。 ◎ value is a Byte Sequence that conveys an encoded version of the byte output produced by the digest calculation.
例えば： ◎ For example:
`~SBS-ST$ Repr-Digest: \ sha-512=:YMAam51Jz/jOATT6/zvHrLVgOYTGFy1d6GJiOHTohq4yP+pgk4vf2aCs\ yRZOtw8MjkM7iw7yZ/WkppmM44T3qg==:
この`~sf辞書$型を利用すれば、 能力が［ 相異なる／発展している ］様々な端点を~supportするために［ 異なる`~hashing~algo$を利用して計算された，複数の~digest ］を添えれる。 そのような~approachは、 より弱い~algoから離れるよう移行tすることも~supportし得る （ `6.6§ を見よ）。 ◎ The Dictionary type can be used to attach multiple digests calculated using different hashing algorithms in order to support a population of endpoints with different or evolving capabilities. Such an approach could support transitions away from weaker algorithms (see Section 6.6).
`~SBS-ST$ Repr-Digest: \ sha-256=:d435Qo+nKZ+gLcUHn7GQtQ72hiBVAgqoLsZnZPiTGPk=:,\ sha-512=:YMAam51Jz/jOATT6/zvHrLVgOYTGFy1d6GJiOHTohq4yP+pgk4vf2aCs\ yRZOtw8MjkM7iw7yZ/WkppmM44T3qg==:
`受信者$は、 受信した各~digestに対し，どれを無視してもヨイ。 応用に特有な挙動や局所的な施策は、 伝達された~digestの処理や検証の実施に対し，追加的な拘束を設定してもヨイ。 ~securityの考慮点は、［ ~digestを無視すること／複数の~digestを検証すること ］に関係する課題のうち一部を受持つ （［ `6.6§ ／ `6.7§ ］を見よ）。 ◎ A recipient MAY ignore any or all digests. Application-specific behavior or local policy MAY set additional constraints on the processing and validation practices of the conveyed digests. The security considerations cover some of the issues related to ignoring digests (see Section 6.6) and validating multiple digests (see Section 6.7).
`送信者$は、 所与の`~hashing~algo$を`受信者$が［ ~supportするかどうか知らなくても, 無視することを知っていても ］，~digestを送信してヨイ。 ◎ A sender MAY send a digest without knowing whether the recipient supports a given hashing algorithm. A sender MAY send a digest if it knows the recipient will ignore it.
`Repr-Digest^h は、 `~trailer節$内にも送信できる。 この事例では、 `Repr-Digest^h を`~header節$の中へ併合してもヨイ — `HTTP$r `~trailerの利用に対する制限＠~HTTPinfra#trailers.limitations§を見よ。 ◎ Repr-Digest can be sent in a trailer section. In this case, Repr-Digest MAY be merged into the header section; see Section 6.5.1 of [HTTP].
3.1. 状態変更~要請における `Repr-Digest^h の利用-法
状態変更~要請~内に同封された表現が`~target資源$を述べるものでないときは、 表現~digestは，`表現~data$から算出されなければナラナイ。 これは、唯一アリな選択になる — 表現~digestは、完全な`表現~metadata$を要求するので （ `3§ を見よ）。 ◎ When the representation enclosed in a state-changing request does not describe the target resource, the representation digest MUST be computed on the representation data. This is the only possible choice because representation digest requires complete representation metadata (see Section 3).
応答においては： ◎ In responses,
- 当の`表現$が要請の状態sを述べる場合、 `Repr-Digest$h は，同封された`表現$から算出されなければナラナイ （ `B.8§ を見よ） ◎ if the representation describes the status of the request, Repr-Digest MUST be computed on the enclosed representation (see Appendix B.8);
- 参照-先の`資源$が在る場合、 `Repr-Digest$h は，その資源に`選定される表現$から算出されなければナラナイ — それが当の`~target資源$と異なっていようが。 `Repr-Digest$h は、 同封された`表現$から算出された結果であることも， そうでないこともある。 ◎ if there is a referenced resource, Repr-Digest MUST be computed on the selected representation of the referenced resource even if that is different from the target resource. This might or might not result in computing Repr-Digest on the enclosed representation.
後者の事例は、 所与の`~method$の意味論に則って行われる — 例えば， `Content-Location$h ~header `HTTP$r を利用して。 対照的に， `Location$h ~headerは、 `表現~metadata$ではないので， `Repr-Digest$h には影響しない。 ◎ The latter case is done according to the HTTP semantics of the given method, for example using the Content-Location header field (see Section 8.7 of [HTTP]). In contrast, the Location header field does not affect Repr-Digest because it is not representation metadata.
例えば `PATCH$m 要請においては、 表現~digestは~patch文書から算出されることになる — `表現~metadata$は、 `~target資源$ではなく，~patch文書を指すので （ `PATCH$r `PATCH§m を見よ）。 対する応答においては、 表現~digestは，代わりに~patchされた`資源$用に`選定された表現$から算出されることになる。 ◎ For example, in PATCH requests, the representation digest will be computed on the patch document because the representation metadata refers to the patch document and not the target resource (see Section 2 of [PATCH]). In responses, instead, the representation digest will be computed on the selected representation of the patched resource.
3.2. 応答~内の `Repr-Digest^h と `Content-Location^h
ある状態変更~methodに対する応答が `Content-Location$h ~headerを返すとき、 応答に同封された表現は，その`~field値$により識別される`資源$を指す — `Repr-Digest$h はそれに則って算出される。 その例は `B.7§ にて与える。 ◎ When a state-changing method returns the Content-Location header field, the enclosed representation refers to the resource identified by its value and Repr-Digest is computed accordingly. An example is given in Appendix B.7.
4. 完全性~選好~field
`送信者$は、［ `Want-Content-Digest$h ／ `Want-Repr-Digest$h ］`~field$を利用して，自身による［ `完全性~field$への関心, `~hashing~algo$の選好 ］を指示できる。 これらは、［ 要請, 応答 ］どちらにも利用できる。 ◎ Senders can indicate their interest in Integrity fields and hashing algorithm preferences using the Want-Content-Digest or Want-Repr-Digest HTTP fields. These can be used in both requests and responses.
`Want-Content-Digest^h ~fieldは、 次を指示する ⇒ `送信者$は、［ 要請の`~target~URI$【！要請~URI】, `表現~metadata$ ］に結付けられた~messageに対し，内容~digestを （ `Content-Digest$h ~fieldを介して） 受信したいと願っている。 ◎ Want-Content-Digest indicates that the sender would like to receive (via the Content-Digest field) a content digest on messages associated with the request URI and representation metadata.＼
`Want-Repr-Digest^h ~fieldは、 次を指示する ⇒ `送信者$は、［ 要請の`~target~URI$【！要請~URI】, `表現~metadata$ ］に結付けられた~messageに対し，表現~digestを （ `Repr-Digest$h ~fieldを介して） 受信したいと願っている。 ◎ Want-Repr-Digest indicates that the sender would like to receive (via the Repr-Digest field) a representation digest on messages associated with the request URI and representation metadata.
［ `Want-Content-Digest^h ／ `Want-Repr-Digest^h ］が応答~内に利用された場合、 次を指示する ⇒ `~server$は、［ `~client$が，対応する`完全性~field$を未来の要請にて供する ］よう願っている。 ◎ If Want-Content-Digest or Want-Repr-Digest are used in a response, it indicates that the server would like the client to provide the respective Integrity field on future requests.
`完全性~選好~field$は、 ~hintでしかない。 当の~fieldの`受信者$は、 それを無視でき，［ 他の何らかの~algoを利用している`完全性~選好~field$を送信する／ `完全性~選好~field$を まるごと省略する ］こともできる。 例えば， `C.2§ を見よ。 選好が無視されたとしても，~protocol~errorではない。 ［ `完全性~field$を利用する応用／ 完全性に関する選好 ］は、 この仕様に加えて運用する［ 期待／拘束 ］を定義し得る。 選好が無視される懸念は、 応用に特有である。 ◎ Integrity preference fields are only a hint. The receiver of the field can ignore it and send an Integrity field using any algorithm or omit the field entirely; for example, see Appendix C.2. It is not a protocol error if preferences are ignored. Applications that use Integrity fields and Integrity preferences can define expectations or constraints that operate in addition to this specification. Ignored preferences are an application-specific concern.
［ `Want-Content-Digest$h ／ `Want-Repr-Digest$h ］は、 `有構造~field$であり，`~sf辞書$を値にとる — 各~memberの： ◎ Want-Content-Digest and Want-Repr-Digest are of type Dictionary where each:
- ~keyは、 当の`~hashing~algo$を伝達する。 ◎ key conveys the hashing algorithm (see Section 5);
- 値は、 `~sf整数$をとり， 【~keyに指示された~hashing~algoの】選好~度を伝達する。 値は、 範囲 { 0 〜 10 } に入らなければナラナイ。 各~memberのうち，値が大きいものほど選好されるが、 値 0 は “受容-可能でない” ことを意味する。 ◎ value is an Integer (Section 3.3.1 of [STRUCTURED-FIELDS]) that conveys an ascending, relative, weighted preference. It must be in the range 0 to 10 inclusive. 1 is the least preferred, 10 is the most preferred, and a value of 0 means "not acceptable".
例： ◎ Examples:
Want-Repr-Digest: sha-256=1 Want-Repr-Digest: sha-512=3, sha-256=10, unixsum=0 Want-Content-Digest: sha-256=1 Want-Content-Digest: sha-512=3, sha-256=10, unixsum=0
5. ~hash~algoの考慮点と登録
完全性の目的に利用できる~hashing~algoには、 多様なものがある。 ~algoの選択は、 次に挙げるものなど，いくつかの要因に依存する ⇒＃ 完全性の利用-事例／ 実装における必要性や拘束／ 応用の設計と~workflow ◎ There are a wide variety of hashing algorithms that can be used for the purposes of integrity. The choice of algorithm depends on several factors such as the integrity use case, implementation needs or constraints, or application design and workflows.
~algoたちが成す初期~集合は、 ~IANAにおいて `~HTTP~digest~field用~hash~algo~registry$cite 内に登録されることになる — `7.2§を見よ。 追加的な~algoは、 この節にて設けられる施策に則って登録できる。 ◎ An initial set of algorithms will be registered with IANA in the "Hash Algorithms for HTTP Digest Fields" registry; see Section 7.2. Additional algorithms can be registered in accordance with the policies set out in this section.
各~algoには、 `位置付け$があり， 実装における選定を援助することが意図される。 ◎ Each algorithm has a status field that is intended to provide an aid to implementation selection.
`位置付け$ `現役$i を伴う~algoは、 多くの目的に相応しくなる — 応用には、 これらの~algoを利用することが`推奨される^2119。 これらは、 敵対者に~~晒される状況にも利用できる — そこでは、 ~hash関数は，［ 衝突~攻撃, 第一-原像~攻撃, 第二-原像~攻撃 ］に対する耐性を供する必要があるかもしれない。 そのような状況において，受容-可能な［ `現役$i を伴う~algo ］の選定は、 当の状況下で~~必要とされる保護~levelに依存することになる。 さらなる考慮点は、 `6.6§ にて呈示される。 ◎ Algorithms with a status value of "Active" are suitable for many purposes and it is RECOMMENDED that applications use these algorithms. These can be used in adversarial situations where hash functions might need to provide resistance to collision, first-preimage, and second-preimage attacks. For adversarial situations, selection of the acceptable "Active" algorithms will depend on the level of protection the circumstances demand. More considerations are presented in Section 6.6.
`位置付け$ `非推奨d$i を伴う~algoは、 これらの特質を何も供さないか，弱いことが既知である （ `NO-MD5$r, `NO-SHA$r を見よ）。 これらの~algoは，破損に抗する完全性を保全するためとして利用してもヨイが、 敵対者に~~晒され得る設定においては，利用してはナラナイ — 例えば、 真正性を得るために`完全性~field$の値を署名するとき。 これらの~algoの利用を許可することは、 一部の応用 （それまで `RFC3230$r を利用していて， この仕様へ移行していて（ `E§ ）， 既存の［ 算出された~digest値たちが成す格納-済みな~collection ］を有するものなど） が，［ より~secureな他の~algoを利用して算出し直すこと ］により［ 必要以上に演算~上の~overheadを~~被る ］ことを避ける助けになることもある。 そのような応用であっても，この節の要件は免除されない。 さらには、 そのような［ 旧来のもの／歴史 ］を伴わない応用は， `位置付け$ `現役$i を伴う~algoを利用するための指導に従う~OUGHT。 ◎ Algorithms with a status value of "Deprecated" either provide none of these properties or are known to be weak (see [NO-MD5] and [NO-SHA]). These algorithms MAY be used to preserve integrity against corruption, but MUST NOT be used in a potentially adversarial setting, for example, when signing Integrity fields' values for authenticity. Permitting the use of these algorithms can help some applications (such as those that previously used [RFC3230], are migrating to this specification (Appendix E), and have existing stored collections of computed digest values) avoid undue operational overhead caused by recomputation using other more-secure algorithms. Such applications are not exempt from the requirements in this section. Furthermore, applications without such legacy or history ought to follow the guidance for using algorithms with the status value "Active".
~algo即応性の論点は、 `6.6§ にて呈示される。 ◎ Discussion of algorithm agility is presented in Section 6.6.
`~HTTP~digest~field用~hash~algo~registry$cite 用の登録~要請は、 “仕様が要求される” とする施策（ `8126/4.6$rfc ）を利用する。 要請は、 次の雛形を利用するべきである： ◎ Registration requests for the "Hash Algorithms for HTTP Digest Fields" registry use the Specification Required policy (Section 4.6 of [RFC8126]). Requests should use the following template:
- `~algo~key@ （ `Algorithm Key^en ） ⇒ 次に挙げる`有構造~field$において， `~sf辞書$を成す各~memberの~keyとして利用される値 ⇒＃ `Content-Digest$h, `Repr-Digest$h, `Want-Content-Digest$h `Want-Repr-Digest$h ◎ Algorithm Key: • The Structured Fields key value used in Content-Digest, Repr-Digest, Want-Content-Digest, or Want-Repr-Digest field Dictionary member keys.
-
`位置付け@ （ `Status^en ） ⇒ 当の~algoの位置付け — 次に挙げるいずれかとする： ◎ Status: • The status of the algorithm. The options are:
- `現役@i （ `Active^en ） ⇒ 既知な問題を伴わない~algo用 ◎ "Active": • Algorithms without known problems
- `暫定的@i （ `Provisional^en ） ⇒ 【~secureかどうか】立証されてない~algo用 ◎ "Provisional": • Unproven algorithms
- `非推奨d@i （ `Deprecated^en ） ⇒ ［ 非推奨にされた／~secureでない ］~algo用 ◎ "Deprecated": • Deprecated or insecure algorithms
- 記述 （ `Description^en ） ⇒ 当の~algoについての短い記述 ◎ Description: • A short description of the algorithm.
- 参照 （ `Reference(s)^en ） ⇒ 次を定義している首な文書~群への~pointer ⇒＃ 当の~algoの~key／ 当の~algoの技術的な詳細 ◎ Reference(s): • Pointer(s) to the primary document(s) defining the Algorithm Key and technical details of the algorithm.
指名された専門家（たち）は， 登録~要請を考査する際には、 要請された`位置付け$に注意を払うべきである。 `位置付け$は、 標準~化の状態sおよび［ 関連な関心~group — ~IETF／~securityに関係する標準~開発~組織（ SDO ）など — からの広範な見解 ］を反映するべきである。 `位置付け$ `現役$i は、［ 弱い／破られた（ `broken^en ）／試験的である ］ことが既知な~algoには，相応でない。 登録~要請が，そのような~algoを `現役$i として登録しようと試みた場合、 指名された専門家（たち）は，代替な`位置付け$ — `非推奨d$i か `暫定的$i — を示唆するべきである。 ◎ When reviewing registration requests, the designated expert(s) should pay attention to the requested status. The status value should reflect standardization status and the broad opinion of relevant interest groups such as the IETF or security-related Standards Development Organizations (SDOs). The "Active" status is not suitable for an algorithm that is known to be weak, broken, or experimental. If a registration request attempts to register such an algorithm as "Active", the designated expert(s) should suggest an alternative status of "Deprecated" or "Provisional".
指名された専門家（たち）は， 登録~要請を考査する際には、 却下の~~根拠として，`位置付け$［ `非推奨d$i ／ `暫定的$i ］を利用できない。 ◎ When reviewing registration requests, the designated expert(s) cannot use a status of "Deprecated" or "Provisional" as grounds for rejection.
既存の登録~内の~fieldを［ 更新する／変更する ］要請は許可される。 例えば、 ~algoの`位置付け$を［ ~security環境が発展するに伴い， `現役$i から `非推奨d$i へ移行tする ］ことも許容され得る。 ◎ Requests to update or change the fields in an existing registration are permitted. For example, this could allow for the transition of an algorithm status from "Active" to "Deprecated" as the security environment evolves.
6. ~securityの考慮点
6.1. ~HTTP~messageは全部的には保護されない
この文書は、 ある~data完全性の仕組みを指定する。 それは、 ~HTTP［ `表現~data$／`内容$ ］を保護するが，~HTTP［ ~headerや~trailer ］を ある種の破損から保護するものではない。 ◎ This document specifies a data integrity mechanism that protects HTTP representation data or content, but not HTTP header and trailer fields, from certain kinds of corruption.
`完全性~field$には、［ ~HTTP~messageに対する悪意的な改ざんに抗する一般的な保護 ］は意図されない。 追加的な~securityの仕組みが無い下では、 経路上の悪意的な動作者は，~digest値を除去し得る, あるいは~digest値を［ 操作される［ `表現~data$／`内容$ ］に対し算出された新たな~digest ］で代用し得る。 この攻撃は、 この文書にて述べた仕組みを他の~approach — ~TLS `TLS$r や~digital署名（例えば `~HTTP~message署名^cite `SIGNATURES$r ）など — と組合せることにより，軽減できる。 ◎ Integrity fields are not intended to be a general protection against malicious tampering with HTTP messages. In the absence of additional security mechanisms, an on-path malicious actor can either remove a digest value entirely or substitute it with a new digest value computed over manipulated representation data or content. This attack can be mitigated by combining mechanisms described in this document with other approaches such as Transport Layer Security (TLS) or digital signatures (for example, HTTP Message Signatures [SIGNATURES]).
6.2. 端点間の完全性
`完全性~field$は［ 実装~error／ 欲されない`形式変換ng~proxy$ `HTTP$r ／ ~dataが いくつかの［ 中継点／~system境界 ］を通過するときに伴われる他の動作 ］に因る`表現~metadata$の改変を検出する助けになり得る。 ［ `端点間$における［ `表現~data$／`内容$ ］の完全性 ］用の単純な仕組みであっても，価値はある — ~UAは、［ ~HTML構文解析器や動画~再生器, 等々 ］に構文解析~用に手渡す前に，資源の検索取得に成功したことを検証できるので。 ◎ Integrity fields can help detect representation data or content modification due to implementation errors, undesired "transforming proxies" (see Section 7.7 of [HTTP]), or other actions as the data passes across multiple hops or system boundaries. Even a simple mechanism for end-to-end representation data integrity is valuable because a user agent can validate that resource retrieval succeeded before handing off to an HTML parser, video player, etc., for parsing.
これらの仕組みだけを利用しても，`端点間$における~HTTP~message【全体】の完全性は — 中継点を経ている場合には — 供さないことに注意 — その~metadataは、 どの段階でも操作され得るので。 ~metadataを保護する手法は、 `6.3§ にて論じられる。 ◎ Note that using these mechanisms alone does not provide end-to-end integrity of HTTP messages over multiple hops since metadata could be manipulated at any stage. Methods to protect metadata are discussed in Section 6.3.
6.3. 署名における用法
~digital署名は、 ある種の［ ~messageの出自を識別するもの ］を供するためとして， ~checksumと一緒に広く利用される `FIPS186-5$r 。 そのような署名は、 1 個以上の`~field$を保護し得る — それらに`完全性~field$も含まれるときには、 追加的な考慮点がある。 ◎ Digital signatures are widely used together with checksums to provide the certain identification of the origin of a message [FIPS186-5]. Such signatures can protect one or more HTTP fields and there are additional considerations when Integrity fields are included in this set.
`完全性~field$と伴に利用できる~digital署名の［ 型／形式 ］に設置される制約は無い。 アリな~approachの一つは、 それらを `~HTTP~message署名^cite `SIGNATURES$r と組合せることである。 ◎ There are no restrictions placed on the type or format of digital signature that Integrity fields can be used with. One possible approach is to combine them with HTTP Message Signatures [SIGNATURES].
~digestは、 `表現~metadata$ （例：`Content-Type$h, `Content-Encoding$h, 等々の値） に明示的に依存する。 `完全性~field$は保護しつつ他の`表現~metadata$は保護しない署名は、 当の通信を改ざんに晒し得る。 例えば，ある動作者は、 `Content-Type$h `~field値$を操作して， `受信者$における~digest検証を失敗に至らすこともでき、 当の応用が`表現$へ~accessするのを防止する。 そのような攻撃は、 両~端点の資源を消費する。 `3.2§ も見よ。 ◎ Digests explicitly depend on the "representation metadata" (e.g., the values of Content-Type, Content-Encoding, etc.). A signature that protects Integrity fields but not other "representation metadata" can expose the communication to tampering. For example, an actor could manipulate the Content-Type field-value and cause a digest validation failure at the recipient, preventing the application from accessing the representation. Such an attack consumes the resources of both endpoints. See also Section 3.2.
署名は、 `完全性~field$を適用するときに，敵対者に~~晒される見込みが高いと判断される — `5§ を見よ。 `Repr-Digest$h は、 署名と組合されたときに，興味深いアリ性を提供する。 送信する`内容$が無い局面では， 当の~message内に空~文字列の~digestを内包でき、 署名された場合は，受信者が［ 内容が何らかの［ 事故，あるいは目的をもった操作 ］による結果として追加されたか否か ］を検出する助けになり得る。 反対の局面も~supportされる — 内容~用の`完全性~field$を内包して，それを署名すれば、 受信者が［ 当の内容が，どこで除去されたか ］を検出する助けになり得る。 ◎ Signatures are likely to be deemed an adversarial setting when applying Integrity fields; see Section 5. Repr-Digest offers an interesting possibility when combined with signatures. In the scenario where there is no content to send, the digest of an empty string can be included in the message and, if signed, can help the recipient detect if content was added either as a result of accident or purposeful manipulation. The opposite scenario is also supported; including an Integrity field for content and signing it can help a recipient detect where the content was removed.
`完全性~field$を弄ることは、 署名の検証に影響するかもしれない — 例えば、 ~digestを与える`~field行l値$たちに対し，［ 重複なものを除去する／ それらを`結合-$する ］など （ `HTTP$r `~field行lと結合-済みな~field値＠~HTTPinfra#field.lines§を見よ）。 ◎ Any mangling of Integrity fields might affect signature validation. Examples of such mangling include de-duplicating digests or combining different field values (see Section 5.2 of [HTTP]).
6.4. ~trailerにおける用法
`送信者$は、 `~trailer節$内に`完全性~field$を送信する前に，次について考慮するべきである ⇒ `中継者$には、 どの`~trailer$も落とすことが明示的に許容されている （ `HTTP$r `~trailerの処理＠~HTTPinfra#trailers.processing§を見よ）。 ◎ Before sending Integrity fields in a trailer section, the sender should consider that intermediaries are explicitly allowed to drop any trailer (see Section 6.5.2 of [HTTP]).
`完全性~field$が`~trailer節$内で利用される場合、 その`~field値$は，`内容$より後に受信される。 `~trailer節$より前に内容の処理を急ぐと，~digestは検証できなくなり、 場合によっては，無効な~dataの処理に至らせ得る。 ◎ When Integrity fields are used in a trailer section, the field-values are received after the content. Eager processing of content before the trailer section prevents digest validation, possibly leading to processing of invalid data.
`完全性~field$を`~trailer節$内で利用することには、 ~byte列を送信するたびに，その~hashingを許容する便益がある。 しかしながら、 `~hashing~algo$は，［ この便益を否定する仕方で内容を処理すること ］を要求するよう設計することもアリである。 例えば， `MICE$r は、 内容を逆順に処理するよう要求する。 すなわち，完全な~dataが予め可用になる必要があり、 `完全性~field$を［ `~header節$内, `~trailer節$内 ］どちらで送信しても，その処理にたいした相違は無いことを意味する。 ◎ One of the benefits of using Integrity fields in a trailer section is that it allows hashing of bytes as they are sent. However, it is possible to design a hashing algorithm that requires processing of content in such a way that would negate these benefits. For example, Merkle Integrity Content Encoding [MICE] requires content to be processed in reverse order. This means the complete data needs to be available, which means there is negligible processing difference in sending an Integrity field in a header versus a trailer section.
6.5. `Content-Encoding$h の中の多様性
`内容~符号法$の仕組みは、 様々な符号化~parameterを~supportし得る — すなわち、 同じ入力~内容から生産される出力は，~parameterに応じて異なり得る。 例えば、 ~GZIPは，複数の圧縮~levelを~supportする。 そのような符号化~parameterは、 一般に，`表現~metadata$としては通信されない。 一例として、 異なる圧縮~levelは，どれも 同じ "`Content-Encoding: gzip^c" ~fieldを利用することになろう。 他の例として、 ~nonceや時刻印に依拠する符号化法も挙げられる — `RFC8188$r にて定義される `aes128gcm^c `内容~符号法$など。 ◎ Content coding mechanisms can support different encoding parameters, meaning that the same input content can produce different outputs. For example, GZIP supports multiple compression levels. Such encoding parameters are generally not communicated as representation metadata. For instance, different compression levels would all use the same "Content-Encoding: gzip" field. Other examples include where encoding relies on nonces or timestamps, such as the aes128gcm content coding defined in [RFC8188].
同じ`内容~符号法$の中にも多様性があり得るので、 `完全性~field$により伝達される~checksumは， “残りの部分（ `at rest^en ）” 【？】における完全性の証明も供するためには利用し得ない — 当の`内容$が一体として持続されない限り。 ◎ Since it is possible for there to be variation within content coding, the checksum conveyed by the Integrity fields cannot be used to provide a proof of integrity "at rest" unless the whole content is persisted.
6.6. ~algo即応性
`~hashing~algo$の~securityの特質は、 固定的でない【時を経れば変化し得る】。 `~algo即応性^cite（ `algorithm agility^en, `RFC7696$r ）は、［ `~hashing~algo$を［ `~HTTP~digest~field用~hash~algo~registry$cite（ `7.2§ ） ］から選ぶ柔軟性 ］を備える実装を供することにより達成される。 ◎ The security properties of hashing algorithms are not fixed. Algorithm agility (see [RFC7696]) is achieved by providing implementations with flexibility to choose hashing algorithms from the IANA Hash Algorithms for HTTP Digest Fields registry; see Section 7.2.
弱い~algoからの移行tは、［ `~hashing~algo$を［ `Want-Content-Digest$h ／ `Want-Repr-Digest$h ］を利用して折衝する／ 複数個の~digestを送信して，その中から`受信者$【！receiver】に選んでもらう ］ことにより~supportされる。 とは言え，資源を消費して複数個の値を送信しても、 `受信者$【！receiver】から無視された場合には，浪費されることになる （ `3§ を見よ）。 ~security用に~digestに依存する`受信者$【！receiver】は、［ 自身が受容する用意がある~algoのうち最も弱いもの ］に対する攻撃に対し脆弱になる。 ◎ Transition from weak algorithms is supported by negotiation of hashing algorithm using Want-Content-Digest or Want-Repr-Digest (see Section 4) or by sending multiple digests from which the receiver chooses. A receiver that depends on a digest for security will be vulnerable to attacks on the weakest algorithm it is willing to accept. Endpoints are advised that sending multiple values consumes resources that may be wasted if the receiver ignores them (see Section 3).
~algo即応性は、 より強い~algoへの移行を許容する一方で，より弱い~algoの利用を防止しない。 `完全性~field$は、 `~hashing~algo$の［ 降格~攻撃／代用~攻撃 ］（`6211/1$rfc を見よ）に対しては，いかなる軽減策も供さない。 端点は、［ そのような攻撃に抗して保護する ］ためとして，［ 自身が~supportする~algoたちが成す集合を より強いものに制約する／ ~TLSや~digital署名を利用することにより~fieldの値を保護する ］こともできる。 ◎ While algorithm agility allows the migration to stronger algorithms, it does not prevent the use of weaker algorithms. Integrity fields do not provide any mitigations for downgrade or substitution attacks (see Section 1 of [RFC6211]) of the hashing algorithm. To protect against such attacks, endpoints could restrict their set of supported algorithms to stronger ones and protect the fields' values by using TLS and/or digital signatures.
6.7. 資源の枯渇
`完全性~field$の検証は、計算l資源を消費する。 実装は、 資源の枯渇を避けるためとして，［ ~algoの種別, 検証の回数, `内容$の~size ］の検証を制約できる。 これらの事例では、 より選好される~algoの［ 検証をまるごと飛ばす／ 検証における失敗を無視する ］と，降格~攻撃のアリ性を残すことになる （ `6.6§ を見よ）。 ◎ Integrity field validation consumes computational resources. In order to avoid resource exhaustion, implementations can restrict validation of the algorithm types, the number of validations, or the size of content. In these cases, skipping validation entirely or ignoring validation failure of a more-preferred algorithm leaves the possibility of a downgrade attack (see Section 6.6).
7. ~IANA考慮点
7.1. ~HTTP~field名の登録
~IANAは、 `~HTTP~field名~registry＠~IANA-a/http-fields$cite `HTTP$r を更新した — 次の表tに示されるとおり： ◎ IANA has updated the "Hypertext Transfer Protocol (HTTP) Field Name Registry" [HTTP] as shown in the table below:
| `~field名$ | 位置付け | 参照 |
|---|---|---|
| `Content-Digest$h | `恒久的^i | RFC 9530 `2§ |
| `Repr-Digest$h | `恒久的^i | RFC 9530 `3§ |
| `Want-Content-Digest$h | `恒久的^i | RFC 9530 `4§ |
| `Want-Repr-Digest$h | `恒久的^i | RFC 9530 `4§ |
| `Digest$h | `廃用d^i | `RFC3230$r, RFC 9530 `1.3§ |
| `Want-Digest$h | `廃用d^i | `RFC3230$r, RFC 9530 `1.3§ |
7.2. ~HTTP~digest~field用~hash~algo~registryの作成
~IANAは、 新たな `~HTTP~digest~field用~hash~algo~registry$cite を作成して，それを `次の表t＠#iana-hash-algorithm-table$内の~entryで拡充した。 新たな登録~用の手続-は、 `5§にて供される。 ◎ IANA has created the new "Hash Algorithms for HTTP Digest Fields" registry at <https://www.iana.org/assignments/http-digest-hash-alg/> and populated it with the entries in Table 2. The procedure for new registrations is provided in Section 5.
| `~algo~key$ | `位置付け$ | 記述 | 参照 |
|---|---|---|---|
| `sha-512@c | `現役$i | `SHA-512^i ~algo。 | `RFC6234$r, `RFC4648$r, RFC 9530 |
| `sha-256@c | `現役$i | `SHA-256^i ~algo。 | `RFC6234$r, `RFC4648$r, RFC 9530 |
| `md5@c | `非推奨d$i | `MD5^i ~algo。 これは、衝突~攻撃に脆弱である — `NO-MD5$r, `CMU-836068$r を見よ。 | `RFC1321$r, `RFC4648$r, RFC 9530 |
| `sha@c | `非推奨d$i | `SHA-1^i ~algo。 これは、衝突~攻撃に脆弱である — `NO-SHA$r, `IACR-2020-014$r を見よ | `RFC3174$r, `RFC4648$r, `RFC6234$r, RFC 9530 |
| `unixsum@c | `非推奨d$i | ~UNIX "sum" ~commandに利用される~algo。 | `RFC4648$r, `RFC6234$r, `UNIX$r, RFC 9530 |
| `unixcksum@c | `非推奨d$i | ~UNIX "cksum" ~commandに利用される~algo。 | `RFC4648$r, `RFC6234$r, `UNIX$r, RFC 9530 |
| `adler@c | `非推奨d$i | `ADLER32^i ~algo。 | `RFC1950$r, RFC 9530 |
| `crc32c@c | `非推奨d$i | `CRC32c^i ~algo。 | `RFC9260$r `A＠~RFCx/rfc9260.html#appendix-A§, RFC 9530 |
7.3. `~HTTP~digest~algo値~registry^cite を非推奨にする
~IANAは、
`~HTTP~digest~algo値~registry＠~IANA-a/http-dig-alg/$cite
を非推奨にして，その注記を次の~textに置換した
⇒
この~registryは非推奨にされた。
それは， `RFC3230$r にて定義された［
`Digest$h, `Want-Digest$h
］~fieldと伴に利用し得る~algoを~listするが、
それらの~fieldは， RFC 9530 により廃用にされたので。
登録は，まだ閉鎖されないが、
新たな登録は，代わりに
`~HTTP~digest~field用~hash~algo~registry$cite
を利用することが奨励される。
◎
IANA has deprecated the "Hypertext Transfer Protocol (HTTP) Digest Algorithm Values" registry at <https://www.iana.org/assignments/http-dig-alg/> and replaced the note on that registry with the following text:
• This registry is deprecated since it lists the algorithms that can be used with the Digest and Want-Digest fields defined in [RFC3230], which has been obsoleted by RFC 9530. While registration is not closed, new registrations are encouraged to use the Hash Algorithms for HTTP Digest Fields registry instead.
付録 A. 資源~表現と表現~data
この節において以下に挙げる例は、［ `表現~metadata$, `内容$の`形式変換$, `~method$ ］が~messageと`内容$にどう影響iするかを示す。 これらの例は、 網羅的ではない。 ◎ The following examples show how representation metadata, content transformations, and methods impact the message and content. These examples a not exhaustive.
他が指示されない限り、 以下に挙げる各~例は，［ ~JSON~obj `{"hello": "world"}^c と後続する 1 個の `LF$P ］に基づく。 以下において，`内容$が印字不能な文字を包含するときは （例：符号化されたとき）、 ~hexに符号化された~byte列として示される。 ◎ Unless otherwise indicated, the examples are based on the JSON object {"hello": "world"} followed by an LF. When the content contains non-printable characters (e.g., when it is encoded), it is shown as a sequence of hex-encoded bytes.
`~client$は、［ `PUT$m ~methodを利用して~JSON~objを~uploadする ］よう望んでいるとする。 `application/json^c を伴う `Content-Type$h を利用すれば、 `内容~符号法$を伴わずに，これを行える。 ◎ Consider a client that wishes to upload a JSON object using the PUT method. It could do this using the application/json Content-Type without any content coding.
PUT /entries/1234 HTTP/1.1
Host: foo.example
Content-Type: application/json
Content-Length: 19
{"hello": "world"}
しかしながら、 `内容~符号法$の利用は，かなり共通的にある。 ~clientは、 同じ~dataを `gzip$c 符号法 `HTTP$r【！§ 8.4.1.3】 で~uploadすることもできる。 この事例では、 当の符号法の~overheadに因り， `Content-Length$h が包含する値は大きくなることに注意。 ◎ However, the use of content coding is quite common. The client could also upload the same data with a GZIP coding (Section 8.4.1.3 of [HTTP]). Note that in this case, the Content-Length contains a larger value due to the coding overheads.
PUT /entries/1234 HTTP/1.1 Host: foo.example Content-Type: application/json Content-Encoding: gzip Content-Length: 39 1F 8B 08 00 88 41 37 64 00 FF AB 56 CA 48 CD C9 C9 57 B2 52 50 2A CF 2F CA 49 51 AA E5 02 00 D9 E4 31 E7 13 00 00 00
`gzip$c で有符号化された~dataを `Content-Encoding$h を介して指示することなく送信することは、 当の内容は不正形であることを意味する。 この事例では、 `~server$は~errorで返信できる。 ◎ Sending the GZIP-coded data without indicating it via Content-Encoding means that the content is malformed. In this case, the server can reply with an error.
PUT /entries/1234 HTTP/1.1 Host: foo.example Content-Type: application/json Content-Length: 39 1F 8B 08 00 88 41 37 64 00 FF AB 56 CA 48 CD C9 C9 57 B2 52 50 2A CF 2F CA 49 51 AA E5 02 00 D9 E4 31 E7 13 00 00 00
HTTP/1.1 400 Bad Request
`範囲~要請$は、 転送される`内容$に影響する。 次の例では、 `~client$は， `/entries/1234^c に在る`資源$ — ~JSON~obj `{"hello": "world"}^c と後続する 1 個の `LF$P — に~accessしているが、 選好される`内容~符号法$と特定の~byte範囲も指示した。 ◎ A Range-Request affects the transferred message content. In this example, the client is accessing the resource at /entries/1234, which is the JSON object {"hello": "world"} followed by an LF. However, the client has indicated a preferred content coding and a specific byte range.
GET /entries/1234 HTTP/1.1 Host: foo.example Accept-Encoding: gzip Range: bytes=1-7
対して`~server$は、 （`上の 2 個目の例＠#ex-put-gz$にて全体が表示された~JSON~objを成す最初の 10 ~byteに等価な） 部分的な表現で応答することにより， ~client要請を満足する。 ◎ The server satisfies the client request by responding with a partial representation (equivalent to the first 10 bytes of the JSON object displayed in whole in Figure 2).
HTTP/1.1 206 Partial Content Content-Encoding: gzip Content-Type: application/json Content-Range: bytes 0-9/39 1F 8B 08 00 A5 B4 BD 62 02 FF
［ `内容~符号法$／`範囲~要請$ ］は別として、 ~methodは，転送される`内容$に影響することもある。 例えば， `HEAD$m 要請に対する応答は`内容$を運ばないが、 この例の事例では， `Content-Length$h `HTTP$r【！§ 8.6】 を内包する。 ◎ Aside from content coding or range requests, the method can also affect the transferred message content. For example, the response to a HEAD request does not carry content, but this example case includes Content-Length; see Section 8.6 of [HTTP].
HEAD /entries/1234 HTTP/1.1 Host: foo.example Accept: application/json Accept-Encoding: gzip
HTTP/1.1 200 OK Content-Type: application/json Content-Encoding: gzip Content-Length: 39
応答の意味論は、 `~target~URI$を同封された表現から切り離すかもしれない。 次の例では、 `~client$は， `/authors/^c へ~directされる `POST$m 要請を発行するが、 対する応答は `Content-Location$h ~headerを内包していて，［ 同封された表現は、 `/authors/123^c にて可用な資源を指す ］ことを指示する。 この例では、 `Content-Length$h は送信されないことに注意。 ◎ Finally, the semantics of a response might decouple the target URI from the enclosed representation. In the example below, the client issues a POST request directed to /authors/, but the response includes a Content-Location header field indicating that the enclosed representation refers to the resource available at /authors/123. Note that Content-Length is not sent in this example.
POST /authors/ HTTP/1.1
Host: foo.example
Accept: application/json
Content-Type: application/json
{"author": "Camilleri"}
HTTP/1.1 201 Created
Content-Type: application/json
Content-Location: /authors/123
Location: /authors/123
{"id": "123", "author": "Camilleri"}
付録 B. 請求されない~digestの例
以下に挙げる例は、 `~client$が［ `Want-Content-Digest$h ／ `Want-Repr-Digest$h ］を利用するよう請求しなかったときでも， `~server$が［ `Content-Digest$h ／ `Repr-Digest$h ］~fieldで応答するときのヤリトリをデモる。 ◎ The following examples demonstrate interactions where a server responds with a Content-Digest or Repr-Digest field even though the client did not solicit one using Want-Content-Digest or Want-Repr-Digest.
例のうちいくつかは、 `内容$に~JSON~objを内包する。 それらは、行l長さの~~都合により — 改行と字下げを伴って — 複数~行lで呈示される場合もある。 【一方で，~digest自体は、そのように整形されていない~dataから算出される。】 ◎ Some examples include JSON objects in the content. For presentation purposes, objects that fit completely within the line-length limits are presented on a single line using compact notation with no leading space. Objects that would exceed line-length limits are presented across multiple lines (one line per key-value pair) with two spaces of leading indentation.
この文書にて定義される~checksumの仕組みは、 `~MIME型$を問わないことに加え，特定の形式~用の正準-化~algoは供さない。 各~例は、【対象の~data内の】 ~spaceも含めて計算される。 ［ `Content-Digest$h, `Repr-Digest$h ］両~fieldを含む例もあるが、 これらは，独立に返され得る。 ◎ Checksum mechanisms defined in this document are media-type agnostic and do not provide canonicalization algorithms for specific formats. Examples are calculated inclusive of any space. While examples can include both fields, Content-Digest and Repr-Digest can be returned independently.
B.1. ~serverは全部的な表現~dataを返す例
この例では、 ~messageの`内容$は完全な`表現~data$を伝達する。 すなわち，応答~内の［ `Content-Digest$h, `Repr-Digest$h ］は、 どちらも［ ~JSON~obj `{"hello": "world"}^c と後続する 1 個の `LF$P ］から計算され，同じ値をとる。 ◎ In this example, the message content conveys complete representation data. This means that in the response, Content-Digest and Repr-Digest are both computed over the JSON object {"hello": "world"} followed by an LF; thus, they have the same value.
GET /items/123 HTTP/1.1 Host: foo.example
`~SBS-ST$
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 19
Content-Digest: \
sha-256=:RK/0qy18MlBSVnWgjwz6lZEWjP/lF5HF9bvEF8FabDg=:
Repr-Digest: \
sha-256=:RK/0qy18MlBSVnWgjwz6lZEWjP/lF5HF9bvEF8FabDg=:
{"hello": "world"}
B.2. ~serverは表現~dataを返さない例
この例では、 `HEAD$m 要請を利用して`資源$の~checksumを検索取得する。 ◎ In this example, a HEAD request is used to retrieve the checksum of a resource.
対する応答の `Content-Digest$h は、 空な`内容$に対し算出される。 `Repr-Digest$h は，［ ~JSON~obj `{"hello": "world"}^c と後続する 1 個の `LF$P ］から計算されるが、 応答の`内容$は無いので，当の~JSON~objは そこには示されない。 ◎ The response Content-Digest field-value is computed on empty content. Repr-Digest is calculated over the JSON object {"hello": "world"} followed by an LF, which is not shown because there is no content.
HEAD /items/123 HTTP/1.1 Host: foo.example
`~SBS-ST$ HTTP/1.1 200 OK Content-Type: application/json Content-Digest: \ sha-256=:47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=: Repr-Digest: \ sha-256=:RK/0qy18MlBSVnWgjwz6lZEWjP/lF5HF9bvEF8FabDg=:
B.3. ~serverは部分的な表現~dataを返す例
この例では、 `~client$は、`範囲~要請$を為す — 対して`~server$は、 部分的な内容で応答する。 ◎ In this example, the client makes a range request and the server responds with partial content.
GET /items/123 HTTP/1.1 Host: foo.example Range: bytes=10-18
`~SBS-ST$ HTTP/1.1 206 Partial Content Content-Type: application/json Content-Range: bytes 10-18/19 Content-Digest: \ sha-256=:jjcgBDWNAtbYUXI37CVG3gRuGOAjaaDRGpIUFsdyepQ=: Repr-Digest: \ sha-256=:RK/0qy18MlBSVnWgjwz6lZEWjP/lF5HF9bvEF8FabDg=: "world"}
上の応答~messageにおける［ `Content-Digest$h, `Repr-Digest$h ］は、 異なることに注意： ◎ In the response message above, note that the Repr-Digest and Content-Digests are different.＼
- `Repr-Digest$h の`~field値$は、［ ~JSON~obj全体 `{"hello": "world"}^c と後続する 1 個の `LF$P ］から計算される ⇒ `sha-256=:RK/0qy18MlBSVnWgjwz6lZEWjP/lF5HF9bvEF8FabDg=:^c ◎ The Repr-Digest field-value is calculated across the entire JSON object {"hello": "world"} followed by an LF, and the field appears as follows: ◎ NOTE: '\' line wrapping per RFC 8792 Repr-Digest: \ sha-256=:RK/0qy18MlBSVnWgjwz6lZEWjP/lF5HF9bvEF8FabDg=:
- 一方で， `Content-Digest$h の`~field値$は、［ 当の~messageの`内容$は、 `bytes 10-18^c 【 0 から数えて 10 番 から 18 番までの`~byte範囲$】 に拘束される ］ので，［ ~byte列 `"world"}^c と後続する 1 個の `LF$P ］から計算される ⇒ `sha-256=:jjcgBDWNAtbYUXI37CVG3gRuGOAjaaDRGpIUFsdyepQ=:^c ◎ However, since the message content is constrained to bytes 10-18, the Content-Digest field-value is calculated over the sequence "world"} followed by an LF, thus resulting in the following: ◎ NOTE: '\' line wrapping per RFC 8792 Content-Digest: \ sha-256=:jjcgBDWNAtbYUXI37CVG3gRuGOAjaaDRGpIUFsdyepQ=:
B.4. ~client, ~serverどちらも全部的な表現~dataを供する例
要請は、同封された表現から計算された `Repr-Digest$h `~field値$を包含する。 また，`~client$は、 当の要請に値 `br^c を伴う `Accept-Encoding$h ~headerを内包して， 自身が `Brotli^i 符号化法を~supportすることを広告する。 ◎ The request contains a Repr-Digest field-value calculated on the enclosed representation. It also includes an Accept-Encoding: br header field that advertises that the client supports Brotli encoding.
対する応答は、 値 `br^c を伴う `Content-Encoding$h ~headerを内包する — それは、`選定された表現$は `Brotli^i に符号化されたことを指示する。 したがって `Repr-Digest$h `~field値$は，要請のそれとは異なる。 ◎ The response includes a Content-Encoding: br that indicates the selected representation is Brotli-encoded. The Repr-Digest field-value is therefore different compared to the request.
応答の`内容$は、 印字不能な文字を包含するので， 呈示~目的においては ~hexに符号化された~byte列として表示される。 ◎ For presentation purposes, the response body is displayed as a sequence of hex-encoded bytes because it contains non-printable characters.
`~SBS-ST$
PUT /items/123 HTTP/1.1
Host: foo.example
Content-Type: application/json
Accept-Encoding: br
Repr-Digest: \
sha-256=:RK/0qy18MlBSVnWgjwz6lZEWjP/lF5HF9bvEF8FabDg=:
{"hello": "world"}
`~SBS-ST$ HTTP/1.1 200 OK Content-Type: application/json Content-Location: /items/123 Content-Encoding: br Content-Length: 23 Repr-Digest: \ sha-256=:d435Qo+nKZ+gLcUHn7GQtQ72hiBVAgqoLsZnZPiTGPk=: 8B 08 80 7B 22 68 65 6C 6C 6F 22 3A 20 22 77 6F 72 6C 64 22 7D 0A 03
B.5. ~clientは全部的な表現~dataを供する, ~serverは表現~dataを供さない例
要請の `Repr-Digest$h `~field値$は、 同封された`内容$ — ~JSON~obj `{"hello": "world"}^c と後続する 1 個の `LF$P — から計算される。 ◎ The request Repr-Digest field-value is calculated on the enclosed content, which is the JSON object {"hello": "world"} followed by an LF.
対する応答の `Repr-Digest$h `~field値$は、 応答が`内容$を包含しないときでも，`表現~header$【！表現~metadata~header】に依存する — この例では、［ 値 `br^c を伴う `Content-Encoding$h ~header ］もそれに含まれる。 ◎ The response Repr-Digest field-value depends on the representation metadata header fields, including Content-Encoding: br, even when the response does not contain content.
`~SBS-ST$
PUT /items/123 HTTP/1.1
Host: foo.example
Content-Type: application/json
Content-Length: 19
Accept-Encoding: br
Repr-Digest: \
sha-256=:RK/0qy18MlBSVnWgjwz6lZEWjP/lF5HF9bvEF8FabDg==:
{"hello": "world"}
HTTP/1.1 204 No Content Content-Type: application/json Content-Encoding: br Repr-Digest: sha-256=:d435Qo+nKZ+gLcUHn7GQtQ72hiBVAgqoLsZnZPiTGPk=:
B.6. ~client, ~serverどちらも全部的な表現~dataを供する例
応答は、 異なる~algoを利用して， 2 個の~digest値を包含する： ◎ The response contains two digest values using different algorithms.
応答の`内容$は、 印字不能な文字を包含するので， 呈示~目的においては ~hexに符号化された~byte列として表示される。 ◎ For presentation purposes, the response body is displayed as a sequence of hex-encoded bytes because it contains non-printable characters.
`~SBS-ST$
PUT /items/123 HTTP/1.1
Host: foo.example
Content-Type: application/json
Accept-Encoding: br
Repr-Digest: \
sha-256=:RK/0qy18MlBSVnWgjwz6lZEWjP/lF5HF9bvEF8FabDg==:
{"hello": "world"}
`~SBS-ST$ HTTP/1.1 200 OK Content-Type: application/json Content-Encoding: br Content-Location: /items/123 Repr-Digest: \ sha-256=:d435Qo+nKZ+gLcUHn7GQtQ72hiBVAgqoLsZnZPiTGPk=:,\ sha-512=:db7fdBbgZMgX1Wb2MjA8zZj+rSNgfmDCEEXM8qLWfpfoNY0sCpHAzZbj\ 09X1/7HAb7Od5Qfto4QpuBsFbUO3dQ==: 8B 08 80 7B 22 68 65 6C 6C 6F 22 3A 20 22 77 6F 72 6C 64 22 7D 0A 03
B.7. `POST^m に対する応答は要請~URIを参照しない例
要請の `Repr-Digest$h `~field値$は、 同封された表現 — ~JSON~obj `{"title": "New Title"}^c と後続する 1 個の `LF$P — から算出される （ `3.1§ を見よ）。 ◎ The request Repr-Digest field-value is computed on the enclosed representation (see Section 3.1), which is the JSON object {"title": "New Title"} followed by an LF.
応答~内に同封された表現は、 複数行からなる~JSON~objと後続する 1 個の `LF$P であり， `Content-Location$h により識別される`資源$を指す （ `HTTP$r `内容の識別-法＠~HTTPinfra#identifying.content§を見よ）。 したがって，応用は、 `Repr-Digest$h を［ `Content-Location$h により参照された`資源$ ］に結付けるよう利用できる。 ◎ The representation enclosed in the response is a multiline JSON object followed by an LF. It refers to the resource identified by Content-Location (see Section 6.4.2 of [HTTP]); thus, an application can use Repr-Digest in association with the resource referenced by Content-Location.
POST /books HTTP/1.1
Host: foo.example
Content-Type: application/json
Accept: application/json
Accept-Encoding: identity
Repr-Digest: sha-256=:mEkdbO7Srd9LIOegftO0aBX+VPTVz7/CSHes2Z27gc4=:
{"title": "New Title"}
HTTP/1.1 201 Created
Content-Type: application/json
Content-Location: /books/123
Location: /books/123
Repr-Digest: sha-256=:uVSlinTTdQUwm2On4k8TJUikGN1bf/Ds8WPX4oe0h9I=:
{
"id": "123",
"title": "New Title"
}
B.8. `POST^m に対する応答は要請の状態sを述べる例
要請の `Repr-Digest$h `~field値$は、 同封された表現 — ~JSON~obj `{"title": "New Title"}^c と後続する 1 個の `LF$P — から算出される （ `3.1§ を見よ）。 ◎ The request Repr-Digest field-value is computed on the enclosed representation (see Section 3.1), which is the JSON object {"title": "New Title"} followed by an LF.
対する応答~内に同封された`表現$は、 要請の状態sを述べるので、 `Repr-Digest$h は，その同封された表現 — 複数行からなる~JSON~objと後続する 1 個の `LF$P — から算出される。 ◎ The representation enclosed in the response describes the status of the request, so Repr-Digest is computed on that enclosed representation. It is a multiline JSON object followed by an LF.
応答の `Repr-Digest$h には、 `Location$h により参照された`資源$との明示的な関係は無い。 ◎ Response Repr-Digest has no explicit relation with the resource referenced by Location.
POST /books HTTP/1.1
Host: foo.example
Content-Type: application/json
Accept: application/json
Accept-Encoding: identity
Repr-Digest: sha-256=:mEkdbO7Srd9LIOegftO0aBX+VPTVz7/CSHes2Z27gc4=:
{"title": "New Title"}
HTTP/1.1 201 Created
Content-Type: application/json
Repr-Digest: sha-256=:yXIGDTN5VrfoyisKlXgRKUHHMs35SNtyC3szSz1dbO8=:
Location: /books/123
{
"status": "created",
"id": "123",
"ts": 1569327729,
"instance": "/books/123"
}
B.9. `PATCH^m を伴う~digest
この事例は、 `~target資源$が`~target~URI$を反映する所では， `POST$m 要請に相似的である。 ◎ This case is analogous to a POST request where the target resource reflects the target URI.
`PATCH$m 要請は、 `RFC7396$r にて定義される`~MIME型$ `application/merge-patch+json^c を利用する。 要請の`内容$が，当の~patch文書に対応する。 `Repr-Digest$h は、 その内容 — ~JSON~obj `{"title": "New Title"}^c と後続する 1 個の `LF$P — から計算される。 ◎ The PATCH request uses the application/merge-patch+json media type defined in [RFC7396]. Repr-Digest is calculated on the content that corresponds to the patch document and is the JSON object {"title": "New Title"} followed by an LF.
対する応答の `Repr-Digest$h `~field値$は、 ~patchされた`資源$の完全な表現 — 複数行からなる~JSON~objと後続する 1 個の `LF$P — から算出される。 ◎ The response Repr-Digest field-value is computed on the complete representation of the patched resource. It is a multiline JSON object followed by an LF.
PATCH /books/123 HTTP/1.1
Host: foo.example
Content-Type: application/merge-patch+json
Accept: application/json
Accept-Encoding: identity
Repr-Digest: sha-256=:mEkdbO7Srd9LIOegftO0aBX+VPTVz7/CSHes2Z27gc4=:
{"title": "New Title"}
HTTP/1.1 200 OK
Content-Type: application/json
Repr-Digest: sha-256=:uVSlinTTdQUwm2On4k8TJUikGN1bf/Ds8WPX4oe0h9I=:
{
"id": "123",
"title": "New Title"
}
`内容$を伴わない `204$st 応答であったとしても、 同じ `Repr-Digest$h `~field値$を伴うなら合法的になることに注意。 その事例では、 `Content-Digest$h は，空な`内容$に対し算出した結果になろう。 ◎ Note that a 204 No Content response without content, but with the same Repr-Digest field-value, would have been legitimate too. In that case, Content-Digest would have been computed on an empty content.
B.10. ~error応答
~error応答【 `4xx$st ／ `5xx$st 】においては、 `表現~data$は`~target資源$を指すとは限らない。 代わりに，~errorの表現を指す。 ◎ In error responses, the representation data does not necessarily refer to the target resource. Instead, it refers to the representation of the error.
以下の例では、`~client$は， `/books/123^c に所在する資源に~patchするために `§ B.9 の例＠#fig-patch$と同じ要請を送信する。 しかしながら，そこには資源は存在しなかったので、 `~server$は — `RFC9457$r に則って — ~errorを述べる`内容$を伴う `404$st0 応答を`生成-$する。 ◎ In the following example, a client sends the same request from Figure 26 to patch the resource located at /books/123. However, the resource does not exist and the server generates a 404 response with a body that describes the error in accordance with [RFC9457].
応答の `Repr-Digest$h `~field値$は、 この同封された表現 — 複数行からなる~JSON~objと後続する 1 個の `LF$P — から算出される。 ◎ The response Repr-Digest field-value is computed on this enclosed representation. It is a multiline JSON object followed by an LF.
HTTP/1.1 404 Not Found
Content-Type: application/problem+json
Repr-Digest: sha-256=:EXB0S2VF2H7ijkAVJkH1Sm0pBho0iDZcvVUHHXTTZSA=:
{
"title": "Not Found",
"detail": "Cannot PATCH a non-existent resource",
"status": 404
}
B.11. ~trailerと転送~符号法との利用
ここでは， `生成元~server$は `Repr-Digest$h を`~trailer$として送信するので、 内容を~streamしている間に~digest値を計算でき， したがって資源の消費を軽減する。 `Repr-Digest$h `~field値$は、 `B.1§ と同じになる — `Repr-Digest$h は、 `転送~符号法$の利用とは独立に設計されるので （ `3§ を見よ）。 ◎ An origin server sends Repr-Digest as trailer field, so it can calculate digest-value while streaming content and thus mitigate resource consumption. The Repr-Digest field-value is the same as in Appendix B.1 because Repr-Digest is designed to be independent of the use of one or more transfer codings (see Section 3).
以下において、 応答の`内容$における文字列 "`\r\n^c" は， `CRLF$P を表現する。 ◎ In the response content below, the string "\r\n" represents the CRLF bytes.
GET /items/123 HTTP/1.1 Host: foo.example
`~SBS-ST$
HTTP/1.1 200 OK
Content-Type: application/json
Transfer-Encoding: chunked
Trailer: Repr-Digest
8\r\n
{"hello"\r\n
8\r\n
: "world\r\n
3\r\n
"}\n\r\n
0\r\n
Repr-Digest: \
sha-256=:RK/0qy18MlBSVnWgjwz6lZEWjP/lF5HF9bvEF8FabDg==:\r\n
付録 C. `Want-Repr-Digest^h により請求される `Repr-Digest^h の例
以下に挙げる例は、 `~client$が `Want-Repr-Digest$h を利用して `Repr-Digest$h を請求するときのヤリトリをデモる。 `Content-Digest$h と `Want-Content-Digest$h の挙動は一致する。 ◎ The following examples demonstrate interactions where a client solicits a Repr-Digest using Want-Repr-Digest. The behavior of Content-Digest and Want-Content-Digest is identical.
例のうちいくつかは、 `内容$に~JSON~objを内包する。 それらは、行l長さの~~都合により — 改行と字下げを伴って — 複数~行lで呈示される場合もある。 【一方で，~digest自体は、そのように整形されていない~dataから算出される。】 ◎ Some examples include JSON objects in the content. For presentation purposes, objects that fit completely within the line-length limits are presented on a single line using compact notation with no leading space. Objects that would exceed line-length limits are presented across multiple lines (one line per key-value pair) with two spaces of leading indentation.
この文書にて述べられる~checksumの仕組みは、 `~MIME型$を問わないことに加え，特定の形式~用の正準-化~algoは供さない。 各~例は、 ~spaceも含めて計算される。 ◎ Checksum mechanisms described in this document are media-type agnostic and do not provide canonicalization algorithms for specific formats. Examples are calculated inclusive of any space.
C.1. ~serverは~clientが最も選好しない~algoを選定する例
`~client$は、 ~digestを要請することに加え "`sha$c" を選好する。 いずれにせよ、 `~server$は "`sha-256$c" で返信してもかまわない。 ◎ The client requests a digest and prefers "sha". The server is free to reply with "sha-256" anyway.
GET /items/123 HTTP/1.1 Host: foo.example Want-Repr-Digest: sha-256=3, sha=10
`~SBS-ST$
HTTP/1.1 200 OK
Content-Type: application/json
Repr-Digest: \
sha-256=:RK/0qy18MlBSVnWgjwz6lZEWjP/lF5HF9bvEF8FabDg==:
{"hello": "world"}
C.2. ~serverは~clientが~supportしない~algoを選定する例
`~client$は、 自身が唯一~supportする "`sha$c" ~digestを要請する。 `~server$は、 "`sha$c" ~digestを包含している応答を生産する~~義務はないので， 代わりに異なる~algoを利用する。 ◎ The client requests a "sha" digest because that is the only algorithm it supports. The server is not obliged to produce a response containing a "sha" digest; it instead uses a different algorithm.
GET /items/123 HTTP/1.1 Host: foo.example Want-Repr-Digest: sha=10
`~SBS-ST$
HTTP/1.1 200 OK
Content-Type: application/json
Repr-Digest: \
sha-512=:YMAam51Jz/jOATT6/zvHrLVgOYTGFy1d6GJiOHTohq4yP+pgk4vf2aCs\
yRZOtw8MjkM7iw7yZ/WkppmM44T3qg==:
{"hello": "world"}
C.3. ~serverは~client~algoを~supportしないので~errorを返す例
`C.2§ では、［ ~clientが選好した~digest~algo ］を~serverが無視する例を与えた。 別法として，`~server$は、 要請を却下して，［ `4xx$st0 ／ `5xx$st0 ］などの~error`状態s~code$を伴う応答を返すこともできる。 この仕様は、 状態s~codeの選定には何も要件を定めない — 以下の例は、 アリな~optionの一つを示す。 ◎ Appendix C.2 is an example where a server ignores the client's preferred digest algorithm. Alternatively, a server can also reject the request and return a response with an error status code such as 4xx or 5xx. This specification does not prescribe any requirement on status code selection; the following example illustrates one possible option.
この例では、 `~client$は， "`sha$c" `Repr-Digest$h を要請するが， `~server$は，問題の詳細 `RFC9457$r を伴う~errorを返す。 問題の詳細は、 ~errorの`内容$に包含され， ~serverが~supportする~hashing~algoたちが成す~listを包含する。 これは純粋に例であり、 そのような内容~用の形式や要件は，この仕様では定義されない。 ◎ In this example, the client requests a "sha" Repr-Digest, and the server returns an error with problem details [RFC9457] contained in the content. The problem details contain a list of the hashing algorithms that the server supports. This is purely an example; this specification does not define any format or requirements for such content.
GET /items/123 HTTP/1.1 Host: foo.example Want-Repr-Digest: sha=10
HTTP/1.1 400 Bad Request
Content-Type: application/problem+json
{
"title": "Bad Request",
"detail": "Supported hashing algorithms: sha-256, sha-512",
"status": 400
}
付録 D. 見本~digest値
この節は、 各種~hashing~algoによる~digest値の例を示す。 入力~値は、 ~JSON~obj `{"hello": "world"}^c である。 各~digest値は、［ 入力に対し，関連な~hashing~algoを走らせた結果の出力~byte列 ］を［ `STRUCTURED-FIELDS$r `§ ~sf~byte列の直列化-法＠~STRUCTURED-FIELDS#ser-binary$に従って直列化する ］ことにより生産される。 ◎ This section shows examples of digest values for different hashing algorithms. The input value is the JSON object {"hello": "world"}. The digest values are each produced by running the relevant hashing algorithm over the input and running the output bytes through Byte Sequence serialization; see Section 4.1.8 of [STRUCTURED-FIELDS].
`~SBS-ST$
sha-512 - :WZDPaVn/7XgHaAy8pmojAkGWoRx2UFChF41A2svX+TaPm+\
AbwAgBWnrIiYllu7BNNyealdVLvRwEmTHWXvJwew==:
sha-256 - :X48E9qOokqqrvdts8nOJRJN3OWDUoyWxBf7kbu9DBPE=:
md5 - :Sd/dVLAcvNLSq16eXua5uQ==:
sha - :07CavjDP4u3/TungoUHJO/Wzr4c=:
unixsum - :GQU=:
unixcksum - :7zsHAA==:
adler - :OZkGFw==:
crc32c - :Q3lHIA==:
付録 E. ~RFC 3230 からの移行-法
~HTTP~digestは、 入力~dataに~hashing~algoを適用することにより算出される。 `RFC3230$r は、 入力~dataを~~自前の用語 “~instance” として定義した。 ~instanceの概念は、 後に，~HTTPの意味論上の用語 “`表現$” に取代された。 “~instance” を`~message$の`内容$を意味すると誤解したのは、 `RFC3230$r の一部の実装と解されている。 `Digest$h ~fieldを`内容$に対し利用することは、 誤りであり， `RFC3230$r を実装する端点どうしを相互運用能の問題へ導く。 ◎ HTTP digests are computed by applying a hashing algorithm to input data. [RFC3230] defined the input data as an "instance", a term it also defined. The concept of an instance has since been superseded by the HTTP semantic term "representation". It is understood that some implementations of [RFC3230] mistook "instance" to mean HTTP content. Using content for the Digest field is an error that leads to interoperability problems between peers that implement [RFC3230].
`RFC3230$r は、［ ~HTTPが，今や`選定された表現~data$として定義するもの ］に限り利用することを意図していた。 ［ ~digest, 表現 ］の意味論上の概念は、 `3§ にて， `Repr-Digest^h の定義に伴って説明される。 ◎ [RFC3230] was only ever intended to use what HTTP now defines as selected representation data. The semantic concept of digest and representation are explained alongside the definition of the Repr-Digest field (Section 3).
`Digest$h と `Repr-Digest$h の構文は異なるが、 この文書が `Repr-Digest$h 用に与える考慮点と一連の例は， `Digest^h にも等しく適用される — それらは、 同じ入力~dataに対し演算するので。 `3.1§, `6§, `6.3§ を見よ。 ◎ While the syntax of Digest and Repr-Digest are different, the considerations and examples this document gives for Repr-Digest apply equally to Digest because they operate on the same input data; see Sections 3.1, 6 and 6.3.
`RFC3230$r は、 `Digest$h ~field内で`内容$の~digestも通信できるようにするものでは，決してない — その能力は、 今や `Content-Digest$h が供する。 ◎ [RFC3230] could never communicate the digest of HTTP message content in the Digest field; Content-Digest now provides that capability.
`RFC3230$r は、 `Digest$h ~fieldと伴に利用するためとして， ~algoが出力~符号化~形式も定義することを許容していた。 その結果、［ ~base64, ~hex, ~decimal ］などの形式が混在していた。 ［ `Content-Digest$h ／ `Repr-Digest$h ］は、 `有構造~field$を利用することから，利用する符号化~形式は一つに限られる。 更なる説明と例は、 `D§ にて供される。 ◎ [RFC3230] allowed algorithms to define their output encoding format for use with the Digest field. This resulted in a mix of formats such as base64, hex, or decimal. By virtue of using Structured Fields, Content-Digest, and Repr-Digest use only a single encoding format. Further explanation and examples are provided in Appendix D.
謝辞
この文書は `RFC3230$r による案に基づく — その偉業を成された［ `Jeff Mogul^en, `Arthur Van Hoff^en ］両氏に謝意を。 `RFC3230$r を刷新する元の案は、 `MICE^i `内容~符号法$を考査したときに［ `Mark Nottingham^en, `Jeffrey Yasskin^en, `Martin Thomson^en ］各氏との興味深い論点から発生した。 ◎ This document is based on ideas from [RFC3230], so thanks to Jeff Mogul and Arthur Van Hoff for their great work. The original idea of refreshing [RFC3230] arose from an interesting discussion with Mark Nottingham, Jeffrey Yasskin, and Martin Thomson when reviewing the MICE content coding.
この文書に価値ある貢献をなされた `Julian Reschke^en 氏に謝意を。 ［ ~bugを報告して／ 賢い質問をして／ ~textを草案~化あるいは考査して／ ~open課題を評価して ］この仕様の改善に助力された，次に挙げる貢献者たちにも ⇒ `Mike Bishop, Brian Campbell, Matthew Kerwin, James Manger, Tommy Pauly, Sean Turner, Justin Richer, and Erik Wilde^en ◎ Thanks to Julian Reschke for his valuable contributions to this document, and to the following contributors that have helped improve this specification by reporting bugs, asking smart questions, drafting or reviewing text, and evaluating open issues: Mike Bishop, Brian Campbell, Matthew Kerwin, James Manger, Tommy Pauly, Sean Turner, Justin Richer, and Erik Wilde.