webappsec-subresource-integrity-ja.html

<!DOCTYPE html><html lang="ja"><head><meta charset="utf-8">

<title>Subresource Integrity</title>
<link rel="stylesheet" href="common.css" type="text/css">
<link rel="stylesheet" href="common-w3c.css" type="text/css">

<style>

samp {
	white-space: nowrap;
	background: var(--bg-color-1);
	margin-left: 0.5em;
	margin-right: 0.5em;
}

.hash-func {
	font-family: sans-serif0, sans-serif;
}

</style>

<script src="common0.js" ></script>
<script src="common1.js" async></script>

<script>

Util.ready = function(){
	const source_data = {
		toc_main: 'MAIN0',
		generate: expand
	};
	Util.switchWordsInit(source_data);
}

function expand(){
	const class_map = this.class_map;
	const tag_map = this.tag_map;
	const link_map = this.link_map;

	return this.html.replace(
		/%[\w\-~一-鿆あ-ん]+|`(.*?)([$@^])(\w*)/g,
		create_html
	);

	function create_html(match, key, indicator, klass){

if(!indicator) {//%
	return `<var>${match.slice(1)}</var>`;
}

let href = '';
let href1 = '';
{
	const n = key.indexOf('＠');
	if(n > 0) {
		href1 = key.slice(n + 1);
		key = key.slice(0, n);
	}
}
let text = key;

switch(klass){
case 'r':
	text = `[${key}]`;
	href = `#biblio-${key.toLowerCase()}`;
	break;
case 'l':
	text = `"<code class="literal">${key}</code>"`;
	break;
case 'U':
	text = `U+${text}`;
	break;
case 'smb':
	text = `(<span class="char-symbol">${text}</span>)`;
	break;
case 'en':
	text = `<span lang="en">${key}</span>`;
	break;
}

let tag = tag_map[klass];
if(tag) {
	let classname = class_map[klass];
	classname = classname ? ` class="${classname}"` : '';
	text = `<${tag}${classname}>${text}</${tag}>`;
}

if(indicator !== '^'){
	href = href1 || link_map[ klass ? `${klass}.${key}` : key ] || href;
	if(!href){
		console.log(match); // check error
		return match;
	}

	switch(indicator){
	case '$':
		text = `<a href="${href}">${text}</a>`;
		break;
	case '@':
		text = `<dfn id="${href.slice(1)}">${text}</dfn>`;
		break;
	}
}

return text;

	}
}
</script>

<script type="text/plain" id="_source_data">


●●options

spec_date:2022-11-30
trans_update:2022-12-07
source_checked:210222
page_state_key:WEBAPPSEC
original_url:https://w3c.github.io/webappsec-subresource-integrity/
	abbr_url:SRI1
spec_status:ED
ref_id_prefix:biblio-
ref_id_lowercase:true
conformance:w3c
copyright:2022,permissive
trans_1st_pub:2016-06-22


●●class_map
P:production
h:header
e:element
a:attr
et:event-type
hS:hash-func
dir:directive
v:value
U:code-point
cn:cp-name

●●tag_map
p:var
P:code
h:code
e:code
a:code
et:code
m:code
dir:code
v:code
c:code
s:samp
hS:span
V:var
U:span
cn:span
em:em

●●words_table

bookmarklet:
command-line:command line::コマンド行::コマンドライン
	Document


	●network
CDN:
DNS:
TLS:
HSTS:
log-in::::ログイン
payload::::ペイロード
媒介:intermediate::~

低速:slow:~
優先度:priority:~
優先-:prioritize:~

	:loading
	経路上で:in-flight:

	●処理
	走っている:running

	%~option群を伴う~hash:hash-with-opt-token-list
	%~hash式:hash-expression
	%~base64値:base64-value
	%~hash式~token~list:hash-expr-token-list
	%期待される値:expectedValue
	%~metadata:metadata
	%~metadata~list:metadataList
	%~metadata文字列:metadata
	%新たな~algo:newAlgorithm
	%~algo:currentAlgorithm
	%~algo:algorithm
	%~token:token
	%~byte列:bytes
	%結果:result
	%構文解析した~metadata:parsedMetadata
	%実際の値:actualValue


	●保安
	CORS-enabled
	NIST
	Integrity
	SHA-1
	SHA-384
	SHA384
	MD5
pin:
base64:
username::::ユーザ名
digest::::ダイジェスト
hash::::ハッシュ
hashing::::ハッシュ
衝突:collision::~
衝突耐性:collision-resistant::~
推測-:guess:~
推定-:surmise:~
認証-:authenticate::~
警告:warning:~
注視-:watch:~
洞察:insight:~
	洞察を得る:gain some insight into
管理者:administrator::~
弱い:weakな::~
最強:strongest::~
弱体化-:compromise::~
弱体化:compromise::~
暗号上の:cryptographic::~
暗号用:cryptographic::~
汚染:poisoning::~
高特権:high-privilege::~
総当たり:brute-force::~
	総当たり:brute-forcing
式:expression:~
露呈-:reveal::~
騙せる:trickできる::~
	~secure化法:securing
	~secureでない:insecure
	~secureな文脈:Secure Context

	●仕様
utility::::ユーティリティ
切替えれ:switchでき:切り替えれ
即応性:agility:~
機敏:agile:~
	機敏に対応できる:provide agility
古い:older:~
拒否-:refuse:~
拡げる:expandする:~
枠組み:scheme:~
定期的:regular basis:~
煮詰める:boil downする:~
移行-:migrate::~
稀:rare:~
選択肢:option:~
直面-:face:~
誤り:error:~

	評価し直-:re-evaluate
	無論:of course:もちろん
	咎め無く:impunity
	対象にしている:meant to
	対象範囲 this coverage
	し続ける:stay aware
	多様な:wide variety of
	現時点では:at the moment
	縛られることなく:being held back by
	〜ない見込みが高い:unlikely:
	着想を得ている:heavily inspired
	無論:of course
	~~主要な:key
	~~判明した:show
	~~実際に:in fact

	●未分類
一重引用符:single quote::~
印字可能:printing:~
改ざん:alter:~
構成-:compose:~
確認-:confirm:~
解析:analytics:~
全世界の:globally-distributed:~
代用-:substitute::~
繰返し:repeatedly:繰り返し

	文法~上の:grammatical
	最終的:eventual
	New
	alg:
	良好な~~基準:good baseline
	basis
	broken
	とらえ:catch
	content-coding
	content-encoding

	encodedResult
	good
	hi
	in-order
	least
	line:
	moreover
	most
	note
	part
	per
	piece
	provided

	refer
	remain
	shown
	space
	src
	stay
	~~十分:sufficient
	surmise
	sync
	taint
	time
	uRI
	不幸な~~形に~unfortunate ways
	unsupported
	val
	wide
	自身が通話相手だと信じる~serverが~~本物である:indeed speaking with the server it believes it’s talking to
	~全体を通してthroughout:

	-:perhaps
	かなりの部分:much of
	ごく:quite
	ずっと:much
	たまたま:happen
	なり次第:begin
	広く:broadly
	予め算出-:precompute
	二次的な:secondary
	伝える:informする
	何でもできる:do absolutely anything else
	前:previous
	加えて:additionally
	し続ける:stays in
	壊れて:broken
	抗して:against
	指す:pointed~to
	指す:refer
	更には:moreover
	書-:write
	直前の:immediately precede
	相応の確証を得られる:fairly certain
	種々の／様々な:a variety of
	選ぶ:choose
	ことごとく:every


