[要約] RFC 6920は、ハッシュを使用して物事に名前を付ける方法についてのガイドラインです。その目的は、ハッシュを使用して名前を一意に識別し、データの整合性を確保することです。
Internet Engineering Task Force (IETF) S. Farrell
Request for Comments: 6920 Trinity College Dublin
Category: Standards Track D. Kutscher
ISSN: 2070-1721 NEC
C. Dannewitz
University of Paderborn
B. Ohlman
A. Keranen
Ericsson
P. Hallam-Baker
Comodo Group Inc.
April 2013
Naming Things with Hashes
ハッシュを使って名前を付ける
Abstract
概要
This document defines a set of ways to identify a thing (a digital object in this case) using the output from a hash function. It specifies a new URI scheme for this purpose, a way to map these to HTTP URLs, and binary and human-speakable formats for these names. The various formats are designed to support, but not require, a strong link to the referenced object, such that the referenced object may be authenticated to the same degree as the reference to it. The reason for this work is to standardise current uses of hash outputs in URLs and to support new information-centric applications and other uses of hash outputs in protocols.
このドキュメントでは、ハッシュ関数からの出力を使用してモノ（この場合はデジタルオブジェクト）を識別する一連の方法を定義します。これは、この目的のための新しいURIスキーム、これらをHTTP URLにマップする方法、およびこれらの名前のバイナリ形式と人間が話すことができる形式を指定します。さまざまな形式は、参照オブジェクトへの強いリンクをサポートするように設計されていますが、これは必須ではありません。そのため、参照オブジェクトは、それへの参照と同じ程度に認証される場合があります。この作業の理由は、URLでのハッシュ出力の現在の使用を標準化し、新しい情報中心のアプリケーションとプロトコルでのハッシュ出力の他の使用をサポートするためです。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6920.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6920で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2013 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Hashes Are What Count . . . . . . . . . . . . . . . . . . . . 4
3. Named Information (ni) URI Format . . . . . . . . . . . . . . 6
3.1. Content Type Query String Attribute . . . . . . . . . . . 8
4. .well-known URI . . . . . . . . . . . . . . . . . . . . . . . 9
5. URL Segment Format . . . . . . . . . . . . . . . . . . . . . . 10
6. Binary Format . . . . . . . . . . . . . . . . . . . . . . . . 10
7. Human-Speakable (nih) URI Format . . . . . . . . . . . . . . . 11
8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Hello World! . . . . . . . . . . . . . . . . . . . . . . . 13
8.2. Public Key Examples . . . . . . . . . . . . . . . . . . . 13
8.3. nih Usage Example . . . . . . . . . . . . . . . . . . . . 14
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
9.1. Assignment of ni URI Scheme . . . . . . . . . . . . . . . 15
9.2. Assignment of nih URI Scheme . . . . . . . . . . . . . . . 15
9.3. Assignment of .well-known 'ni' URI . . . . . . . . . . . . 16
9.4. Creation of Named Information Hash Algorithm Registry . . 16
9.5. Creation of Named Information Parameter Registry . . . . . 18
10. Security Considerations . . . . . . . . . . . . . . . . . . . 18
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
12.1. Normative References . . . . . . . . . . . . . . . . . . . 20
12.2. Informative References . . . . . . . . . . . . . . . . . . 21
Identifiers -- names or locators -- are used in various protocols to identify resources. In many scenarios, those identifiers contain values that are obtained from hash functions. Different deployments have chosen different ways to include the hash function outputs in their identifiers, resulting in interoperability problems.
識別子（名前またはロケーター）は、リソースを識別するためにさまざまなプロトコルで使用されます。多くのシナリオでは、これらの識別子にはハッシュ関数から取得された値が含まれています。デプロイメントによって、ハッシュ関数の出力を識別子に含める方法が異なるため、相互運用性の問題が発生します。
This document defines the "Named Information" identifier, which provides a set of standard ways to use hash function outputs in names. We begin with a few example uses for various ways to include hash function output in a name, with the specifics defined later in this document. Figure 1 shows an example of the Named Information (ni) URI scheme that this document defines.
このドキュメントは、「名前付き情報」識別子を定義します。これは、名前でハッシュ関数出力を使用する一連の標準的な方法を提供します。名前にハッシュ関数の出力を含めるためのさまざまな方法のいくつかの使用例から始めます。詳細は、このドキュメントで後ほど定義します。図1は、このドキュメントで定義する名前付き情報（ni）URIスキームの例を示しています。
ni:///sha-256;UyaQV-Ev4rdLoHyJJWCi11OHfrYv9E1aGQAlMO2X_-Q
Figure 1: Example ni URI
ふぃぐれ １： えぁｍｐぇ に うり
Hash function outputs can be used to ensure uniqueness in terms of mapping URIs [RFC3986] to a specific resource or to make URIs hard to guess for security reasons. Since there is no standard way to interpret those strings today, in general only the creator of the URI knows how to use the hash function output. Other protocols, such as application-layer protocols for accessing "smart objects" in constrained environments, also require more compact (e.g., binary) forms of such identifiers. In yet other situations, people may have to speak such values, e.g., in a voice call (see Section 8.3), in order to confirm the presence or absence of a resource.
ハッシュ関数の出力を使用して、URI [RFC3986]を特定のリソースにマッピングするという点で一意性を確保したり、セキュリティ上の理由からURIを推測しにくくしたりできます。現在、これらの文字列を解釈する標準的な方法はないため、通常、URIの作成者だけがハッシュ関数出力の使用方法を知っています。制約された環境で「スマートオブジェクト」にアクセスするためのアプリケーション層プロトコルなどの他のプロトコルも、そのような識別子のよりコンパクトな（バイナリなど）フォームを必要とします。さらに他の状況では、リソースの有無を確認するために、人々はそのような値を、たとえば音声通話（セクション8.3を参照）で話す必要がある場合があります。
As another example, protocols for accessing in-network storage servers need a way to identify stored resources uniquely and in a location-independent way so that replicas on different servers can be accessed by the same name. Also, such applications may require verification that a resource representation that has been obtained actually corresponds to the name that was used to request the resource, i.e., verifying the binding between the data and the name, which is here termed "name-data integrity".
別の例として、ネットワーク内のストレージサーバーにアクセスするためのプロトコルには、異なるサーバー上のレプリカに同じ名前でアクセスできるように、保存されているリソースを場所に依存しない方法で一意に識別する方法が必要です。また、このようなアプリケーションでは、取得されたリソース表現が実際にリソースの要求に使用された名前に対応していることの確認、つまり、ここでは「名前とデータの整合性」と呼ばれる、データと名前の間のバインディングの確認が必要になる場合があります。 。
Similarly, in the context of information-centric networking [NETINF-ARCHITECTURE] [CCN] and elsewhere, there is value in being able to compare a presented resource against the URI that was used to access that resource. If a cryptographically strong comparison function can be used, then this allows for many forms of in-network storage, without requiring as much trust in the infrastructure used to present the resource. The outputs of hash functions can be used in this manner, if they are presented in a standard way.
同様に、情報中心のネットワーキング[NETINF-ARCHITECTURE] [CCN]などのコンテキストでは、提示されたリソースを、そのリソースへのアクセスに使用されたURIと比較できることに価値があります。暗号学的に強力な比較機能を使用できる場合、これにより、リソースを提示するために使用されるインフラストラクチャにそれほど多くの信頼を必要とせずに、さまざまな形式のネットワーク内ストレージが可能になります。ハッシュ関数の出力は、標準的な方法で提示されている場合、この方法で使用できます。
Additional applications might include creating references from web pages delivered over HTTP/TLS; DNS resource records signed using DNSSEC or data values embedded in certificates, Certificate Revocation Lists (CRLs), or other signed data objects.
追加のアプリケーションには、HTTP / TLSを介して配信されるWebページからの参照の作成が含まれる場合があります。 DNSSECを使用して署名されたDNSリソースレコード、または証明書、証明書失効リスト（CRL）、またはその他の署名されたデータオブジェクトに埋め込まれたデータ値。
The Named Identifier can be represented in a number of ways: using the ni URI scheme that we specifically define for the name (which is very similar to the "magnet link" that is informally defined in other protocols [Magnet]), or using other mechanisms also defined herein. However it is represented, the Named Identifier *names* a resource, and the mechanism used to dereference the name and to *locate* the named resource needs to be known by the entity that dereferences it.
名前付き識別子は、いくつかの方法で表すことができます。名前に対して具体的に定義したni URIスキームを使用します（これは、他のプロトコル[マグネット]で非公式に定義されている「マグネットリンク」に非常に似ています）、または他の方法を使用します。メカニズムもここで定義されています。ただし、それが表される場合、名前付き識別子はリソースに*名前*を付け、名前の逆参照と名前付きリソースの*位置特定*に使用されるメカニズムは、逆参照するエンティティによって認識される必要があります。
Media content-type, alternative locations for retrieval, and other additional information about a resource named using this scheme can be provided using a query string. "The Named Information (ni) URI Scheme: Optional Features" [DECPARAMS] describes specific values that can be used in such query strings for these various purposes and other extensions to this basic format specification.
メディアコンテンツタイプ、取得の代替場所、およびこのスキームを使用して命名されたリソースに関するその他の追加情報は、クエリ文字列を使用して提供できます。 「名前付き情報（ni）URIスキーム：オプション機能」[DECPARAMS]は、これらのさまざまな目的およびこの基本的なフォーマット仕様の他の拡張のために、このようなクエリ文字列で使用できる特定の値について説明しています。
In addition, we define a ".well-known" URL equivalent, a way to include a hash as a segment of an HTTP URL, a binary format for use in protocols that require more compact names, and a human-speakable text form that could be used, e.g., for reading out (parts of) the name over a voice connection.
さらに、「。well-known」に相当するURL、HTTP URLのセグメントとしてハッシュを含める方法、よりコンパクトな名前を必要とするプロトコルで使用するバイナリ形式、および人間が話すことができるテキスト形式を定義します。たとえば、音声接続で名前（の一部）を読み取るために使用できます。
Not all uses of these names require use of the full hash output -- truncated hashes can be safely used in some environments. For this reason, we define a new IANA registry for hash functions to be used with this specification so as not to mix strong and weak (truncated) hash algorithms in other protocol registries.
これらの名前のすべての使用が完全なハッシュ出力の使用を必要とするわけではありません-一部の環境では切り捨てられたハッシュを安全に使用できます。このため、他のプロトコルレジストリで強力なハッシュアルゴリズムと弱い（切り捨てられた）ハッシュアルゴリズムが混在しないように、この仕様で使用されるハッシュ関数用の新しいIANAレジストリを定義します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
Syntax definitions in this memo are specified according to ABNF [RFC5234].
このメモの構文定義は、ABNF [RFC5234]に従って指定されています。
This section contains basic considerations related to how we use hash function outputs that are common to all formats.
このセクションには、すべての形式に共通のハッシュ関数出力の使用方法に関する基本的な考慮事項が含まれています。
When comparing two names of the form defined here, an implementation MUST only consider the digest algorithm and the digest value, i.e., it MUST NOT consider other fields defined below (such as an authority field from a URI or any parameters). Implementations MUST consider two hashes identical, regardless of encoding, if the decoded hashes are based on the same algorithm and have the same length and the same binary value. In that case, the two names can be treated as referring to the same thing.
ここで定義されたフォームの2つの名前を比較する場合、実装はダイジェストアルゴリズムとダイジェスト値のみを考慮しなければなりません。つまり、以下で定義されている他のフィールド（URIや任意のパラメーターの認証フィールドなど）を考慮してはなりません。デコードされたハッシュが同じアルゴリズムに基づいており、同じ長さと同じバイナリ値を持っている場合、実装はエンコードに関係なく2つのハッシュを同一と見なさなければなりません（MUST）。その場合、2つの名前は同じものを参照するものとして扱うことができます。
The sha-256 algorithm as specified in [SHA-256] is mandatory to implement; that is, implementations MUST be able to generate/send and to accept/process names based on a sha-256 hash. However, implementations MAY support additional hash algorithms and MAY use those for specific names, for example, in a constrained environment where sha-256 is non-optimal or where truncated names are needed to fit into corresponding protocols (when a higher collision probability can be tolerated).
[SHA-256]で指定されているsha-256アルゴリズムの実装は必須です。つまり、実装は、sha-256ハッシュに基づいて名前を生成/送信および受け入れ/処理できる必要があります。ただし、実装は追加のハッシュアルゴリズムをサポートする場合があり、たとえば、sha-256が最適ではない、または対応するプロトコルに適合するために切り詰められた名前が必要な制約のある環境などで、特定の名前のハッシュアルゴリズムを使用する場合があります（高い衝突確率が発生する可能性がある場合）許容される）。
Truncated hashes MAY be supported. When a hash value is truncated, the name MUST indicate this. Therefore, we use different hash algorithm strings in these cases, such as sha-256-32 for a 32-bit truncation of a sha-256 output. A 32-bit truncated hash is essentially useless for security in almost all cases but might be useful for naming. With current best practices [RFC3766], very few, if any, applications making use of names with less than 100-bit hashes will have useful security properties.
切り捨てられたハッシュがサポートされる場合があります。ハッシュ値が切り捨てられる場合、名前はこれを示さなければなりません（MUST）。したがって、これらのケースでは、sha-256出力の32ビット切り捨て用のsha-256-32など、異なるハッシュアルゴリズム文字列を使用します。 32ビットの切り捨てられたハッシュは、ほとんどすべての場合において本質的にセキュリティには役に立たないが、名前を付けるのに役立つかもしれない。現在のベストプラクティス[RFC3766]では、100ビット未満のハッシュを持つ名前を使用するアプリケーションがあったとしても、有用なセキュリティプロパティはほとんどありません。
When a hash value is truncated to N bits, the leftmost N bits (that is, the most significant N bits in network byte order) from the binary representation of the hash value MUST be used as the truncated value. An example of a 128-bit hash output truncated to 32 bits is shown in Figure 2.
ハッシュ値がNビットに切り捨てられる場合、切り捨てられた値として、ハッシュ値のバイナリ表現の左端のNビット（つまり、ネットワークバイトオーダーの最上位Nビット）を使用する必要があります。 32ビットに切り捨てられた128ビットのハッシュ出力の例を図2に示します。
128-bit hash: 0x265357902fe1b7e2a04b897c6025d7a2 32-bit truncated hash: 0x26535790
128ビットのハッシュ：0x265357902fe1b7e2a04b897c6025d7a2 32ビットの切り捨てられたハッシュ：0x26535790
Figure 2: Example of Truncated Hash
図2：切り捨てられたハッシュの例
When the input to the hash algorithm is a public key value, as may be used by various security protocols, the hash SHOULD be calculated over the public key in an X.509 SubjectPublicKeyInfo structure (Section 4.1 of [RFC5280]). This input has been chosen primarily for compatibility with the DANE TSLA protocol [RFC6698] but also includes any relevant public key parameters in the hash input, which is sometimes necessary for security reasons. This does not force use of X.509 or full compliance with [RFC5280] since formatting any public key as a SubjectPublicKeyInfo is relatively straightforward and well supported by libraries.
ハッシュアルゴリズムへの入力が公開鍵の値である場合、さまざまなセキュリティプロトコルで使用される可能性があるため、ハッシュはX.509 SubjectPublicKeyInfo構造の公開鍵に対して計算する必要があります（[RFC5280]のセクション4.1）。この入力は、主にDANE TSLAプロトコル[RFC6698]との互換性のために選択されましたが、関連する公開鍵パラメーターがハッシュ入力に含まれています。これは、セキュリティ上の理由で必要になる場合があります。これは、X.509の使用または[RFC5280]への完全な準拠を強制するものではありません。公開鍵をSubjectPublicKeyInfoとしてフォーマットすることは比較的簡単で、ライブラリによって十分にサポートされているためです。
Any of the formats defined below can be used to represent the resulting name for a public key.
以下に定義されている形式のいずれかを使用して、公開鍵の結果の名前を表すことができます。
Other than in the aforementioned special case where public keys are used, we do not specify the hash function input here. Other specifications are expected to define this.
前述の公開鍵が使用される特別な場合を除いて、ここではハッシュ関数入力を指定しません。他の仕様がこれを定義すると予想されます。
A Named Information (ni) URI consists of the following nine components:
名前付き情報（ni）URIは、次の9つのコンポーネントで構成されています。
Scheme Name: The scheme name is 'ni'.
スキーム名：スキーム名は「ni」です。
Colon and Slashes: The literal "://"
Authority: The optional authority component may assist applications in accessing the object named by an ni URI. There is no default value for the authority field. (See Section 3.2.2 of [RFC3986] for details.) While ni names with and without an authority differ syntactically from ni names with different authorities, all three refer to the same object if and only if the digest algorithm, length, and value are the same.
権限：オプションの権限コンポーネントは、アプリケーションがni URIで指定されたオブジェクトにアクセスするのを支援します。権限フィールドにはデフォルト値はありません。 （詳細については、[RFC3986]のセクション3.2.2を参照してください。）権限のあるni名と権限のないni名は、異なる権限を持つni名と構文的に異なりますが、ダイジェストアルゴリズム、長さ、および値が一致する場合に限り、3つすべてが同じオブジェクトを参照します。同じだ。
One slash: The literal "/"
スラッシュ1つ：リテラル「/」
Digest Algorithm: The name of the digest algorithm, as specified in the IANA registry defined in Section 9.4 below.
ダイジェストアルゴリズム：以下のセクション9.4で定義されているIANAレジストリで指定されているダイジェストアルゴリズムの名前。
Separator: The literal ";"
区切り文字：リテラル ";"
Digest Value: The digest value MUST be encoded using the base64url [RFC4648] encoding, with no "=" padding characters.
ダイジェスト値：ダイジェスト値は、base64url [RFC4648]エンコーディングを使用して、「=」パディング文字なしでエンコードする必要があります。
Query Parameter separator '?': The query parameter separator acts as a separator between the digest value and the query parameters (if specified). For compatibility with Internationalized Resource Identifiers (IRIs), non-ASCII characters in the query part MUST be encoded as UTF-8, and the resulting octets MUST be percent-encoded (see [RFC3986], Section 2.1).
クエリパラメータセパレータ '？'：クエリパラメータセパレータは、ダイジェスト値とクエリパラメータ（指定されている場合）の間のセパレータとして機能します。国際化リソース識別子（IRI）との互換性のために、クエリ部分の非ASCII文字はUTF-8としてエンコードする必要があり、結果のオクテットはパーセントエンコードする必要があります（[RFC3986]、セクション2.1を参照）。
Query Parameters: A "tag=value" list of optional query parameters as are used with HTTP URLs [RFC2616] with a separator character '&' between each. For example, "foo=bar&baz=bat".
クエリパラメータ：HTTP URL [RFC2616]で使用されるオプションのクエリパラメータの「tag = value」リスト。各パラメータの間に区切り文字「＆」が付いています。たとえば、「foo = bar＆baz = bat」です。
It is OPTIONAL for implementations to check the integrity of the URI/ resource mapping when sending, receiving, or processing ni URIs.
実装がni URIを送信、受信、または処理するときにURI /リソースマッピングの整合性をチェックすることはオプションです。
Escaping of characters follows the rules in RFC 3986. This means that percent-encoding is used to distinguish between reserved and unreserved functions of the same character in the same URI component.
文字のエスケープは、RFC 3986のルールに従います。これは、パーセントエンコーディングを使用して、同じURIコンポーネント内の同じ文字の予約済み関数と予約されていない関数を区別することを意味します。
As an example, an ampersand ('&') is used in the query part to separate attribute-value pairs; therefore, an ampersand in a value has to be escaped as '%26'. Note that the set of reserved characters differs for each component. As an example, a slash ('/') does not have any reserved function in a query part and therefore does not have to be escaped. However, it can still appear escaped as '%2f' or '%2F', and implementations have to be able to understand such escaped forms. Also note that any characters outside those allowed in the respective URI component have to be escaped.
例として、アンパサンド（ '＆'）をクエリ部分で使用して、属性と値のペアを区切ります。したがって、値のアンパサンドは '％26'としてエスケープする必要があります。予約文字のセットはコンポーネントごとに異なることに注意してください。例として、スラッシュ（ '/'）はクエリ部分に予約済み関数がないため、エスケープする必要はありません。ただし、エスケープされた '％2f'または '％2F'として表示される可能性があり、実装はこのようなエスケープされたフォームを理解できる必要があります。また、それぞれのURIコンポーネントで許可されている文字以外の文字はエスケープする必要があることに注意してください。
The Named Information URI adapts the URI definition from the URI Generic Syntax [RFC3986]. We start with the base URI production:
Named Information URIは、URI Generic Syntax [RFC3986]のURI定義を適合させます。まず、ベースURIの生成から始めます。
URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ]
; from RFC 3986
Figure 3: URI Syntax
ふぃぐれ ３： うり Ｓｙんたｘ
Then, we adapt that for the Named Information URI:
次に、それを名前付き情報URIに適合させます。
NI-URI = ni-scheme ":" ni-hier-part [ "?" query ]
; adapted from "URI" in RFC 3986
; query is from RFC 3986, Section 3.4
ni-scheme = "ni"
ni-hier-part = "//" [ authority ] "/" alg-val
; authority is from RFC 3986, Section 3.2
alg-val = alg ";" val
; adapted from "hier-part" in RFC 3986
alg = 1*unreserved
val = 1*unreserved
; unreserved is from RFC 3986, Section 2.3
Figure 4: ni Name Syntax
ふぃぐれ ４： に なめ Ｓｙんたｘ
The "val" field MUST contain the output of base64url encoding (with no "=" padding characters), the result of applying the hash function ("alg") to its defined input, which defaults to the object bytes that are expected to be returned when the URI is dereferenced.
「val」フィールドには、base64urlエンコーディングの出力（「=埋め込み文字なし」）、ハッシュ関数（「alg」）を定義済みの入力に適用した結果が含まれている必要があります。デフォルトでは、予期されるオブジェクトバイトに設定されます。 URIが逆参照されると返されます。
Relative ni URIs can occur. In such cases, the algorithm in Section 5 of [RFC3986] applies. As an example, in Figure 5, the absolute URI for "this third document" is "ni://example.com/sha-256-128;...".
相対ni URIが発生する可能性があります。そのような場合、[RFC3986]のセクション5のアルゴリズムが適用されます。例として、図5では、「この3番目のドキュメント」の絶対URIは「ni：//example.com/sha-256-128; ...」です。
<html>
<head>
<title>ni: relative URI test</title>
<base href="ni://example.com">
</head>
<body>
<p>Please check <a href="sha-256;f4OxZX...">this document</a>.
and <a href="sha-256;UyaQV...">this other document</a>.
and <a href="sha-256-128;...">this third document</a>.
</p>
</body>
</html>
Figure 5: Example HTML with Relative ni URI
図5：相対ni URIを使用したHTMLの例
The authority field in an ni URI is not quite the same as that from an HTTP URL, even though the same values (e.g., DNS names) may be usefully used in both. For an ni URI, the authority does not control nearly as much of the structure of the "right-hand side" of the URI. With ni URIs we also define standard query string attributes and, of course, have a strictly defined way to include the hash value.
同じ値（DNS名など）が両方で有効に使用されている場合でも、ni URIの権限フィールドはHTTP URLの権限フィールドとまったく同じではありません。 ni URIの場合、権限はURIの「右側」の構造のほとんどを制御しません。 ni URIを使用して、標準のクエリ文字列属性も定義します。もちろん、ハッシュ値を含める方法は厳密に定義されています。
Internationalisation of strings within ni names is handled exactly as for http URIs -- see [RFC2616], Section 3.2.3.
ni名内の文字列の国際化は、http URIと同様に処理されます。[RFC2616]のセクション3.2.3を参照してください。
The semantics of a digest being used to establish a secure reference from an authenticated source to an external source may be a function of associated metadata such as the Content Type. The Content Type "ct" parameter specifies the MIME Content Type of the associated data as defined in [RFC6838]. See Section 9.5 for the associated IANA registry for ni parameter names as shown in Figure 6. Implementations of this specification MUST support parsing the "ct=" query string attribute name.
認証されたソースから外部ソースへの安全な参照を確立するために使用されるダイジェストのセマンティクスは、コンテンツタイプなどの関連するメタデータの関数である場合があります。 Content Type "ct"パラメータは、[RFC6838]で定義されている関連データのMIME Content Typeを指定します。図6に示すように、niパラメータ名の関連するIANAレジストリについては、セクション9.5を参照してください。この仕様の実装では、「ct =」クエリ文字列属性名の解析をサポートする必要があります。
ni:///sha-256-32;f4OxZQ?ct=text/plain
Figure 6: Example ni URI with Content Type
図6：コンテンツタイプを含むni URIの例
Protocols making use of ni URIs will need to specify how to verify name-data integrity for the MIME Content Types that they need to process and will need to take into account possible Content-Transfer-Encodings and other aspects of MIME encoding.
ni URIを使用するプロトコルは、処理する必要のあるMIMEコンテンツタイプの名前とデータの整合性を検証する方法を指定する必要があり、可能なContent-Transfer-EncodingsおよびMIMEエンコーディングの他の側面を考慮する必要があります。
Implementations of this specification SHOULD support name-data integrity validation for at least the application/octet-stream Content Type, with no explicit Content-Transfer-Encoding (which is equivalent to binary). Additional Content Types and Content-Transfer-Encodings can of course also be supported, but are OPTIONAL. Note that the hash is calculated after the Content-Transfer-Encoding is removed so it is applied to the raw data.
この仕様の実装は、明示的なContent-Transfer-Encoding（バイナリと同等）なしで、少なくともapplication / octet-streamコンテンツタイプの名前とデータの整合性検証をサポートする必要があります（SHOULD）。追加のコンテンツタイプとContent-Transfer-Encodingsももちろんサポートできますが、オプションです。ハッシュはContent-Transfer-Encodingが削除された後に計算されるため、生データに適用されることに注意してください。
If a) the user agent is sensitive to the Content Type and b) the ni name used has a "ct=" query string attribute and c) the object is retrieved (from a server) using a protocol that specifies a Content Type, then, if the two Content Types match, all is well. If, in this situation, the Content Types do not match, then the client SHOULD handle that situation as a potential security error. Content Type matching rules are defined in [RFC2045], Section 5.1.
a）ユーザーエージェントがコンテンツタイプの影響を受け、b）使用されるni名に "ct ="クエリ文字列属性があり、c）オブジェクトが（サーバーから）コンテンツタイプを指定するプロトコルを使用して取得される場合、 、2つのコンテンツタイプが一致する場合は、すべて順調です。この状況でコンテンツタイプが一致しない場合、クライアントはその状況を潜在的なセキュリティエラーとして処理する必要があります（SHOULD）。コンテンツタイプの一致ルールは、[RFC2045]のセクション5.1で定義されています。
We define a mapping between URIs following the ni URI scheme and HTTP [RFC2616] or HTTPS [RFC2818] URLs that makes use of the .well-known URI [RFC5785] by defining an "ni" suffix (see Section 9).
「ni」サフィックスを定義することにより、ni URIスキームに続くURIと、.well-known URI [RFC5785]を利用するHTTP [RFC2616]またはHTTPS [RFC2818] URL間のマッピングを定義します（セクション9を参照）。
The HTTP(S) mapping MAY be used in any context where clients with support for ni URIs are not available.
HTTP（S）マッピングは、ni URIをサポートするクライアントが利用できない状況で使用できます。
Since the .well-known name-space is not intended for general information retrieval, if an application dereferences a .well-known/ni URL via HTTP(S), then it will often receive a 3xx HTTP redirection response. A server responding to a request for a .well-known/ni URL will often therefore return a 3xx response, and a client sending such a request MUST be able to handle that, as should any fully compliant HTTP [RFC2616] client.
.well-known名前空間は一般的な情報の取得を目的としていないため、アプリケーションがHTTP（S）を介して.well-known / ni URLを逆参照すると、多くの場合、3xx HTTPリダイレクト応答を受け取ります。したがって、.well-known / ni URLの要求に応答するサーバーは3xx応答を返すことが多く、そのような要求を送信するクライアントは、完全に準拠したHTTP [RFC2616]クライアントと同様に、それを処理できなければなりません（MUST）。
For an ni name of the form "ni://n-authority/alg;val?query-string" the corresponding HTTP(S) URL produced by this mapping is "http://h-authority/.well-known/ni/alg/val?query-string", where "h-authority" is derived as follows: If the ni name has a specified authority (i.e., the n-authority is non-empty), then the h-authority MUST have the same value. If the ni name has no authority specified (i.e., the n-authority string is empty), a h-authority value MAY be derived from the application context. For example, if the mapping is being done in the context of a web page, then the origin [RFC6454] for that web site can be used. Of course, in general there are no guarantees that the object named by the ni URI will be available via the corresponding HTTP(S) URL. But in the case that any data is returned, the retriever can determine whether or not it is content that matches the ni URI.
「ni：// n-authority / alg; val？query-string」形式のni名の場合、このマッピングによって生成される対応するHTTP（S）URLは「http：//h-authority/.well-known/ ni / alg / val？query-string "、ここで" h-authority "は次のように導出されます：ni名に指定された権限がある（つまり、n-authorityが空ではない）場合、h-authorityは同じ値。 ni名に権限が指定されていない場合（n-authority文字列が空の場合）、h-authority値はアプリケーションコンテキストから派生してもよい（MAY）。たとえば、マッピングがWebページのコンテキストで行われている場合、そのWebサイトのオリジン[RFC6454]を使用できます。もちろん、一般的に、ni URIで指定されたオブジェクトが対応するHTTP（S）URL経由で利用できるという保証はありません。ただし、データが返された場合、検索機能は、それがni URIと一致するコンテンツであるかどうかを判別できます。
If an application is presented with an HTTP(S) URL with "/.well-known/ni/" as the start of its pathname component, then the reverse mapping to an ni URI either including or excluding the authority might produce an ni URI that is meaningful. However, there is no guarantee that this will be the case.
アプリケーションに、パス名コンポーネントの先頭に "/.well-known/ni/"を含むHTTP（S）URLが提示された場合、権限を含むまたは除外するni URIへの逆マッピングにより、ni URIが生成される可能性があります。それは意味があります。ただし、これが当てはまるという保証はありません。
When mapping from an ni URI to a .well-known URL, an implementation will have to decide between choosing an "http" or "https" URL. If the object referenced does in fact match the hash in the URL, then there is arguably no need for additional data integrity, if the ni URI or .well-known URL was received "securely." However, TLS also provides confidentiality, so there can still be reasons to use the "https" URL scheme even in this case. Additionally, web server policy such as [RFC6797] may dictate that data only be available over "https". In general, however, whether to use "http" or "https" is something that needs to be decided by the application.
ni URIから.well-known URLにマッピングする場合、実装は「http」または「https」のどちらのURLを選択するかを決定する必要があります。参照されるオブジェクトが実際にURLのハッシュと一致する場合、ni URIまたは.well-known URLが「安全に」受信された場合、追加のデータ整合性はおそらく必要ありません。ただし、TLSは機密性も提供するため、この場合でも「https」URLスキームを使用する理由がまだある可能性があります。さらに、[RFC6797]などのWebサーバーポリシーでは、データが「https」経由でのみ利用可能であると規定されている場合があります。ただし、一般に、「http」と「https」のどちらを使用するかは、アプリケーションで決定する必要があります。
Some applications may benefit from using hashes in existing HTTP URLs or other URLs. To do this, one simply uses the "alg-val" production from the ni name scheme ABNF, which may be included, for example, in the pathname, query string, or even fragment components of HTTP URLs [RFC2616]. In such cases, there is nothing present in the URL that ensures that a client can depend on compliance with this specification, so clients MUST NOT assume that any URL with a pathname component that matches the "alg-val" production was in fact produced as a result of this specification. That URL might or might not be related to this specification, only the context will tell.
一部のアプリケーションは、既存のHTTP URLまたは他のURLでハッシュを使用することで利益を得る可能性があります。これを行うには、パス名、クエリ文字列、またはHTTP URL [RFC2616]のフラグメントコンポーネントなどに含まれる可能性があるni名スキームABNFからの「alg-val」生成を使用するだけです。このような場合、クライアントがこの仕様への準拠に依存できることを保証するURLには何も存在しないため、クライアントは、「alg-val」生成と一致するパス名コンポーネントを持つURLが実際に次のように生成されたと想定してはなりません。この仕様の結果。そのURLはこの仕様に関連する場合としない場合があり、コンテキストのみが通知します。
If a more space-efficient version of the name is needed, the following binary format can be used. The binary format name consists of two fields: a header and the hash value. The header field defines how the identifier has been created, and the hash value contains a (possibly truncated) result of a one-way hash over whatever is being identified by the hash value. The binary format of a name is shown in Figure 7.
よりスペース効率の良いバージョンの名前が必要な場合は、次のバイナリ形式を使用できます。バイナリ形式の名前は、ヘッダーとハッシュ値の2つのフィールドで構成されます。ヘッダーフィールドは、識別子がどのように作成されたかを定義し、ハッシュ値には、ハッシュ値によって識別されているものに対する一方向ハッシュの（おそらく切り捨てられた）結果が含まれます。名前のバイナリ形式を図7に示します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Res| Suite ID | Hash Value /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ... /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ... |
+-+-+-+-+-+-+-+-+
Figure 7: Binary Name Format
図7：バイナリ名の形式
The Res field is a reserved 2-bit field for future use and MUST be set to zero for this specification and ignored on receipt.
Resフィールドは、将来の使用のために予約された2ビットのフィールドであり、この仕様ではゼロに設定し、受信時に無視する必要があります。
The hash algorithm and truncation length are specified by the Suite ID. For maintaining efficient encoding for the binary format, only a few hash algorithms and truncation lengths are supported. See Section 9.4 for details.
ハッシュアルゴリズムと切り捨ての長さは、スイートIDによって指定されます。バイナリ形式の効率的なエンコーディングを維持するために、サポートされているハッシュアルゴリズムと切り捨て長さはわずかです。詳細については、9.4項を参照してください。
A hash value that is truncated to 120 bits will result in the overall name being a 128-bit value, which may be useful for protocols that can easily use 128-bit identifiers.
120ビットに切り捨てられたハッシュ値は、全体的な名前が128ビットの値になるため、128ビットの識別子を簡単に使用できるプロトコルに役立ちます。
Sometimes a resource may need to be referred to via a name in a format that is easy for humans to read out and less likely to be ambiguous when heard. This is intended to be usable, for example, over the phone in order to confirm the (current or future) presence or absence of a resource. This "confirmation" use-case described further in Section 8.3 is the main current use-case for Named Information for Humans (nih) URIs. ("nih" also means "Not Invented Here", which is clearly false, and therefore worth including [RFC5513]. :-)
リソースは、人間が読みやすく、聞いたときにあいまいになる可能性が低い形式の名前で参照する必要がある場合があります。これは、リソースの（現在または将来の）存在または不在を確認するために、たとえば電話で使用できるようにすることを目的としています。セクション8.3でさらに説明するこの「確認」ユースケースは、名前付き情報の人間（nih）URIの現在の主なユースケースです。 （ "nih"は "Not Invented Here"も意味します。これは明らかに誤りであり、したがって[RFC5513]を含める価値があります。:-)
The ni URI format is not well-suited for this, as, for example, base64url uses both uppercase and lowercase, which can easily cause confusion. For this particular purpose ("speaking" the value of a hash output), the more verbose but less ambiguous (when spoken) nih URI scheme is defined.
たとえば、base64urlは大文字と小文字の両方を使用するため、ni URI形式はこれにはあまり適していません。この特定の目的（ハッシュ出力の値を「話す」）のために、より詳細ですが（あいまいでない場合）あいまいさが少ないnih URIスキームが定義されています。
The justification for nih being a URI scheme is that it can help a user agent for the speaker to better display the value or help a machine to better speak or recognise the value when spoken. We do not include the query string since there is no way to ensure that its value might be spoken unambiguously and similarly for the authority, where, e.g., some internationalised forms of domain name might not be easy to speak and comprehend easily. This leaves the hash value as the only part of the ni URI that we feel can be usefully included. But since speakers or listeners (or speech recognition) may err, we also include a checkdigit to catch common errors and allow for the inclusion of "-" separators to make nih URIs easier to read out.
nihがURIスキームであることの正当性は、話者のユーザーエージェントが値をより適切に表示したり、機械が話したり値を認識したりするのに役立つことです。クエリ文字列は含まれていません。その値が明確に、また当局に対して同様に話されることを保証する方法がないためです。たとえば、一部の国際化された形式のドメイン名は、簡単に話したり理解したりすることが難しい場合があります。これにより、ハッシュ値がni URIの唯一の部分として残り、便利に含めることができると考えられます。ただし、スピーカーまたはリスナー（または音声認識）はエラーになる可能性があるため、一般的なエラーをキャッチし、「-」区切り文字を含めてnih URIを読みやすくするためのチェックデジットも含めます。
Fields in nih URIs are separated by a semicolon (;) character. The first field is a hash algorithm string, as in the ni URI format. The hash value is represented using lowercase ASCII hex characters; for example, an octet with the decimal value 58 (0x3A) is encoded as '3a'. This is the same as base16 encoding as defined in RFC 4648 [RFC4648] except using lowercase letters. Separators ("-" characters) MAY be interspersed in the hash value in any way to make those easier to read, typically grouping four or six characters with a separator between.
nih URIのフィールドは、セミコロン（;）文字で区切られます。最初のフィールドは、ni URI形式のようなハッシュアルゴリズム文字列です。ハッシュ値は小文字のASCII 16進文字を使用して表されます。たとえば、10進数の値が58（0x3A）のオクテットは「3a」としてエンコードされます。これは、小文字を使用することを除いて、RFC 4648 [RFC4648]で定義されているbase16エンコーディングと同じです。区切り文字（ "-"文字）を読みやすくするために、ハッシュ値に任意の方法で散在させることができます。通常、区切り文字を使用して4文字または6文字をグループ化します。
The hash value MAY be followed by a semicolon ';' then a checkdigit. The checkdigit MUST be calculated using Luhn's mod N algorithm (with N=16) as defined in [ISOIEC7812] (see also [Luhn]). The input to the calculation is the ASCII hex-encoded hash value (i.e., "sepval" in the ABNF production below) but with all "-" separator characters first stripped out. This maps the ASCII hex so that '0'=0, ...'9'=9, 'a'=10, ...'f'=15. None of the other fields, nor any "-" separators, are input when calculating the checkdigit.
ハッシュ値の後にはセミコロン「;」が続く場合があります。次にチェックディジット。チェックディジットは、[ISOIEC7812]で定義されているように、Luhnのmod Nアルゴリズム（N = 16）を使用して計算する必要があります（[Luhn]も参照）。計算への入力は、ASCII 16進エンコードされたハッシュ値（つまり、以下のABNFプロダクションでは「sepval」）ですが、すべての「-」区切り文字が最初に取り除かれています。これにより、ASCII 16進数がマッピングされ、「0」= 0、...「9」= 9、「a」= 10、...「f」= 15となります。チェックディジットを計算するときに、他のフィールドも「-」区切り文字も入力されません。
humanname = "nih:" alg-sepval [ ";" checkdigit ]
alg-sepval = alg ";" sepval
sepval = 1*(ahlc / "-")
ahlc = DIGIT / "a" / "b" / "c" / "d" / "e" / "f"
; DIGIT is defined in RFC 5234 and is 0-9
checkdigit = ahlc
Figure 8: Human-Speakable Syntax
図8：人間が話すことができる構文
For algorithms that have a Suite ID reserved (see Figure 11), the alg field MAY contain the ID value as an ASCII-encoded decimal number instead of the hash name string (for example, "3" instead of "sha-256-120"). Implementations MUST be able to match the decimal ID values for the algorithms and hash lengths that they support, even if they do not support the binary format.
スイートIDが予約されているアルゴリズムの場合（図11を参照）、algフィールドにはID値がハッシュ名文字列ではなくASCIIエンコードされた10進数として含まれる場合があります（たとえば、「sha-256-120ではなく「3」 "）。実装は、バイナリ形式をサポートしていない場合でも、それらがサポートするアルゴリズムとハッシュ長の10進数ID値と一致する必要があります。
There is no such thing as a relative nih URI.
相対nih URIのようなものはありません。
The following ni URI is generated from the text "Hello World!" (12 characters without the quotes), using the sha-256 algorithm shown with and without an authority field:
次のni URIは、「Hello World！」というテキストから生成されます。 （引用符なしの12文字）、権限フィールドがある場合とない場合のsha-256アルゴリズムを使用：
ni:///sha-256;f4OxZX_x_FO5LcGBSKHWXfwtSx-j1ncoSt3SABJtkGk
ni://example.com/sha-256;f4OxZX_x_FO5LcGBSKHWXfwtSx-j1ncoSt3SABJtkGk
The following HTTP URL represents a mapping from the previous ni name based on the algorithm outlined above.
次のHTTP URLは、上記で概説したアルゴリズムに基づく以前のni名からのマッピングを表しています。
http://example.com/.well-known/ni/sha-256/
f4OxZX_x_FO5LcGBSKHWXfwtSx-j1ncoSt3SABJtkGk
Given the DER-encoded SubjectPublicKeyInfo in Figure 9, we derive the names shown in Figure 10 for this value.
図9のDERエンコードされたSubjectPublicKeyInfoを前提として、図10に示すこの値の名前を導出します。
0000000 30 82 01 22 30 0d 06 09 2a 86 48 86 f7 0d 01 01 0000020 01 05 00 03 82 01 0f 00 30 82 01 0a 02 82 01 01 0000040 00 a2 5f 83 da 9b d9 f1 7a 3a 36 67 ba fd 5a 94 0000060 0e cf 16 d5 5a 55 3a 5e d4 03 b1 65 8e 6d cf a3 0000100 b7 db a4 e7 cc 0f 52 c6 7d 35 1d c4 68 c2 bd 7b 0000120 9d db e4 0a d7 10 cd f9 53 20 ee 0d d7 56 6e 5b 0000140 7a ae 2c 5f 83 0a 19 3c 72 58 96 d6 86 e8 0e e6 0000160 94 eb 5c f2 90 3e f3 a8 8a 88 56 b6 cd 36 38 76 0000200 22 97 b1 6b 3c 9c 07 f3 4f 97 08 a1 bc 29 38 9b 0000220 81 06 2b 74 60 38 7a 93 2f 39 be 12 34 09 6e 0b 0000240 57 10 b7 a3 7b f2 c6 ee d6 c1 e5 ec ae c5 9c 83 0000260 14 f4 6b 58 e2 de f2 ff c9 77 07 e3 f3 4c 97 cf 0000300 1a 28 9e 38 a1 b3 93 41 75 a1 a4 76 3f 4d 78 d7 0000320 44 d6 1a e3 ce e2 5d c5 78 4c b5 31 22 2e c7 4b 0000340 8c 6f 56 78 5c a1 c4 c0 1d ca e5 b9 44 d7 e9 90 0000360 9c bc ee b0 a2 b1 dc da 6d a0 0f f6 ad 1e 2c 12 0000400 a2 a7 66 60 3e 36 d4 91 41 c2 f2 e7 69 39 2c 9d 0000420 d2 df b5 a3 44 95 48 7c 87 64 89 dd bf 05 01 ee 0000440 dd 02 03 01 00 01
0000000 30 82 01 22 30 0d 06 09 2a 86 48 86 f7 0d 01 01 0000020 01 05 00 03 82 01 0f 00 30 82 01 0a 02 82 01 01 0000040 00 a2 5f 83 da 9b d9 f1 7a 3a 36 67 ba fd 5a 94 0000060 0e cf 16 d5 5a 55 3a 5e d4 03 b1 65 8e 6d cf a3 0000100 b7 db a4 e7 cc 0f 52 c6 7d 35 1d c4 68 c2 bd 7b 0000 120 9d db e4 0a d7 10 cd f9 53 20 ee 0d d7 56 6e 5b 0000 140 7a ae 2c 5f 83 0a 19 3c 72 58 96 d6 86 e8 0e e6 0000 160 94 eb 5c f2 90 3e f3 a8 8a 88 56 b6 cd 36 38 76 0000 200 22 97 b1 6b 3c 9c 07 f3 4f 97 08 a1 bc 29 38 9b 0000 220 81 06 2b 74 60 38 7a 93 2f 39 be 12 34 09 6e 0b 0000 240 57 10 b7 a3 7b f2 c6 ee d6 c1 e5 ec ae c5 9c 83 0000 260 14 f4 6b 58 e2 de f2 ff c9 77 07 e3 f3 4c 97 cf 0000300 1a 28 9e 38 a1 b3 93 41 75 a1 a4 76 3f 4d 78 d7 0000 320 44 d6 1a e3 ce e2 5d c5 78 4c b5 31 22 2e c7 4b 0000 340 8c 6f 56 78 5c a1 c4 c0 1d ca e5 b9 44 d7 e9 90 0000 360 9c bc ee b0 a2 b1 dc da 6d a0 0f f6 ad 1e 2c 12 0000 400 a2 a7 66 60 3e 36 d4 91 41 c2 f2 e7 69 39 2c 9d 0000 420 d2 df b5 a3 44 95 48 7c 87 64 89 dd bf 0 5 01 ee 0000 440 dd 02 03 01 00 01
0000000 53 26 90 57 e1 2f e2 b7 4b a0 7c 89 25 60 a2 d7 0000020 53 87 7e b6 2f f4 4d 5a 19 00 25 30 ed 97 ff e4
0000000 53 26 90 57 e1 2f e2 b7 4b a0 7c 89 25 60 a2 d7 0000020 53 87 7e b6 2f f4 4d 5a 19 00 25 30 ed 97 ff e4
Figure 9: A SubjectPublicKeyInfo Used in Examples and Its sha-256 Hash
図9：例で使用されているSubjectPublicKeyInfoとそのsha-256ハッシュ
+-------------------------------------------------------------------+
| URI: |
| ni:///sha-256;UyaQV-Ev4rdLoHyJJWCi11OHfrYv9E1aGQAlMO2X_-Q |
+-------------------------------------------------------------------+
| .well-known URL (split over 2 lines): |
| http://example.com/.well-known/ni/sha256/ |
| UyaQV-Ev4rdLoHyJJWCi11OHfrYv9E1aGQAlMO2X_-Q |
+-------------------------------------------------------------------+
| URL Segment: |
| sha-256;UyaQV-Ev4rdLoHyJJWCi11OHfrYv9E1aGQAlMO2X_-Q |
+-------------------------------------------------------------------+
| Binary name (ASCII hex encoded) with 120-bit truncated hash value |
| which is Suite ID 0x03: |
| 0353 2690 57e1 2fe2 b74b a07c 8925 60a2 |
+-------------------------------------------------------------------+
| Human-speakable form of a name for this key (truncated to 120 bits|
| in length) with checkdigit: |
| nih:sha-256-120;5326-9057-e12f-e2b7-4ba0-7c89-2560-a2;f |
+-------------------------------------------------------------------+
| Human-speakable form of a name for this key (truncated to 32 bits |
| in length) with checkdigit and no "-" separators: |
| nih:sha-256-32;53269057;b |
+-------------------------------------------------------------------+
| Human-speakable form using decimal presentation of the |
| algorithm ID (sha-256-120) with checkdigit: |
| nih:3;532690-57e12f-e2b74b-a07c89-2560a2;f |
+-------------------------------------------------------------------+
Figure 10: Example Names
図10：名前の例
Alice has set up a server node with an RSA key pair. She uses an ni URI as the name for the public key that corresponds to the private key on that box. Alice's node might identify itself using that ni URI in some protocol.
アリスは、RSAキーペアでサーバーノードを設定しました。彼女は、そのボックスの秘密鍵に対応する公開鍵の名前としてni URIを使用します。アリスのノードは、いくつかのプロトコルでそのni URIを使用してそれ自体を識別する場合があります。
Bob would like to believe that it's really Alice's node when his node interacts with the network and asks his friend Alice to tell him what public key she uses. Alice hits the "tell someone the name of the public key" button on her admin user interface and that displays the nih URI and says "tell this to your buddy". She phones Bob and reads the nih URI to him.
ボブは、自分のノードがネットワークと対話し、友人のアリスに彼女が使用している公開鍵を教えるように依頼するとき、それは本当にアリスのノードであると信じたいと思います。アリスは、管理者ユーザーインターフェイスの[公開キーの名前を誰かに知らせる]ボタンを押すと、nih URIが表示され、「これをあなたの仲間に伝えます」と言います。彼女はボブに電話をかけ、彼にnih URIを読みます。
Bob types that in to his "manage known nodes" admin application (or lets that application listen to part of the call), which can regenerate the ni URI and store that or some equivalent. Then when Bob's node interacts with Alice's node, it can more safely accept a signature or encrypt data to Alice's node.
Bobは、「既知のノードを管理する」管理アプリケーションに入力します（または、そのアプリケーションに呼び出しの一部をリッスンさせます）。これにより、ni URIを再生成し、それまたは同等のものを保存できます。次に、ボブのノードがアリスのノードと対話するとき、署名をより安全に受け入れるか、データをアリスのノードに暗号化できます。
The procedures for registration of a URI scheme are specified in RFC 4395 [RFC4395]. The following assignment has been made.
URIスキームの登録手順はRFC 4395 [RFC4395]で指定されています。次の割り当てが行われました。
URI scheme name: ni
うり ｓちぇめ なめ： に
Status: Permanent
ステータス：永久
URI scheme syntax: See Section 3.
URIスキームの構文：セクション3を参照してください。
URI scheme semantics: See Section 3.
URIスキームのセマンティクス：セクション3を参照してください。
Encoding considerations: See Section 3.
エンコードに関する考慮事項：セクション3を参照してください。
Applications/protocols that use this URI scheme name:
このURIスキーム名を使用するアプリケーション/プロトコル：
General applicability.
一般的な適用性。
Interoperability considerations: Defined here.
相互運用性に関する考慮事項：ここで定義されています。
Security considerations: See Section 10.
セキュリティに関する考慮事項：セクション10を参照してください。
Contact: Stephen Farrell, stephen.farrell@cs.tcd.ie
連絡先：Stephen Farrell、stephen.farrell @ cs.tcd.ie
Author/Change controller: IETF
作成者/変更コントローラ：IETF
References: As specified in this document
参照：このドキュメントで指定されているとおり
The procedures for registration of a URI scheme are specified in RFC 4395 [RFC4395]. The following assignment has been made.
URIスキームの登録手順はRFC 4395 [RFC4395]で指定されています。次の割り当てが行われました。
URI scheme name: nih
URIスキーム名：nih
Status: Permanent
ステータス：永久
URI scheme syntax: See Section 7.
URIスキームの構文：セクション7を参照してください。
URI scheme semantics: See Section 7.
URIスキームのセマンティクス：セクション7を参照
Encoding considerations: See Section 7.
エンコードに関する考慮事項：セクション7を参照してください。
Applications/protocols that use this URI scheme name:
このURIスキーム名を使用するアプリケーション/プロトコル：
General applicability.
一般的な適用性。
Interoperability considerations: Defined here.
相互運用性に関する考慮事項：ここで定義されています。
Security considerations: See Section 10.
セキュリティに関する考慮事項：セクション10を参照してください。
Contact: Stephen Farrell, stephen.farrell@cs.tcd.ie
連絡先：Stephen Farrell、stephen.farrell @ cs.tcd.ie
Author/Change controller: IETF
作成者/変更コントローラ：IETF
References: As specified in this document
参照：このドキュメントで指定されているとおり
The procedures for registration of a Well-Known URI entry are specified in RFC 5785 [RFC5785]. The following assignment has been made.
既知のURIエントリの登録手順は、RFC 5785 [RFC5785]で指定されています。次の割り当てが行われました。
URI suffix: ni
うり すっふぃｘ： に
Change controller: IETF
コントローラの変更：IETF
Specification document(s): This document
仕様書：この文書
Related information: None
関連情報：なし
IANA has created a new registry for hash algorithms as used in the name formats specified here; it is called the "Named Information Hash Algorithm Registry". Future assignments are to be made through Expert Review [RFC5226]. This registry has five fields: the suite ID, the hash algorithm name string, the truncation length, the underlying algorithm reference, and a status field that indicates if the algorithm is current or deprecated and should no longer be used. The status field can have the value "current" or "deprecated". Other values are reserved for possible future definition.
IANAは、ここで指定された名前形式で使用されるハッシュアルゴリズムの新しいレジストリを作成しました。これは、「名前付き情報ハッシュアルゴリズムレジストリ」と呼ばれます。今後の割り当ては、専門家レビュー[RFC5226]を通じて行われます。このレジストリには5つのフィールドがあります。スイートID、ハッシュアルゴリズム名の文字列、切り捨ての長さ、基になるアルゴリズム参照、およびアルゴリズムが最新であるか非推奨であり、今後使用しないかを示すステータスフィールドです。ステータスフィールドの値は、「現在」または「非推奨」にすることができます。その他の値は、将来の定義のために予約されています。
If the status is "current", then that does not necessarily mean that the algorithm is "good" for any particular purpose, since the cryptographic strength requirements will be set by other applications or protocols.
ステータスが「現在」の場合、暗号強度の要件は他のアプリケーションまたはプロトコルによって設定されるため、特定の目的に対してアルゴリズムが「良好」であるとは限りません。
A request to mark an entry as "deprecated" can be done by sending a mail to the Designated Expert. Before approving the request, the community MUST be consulted via a "call for comments" of at least two weeks by sending a mail to the IETF discussion list.
エントリーを「非推奨」としてマークする要求は、Designated Expertにメールを送信することで実行できます。リクエストを承認する前に、IETFディスカッションリストにメールを送信して、少なくとも2週間の「コメント募集」を介してコミュニティに相談する必要があります。
Initial values are specified below. The Designated Expert SHOULD generally approve additions that reference hash algorithms that are widely used in other IETF protocols. In addition, the Designated Expert SHOULD NOT accept additions where the underlying hash function (with no truncation) is considered weak for collisions. Part of the reasoning behind this last point is that inclusion of code for weak hash functions, e.g., the MD5 algorithm, can trigger costly false positives if code is audited for inclusion of obsolete ciphers. See [RFC6149], [RFC6150], and [RFC6151] for examples of some hash functions that are considered obsolete in this sense.
初期値は以下のとおりです。 Designated Expertは一般に、他のIETFプロトコルで広く使用されているハッシュアルゴリズムを参照する追加を承認する必要があります（SHOULD）。さらに、Designated Expertは、基になるハッシュ関数（切り捨てなし）が衝突に対して弱いと見なされる追加を受け入れるべきではありません（SHOULD NOT）。この最後のポイントの背後にある理由の1つは、MD5アルゴリズムなどの弱いハッシュ関数のコードを含めると、コードが古い暗号の包含について監査された場合に、コストのかかる誤検知を引き起こす可能性があることです。この意味で廃止されたと見なされるいくつかのハッシュ関数の例については、[RFC6149]、[RFC6150]、および[RFC6151]を参照してください。
The suite ID field ("ID") can be empty or can have values between 0 and 63, inclusive. Because there are only 64 possible values, this field is OPTIONAL (leaving it empty if omitted). Where the binary format is not expected to be used for a given hash algorithm, this field SHOULD be omitted. If an entry is registered without a suite ID, the Designated Expert MAY allow for later allocation of a suite ID, if that appears warranted. The Designated Expert MAY consult the community via a "call for comments" by sending a mail to the IETF discussion list before allocating a suite ID.
スイートIDフィールド（ "ID"）は空にすることも、0〜63の値にすることもできます。可能な値は64しかないため、このフィールドはオプションです（省略した場合は空のままにします）。バイナリ形式が特定のハッシュアルゴリズムで使用されることが想定されていない場合、このフィールドは省略してください。スイートIDなしでエントリが登録されている場合、指定されたエキスパートは、スイートIDを後で割り当てられることを許可してもよい（MAY）。 Designated Expertは、スイートIDを割り当てる前にIETFディスカッションリストにメールを送信することにより、「コメント募集」を介してコミュニティに相談することができます。
ID Hash Name String Value Length Reference Status 0 Reserved 1 sha-256 256 bits [SHA-256] current 2 sha-256-128 128 bits [SHA-256] current 3 sha-256-120 120 bits [SHA-256] current 4 sha-256-96 96 bits [SHA-256] current 5 sha-256-64 64 bits [SHA-256] current 6 sha-256-32 32 bits [SHA-256] current 32 Reserved
IDハッシュ名文字列値長さ参照ステータス0予約済み1 sha-256 256ビット[SHA-256]現在2 sha-256-128 128ビット[SHA-256]現在3 sha-256-120 120ビット[SHA-256]現在4 sha-256-96 96ビット[SHA-256]現在5 sha-256-64 64ビット[SHA-256]現在6 sha-256-32 32ビット[SHA-256]現在32予約済み
Figure 11: Suite Identifiers
図11：スイート識別子
The Suite ID value 32 is reserved for compatibility with IPv6 addresses from the Special Purpose Address Registry [RFC4773], such as Overlay Routable Cryptographic Hash Identifiers (ORCHIDs) [RFC4843].
スイートID値32は、オーバーレイルーティング可能な暗号化ハッシュ識別子（ORCHID）[RFC4843]など、特別目的アドレスレジストリ[RFC4773]のIPv6アドレスとの互換性のために予約されています。
The referenced hash algorithm matching the Suite ID, truncated to the length indicated, according to the description given in Section 2, is used for generating the hash. The Designated Expert is responsible for ensuring that the document referenced for the hash algorithm meets the "specification required" rule.
セクション2の説明に従って、指定された長さに切り捨てられた、スイートIDに一致する参照ハッシュアルゴリズムが、ハッシュの生成に使用されます。 Designated Expertは、ハッシュアルゴリズムで参照されるドキュメントが「必要な仕様」のルールを確実に満たすようにする責任があります。
IANA has created a new registry entitled "Named Information URI Parameter Definitions".
IANAは、「名前付き情報URIパラメータ定義」という名前の新しいレジストリを作成しました。
The policy for future assignments to the registry is Expert Review, and as for the ni Hash Algorithm Registry above, the Designated Expert is responsible for ensuring that the document referenced for the parameter definition meets the "specification required" rule.
レジストリへの今後の割り当てのポリシーはエキスパートレビューであり、上記のniハッシュアルゴリズムレジストリと同様に、指定されたエキスパートは、パラメータ定義で参照されるドキュメントが「必要な仕様」のルールを満たすことを保証する責任があります。
The fields in this registry are the parameter name, a description, and a reference. The parameter name MUST be such that it is suitable for use as a query string parameter name in an ni URI. (See Section 3.)
このレジストリのフィールドは、パラメーター名、説明、および参照です。パラメータ名は、ni URIでクエリ文字列パラメータ名として使用するのに適した名前にする必要があります。 （セクション3を参照。）
The initial contents of the registry are:
レジストリの初期内容は次のとおりです。
Parameter Meaning Reference
----------- -------------------------------------------- ---------
ct Content Type [RFC6920]
No secret information is required to generate or verify a name of the form described here. Therefore, a name like this can only provide evidence for the integrity of the referenced object, and the proof of integrity provided is only as good as the proof of integrity for the name from which we started. In other words, the hash value can provide a name-data integrity binding between the name and the bytes returned when the name is dereferenced using some protocol.
ここで説明するフォームの名前を生成または検証するために秘密情報は必要ありません。したがって、このような名前は、参照されるオブジェクトの整合性の証拠を提供するだけであり、提供される整合性の証明は、開始した名前の整合性の証明と同じくらい優れています。言い換えると、ハッシュ値は、名前が何らかのプロトコルを使用して逆参照されたときに返される名前とバイトの間の名前とデータの整合性バインディングを提供できます。
Disclosure of a name value does not necessarily entail disclosure of the referenced object but may enable an attacker to determine the contents of the referenced object by reference to a search engine or other data repository or, for a highly formatted object with little variation, by simply guessing the value and checking if the digest value matches. So, the fact that these names contain hashes does not protect the confidentiality of the object that was input to the hash.
名前の値の開示は、必ずしも参照オブジェクトの開示を伴うものではありませんが、攻撃者が検索エンジンまたは他のデータリポジトリを参照することによって、またはほとんど変化のない高度にフォーマットされたオブジェクトの場合、単に参照オブジェクトの内容を特定できる可能性があります値を推測し、ダイジェスト値が一致するかどうかを確認します。したがって、これらの名前にハッシュが含まれているという事実は、ハッシュに入力されたオブジェクトの機密性を保護しません。
The integrity of the referenced content would be compromised if a weak hash function were used. SHA-256 is currently our preferred hash algorithm; this is why we've added only SHA-256-based suites to the initial IANA registry.
弱いハッシュ関数が使用された場合、参照されるコンテンツの整合性が損なわれます。現在、SHA-256が推奨されるハッシュアルゴリズムです。これが、初期のIANAレジストリにSHA-256ベースのスイートのみを追加した理由です。
If a truncated hash value is used, certain security properties will be affected. In general, a hash algorithm is designed to produce sufficient bits to prevent a 'birthday attack' collision occurring. Ensuring that the difficulty of discovering two pieces of content that result in the same digest with a work factor O(2^x) by brute force requires a digest length of 2x. Many security applications only require protection against a second pre-image attack, which only requires a digest length of x to achieve the same work factor. Basically, the shorter the hash value used, the less security benefit you can possibly get.
切り捨てられたハッシュ値が使用される場合、特定のセキュリティプロパティが影響を受けます。一般に、ハッシュアルゴリズムは、「誕生日攻撃」の衝突の発生を防ぐのに十分なビットを生成するように設計されています。ブルートフォースによって仕事係数O（2 ^ x）で同じダイジェストを生成する2つのコンテンツを発見することの難しさを保証するには、ダイジェストの長さを2xにする必要があります。多くのセキュリティアプリケーションは、2番目のプリイメージ攻撃に対する保護のみを必要とします。これは、同じ作業係数を達成するためにxのダイジェスト長のみを必要とします。基本的に、使用するハッシュ値が短いほど、得られるセキュリティ上の利点は少なくなります。
An important thing to keep in mind is not to make the mistake of thinking two names are the same when they aren't. For example, a name with a 32-bit truncated sha-256 hash is not the same as a name with the full 256 bits of hash output, even if the hash value for one is a prefix of that for the other.
覚えておくべき重要なことは、2つの名前が同じでない場合に同じであると誤解しないことです。たとえば、32ビットの短縮されたsha-256ハッシュの名前は、一方のハッシュ値が他方のハッシュ値のプレフィックスであっても、ハッシュ出力の完全な256ビットの名前と同じではありません。
The reason for this is that if an application treats these as the same name, then that might open up a number of attacks. For example, if I publish an object with the full hash, then I probably (in general) don't want some other application to treat a name with just the first 32 bits of that as referring to the same thing, since the 32-bit name will have lots of colliding objects. If ni or nih URIs become widely used, there will be many cases where names will occur more than once in application protocols, and it'll be unpredictable which instance of the name would be used for name-data integrity checking, thus leading to threats. For this reason, we require that the algorithm, length, and value all match before we consider two names to be the same.
これは、アプリケーションがこれらを同じ名前として扱う場合、多くの攻撃を受ける可能性があるためです。たとえば、完全なハッシュを使用してオブジェクトを公開する場合、おそらく他のアプリケーションで、最初の32ビットのみの名前を同じものを参照するものとして扱うことを望まないでしょう。ビット名には衝突するオブジェクトがたくさんあります。 niまたはnih URIが広く使用されるようになると、アプリケーションプロトコルで名前が2回以上出現する場合が多くなり、名前データの整合性チェックに使用される名前のインスタンスが予測できなくなり、脅威につながります。 。このため、2つの名前が同じであると見なす前に、アルゴリズム、長さ、値をすべて一致させる必要があります。
The fact that an ni URI includes a domain name in the authority field by itself implies nothing about the relationship between the owner of the domain name and any content referenced by that URI. While a name-data integrity service can be provided using ni URIs, that does not in any sense validate the authority part of the name. For example, there is nothing to stop anyone from creating an ni URI containing a hash of someone else's content. Application developers MUST NOT assume any relationship between the registrant of the domain name that is part of an ni URI and some matching content just because the ni URI matches that content.
ni URI自体が権限フィールドにドメイン名を含むという事実は、ドメイン名の所有者とそのURIによって参照されるコンテンツとの関係については何も意味しません。名前とデータの整合性サービスはni URIを使用して提供できますが、名前の権限部分は検証されません。たとえば、誰かが他の誰かのコンテンツのハッシュを含むni URIを作成するのを妨げるものは何もありません。アプリケーション開発者は、ni URIがそのコンテンツに一致するからといって、ni URIの一部であるドメイン名の登録者と一致するコンテンツとの関係を想定してはなりません。
If name-data integrity is successfully validated, and the hash is strong and long enough, then the "web origin" [RFC6454] for the bytes of the named object is really going to be the place from which you get the ni name and not the place from which you get the bytes of the object. This appears to offer a potential benefit if using ni names for scripts included from a HTML page accessed via server-authenticated https, for example. If name-data integrity is not validated (and it is optional) or fails, then the web origin is, as usual, the place from which the object bytes were received. Applications making use of ni names SHOULD take this into account in their trust models.
名前とデータの整合性が正常に検証され、ハッシュが強力で十分に長い場合、名前付きオブジェクトのバイトの「Webオリジン」[RFC6454]は、実際にはni名を取得する場所であり、ni名を取得する場所ではありません。オブジェクトのバイトを取得する場所。これは、たとえばサーバー認証のhttpsを介してアクセスされるHTMLページからインクルードされたスクリプトにni名を使用する場合に、潜在的な利点を提供するようです。名前とデータの整合性が検証されない（オプションである）か失敗した場合、Webの原点は、通常どおり、オブジェクトのバイトが受信された場所です。 ni名を使用するアプリケーションは、信頼モデルでこれを考慮する必要があります（SHOULD）。
Some implementations might mishandle ni URIs that include non-base64 characters, whitespace, or other non-conforming strings, and that could lead to erroneously considering names to be the same when they are not. An ni URI that is malformed in such ways MUST NOT be treated as matching any other ni URI. Implementers need to check the behaviour of libraries for such parsing problems.
一部の実装では、base64以外の文字、空白、またはその他の非準拠の文字列を含むni URIを誤って処理する可能性があり、そうでない場合、名前が同じであると誤って見なす可能性があります。このような方法で不正なni URIは、他のni URIと一致するものとして扱われてはいけません。実装者は、このような解析の問題についてライブラリの動作を確認する必要があります。
This work has been supported by the EU FP7 project SAIL. The authors would like to thank SAIL participants to our naming discussions, especially Jean-Francois Peltier, for their input.
この作業は、EU FP7プロジェクトSAILによってサポートされています。著者は、私たちのネーミングディスカッション、特にJean-Francois Peltierへの意見を提供してくれたSAIL参加者に感謝します。
The authors would also like to thank Carsten Bormann, Martin Duerst, Tobias Heer, Bjoern Hoehrmann, Tero Kivinen, Barry Leiba, Larry Masinter, David McGrew, Alexey Melnikov, Bob Moskowitz, Jonathan Rees, Eric Rescorla, Zach Shelby, and Martin Thomas for their comments and input to the document. Thanks, in particular, to James Manger for correcting the examples.
著者はまた、Carsten Bormann、Martin Duerst、Tobias Heer、Bjoern Hoehrmann、Tero Kivinen、Barry Leiba、Larry Masinter、David McGrew、Alexey Melnikov、Bob Moskowitz、Jonathan Rees、Eric Rescorla、Zach Shelby、およびMartin Thomasにも感謝します。彼らのコメントとドキュメントへの入力。特に、例を修正してくれたJames Mangerに感謝します。
[ISOIEC7812] ISO, "Identification cards -- Identification of issuers -- Part 1: Numbering system", ISO/IEC 7812-1:2006, October 2006, <http://www.iso.org/iso/iso_catalogue/ catalogue_tc/catalogue_detail.htm?csnumber=39698>.
[ISOIEC7812] ISO、「IDカード-発行者の識別-パート1：番号付けシステム」、ISO / IEC 7812-1：2006、2006年10月、<http://www.iso.org/iso/iso_catalogue/ catalogue_tc /catalogue_detail.htm?csnumber=39698>。
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[RFC2045] Freed、N。およびN. Borenstein、「Multipurpose Internet Mail Extensions（MIME）Part One：Format of Internet Message Bodies」、RFC 2045、1996年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、「Hypertext Transfer Protocol-HTTP / 1.1」 、RFC 2616、1999年6月。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2818] Rescorla、E。、「HTTP over TLS」、RFC 2818、2000年5月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、STD 66、RFC 3986、2005年1月。
[RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and Registration Procedures for New URI Schemes", BCP 35, RFC 4395, February 2006.
[RFC4395] Hansen、T.、Hardie、T。、およびL. Masinter、「新しいURIスキームのガイドラインと登録手順」、BCP 35、RFC 4395、2006年2月。
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006.
[RFC4648] Josefsson、S。、「The Base16、Base32、およびBase64データエンコーディング」、RFC 4648、2006年10月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234] Crocker、D。およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、2008年1月。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[RFC5280] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R。、およびW. Polk、「Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List（CRL）Profile "、RFC 5280、2008年5月。
[RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known Uniform Resource Identifiers (URIs)", RFC 5785, April 2010.
[RFC5785]ノッティンガム、M。およびE.ハマーラハブ、「Defining Well-Known Uniform Resource Identifiers（URIs）」、RFC 5785、2010年4月。
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, January 2013.
[RFC6838] Freed、N.、Klensin、J。、およびT. Hansen、「メディアタイプの仕様と登録手順」、BCP 13、RFC 6838、2013年1月。
[SHA-256] NIST, "Secure Hash Standard", FIPS 180-3, October 2008, <http://csrc.nist.gov/publications/fips/fips180-3/ fips180-3_final.pdf>.
[SHA-256] NIST、「Secure Hash Standard」、FIPS 180-3、2008年10月、<http://csrc.nist.gov/publications/fips/fips180-3/ fips180-3_final.pdf>。
[CCN] Jacobson, V., Smetters, D., Thornton, J., Plass, M., Briggs, N., and R. Braynard, "Networking Named Content", Proceedings of the 5th international conference on Emerging networking experiments and technologies (CoNEXT '09), December 2009.
[CCN] Jacobson、V.、Smetters、D.、Thornton、J.、Plass、M.、Briggs、N。、およびR. Braynard、「Networking Named Content」、第5回国際ネットワーキング会議の議事録テクノロジー（CoNEXT '09）、2009年12月。
[DECPARAMS] Hallam-Baker, P., Stradling, R., Farrell, S., Kutscher, D., and B. Ohlman, "The Named Information (ni) URI Scheme: Optional Features", Work in Progress, June 2012.
[DECPARAMS] Hallam-Baker、P.、Stradling、R.、Farrell、S.、Kutscher、D。、およびB. Ohlman、「名前付き情報（ni）URIスキーム：オプション機能」、作業中、2012年6月。
[Luhn] Wikipedia, "Luhn mod N algorithm", September 2011, <http://en.wikipedia.org/w/ index.php?title=Luhn_mod_N_algorithm&oldid=449928878>.
[Luhn] Wikipedia、「Luhn mod Nアルゴリズム」、2011年9月、<http://en.wikipedia.org/w/ index.php？Title = Luhn_mod_N_algorithm＆oldid = 449928878>。
[Magnet] Wikipedia, "Magnet URI scheme", March 2013, <http://en.wikipedia.org/w/ index.php?title=Magnet_URI_scheme&oldid=546892719>.
[マグネット] Wikipedia、「マグネットURIスキーム」、2013年3月、<http://en.wikipedia.org/w/ index.php？title = Magnet_URI_scheme＆oldid = 546892719>。
[NETINF-ARCHITECTURE] Dannewitz, C., Kutscher, D., Ohlman, B., Farrell, S., Ahlgren, B., and M. Karl, "Network of Information (NetInf) - An information-centric networking architecture", Computer Communications, Volume 36, Issue 7, pages 721-735, ISSN 0140-3664, 1 April 2013, <http://www.sciencedirect.com/science/article/pii/ S0140366413000364>.
[NETINF-ARCHITECTURE] Dannewitz、C.、Kutscher、D.、Ohlman、B.、Farrell、S.、Ahlgren、B。、およびM. Karl、「情報ネットワーク（NetInf）-情報中心のネットワークアーキテクチャ」 、コンピュータ通信、第36巻、第7号、721-735ページ、ISSN 0140-3664、2013年4月1日、<http://www.sciencedirect.com/science/article/pii/ S0140366413000364>。
[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For Public Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766, April 2004.
[RFC3766] Orman、H。およびP. Hoffman、「Determining Strengths for Public Keys Exchangeing Symmetric Keys」、BCP 86、RFC 3766、2004年4月。
[RFC4773] Huston, G., "Administration of the IANA Special Purpose IPv6 Address Block", RFC 4773, December 2006.
[RFC4773] Huston、G。、「Administration of the IANA Special Purpose IPv6 Address Block」、RFC 4773、2006年12月。
[RFC4843] Nikander, P., Laganier, J., and F. Dupont, "An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers (ORCHID)", RFC 4843, April 2007.
[RFC4843] Nikander、P.、Laganier、J。、およびF. Dupont、「オーバーレイ可能なルーティング可能な暗号化ハッシュ識別子（ORCHID）のIPv6プレフィックス」、RFC 4843、2007年4月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[RFC5513] Farrel, A., "IANA Considerations for Three Letter Acronyms", RFC 5513, April 1 2009.
[RFC5513] Farrel、A。、「3文字の頭字語に関するIANAの考慮事項」、RFC 5513、2009年4月1日。
[RFC6149] Turner, S. and L. Chen, "MD2 to Historic Status", RFC 6149, March 2011.
[RFC6149]ターナー、S。およびL.チェン、「MD2 to Historic Status」、RFC 6149、2011年3月。
[RFC6150] Turner, S. and L. Chen, "MD4 to Historic Status", RFC 6150, March 2011.
[RFC6150]ターナー、S。およびL.チェン、「MD4 to Historic Status」、RFC 6150、2011年3月。
[RFC6151] Turner, S. and L. Chen, "Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms", RFC 6151, March 2011.
[RFC6151]ターナー、S。およびL.チェン、「MD5メッセージダイジェストおよびHMAC-MD5アルゴリズムの更新されたセキュリティに関する考慮事項」、RFC 6151、2011年3月。
[RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, December 2011.
[RFC6454]バース、A。、「The Web Origin Concept」、RFC 6454、2011年12月。
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA", RFC 6698, August 2012.
[RFC6698] Hoffman、P。およびJ. Schlyter、「DNSベースの名前付きエンティティの認証（DANE）トランスポート層セキュリティ（TLS）プロトコル：TLSA」、RFC 6698、2012年8月。
[RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict Transport Security (HSTS)", RFC 6797, November 2012.
[RFC6797] Hodges、J.、Jackson、C。、およびA. Barth、「HTTP Strict Transport Security（HSTS）」、RFC 6797、2012年11月。
Authors' Addresses
著者のアドレス
Stephen Farrell Trinity College Dublin Dublin, 2 Ireland Phone: +353-1-896-2354 EMail: stephen.farrell@cs.tcd.ie
Stephen Farrell Trinity College Dublin Dublin、2 Ireland電話：+ 353-1-896-2354メール：stephen.farrell@cs.tcd.ie
Dirk Kutscher NEC Kurfuersten-Anlage 36 Heidelberg Germany EMail: kutscher@neclab.eu
Dirk Kutscher NEC Kurfuersten-Anlage 36ハイデルベルクドイツEメール：kutscher@neclab.eu
Christian Dannewitz University of Paderborn Paderborn Germany EMail: cdannewitz@googlemail.com
クリスチャンダンネウィッツ大学パーダーボルン大学パーダーボルンドイツEメール：cdannewitz@googlemail.com
Borje Ohlman Ericsson Stockholm S-16480 Sweden EMail: Borje.Ohlman@ericsson.com
Borje Ohlman EricssonストックホルムS-16480スウェーデンEメール：Borje.Ohlman@ericsson.com
Ari Keranen Ericsson Jorvas 02420 Finland EMail: ari.keranen@ericsson.com
あり けらねん えりｃっそん じょｒゔぁｓ ０２４２０ ふぃんぁんｄ えまいｌ： あり。けらねん＠えりｃっそん。こｍ
Phillip Hallam-Baker Comodo Group Inc. EMail: philliph@comodo.com
Phillip Hallam-Baker Comodo Group Inc.メール：philliph@comodo.com