●●original_id_map


●●words_table1


RFC6454:RFC6454-ja.html
CSP2:CSP-ja.html
	HTML50:https://www.w3.org/TR/html5


●●link_map

P.integrity-metadata:#grammardef-integrity-metadata
P.hash-with-options:#grammardef-hash-with-options
P.option-expression:#grammardef-option-expression
P.hash-expression:#grammardef-hash-expression
P.hash-source:~CSP3#grammardef-hash-source
	P.hash-source:#grammardef-hash-source
	P.hash-source:~CSP2#hash_source
P.hash-algo:#grammardef-hash-algo
	P.hash-algo:~CSP3#grammardef-hash-algorithm
	P.hash-algo:~CSP2#hash_algo
P.base64-value:#grammardef-base64-value
	P.base64-value:~CSP2#base64_value
	P.base64-value:~CSP3#grammardef-base64-value

P.VCHAR:~RFCx/rfc5234#appendix-B.1
P.WSP:~RFCx/rfc5234#appendix-B.1

h.Cache-Control:~HTTPcache#field.cache-control
dir.no-transform:~HTTPcache#cache-response-directive.no-transform

a.integrity:#the-integrity-attribute

e.script:~HEscripting#the-script-element
e.link:~HEmetadata#the-link-element

et.error:~HTMLindex#event-error

hS.SHA-256:#dfn-sha-2
hS.SHA-384:#dfn-sha-2
hS.SHA-512:#dfn-sha-2
hS.SHA-2:#dfn-sha-2

	●用語
~digest:#digest
V.…( ~digest )…:#digest

完全性~metadata:#integrity-metadata
iM.~algo:#_integrity-metadata-hash-algo
iM.値:#_integrity-metadata-digest
iM.~option群:#_integrity-metadata-options
	alg/val/opt

~base64符号化法:#base64-encoding
より優先される~hash関数を取得する:#getprioritizedhashfunction
~byte列に~algoを適用する:#apply-algorithm-to-response
最も強い~metadataを取得する:#get-the-strongest-metadata
~metadata~listを構文解析する:#parse-metadata
~byte列は~metadata~listに合致するか？:#does-response-match-metadatalist

	●用語（外部
§ ~source~list:~CSP3#framework-directive-source-list
	§ ~source~listの構文:~CSP#source-list-syntax

enV.~secureな文脈:~WAPI#secure-context
~secureな文脈:~SECURE-CONTEXT#secure-contexts

	pinned public keys:~RFCx/rfc7469
	要請:~FETCH#concept-request
	rq.完全性~metadata
	要請の一部:~FETCH#concept-request-integrity-metadata
	:http://www.w3.org/Security/wiki/Same_Origin_Policy
	:~CSP2#source-list-syntax

区切子で厳密に分割する:~INFRA#strictly-split
~byte列:~INFRA#byte-sequence

~list:~INFRA#list
~size:~INFRA#list-size
空:~INFRA#list-is-empty
付加する:~INFRA#list-append

~CORS設定群~属性:~HTMLurl#cors-settings-attributes
	~HTML50/infrastructure.html#cors-settings-attributes


	:https://www.eff.org/https-everywhere
	:http://www.gerv.net/security/link-fingerprints/
	:https://wiki.whatwg.org/wiki/Link_Hashes
	:https://www.openssl.org/
	SHA-XXX:http://csrc.nist.gov/publications/fips/fips180-4/fips-180-4.pdf#
	Common parser idioms:~HTML50/infrastructure.html#space-character
	:https://www.rfc-editor.org/rfc/rfc4648#section-4
	:http://www.w3.org/2001/tag/doc/web-https
	~ORIGIN#concept-origin
	要請:~FETCH#concept-request
	~ORIGIN#same-origin
	:~CSP2#source-list-syntax


●●ref_normative

[ABNF]
    D. Crocker, Ed.; P. Overell. ＜Augmented BNF for Syntax Specifications: ABNF＞. January 2008. Internet Standard. URL: https://www.rfc-editor.org/rfc/rfc5234
[Fetch]
    Anne van Kesteren. ＜Fetch Standard＞. Living Standard. URL: https://fetch.spec.whatwg.org/
[HTML]
    Anne van Kesteren; et al. ＜HTML Standard＞. Living Standard. URL: https://html.spec.whatwg.org/multipage/
[HTML5]
    Ian Hickson; et al. ＜HTML5＞. URL: https://www.w3.org/html/wg/drafts/html/master/
[INFRA]
    Anne van Kesteren; Domenic Denicola. ＜Infra Standard＞. Living Standard. URL: https://infra.spec.whatwg.org/
[MIME-TYPES]
    N. Freed; N. Borenstein. ＜Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types＞. November 1996. Draft Standard. URL: https://www.rfc-editor.org/rfc/rfc2046
[RFC2119]
    S. Bradner. ＜Key words for use in RFCs to Indicate Requirement Levels＞. March 1997. Best Current Practice. URL: https://datatracker.ietf.org/doc/html/rfc2119
[RFC4648]
    S. Josefsson. ＜The Base16, Base32, and Base64 Data Encodings＞. October 2006. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc4648
[RFC7234]
    R. Fielding, Ed.; M. Nottingham, Ed.; J. Reschke, Ed.. ＜Hypertext Transfer Protocol (HTTP/1.1): Caching＞. June 2014. Proposed Standard. URL: https://httpwg.org/specs/rfc7234.html
[SECURE-CONTEXTS]
    Mike West; Yan Zhu. ＜Secure Contexts＞. WD. URL: https://w3c.github.io/webappsec-secure-contexts/
[SHA2]
    ＜FIPS PUB 180-4, Secure Hash Standard＞. URL: http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf

●●ref_informative

[RFC1035]
    P. Mockapetris. ＜Domain names - implementation and specification＞. November 1987. Internet Standard. URL: https://www.rfc-editor.org/rfc/rfc1035
[RFC6797]
    J. Hodges; C. Jackson; A. Barth. ＜HTTP Strict Transport Security (HSTS)＞. November 2012. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc6797
[RFC7469]
    C. Evans; C. Palmer; R. Sleevi. ＜Public Key Pinning Extension for HTTP＞. April 2015. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc7469
[TLS]
    E. Rescorla. ＜The Transport Layer Security (TLS) Protocol Version 1.3＞. August 2018. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc8446


●●trans_metadata
<p>
~THIS_PAGEは、~W3Cにより編集者草案として公開された
<a href="~SPEC_URL">Subresource Integrity</a>
を日本語に翻訳したものです。
~PUB
</p>


●●spec_metadata

最新公表バージョン
	https://www.w3.org/TR/SRI/
公表履歴
	https://www.w3.org/standards/history/SRI/
commit 履歴
	https://github.com/w3c/webappsec-subresource-integrity/commits/main
	https://github.com/w3c/webappsec-subresource-integrity/commits/gh-pages
フィードバック
	<a href="mailto:public-webappsec@w3.org?subject=%5BSRI%5D%20YOUR%20TOPIC%20HERE">public-webappsec@w3.org</a> with subject line “<kbd>[SRI] <i>… message topic …</i></kbd>” (<a href="https://lists.w3.org/Archives/Public/public-webappsec/" rel="discussion">archives</a>)
	<a href="https://github.com/w3c/webappsec-subresource-integrity/issues/">GitHub</a>

編集
	<a href="http://devd.me">Devdatta Akhawe</a> (Dropbox Inc.) <a href="mailto:dev.akhawe@gmail.com">dev.akhawe@gmail.com</a>
	<a href="https://frederik-braun.com">Frederik Braun</a> (Mozilla) <a href="mailto:fbraun@mozilla.com">fbraun@mozilla.com</a>
	<a href="https://fmarier.org">François Marier</a> (Mozilla) <a href="mailto:francois@mozilla.com">francois@mozilla.com</a>
	<a href="https://joelweinberger.us">Joel Weinberger</a> (Google Inc.) <a href="mailto:jww@google.com">jww@google.com</a>

実装ステータス
	<a href="https://code.google.com/p/chromium/issues/detail?id=355467">Blink/Chromium</a>
	<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=992096">Gecko</a>
実装報告
	https://github.com/w3c/webappsec-subresource-integrity/wiki/Links

公表者
	<a href="https://www.w3.org/groups/wg/webappsec">Web Application Security WG</a>

</script>

<body>

<header>
	<hgroup>
<h1>下位資源の完全性 — Subresource Integrity</h1>
	</hgroup>
</header>

<div id="MAIN" hidden>
	<section id="abstract">
◎要約

<p>
この仕様は、［
~fetchした資源は，期待されない操作により送達されていない
］ことを，~UAが検証yできるようにする仕組みを定義する。
◎
This specification defines a mechanism by which user agents may verify that a fetched resource has been delivered without unexpected manipulation.
</p>
	</section>
	<section id="sotd">
◎位置付け

<p>
これは、
編集者草案の公な複製です…
【以下、この節の内容は，~SOTD-W3Cに移譲。】
</p>

	</section>

<main id="MAIN0">

	<section id="introduction">
<h2 title="Introduction">1. 序論</h2>

◎非規範的

<p>
~web上の~siteや~appが，単独の生成元のみからの資源で構成されることは稀である。
例えば，作者は、
多様な［
~service／ ~CDN （ Content Delivery Network, “内容~送達~network” ）
］から，~scriptや~stylesheetを~pullする
— 作者は、
送達された表現が［
読込まれるものと自身が期待するものと，~~実際に~~相違ない
］ことを信用しなければナラナイ。
攻撃者が，敵対的~serverからの内容を~downloadするよう 利用者を騙せる場合（~DNS `RFC1035$r 汚染, その他の手段を介して）、
作者にできる手立てはない。
同様に、
~CDN~server上の~fileを置換できる攻撃者は，任意な内容を注入できる能を有する。
◎
Sites and applications on the web are rarely composed of resources from only a single origin. For example, authors pull scripts and styles from a wide variety of services and content delivery networks, and must trust that the delivered representation is, in fact, what they expected to load. If an attacker can trick a user into downloading content from a hostile server (via DNS [RFC1035] poisoning, or other such means), the author has no recourse. Likewise, an attacker who can replace the file on the Content Delivery Network (CDN) server has the ability to inject arbitrary content.
</p>

<p>
この~riskの一部は、
資源を~secure~channel
— ~TLS `TLS$r, ~HSTS `RFC6797$r, `pinned public keys^en `RFC7469$r —
越しに送達することで軽減される。
~UAは、
自身が通話相手と信じる~serverが~~本物であることについて，相応の~~確証を得られるので。
しかしながら，これらの仕組みが認証するのは、
`内容ではなく^em，`~serverに限られる^em。
~serverへの~accessを有する攻撃者（あるいは管理者）は、
咎め無く内容を操作できる。
理想は、
作者が~serverの~keyを~pin†できるのみならず，`内容^emについても資源~表現の~~同一性が確保されるよう~pinして，`そのような表現に限って^em読込んで実行できるようにすることである。
◎
Delivering resources over a secure channel mitigates some of this risk: with TLS [TLS], HSTS [RFC6797], and pinned public keys [RFC7469], a user agent can be fairly certain that it is indeed speaking with the server it believes it’s talking to. These mechanisms, however, authenticate only the server, not the content. An attacker (or administrator) with access to the server can manipulate content with impunity. Ideally, authors would not only be able to pin the keys of a server, but also pin the content, ensuring that an exact representation of a resource, and only that representation, loads and executes.
</p>

<p class="trans-note">【†
“~keyを~pinする”
— 相手（ ~server ）の身元を随時確認できるよう，その証明情報の “真正な写し” （ ~key ）を手元（ ~UA側）に “ピン留め” しておく。
（したがって、
最初に “写し” を得る段階で，その真正性が確保される必要がある。）
】</p>

<p>
この文書は、
そのような検証の枠組みを指定する。
また、
2 個の~HTML要素
— `script$e, `link$e —
を `integrity$a 属性で拡張する。
この属性は、
作者が読込むものと期待する資源の表現に対する，暗号用~hashを包含する。
一例として、
作者は［
ある~frameworkを，自前の生成元では~hostせずに 共用~serverから読込みたい
］と望んでいるとする。
`https://example.com/example-framework.js^s
に`期待される^em `SHA-384$hS ~hashとして`~digest$
`Li9vy3DqF8tnTXuiaAJuML3ky+er10rcgNR/VqsVpcw+ThHmYcwiB1pbOxEbzJr7^s
を指定することは、
~UAが、
その~URLから読込む~dataが包含している~JSを実行する前に，~dataが期待されている~hashに合致するかどうか検証yできることを意味する。
この完全性~検証yは、
攻撃者により資源が悪意的な内容で代用される~riskを，有意に抑制する。
◎
This document specifies such a validation scheme, extending two HTML elements with an integrity attribute that contains a cryptographic hash of the representation of the resource the author expects to load. For instance, an author may wish to load some framework from a shared server rather than hosting it on their own origin. Specifying that the expected SHA-384 hash of https://example.com/example-framework.js is Li9vy3DqF8tnTXuiaAJuML3ky+er10rcgNR/VqsVpcw+ThHmYcwiB1pbOxEbzJr7 means that the user agent can verify that the data it loads from that URL matches that expected hash before executing the JavaScript it contains. This integrity verification significantly reduces the risk that an attacker can substitute malicious content.
</p>

<div class="example">

<p>
例えば `script^e 要素に次の様に~hashを追加すれば、
~UAへ向けて ~hashを通信できる：
◎
This example can be communicated to a user agent by adding the hash to a script element, like so:
</p>

<pre class="lang-html">
&lt;script src="https://example.com/example-framework.js"
        integrity="sha384-Li9vy3DqF8tnTXuiaAJuML3ky+er10rcgNR/VqsVpcw+ThHmYcwiB1pbOxEbzJr7"
        crossorigin="anonymous"&gt;&lt;/script&gt;
</pre>
</div>

<p>
無論、
~scriptだけが 完全性~検証からの便益を得られる応答~種別ではない。
ここで指定される枠組みは、
`link^e にも適用され、
また，この仕様の将来の~versionでは、
対象範囲を拡げる見込みが高い。
◎
Scripts, of course, are not the only response type which would benefit from integrity validation. The scheme specified here also applies to link and future versions of this specification are likely to expand this coverage.
</p>

		<section id="goals">
<h3 title="Goals">1.1. 目標</h3>

<ol>
	<li>
第三者-主体~serviceが弱体化されても，自動的に その~scriptを含む~siteまで ことごとく弱体化されるべきでない。
内容~作者が、
自身が読込む内容に対する期待を指定できる仕組みを与える
— 例えば、
当の~URLにたまたま あてがわれた `~~任意の^em ~scriptではなく，`特定の^em ~scriptに限って読込めるような。
◎
Compromise of a third-party service should not automatically mean compromise of every site which includes its scripts. Content authors will have a mechanism by which they can specify expectations for content they load, meaning for example that they could load a specific script, and not any script that happens to have a particular URL.
</li>
	<li>
検証yの仕組みは、
受信された応答が妥当でないときは，それを作者に伝えるような、
~errorを報告する機能性を備えるべきである。
◎
The verification mechanism should have error-reporting functionality which would inform the author that an invalid response was received.
</li>
</ol>

		</section>
		<section id="use-casesexamples">
<h3 title="Use Cases/Examples">1.2. 利用事例と例</h3>

			<section id="resource-integrity">
<h4 title="Resource Integrity">1.2.1. 資源の完全性</h4>

<ul>
	<li>
<p>
作者は、
全世界の利用者のために処理能を改善するため，~CDNを利用したいと望んでいるとする。
しかしながら、［
~CDNの~serverが，作者が`期待する~codeのみ^emを送達する
］ことを確保することも重要である。
~CDNが弱体化されて（あるいは期待されない悪意的な挙動により），~siteが不幸な~~形に変えられてしまう~riskを軽減するためには、
~pageに含まれる `link$e 要素に，次の`完全性~metadata$を追加する：
◎
An author wishes to use a content delivery network to improve performance for globally-distributed users. It is important, however, to ensure that the CDN’s servers deliver only the code the author expects them to deliver. To mitigate the risk that a CDN compromise (or unexpectedly malicious behavior) would change that site in unfortunate ways, the following integrity metadata is added to the link element included on the page:
</p>

<pre class="lang-html">
&lt;link
    rel="stylesheet"
    href="https://site53.example.net/style.css"
    integrity="sha384-`…( ~digest )…$V"
    crossorigin="anonymous"
&gt;
</pre>

	</li>
	<li>
<p>
作者は、
第三者-主体が解析~service用に供した~JSを~pageに含めるよう求めているとする。
注意深く考査された~codeのみ 実行されることを確保するためには、
~scriptに対する`完全性~metadata$を生成して，それを `script$e 要素に追加する：
◎
An author wants to include JavaScript provided by a third-party analytics service. To ensure that only the code that has been carefully reviewed is executed, the author generates integrity metadata for the script, and adds it to the script element:
</p>

<pre class="lang-html">
&lt;script
    src="https://analytics-r-us.example.com/v1.0/include.js"
    integrity="sha384-`…( ~digest )…$V"
    crossorigin="anonymous"
&gt;&lt;/script&gt;
</pre>
	</li>
	<li>
~UAは、
高特権な~HTML文脈（例えば, ~browserの新たな~UItab~page）内で走っている~JS~codeが，表示される前に操作されないことを確保したいと望む。
`完全性~metadata$は、
改ざんされた~JSが そのような高特権な文脈~下で走る~riskを軽減する。
◎
A user agent wishes to ensure that JavaScript code running in high-privilege HTML contexts (for example, a browser’s New Tab page) aren’t manipulated before display. Integrity metadata mitigates the risk that altered JavaScript will run in these pages' high-privilege contexts.
</li>
</ul>

			</section>
		</section>
	</section>
	<section id="key-concepts-and-terminology">
<h2 title="Key Concepts and Terminology">2. ~~主要な概念と各種用語</h2>

<p>
この節では、
文書~全体を通して利用されるいくつかの用語を定義する。
◎
This section defines several terms used throughout the document.
</p>

<p>
用語
`~digest@
は、
任意な~data~blockに暗号用~hash関数を適用した結果を~base64に符号化した結果を指す。
◎
The term digest refers to the base64 encoded result of executing a cryptographic hash function on an arbitrary block of data.
</p>

<p>
用語［
生成元, 同一-生成元
］は、
`HTML$r にて定義される。
◎
The terms origin and same origin are defined in HTML. [HTML]
</p>

<p>
`~base64符号化法@
は、
`RFC4648$r `§ 4＠~RFCx/rfc4648#section-4$
にて定義される。
◎
A base64 encoding is defined in Section 4 of RFC 4648. [RFC4648]
</p>

<p>
`SHA-256^hS, `SHA-384^hS, `SHA-512^hS
は、
暗号用~hash関数
`SHA-2@hS
の一部を成し、
`SHA2$r にて定義される。
◎
The SHA-256, SHA-384, and SHA-512 are part of the SHA-2 set of cryptographic hash functions defined by the NIST. [SHA2]
</p>

		<section id="grammatical-concepts">
<h3 title="Grammatical Concepts">2.1. 文法~上の概念</h3>

<p class="trans-note">【
この節の内容は、
関連な節に直に記すことにする。
】
◎
The Augmented Backus-Naur Form (ABNF) notation used in this document is specified in RFC5234. [ABNF]
◎
Appendix B.1 of [ABNF] defines VCHAR (printing characters).
◎
WSP (white space) characters are defined in Section 2.4.1 Common parser idioms of the HTML 5 specification as White_Space characters. [HTML5]
</p>

		</section>
	</section>
	<section id="framework">
<h2 title="Framework">3. ~framework</h2>

<div class="p">
<p>
ここで指定する 完全性~検証yの仕組みは、
次の処理-を煮詰める：
</p>

<ul ><li>資源から ~~十分に強い暗号用~digestを生成する。
</li><li>生成した~digestを，応答を検証yするために利用できるよう，~UAへ伝送する。
</li></ul>
◎
The integrity verification mechanism specified here boils down to the process of generating a sufficiently strong cryptographic digest for a resource, and transmitting that digest to a user agent so that it may be used to verify the response.
</div>

		<section id="integrity-metadata-description">
<h3 title="Integrity metadata">3.1. 完全性~metadata</h3>

<p>
応答の完全性を検証yするため、
~UAは，
`要請の一部＠~FETCH#concept-request-integrity-metadata$として
`完全性~metadata@
を要求する。
この~metadataは、
次に挙げる情報~片からなる：
◎
To verify the integrity of a response, a user agent requires integrity metadata as part of the request. This metadata consists of the following pieces of information:
</p>
<ul>
	<li>
`~algo@iM
⇒
ある暗号用~hash関数【を識別する名前】
◎
cryptographic hash function ("alg")
</li>
	<li>
`値@iM
⇒
ある`~digest$
◎
digest ("val")
</li>
	<li>
`~option群@iM
◎
options ("opt")
</li>
</ul>

<p>
これらのうち，`~algo$iMと`値$iM は、
供されなければナラナイ
— 応答の完全性を検証するためには必須なので。
◎
The hash function and digest MUST be provided in order to validate a response’s integrity.
</p>

<p class="note">注記：
現時点では，定義された~optionはないが、
この仕様は，将来の~versionにて~optionを定義し得る
— ~MIME型 `MIME-TYPES$r など。
◎
Note: At the moment, no options are defined. However, future versions of the spec may define options, such as MIME types [MIME-TYPES].
</p>

<p>
この~metadataは、
~CSP
`§ ~source~list$の `hash-source$P と同じ形式に符号化されなければナラナイ（ただし、
一重引用符は含めない）。
◎
This metadata MUST be encoded in the same format as the hash-source (without the single quotes) in section 4.2 of the Content Security Policy Level 2 specification.
</p>

<div class="example">
<p>
例えば、
~script資源の内容が文字列
`alert(\'Hello, world.\');^l
で，作者が~hash関数として `SHA-384$hS を選んだなら、
~base64に符号化された結果の~digestは、
`H8BRh8j48O9oYatfu5AZzq6A9RINhZO5H16dQZngK7T62em8MUt1FLm52t+eX6xO^s
になる。
これは、
次のように符号化できる：
◎
For example, given a script resource containing only the string alert('Hello, world.');, an author might choose SHA-384 as a hash function. H8BRh8j48O9oYatfu5AZzq6A9RINhZO5H16dQZngK7T62em8MUt1FLm52t+eX6xO is the base64 encoded digest that results. This can be encoded as follows:
</p>

<pre class="lang-http">
sha384-H8BRh8j48O9oYatfu5AZzq6A9RINhZO5H16dQZngK7T62em8MUt1FLm52t+eX6xO
</pre>

</div>

<div class="note">
<p>注記：
~digestを生成するために利用できる~utilityは、
いくつもある。
例えば `OpenSSL＠https://www.openssl.org/$ は、
ごく共通に可用である。
この節の例は、
次の~command-lineによる結果である：
◎
Digests may be generated using any number of utilities. OpenSSL, for example, is quite commonly available. The example in this section is the result of the following command line:
</p>

<pre class="lang-other">
echo -n "alert('Hello, world.');" | \
   openssl dgst -sha384 -binary | \
   openssl base64 -A
</pre>

</div>

		</section>
		<section id="cryptographic-hash-functions">
<h3 title="Cryptographic hash functions">3.2. 暗号用~hash関数</h3>

<p>
適合t~UAは、
要請の`完全性~metadata$の一部として利用する暗号用~hash関数として［
`SHA-256$hS,
`SHA-384$hS,
`SHA-512$hS
］を~supportするモノトスル。
また、
追加的な~hash関数も~supportしてヨイ。
◎
Conformant user agents MUST support the SHA-256, SHA-384, and SHA-512 cryptographic hash functions for use as part of a request’s integrity metadata and MAY support additional hash functions.
</p>

<div class="p">
<p>
~UAは、
自身が~supportする~hashing関数を，次に従って制約するベキである
（`§ ~hash衝突~攻撃＠#hash-collision-attacks$を見よ）：
</p>
<ul>
	<li>
`MD5^hS や `SHA-1^hS の様な弱いことが既知なものは~supportしない。
</li>
	<li>
衝突耐性があることが既知なものに限る。
</li>
	<li>
~supportしている~hashing関数を定期的に評価し直して、
~secureでなくなったものは非推奨にする。
</li>
</ul>
◎
User agents SHOULD refuse to support known-weak hashing functions like MD5 or SHA-1 and SHOULD restrict supported hashing functions to those known to be collision-resistant. Additionally, user agents SHOULD re-evaluate their supported hash functions on a regular basis and deprecate support for those functions that have become insecure. See § 5.2 Hash collision attacks.
</div>

			<section id="agility">
<h4 title="Agility">3.2.1. 即応性</h4>

<p>
将来，暗号上の発見に直面したときに 機敏に対応できるよう、
同じ資源に複数個の［
`完全性~metadata$の集合
］を結付けてもよい†。
◎
Multiple sets of integrity metadata may be associated with a single resource in order to provide agility in the face of future cryptographic discoveries. For example, the resource described in the previous section may be described by either of the following hash expressions:
</p>

<div class="example">

<p>
作者は、
同じ資源に対し，例えば `SHA-384$hS, `SHA-512$hS ~hashの 2 つを指定してよい：
◎
sha384-H8BRh8j48O9oYatfu5AZzq6A9RINhZO5H16dQZngK7T62em8MUt1FLm52t+eX6xO
◎
sha512-Q2bFTOhEALkN8hOms2FKTDLy7eugP2zFZ1T8LCvX42Fp3WoNr3bjZSAHeOsHrbV1Fu9/A0EzCinRE7Af1ofPrw==
◎
Authors may choose to specify both, for example:
</p>

<pre class="lang-html">
&lt;script src="hello_world.js"
   integrity="sha384-`…( ~digest )…$V
              sha512-`…( ~digest )…$V"
   crossorigin="anonymous"&gt;&lt;/script&gt;
</pre>
</div>

<p class="trans-note">【†
複数個の集合（ `multiple sets of^en 〜 ）：
各~hash関数に対しても，複数個の~hash値を与え得る
— `後述の例＠#_multi-hash$のように。
】</p>

<p>
この事例では、
~UAは，応答を検証するときに~list内の最も強い~hash関数を選んで，
その~metadataを利用することになる（後述の［
`~metadata~listを構文解析する$ ／ `最も強い~metadataを取得する$
］~algoに則って）。
◎
In this case, the user agent will choose the strongest hash function in the list, and use that metadata to validate the response (as described below in the § 3.3.2 Parse metadata and § 3.3.3 Get the strongest metadata from set algorithms).
</p>

<p>
~secureでないと決定された~hash関数に対しては、
~UAは，それを非推奨にした上で、
最終的には，~secureでないな~hash関数を利用している完全性~検証の~supportを除去するベキである。
~UAは、
応答の妥当性を検査する際に，非推奨にされた関数に基づく~digestを利用してもヨイ。
◎
When a hash function is determined to be insecure, user agents SHOULD deprecate and eventually remove support for integrity validation using the insecure hash function. User agents MAY check the validity of responses using a digest based on a deprecated function.
</p>

<p>
作者が，古い~UAに縛られることなく より強い~hash関数に切替えれるよう、
~UAは，自身が~supportしない~hash関数を利用している検証に対しては，その完全性~値は供されなかったかの様に動作することになる（後述の，`~byte列は~metadata~listに合致するか？$を見よ）。
作者には、
強い~hash関数を利用することに加え，より強い~hash関数が可用になり次第 それへ移行することが奨励される。
◎
To allow authors to switch to stronger hash functions without being held back by older user agents, validation using unsupported hash functions acts like no integrity value was provided (see the § 3.3.4 Do bytes match metadataList? algorithm below). Authors are encouraged to use strong hash functions, and to begin migrating to stronger hash functions as they become available.
</p>

			</section>
			<section id="priority">
<h4 title="Priority">3.2.2. 優先度</h4>

<p>
~UAは、
`より優先される~hash関数を取得する@
~algo（ `getPrioritizedHashFunction^en ）を供するモノトスル。
それは、
所与の 2 つの~hash関数 ( %A, %B ) に対し，より優先される方
— ~UAがより衝突耐性があると見なす方 —
を返す
— ただし、
優先度が等しい場合は ε 【！空~文字列】を返す。
例えば、［
`より優先される~hash関数を取得する$(`sha256^l, `sha512^l)
は `sha512^l ／
`より優先される~hash関数を取得する$(`sha256^l, `sha256^l)
は空~文字列
］を返すことになる。
◎
User agents must provide a mechanism for determining the relative priority of two hash functions and return the empty string if the priority is equal. That is, if a user agent implemented a function like getPrioritizedHashFunction(a, b) it would return the hash function the user agent considers the most collision-resistant. For example, getPrioritizedHashFunction('sha256', 'sha512') would return 'sha512' and getPrioritizedHashFunction('sha256', 'sha256') would return the empty string.
</p>

<p class="note">注記：
この~algoは、
もっぱら，この文書にて~algoの記述を単純~化するために利用される。
◎
Note: The getPrioritizedHashFunction is an internal implementation detail. It is not an API that implementors provide to web applications. It is used in this document only to simplify the algorithm description.
</p>

<p class="trans-note">【
この~algoを［
3 個~以上の~hash関数の優先度が循環する様な結論を導く
］ように定義することも明示的には禁止されてはいないが、
許容されないであろう（この仕様の他の~algoは、
そうであっても~~問題なく働いてしまうが）。
】</p>

			</section>
		</section>
		<section id="response-verification-algorithms">
<h3 title="Response verification algorithms">3.3. 応答【の本体~data】を検証yする~algo</h3>

			<section id="apply-algorithm-to-response">
<h4 title="Apply algorithm to bytes">3.3.1. ~byte列に~algoを適用する</h4>

<p>
所与の
( `~byte列$ %~byte列, ~algo %~algo )
に対し：
</p>
<ol>
	<li>
%結果 ~LET %~byte列 に %~algo を適用した結果
◎
Let result be the result of applying algorithm to bytes.
</li>
	<li>
~RET %結果 に`~base64符号化法$を適用した結果
◎
Return the result of base64 encoding result.
</li>
</ol>

			</section>
			<section id="parse-metadata">
<h4 title="Parse metadata">3.3.2. ~metadataを構文解析する</h4>

<p>
この~algoは、
所与の
( 文字列 %~metadata文字列 )
に対し，一連の［
~UAが解する~hash関数を伴う~hash式【`完全性~metadata$】
］を返す：
◎
This algorithm accepts a string, and returns a set of hash expressions whose hash functions are understood by the user agent.
</p>
<ol>
	<li>
%結果 ~LET 空~集合
【ではなく`~list$ — 以下に利用される %結果 に付加する演算は，`~list$用なので。】
◎
Let result be the empty set.
</li>
	<li>
%~token~list ~LET `区切子で厳密に分割する$( %~metadata文字列, `0020^U `SPACE^cn )
◎
↓</li>
	<li>
<p>
%~token~list を成す
~EACH( %~token )
に対し：
◎
For each item returned by splitting metadata on spaces:
</p>
		<ol>
			<li>
%~option群を伴う~hash ~LET `区切子で厳密に分割する$( %~item, `003F^U `?^smb )
◎
Let hash-with-opt-token-list be the result of splitting item on U+003F (?).
</li>
			<li>
%~hash式 ~LET %~option群を伴う~hash[ 0 ]
◎
Let hash-expression be hash-with-opt-token-list[0].
</li>
			<li>
%~base64値 ~LET 空~文字列
◎
Let base64-value be the empty string.
</li>
			<li>
%~hash式~token~list ~LET `区切子で厳密に分割する$( %~hash式, `002D^U `-^smb )
◎
Let hash-expr-token-list be the result of splitting hash-expression on U+002D (-).
</li>
			<li>
%~algo ~LET %~hash式~token~list[ 0 ]
◎
Let algorithm be hash-expr-token-list[0].
</li>
			<li>
~IF［
%~hash式~token~list の`~size$ ~GTE 2
］
⇒
%~base64値 ~SET %~hash式~token~list[ 1 ]
◎
If hash-expr-token-list[1] exists, set base64-value to hash-expr-token-list[1].
</li>
			<li>
~IF［
%~algo は~UAが認識する~hash関数でない
］
⇒
~CONTINUE
◎
If algorithm is not a hash function recognized by the user agent, continue.
</li>
			<li>
<p>
%~metadata ~LET 新たな`完全性~metadata$
— その
⇒＃
`~algo$iM ~SET %~algo,
`値$iM ~SET %~base64値
◎
Let metadata be the ordered map «["alg" → algorithm, "val" → base64-value]».
</p>

<p class="note">注記：
定義された~optionは無いので
（`§ 完全性~metadata＠#integrity-metadata-description$を見よ）、
%~metadata の`~option群$iMは設定されない。
将来の~versionにおいて，~optionが定義されたなら、
%~option群を伴う~hash[ 1 ] が`~option群$iMとして用立てられ得る。
◎
Note: Since no options are defined (see the § 3.1 Integrity metadata), a corresponding entry is not set in metadata. If options are defined in a future version, hash-with-opt-token-list[1] can be utilized as options.
</p>
			</li>
			<li>
%結果 に %~metadata を`付加する$
◎
Append metadata to result.
</li>
		</ol>
	</li>
	<li>
~RET %結果
◎
Return result.
</li>
</ol>

			</section>
			<section id="get-the-strongest-metadata">
<h4 title="Get the strongest metadata from set.">3.3.3. 集合から最も強い~metadataを取得する</h4>

<p>
所与の
( %集合 )
に対し：
</p>
<ol>
	<li>
%結果 ~LET 空~集合
◎
↓</li>
	<li>
%最強~algo ~LET ~NULL
◎
Let result be the empty set and strongest be the empty string.
</li>
	<li>
<p>
%集合 を成す
~EACH( %~item )
に対し：
</p>
		<ol>
			<li>
%新たな~algo ~LET %~item の`~algo$iM
</li>
			<li>
%~algo ~SET %最強~algo に応じて
⇒＃
~NULL ならば %新たな~algo ／
~ELSE_ `より優先される~hash関数を取得する$( %最強~algo, %新たな~algo )
</li>
			<li>
<p>
~IF［
%~algo ~NEQ %最強~algo
］：
</p>
				<ol>
					<li>
~IF［
%~algo ~EQ %新たな~algo
］
⇒＃
%結果 を空にする；
%最強~algo ~SET %新たな~algo
</li>
					<li>
%結果 に %~item を追加する
</li>
				</ol>
			</li>
		</ol>
◎
For each item in set:
• If result is the empty set, add item to result and set strongest to item, skip to the next item.
• Let currentAlgorithm be the alg component of strongest.
• Let newAlgorithm be the alg component of item.
• If the result of getPrioritizedHashFunction(currentAlgorithm, newAlgorithm) is the empty string, add item to result. If the result is newAlgorithm, set strongest to item, set result to the empty set, and add item to result.
</li>
	<li>
~RET %結果
◎
Return result.
</li>
</ol>


			</section>
			<section id="does-response-match-metadatalist">
<h4 title="Do bytes match metadataList?">3.3.4. ~byte列は~metadata~listに合致するか？</h4>

<p>
所与の
( `~byte列$ %~byte列, 文字列 %~metadata~list )
に対し：
</p>
<ol>
	<li>
%構文解析した~metadata ~LET `~metadata~listを構文解析する$( %~metadata~list )
◎
Let parsedMetadata be the result of parsing metadataList.
</li>
	<li>
~IF［
%構文解析した~metadata は`空$である
］
⇒
~RET ~T
◎
If parsedMetadata is empty set, return true.
</li>
	<li>
%~metadata ~LET `最も強い~metadataを取得する$( %構文解析した~metadata )
◎
Let metadata be the result of getting the strongest metadata from parsedMetadata.
</li>
	<li>
<p>
%~metadata を成す
~EACH( %~item )
に対し：
◎
For each item in metadata:
</p>
		<ol>
			<li>
%~algo ~LET %~item の`~algo$iM
◎
Let algorithm be the item["alg"].
</li>
			<li>
%期待される値 ~LET %~item の`値$iM
◎
Let expectedValue be the item["val"].
</li>
			<li>
%実際の値 ~LET `~byte列に~algoを適用する$( %~byte列, %~algo )
◎
Let actualValue be the result of applying algorithm to bytes .
</li>
			<li>
~IF［
%実際の値 ~EQ %期待される値
］
⇒
~RET ~T
◎
If actualValue is a case-sensitive match for expectedValue, return true.
</li>
		</ol>
	</li>
	<li>
~RET ~F
◎
Return false.
</li>
</ol>

<p id="_multi-hash">
この~algoは、
複数個の［
妥当かつ強い~hash関数
］を受容することを~UAに許容する。
◎
This algorithm allows the user agent to accept multiple, valid strong hash functions.＼
</p>

<div class="example">
<p>
例えば，開発者は、
`script$e 要素を次のようにも記せる：
◎
For example, a developer might write a script element such as:
</p>

<pre class="lang-html">
&lt;script src="https://example.com/example-framework.js"
        integrity="sha384-`…( ~digest )…$V
                   sha384-`…( ~digest )…$V"
        crossorigin="anonymous"&gt;&lt;/script&gt;
</pre>

<p>
これは、
2 つの異なる内容~payload
— 1 個目, 2 個目どちらかの `SHA-384$hS ~hash値に合致するもの —
を~UAに受容させる。
◎
which would allow the user agent to accept two different content payloads, one of which matches the first SHA-384 hash value and the other matches the second SHA-384 hash value.
</p>
</div>

<p class="note">注記：
~UAは、
この~algoの結果を改変することを利用者に許容してよい
— ［
利用者-選好,
~bookmarklet,
第三者-主体による~UAに対する追加,
その他の同類の仕組み
］を介して。
例えば、
`HTTPS Everywhere＠https://www.eff.org/https-everywhere$en
の様な拡張により生成される~redirectは、
資源の［
~HTTPS, ~HTTP
］~versionが相違する場合でも，正しく読込んで実行する。
◎
Note: User agents may allow users to modify the result of this algorithm via user preferences, bookmarklets, third-party additions to the user agent, and other such mechanisms. For example, redirects generated by an extension like HTTPS Everywhere could load and execute correctly, even if the HTTPS version of a resource differs from the HTTP version.
</p>

<p class="note">注記：
下位資源の完全性には、
~CORSが要求される
— ~CORSを伴わずにそれを利用しようとする試みるのは、
論理的な誤りである。
それが生じた場合、
~UAには［
開発者~consoleに，この失敗を説明する警告~messageを報告すること
］が奨励される。
`Fetch$r
◎
Note: Subresource Integrity requires CORS and it is a logical error to attempt to use it without CORS. User agents are encouraged to report a warning message to the developer console to explain this failure. [Fetch]
</p>

			</section>
		</section>
		<section id="verification-of-html-document-subresources">
<h3 title="Verification of HTML document subresources">3.4. ~HTML文書の下位資源に対する検証y</h3>

<p>
種々の~HTML要素が，［
文書の中へ埋込まれる／文書の文脈において実行される
］ことになる資源を要請する。
その種の要素に対し，完全性~metadataを~supportする一環として、［
`link$e ／ `script$e
］要素には，新たな内容~属性 `integrity$a が追加される。
`HTML$r
◎
A variety of HTML elements result in requests for resources that are to be embedded into the document, or executed in its context. To support integrity metadata for some of these elements, a new integrity attribute is added to the list of content attributes for the link and script elements. [HTML]
</p>

<p class="note">注記：
この仕様の将来の改訂版は、
アリなすべての下位資源
— すなわち，次に挙げる要素 —
に対しても，完全性の~supportを含める見込みが高い
⇒
`a^e, `audio^e, `embed^e, `iframe^e, `img^e, `link^e, `object^e, `script^e,
`source^e, `track^e, `video^e
◎
Note: A future revision of this specification is likely to include integrity support for all possible subresources, i.e., a, audio, embed, iframe, img, link, object, script, source, track, and video elements.
</p>

		</section>
		<section id="the-integrity-attribute">
<h3 title="The integrity attribute">3.5. `integrity^a 属性</h3>

<p>
`integrity^a 属性は、
要素に対する`完全性~metadata$を表現する。
この属性の値は、
空~文字列か, または
少なくとも 1 個以上の，次の~ABNF `ABNF$r 文法に則って妥当な~metadataを含んでなければナラナイ
◎
The integrity attribute represents integrity metadata for an element. The value of the attribute MUST be either the empty string, or at least one valid metadata as described by the following ABNF grammar:
</p>

<pre class="bnf">
`integrity-metadata@P
	= *`WSP$P `hash-with-options$P *( 1*`WSP$P `hash-with-options$P ) *`WSP$P
	/ *`WSP$P
`hash-with-options@P
	= `hash-expression$P *("?" `option-expression$P)
`option-expression@P
	= *`VCHAR$P
`hash-algo@P
	= &lt;~CSP `§ ~source~list$の `hash-algorithm^P 生成規則&gt;
`base64-value@P
	= &lt;~CSP `§ ~source~list$の `base64-value^P 生成規則&gt;
`hash-expression@P
	= `hash-algo$P "-" `base64-value$P
</pre>

<p>
`option-expression$P は、
各 `hash-expression$P ごとに結付けられ，当の `hash-expression^P に限り適用される。
◎
option-expressions are associated on a per hash-expression basis and are applied only to the hash-expression that immediately precedes it.
</p>

<p>
~UAは、
将来の~optionと全部的に前方-互換であり続けるようにするため，自身が認識しない `option-expression$P を無視するモノトスル。
◎
In order for user agents to remain fully forwards compatible with future options, the user agent MUST ignore all unrecognized option-expressions.
</p>

<p class="note">注記：
構文~内では `option-expression$P が予約されているが、
定義された~optionはまだないことに注意。
この仕様の将来の~versionでは，~optionに対しより特定な構文を定義することになる見込みが高いので、
アリな限り広く定義されている。
◎
Note: Note that while the option-expression has been reserved in the syntax, no options have been defined. It is likely that a future version of the spec will define a more specific syntax for options, so it is defined here as broadly as possible.
</p>

		</section>
		<section id="handling-integrity-violations">
<h3 title="Handling integrity violations">3.6. 完全性~違反の取扱い</h3>

<p>
~UAは、
完全性~検査に失敗した応答を［
具現化する／実行する
］のを拒否して，代わりに
`Fetch$r にて定義される~network~errorを返すことになる。
◎
The user agent will refuse to render or execute responses that fail an integrity check, instead returning a network error as defined in Fetch [Fetch].
</p>

<p class="note">注記：
完全性~検査の失敗-時には、
`error^et ~eventが発火される。
開発者は、
正準的~fallback資源（例： ~CDNから~serveされていない, 二次的な，信用されてはいるが より低速な~sourceからの資源など）を供したいと望むなら、［
この `error^et ~eventをとらえて，失敗した当の資源を異なるものに置換する
］ような適切な~handlerを供せる。
◎
Note: On a failed integrity check, an error event is fired. Developers wishing to provide a canonical fallback resource (e.g., a resource not served from a CDN, perhaps from a secondary, trusted, but slower source) can catch this error event and provide an appropriate handler to replace the failed resource with a different one.
</p>

		</section>
	</section>
	<section id="proxies">
<h2 title="Proxies">4. ~proxy</h2>

<div class="p">
<p>
応答を改変するような~proxyその他の媒介~serverを最適化するときは、
当の応答に結付けられた~digestが新たな内容にも同期cし続けることを確保しなければナラナイ。
選択肢としては、
次が挙げられる：
</p>
<ul>
	<li>
資源に結付けられた`完全性~metadata$が更新されることを確保する。
</li>
	<li>
単純に，~page作者が完全性の検証yを要請した際には，当の資源の正準的~versionのみを送達する。
</li>
</ul>
◎
Optimizing proxies and other intermediate servers which modify the responses MUST ensure that the digest associated with those responses stays in sync with the new content. One option is to ensure that the integrity metadata associated with resources is updated. Another would be simply to deliver only the canonical version of resources for which a page author has requested integrity verification.
</div>

<p>
媒介~serverに伝わり易くするため、
資源を~serveしている~serverは，自身が送信する資源に，値 `no-transform$dir を伴う `Cache-Control$h ~headerを伴わせるベキである。
◎
To help inform intermediate servers, those serving the resources SHOULD send along with the resource a Cache-Control header with a value of no-transform.
</p>

	</section>
	<section id="security-considerations">
<h2 title="Security and Privacy Considerations">5. ~securityと~privacyの考慮点</h2>

◎非規範的

		<section id="non-secure-contexts-remain-non-secure">
<h3 title="Non-secure contexts remain non-secure">5.1. ~secureでない文脈は~secureでないであり続ける</h3>

<p>
［
`~secureな文脈$enVでない文脈
— ~HTTP【~HTTPSでない】~pageなど —
により送達される`完全性~metadata$
］が保護する生成元は，［
外部~資源を~hostしている~serverの弱体化に抗する
］ことに限られる。
~network攻撃者は、
~hashの検証-対象である応答を，その経路上で改ざんできるのと同じく，~~元の~digestも改ざんできる（あるいは，それを除去するなど，文書に対し何でもできる）。
したがって，作者は、
完全性~metadataを`~secureな文脈$enV下にある場合に限り送達するベキである。
`~webの~secure化法＠http://www.w3.org/2001/tag/doc/web-https$も見よ。
◎
Integrity metadata delivered by a context that is not a Secure Context such as an HTTP page, only protects an origin against a compromise of the server where an external resources is hosted. Network attackers can alter the digest in-flight (or remove it entirely, or do absolutely anything else to the document), just as they could alter the response the hash is meant to validate. Thus, it is recommended that authors deliver integrity metadata only to a Secure Context. See also Securing the Web.
</p>

		</section>
		<section id="hash-collision-attacks">
<h3 title="Hash collision attacks">5.2. ~hash衝突~攻撃</h3>

<p>
~digestの強さは、
それを生成する~hash関数に基づく。
~UAには、［
弱いことが既知である~hashing関数に対する~supportは拒否すること
］, および［
~supportする~algoを，衝突耐性があることが既知であるものに制限すること
］が推奨される。
推奨されない~hashing関数の例としては、
`MD5^hS や `SHA-1^hS が挙げられる。
これを書いている時点では、
`SHA-384$hS は 良好な~~基準である。
◎
Digests are only as strong as the hash function used to generate them. It is recommended that user agents refuse to support known-weak hashing functions and limit supported algorithms to those known to be collision resistant. Examples of hashing functions that are not recommended include MD5 and SHA-1. At the time of writing, SHA-384 is a good baseline.
</p>

<p>
更には、
~UAには，［
定期的に，自身が~supportしている~hash関数を評価し直すこと
］, および［
~secureでないと~~判明した関数に対しては，~supportを非推奨にすること
］が推奨される。
~hash関数は，時を経て［
期待されるより ずっと弱い, あるいは 一部の事例では壊れている
］ものと~~判明することがあるので、
~UAは，開発にあたって そのことを自覚し続けることが重要である。
◎
Moreover, it is recommended that user agents re-evaluate their supported hash functions on a regular basis and deprecate support for those functions shown to be insecure. Over time, hash functions may be shown to be much weaker than expected and, in some cases, broken, so it is important that user agents stay aware of these developments.
</p>

		</section>
		<section id="cross-origin-data-leakage">
<h3 title="Cross-origin data leakage">5.3. 非同一-生成元~data漏洩e</h3>

<p>
この仕様は、［
完全性の保護-対象である非同一-生成元~要請
］に`~CORS設定群~属性$が在ることを要求する。
この要件が無ければ、
攻撃者は
`同一-生成元~施策＠http://www.w3.org/Security/wiki/Same_Origin_Policy$に違反することもでき、
非同一-生成元~資源が，ある種の内容を持つかどうか決定できてしまう：
◎
This specification requires the CORS settings attribute to be present on integrity-protected cross-origin requests. If that requirement were omitted, attackers could violate the same-origin policy and determine whether a cross-origin resource has certain content.
</p>

<ul>
	<li>
攻撃者は、
既知な~digestで資源の読込nを試みながら，その失敗を注視する。
読込nに失敗したなら、
応答はその~hashに合致しないものと推定でき、
それにより その内容についての洞察を得られる。
これは例えば、
利用者が特定0の~serviceに~log-inしたかどうかを露呈するかもしれない。
◎
Attackers would attempt to load the resource with a known digest, and watch for load failures. If the load fails, the attacker could surmise that the response didn’t match the hash and thereby gain some insight into its contents. This might reveal, for example, whether or not a user is logged into a particular service.
</li>
	<li>
<p>
更には，攻撃者は、
静的な資源~内の特定の値を総当たりできる。
◎
Moreover, attackers could brute-force specific values in an otherwise static resource.＼
</p>

<div class="example">

<p>
次の様な~JSON応答を考える：
◎
Consider a JSON response that looks like this:
</p>

<pre class="lang-json">
{'status': 'authenticated', 'username': 'admin'}
</pre>

<p>
攻撃者は、
様々な共通的な~username（ `username^c ）から，応答に対する~hashを予め算出しておいて、
それらの~hashを順々に指定しながら繰返し文書の読込nを試みれる。
読込nに成功したなら、
~usernameを正しく推測できたことが確認されたことになる。
◎
An attacker could precompute hashes for the response with a variety of common usernames, and specify those hashes while repeatedly attempting to load the document. A successful load would confirm that the attacker has correctly guessed the username.
</p>
</div>

	</li>
</ul>

		</section>
	</section>
	<section id="acknowledgements">
<h2 title="Acknowledgements">謝辞</h2>

<p>
この仕様のかなりの部分は、
`Gervase Markham^en 氏による
`Link Fingerprints＠http://www.gerv.net/security/link-fingerprints/$en
の概念, および WHATWG による
`Link Hashes＠https://wiki.whatwg.org/wiki/Link_Hashes$en
から着想を得ている。
◎
Much of the content here is inspired heavily by Gervase Markham’s Link Fingerprints concept as well as WHATWG’s Link Hashes.
</p>

<p>
この仕様の初期~versionに貴重な貢献された `Mike West^en 氏に特別な謝意を。
貴重な~feedbackを寄せられた次の方々にも：
◎
A special thanks to Mike West for his invaluable contributions to the initial version of this spec.＼
</p>

<div lang="en">
Thanks to Brad Hill, Anne van Kesteren, Jonathan Kingston, Mark Nottingham, Sergey Shekyan , Dan Veditz, Eduardo Vela, Tanvi Vyas, and Michal Zalewski for providing invaluable feedback.
</div>

	</section>
</main></div>