One document matched: draft-farrell-decade-ni-03.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC1035 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1035.xml">
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC5280 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5280.xml">
<!ENTITY RFC3552 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml">
<!ENTITY RFC3642 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3642.xml">
<!ENTITY RFC4033 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4033.xml">
<!ENTITY RFC4055 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4055.xml">
<!ENTITY RFC5395 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5395.xml">
<!ENTITY RFC5050 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5050.xml">
<!ENTITY RFC5226 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.xml">
<!-- Defines the URI Syntax -->
<!ENTITY RFC3986 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3986.xml">
<!-- Design guide -->
<!ENTITY RFC4395 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4395.xml">
<!-- Defines the well known services URL positions -->
<!ENTITY RFC5785 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5785.xml">
<!-- Defines the URI safe BASE64 encoding mechanism -->
<!ENTITY RFC4648 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4648.xml">
<!-- Defines the Cryptographic Algorithm registry-->
<!ENTITY RFC5698 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5698.xml">
<!-- Defines sha-256 identifier -->
<!ENTITY RFC4055 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4055.xml">
<!--MIME Media Type Registry -->
<!ENTITY RFC4288 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4288.xml">
<!ENTITY RFC4843 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4843.xml">
<!ENTITY RFC6454 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6454.xml">
<!-- ABNF -->
<!ENTITY RFC5234 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5234.xml">
<!ENTITY I-D.ietf-dane-protocol SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-dane-protocol.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="no" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="std" ipr="trust200902" submissionType="independent" docName="draft-farrell-decade-ni-03">
<front>
<title abbrev="Naming Things with Hashes">Naming Things with Hashes</title>
<author fullname="Stephen Farrell" initials="S."
surname="Farrell">
<organization>Trinity College Dublin</organization>
<address>
<postal>
<street></street>
<!-- Reorder these if your country does things differently -->
<city>Dublin</city>
<region></region>
<code>2</code>
<country>Ireland</country>
</postal>
<phone>+353-1-896-2354</phone>
<email>stephen.farrell@cs.tcd.ie</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Dirk Kutscher" initials="D."
surname="Kutscher">
<organization>NEC</organization>
<address>
<postal>
<street>Kurfuersten-Anlage 36</street>
<!-- Reorder these if your country does things differently -->
<city>Heidelberg</city>
<region></region>
<code></code>
<country>Germany</country>
</postal>
<phone></phone>
<email>kutscher@neclab.eu</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Christian Dannewitz" initials="C" surname="Dannewitz">
<organization>University of Paderborn</organization>
<address>
<postal>
<street></street>
<city>Paderborn</city>
<!--code> 12345</code-->
<country>Germany</country>
</postal>
<email>cdannewitz@upb.de</email>
</address>
</author>
<author fullname="Borje Ohlman" initials="B" surname="Ohlman">
<organization>Ericsson</organization>
<address>
<postal>
<street></street>
<code> S-16480</code>
<city>Stockholm</city>
<country>Sweden</country>
</postal>
<email>Borje.Ohlman@ericsson.com</email>
</address>
</author>
<author initials="A." surname="Keranen" fullname="Ari Keranen">
<organization>Ericsson</organization>
<address>
<postal>
<street/>
<city>Jorvas</city> <code>02420</code>
<country>Finland</country>
</postal>
<email>ari.keranen@ericsson.com</email>
</address>
</author>
<author fullname="Phillip Hallam-Baker" initials="P. M." surname="Hallam-Baker">
<organization>Comodo Group Inc.</organization>
<address>
<email>philliph@comodo.com</email>
</address>
</author>
<date month="April" year="2012" />
<area>General</area>
<workgroup>Internet Engineering Task Force</workgroup>
<keyword>Cryptography</keyword>
<keyword>URI</keyword>
<keyword>Information Centric Networking</keyword>
<abstract>
<t>
This document defines a set of ways to identify a
thing using the output from a hash function, specifying
URI, URL, 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.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
Names or identifiers are used in various protocols for identifying resources.
In many scenarios those names or identifiers contain values that are hash
function outputs. However, different deployments have chosen various different
ways to include hash function outputs in such names or identifiers. This
document specifies standard ways to do that to aid interoperability.
</t>
<t>
Hash function outputs can be used to ensure uniqueness in terms
of mapping URIs <xref target="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, while in other situations people may have
to input such values or talk about them, e.g., in a voice call.
</t>
<t>
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 verifying that a resource representation that has been
obtained actually corresponds to the name that was used to request the
resource, i.e., verifying the name-content binding.
</t>
<t>
Similarly, in the context of information-centric networking
<xref target="ref.netinf-design"/> <xref target="ref.ccn"/>
and elsewhere there is value in being able to compare a
presented resource against the URI that was dereferenced in
order 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
presented in a standard way.
</t>
<t>
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.
</t>
<!--
<t>
Accordingly, a standard form of name using a hash outout allows for checking of the
integrity of the name-content mapping, but it is OPTIONAL for
implementations to do so when sending, receiving or processing
these name forms.
</t>
-->
<t>
The new URI scheme defined here allows for the use of a
query-string, similar to how query-strings are used in HTTP
URLs. A companion specification <xref target="niexts"/>
describes specific values that can be used in such query
strings for various purposes and other extensions to this
basic format specification.
</t>
<t>The "ni" URI scheme defined here is very similar to the "magnet
link" informally defined in various other protocols. <xref target="magnet"/>
</t>
<t>
In addition to the URI form we also define a ".well-known"
URL equivalent, and a way to include a hash as a segment
of an HTTP URL,
as well as 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.
</t>
<t>
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 hash
algorithms in other protocol registries.
</t>
<t>
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 <xref target="RFC2119">RFC 2119</xref>.
</t>
<t>
Syntax definitions in this memo are specified according to
ABNF <xref target="RFC5234"/>.
</t>
<t>[[Comments are included in double-square brackets, like this.]]</t>
</section>
<section anchor="basics" title="Basics">
<t>This section contains basic considerations common to all
formats.</t>
<t>
When verifying whether two names refer to same object, an
implementation MUST only consider the digest algorithm identifier
and the digest value, i.e., it MUST NOT consider the authority
field from a URI or any parameters and MUST consider two
hashes identical regardless of encoding, if they encode
the same binary value, and are the same length.
</t>
<t>
The sha-256 algorithm as specified in <xref target="RFC4055"/> 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).
</t>
<t>Truncated hashes MAY be supported if needed. When a hash value is
truncated the name MUST indicate this. Therefore we use different hash algorithm
strings for these, such as sha-256-32 for a 32-bit truncation of a sha-256
output. (Note that a 32-bit truncated hash is essentially useless for
security but might be useful for naming.)</t>
<t>When a hash value is truncated to N bits the left-most or
most significant in network byte order N bits 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 <xref target="fig-trunc"/>. </t>
<figure anchor="fig-trunc" title="Example of Truncated Hash">
<artwork>
<![CDATA[
128-bit hash: 0x265357902fe1b7e2a04b897c6025d7a2
32-bit truncated hash: 0x26535790
]]></artwork></figure>
<t> 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 <xref
target="RFC5280"/>). This input has been chosen primarily for
compatibility with DANE <xref target="I-D.ietf-dane-protocol"/>, but also includes any relevant
public key parameters in the hash input, which is sometimes
necessary for security reasons. Note also that this does not force
use of X.509 or full compliance with <xref target="RFC5280"/>
since formatting any public key as a SubjectPublicKeyInfo is
relatively straightforward and well supported by libraries. </t>
<t>Any of the formats defined below can be used to represent the
resulting name for a public key.</t>
<t>Other than in the above special case where public keys are used,
we do not specify the hash function input here.
Other specifications are expected to define this.</t>
</section>
<section anchor="syntax" title="Named Information (ni) URI Format">
<t>
A Named Information (ni) URI consists of the following components:
</t>
<t>
<list style="hanging">
<t hangText="Scheme Name [Required]">The scheme name is 'ni'.
</t>
<t hangText="Colon and Slashes [Required]">The literal "://" </t>
<t hangText="Authority [Optional]">
The optional authority component may assist applications in
accessing the object named by an ni URI. Note that while the
ni names with and without an authority differ syntactically,
both names will almost always refer to the same object.
</t>
<t hangText="One slash [Required]">The literal "/" </t>
<t hangText="Digest Algorithm [Required]">
The name of the digest algorithm, as specified in the IANA registry
defined in <xref target="IANAbin"/> below.
</t>
<t hangText="Separator [Required]">The literal ";" </t>
<t hangText="Digest Value [Required]">
The digest value encoded in the specified encoding.
</t>
<t hangText="Query Parameter separator [Optional] '?'">
The query parameter separator acts a
separator between the digest value
and the query parameters (if specified).
</t>
<t hangText="Query Parameters [Optional]">
A tag=value list of optional query parameters as are used with HTTP URLs.
</t>
</list>
</t>
<t>
It is OPTIONAL for implementations to check the integrity of the
URI/resource mapping when sending, receiving or processing "ni"
URIs.
</t>
<t>
The digest value MUST be encoded using base64url
<xref target="RFC4648"/> encoding.
</t>
<t> The query segment of an URI is NOT hierarchical. Thus escape
encoding of slash '/' characters is NOT required. Since application code often
attempts to enforce such encoding, decoders MUST recognize the use of URI
escape encoding (e.g., '%2f' or '%2F' for the slash character). Section 3.4 of
<xref target="RFC3986"/> states that "The characters slash ("/") and question
mark ("?") may represent data within the query component."
</t>
<t>[[The above is maybe ambiguous, 'cause we're not sure of what's right.
Is it better to say "decoders MUST treat %2f as /" or that they MUST NOT
do that, or that the world's a nasty place so you just need to know when
to do which?]]</t>
<t>
Consequently no special escaping mechanism is required for the
query parameter portion of ni URIs. URI escaping is however frequently
imposed automatically by scripting environments. Thus to
ensure interoperability, implementations SHOULD NOT generate URIs that
employ URI character escaping, and implementations MUST NOT reject any
URIs that employ URI character escaping.
</t>
<t>
The Named Information URI has the following syntax:
</t>
<figure title="ni Name syntax" anchor="fig_abnf">
<artwork type="abnf">
niname ="ni://" [ authority ] "/" algval [ "?" query ]
algval = alg ";" val
alg = 1*unreserved
val = 1*unreserved
unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
</artwork>
</figure>
<t>Note that "unreserved" is defined in the URI specification <xref
target="RFC3986"/> Section 2.3, in the way shown above. The "authority" and
"query" types are also from the URI specification. <xref target="RFC3986"/>
</t>
<t>
The "val" field MUST contain the output 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.
</t>
</section>
<section title=".well-known URL Format">
<t>
We define a mapping between URIs following the ni URI scheme and HTTP or
HTTPS URLs that makes use of the .well-known URI <xref target="RFC5785"/> by defining an
"ni" suffix (see <xref target="IANACons"/>).
</t>
<t>
The HTTP(S) mapping MAY be used in any context where clients
without support for ni URIs are needed without loss
of interoperability or functionality.
</t>
<t>
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
<xref target="RFC6454"/> for that web site can be used. Of course, there are in general no
guarantees that the object named by the ni URI will be available at 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.
</t>
<t>
If an application is presented with a 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, but there is no guarantee that this will be the
case.
</t>
<t>
When mapping from a 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 may still be reasons to use the "https" URL scheme even in this
case. In general however, whether to use "http" or "https" is something
that needs to be decided by the application.
</t>
</section>
<section anchor="url-frag" title="URL Segment Format">
<t>Some applications may benefit from using hashes in existing HTTP URLs or
other URLs. To do this one simply uses the "algval" production from the
ni name scheme ABNF which may be included in the pathname component of
HTTP URLs. 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 "algval" 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.
</t>
</section>
<section anchor="binary-format" title="Binary Format">
<t> When a more space-efficient version of the name is needed, we
can use a binary format. 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 the whatever is
being identified by the hash value. The format of the binary
representation of a name is shown in <xref
target="fig-format"/>. </t>
<figure anchor="fig-format" title="Binary Name Format">
<artwork align="center">
<![CDATA[
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 /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ... /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ... |
+-+-+-+-+-+-+-+-+
]]></artwork></figure>
<t> The Res field is a reserved 2-bit field for future use and MUST
be set to zero for this specification.</t>
<t> The hash algorithm and truncation length are specified by the Suite
ID. For maintaining efficient encoding for the binary presentation,
only a few hash algorithms and truncation lengths are supported. See
Section <xref target="IANAbin"/> for details.</t>
<t>Note that a hash value that is truncated to 120 bits will
result in the overall name being a 128-bit value which may be
useful with certain use-cases.</t>
</section>
<section anchor="nihsyntax" title="Human-readable Format">
<t>[[Comment on apps-discuss asked about using "ni:" for this, but
might be that then the abnf is too complex and easily confused, so
I think a different scheme is warranted here, so how about "nih"?
Hard-to-resist acronym anyway:-) ]] </t>
<t> Sometimes the name may need to be used in a format that is easy
for humans to read and possibly communicate, for example, over the
phone. For this purpose, the following more verbose but less
ambiguous (when spoken) URI format is defined with scheme name
"nih," standing for "Named Information for Humans," (or
possibly jokingly for for "Not Invented Here," which is clearly false,
and therefore worth including:-) </t>
<t> As with the ni URI format, nih URI fields are separated by a
semi-colon (;) character. The first field is a hash algorithm
string, as in the ni URI format. Then the hash value is encoded
using base32 encoding <xref target="RFC4648"/> and lower-case
alphabets. Since the length of the hash value is known from the hash
algorithm string, padding characters are not needed and SHOULD NOT
be used when the result of the base32 encoding is used in the hash
value field. When decoding the base32-encoded string, only first N
bits of the result, depending on the truncation as indicated by the
hash algorithm string, MUST be used. </t>
<t> The hash value is OPTIONALLY followed by a checksum. The checksum MUST be
calculated as a crc16 over the following parts: the URI scheme and separator
("nih:"), the algorithm string, the first delimiter, (";") the base32 encoding
of the hash value, and
the second delimiter (also ";"). The result of crc16 is encoded like the hash
value with base32 encoding and lower-case alphabets (only the first 4
characters of the base32 encoded result are used to exclude padding). </t>
<t>The crc16 MUST use the CRC-CCITT polynomial: x^16 + x^12 + x^5 +
1.</t>
<t>[[CCITT crc16 needs a proper reference]]</t>
<figure title="Human-readable syntax" anchor="fig_human">
<artwork type="abnf">
humanname = "nih: " algval [ ";" checksum ]
algval = alg ";" val
alg = 1*unreserved
val = 1*unreserved
checksum = 1*unreserved
</artwork>
</figure>
</section>
<section title="Examples">
<t>
The following ni URI references the text
"Hello World!" (without the quotes, being 12 characters),
using the SHA-2 algorithm with 256-bit
output and no authority field:
</t>
<t>ni:///sha-256;A7ogTlDRJuRnTABeBNguhMITZngK8fQ71Uo3gWtqs0A</t>
<t>And the same example shown with an authority would be:</t>
<t>ni://example.com/sha-256;A7ogTlDRJuRnTABeBNguhMITZngK8fQ71Uo3gWtqs0A</t>
<t>The following HTTP URL represents a mapping from the
previous ni name based on the algorithm outlined above.
</t>
<t>http://example.com/.well-known/ni/sha-256/A7ogTlDRJuRnTABeBNguhMITZngK8fQ71Uo3gWtqs0A</t>
<t> Given the SubjectPublicKeyInfo in <xref target="eg-spki"/>
we derive the names shown in <xref target="eg-names"/> for
this value.</t>
<figure anchor="eg-spki" title="A SubjectPublicKeyInfo used in examples and its sha-256 hash">
<artwork>
<![CDATA[
0000000 82 01 0a 02 82 01 01 00 a2 5f 83 da 9b d9 f1 7a
0000020 3a 36 67 ba fd 5a 94 0e cf 16 d5 5a 55 3a 5e d4
0000040 03 b1 65 8e 6d cf a3 b7 db a4 e7 cc 0f 52 c6 7d
0000060 35 1d c4 68 c2 bd 7b 9d db e4 0a d7 10 cd f9 53
0000100 20 ee 0d d7 56 6e 5b 7a ae 2c 5f 83 0a 19 3c 72
0000120 58 96 d6 86 e8 0e e6 94 eb 5c f2 90 3e f3 a8 8a
0000140 88 56 b6 cd 36 38 76 22 97 b1 6b 3c 9c 07 f3 4f
0000160 97 08 a1 bc 29 38 9b 81 06 2b 74 60 38 7a 93 2f
0000200 39 be 12 34 09 6e 0b 57 10 b7 a3 7b f2 c6 ee d6
0000220 c1 e5 ec ae c5 9c 83 14 f4 6b 58 e2 de f2 ff c9
0000240 77 07 e3 f3 4c 97 cf 1a 28 9e 38 a1 b3 93 41 75
0000260 a1 a4 76 3f 4d 78 d7 44 d6 1a e3 ce e2 5d c5 78
0000300 4c b5 31 22 2e c7 4b 8c 6f 56 78 5c a1 c4 c0 1d
0000320 ca e5 b9 44 d7 e9 90 9c bc ee b0 a2 b1 dc da 6d
0000340 a0 0f f6 ad 1e 2c 12 a2 a7 66 60 3e 36 d4 91 41
0000360 c2 f2 e7 69 39 2c 9d d2 df b5 a3 44 95 48 7c 87
0000400 64 89 dd bf 05 01 ee dd 02 03 01 00 01
0000415
0000000 c4 f6 dd 00 8f 7e b5 a0 95 cf 09 c5 8d d7 95 ba
0000020 1d 06 6c 11 50 cf 2a e3 d3 07 9b fa af e6 2b 1a
]]></artwork></figure>
<figure anchor="eg-names" title="Example Names">
<artwork>
<![CDATA[
+-------------------------------------------------------------------+
| URI: |
| ni:///sha-256;xPbdAI9-taCVzwnFjdeVuh0GbBFQzyrj0web-q_mKxo |
+-------------------------------------------------------------------+
| .well-known URL (split over 2 lines): |
| http://example.com/.well-known/ni/sha256/ |
| xPbdAI9-taCVzwnFjdeVuh0GbBFQzyrj0web-q_mKxo |
+-------------------------------------------------------------------+
| URL Segment: |
| sha-256;xPbdAI9-taCVzwnFjdeVuh0GbBFQzyrj0web-q_mKxo |
+-------------------------------------------------------------------+
| Binary name (ASCII hex encoded) with 120-bit truncated hash value |
| which is Suite ID 0x03: |
| 03c4 f6dd 008f 7eb5 a095 cf09 c58d d795 |
+-------------------------------------------------------------------+
| Human-readable form of a name for this key (truncated to 120 bits |
| in length) with checksum: |
| nih:sha-256-120;yt3n2aepp222bfopbhcy3v4v;ezcg |
+-------------------------------------------------------------------+
| Human readable form of a name for this key (truncated to 32 bits |
| in length) with checksum: |
| nih:sha-256-32;yt3n2aa;moer |
+-------------------------------------------------------------------+
]]></artwork></figure>
</section>
<section title="IANA Considerations" anchor="IANACons">
<section anchor="IANAscheme" title="Assignment of Named Information (ni) URI Scheme">
<t>
The procedures for registration of a URI scheme are specified in
<xref target="RFC4395">RFC 4395</xref>. The following is the proposed
assignment template.
</t>
<t>
URI scheme name: ni
</t>
<t>
Status: Permanent
</t>
<t>
URI scheme syntax. See <xref target="syntax" />
</t>
<t>
URI scheme semantics. See <xref target="syntax" />
</t>
<t>
Encoding considerations. See <xref target="syntax" />
</t>
<t>
Applications/protocols that use this URI scheme name:
General applicability with initial use cases provided by CoAP
and DECADE
</t>
<t>
Interoperability considerations: Defined here.
</t>
<t>
Security considerations: See <xref target="sec_cons" />
</t>
<t>
Contact: stephen.farrell@cs.tcd.ie
</t>
<t>
Author/Change controller: IETF
</t>
<t>
References: As specified in this document
</t>
</section>
<section anchor="IANAschemeh" title="Assignment of Named Information for Humans (nih) URI Scheme">
<t>
The procedures for registration of a URI scheme are specified in
<xref target="RFC4395">RFC 4395</xref>. The following is the proposed
assignment template.
</t>
<t>
URI scheme name: nih
</t>
<t>
Status: Permanent
</t>
<t>
URI scheme syntax. See <xref target="nihsyntax" />
</t>
<t>
URI scheme semantics. See <xref target="nihsyntax" />
</t>
<t>
Encoding considerations. See <xref target="nihsyntax" />
</t>
<t>
Applications/protocols that use this URI scheme name:
General applicability with initial use cases provided by CoAP
and DECADE
</t>
<t>
Interoperability considerations: Defined here.
</t>
<t>
Security considerations: See <xref target="sec_cons" />
</t>
<t>
Contact: stephen.farrell@cs.tcd.ie
</t>
<t>
Author/Change controller: IETF
</t>
<t>
References: As specified in this document
</t>
</section>
<section title="Assignment of Well Known URI prefix ni">
<t>
The procedures for registration of a Well Known URI entry
are specified in <xref target="RFC5785">RFC 5785</xref>.
The following is the proposed
assignment template.
</t>
<t>
URI suffix: ni
</t>
<t>
Change controller: IETF
</t>
<t>
Specification document(s): This document
</t>
<t>
Related information: None
</t>
</section>
<section anchor="IANAbin" title="Hash Name Algorithm Registry">
<t> IANA is requested to create a new registry for hash
algorithms as used in the name formats specified here. This
registry has four fields, the binary suite ID, the hash
algorithm name string, the truncation length and the underlying
algorithm reference. Future assignments are to be made through
expert review <xref target="RFC5226"/>. Initial values are
specified below.</t>
<t>Since there are only 63 possible binary suite ID field values
allowed by the binary format specified here, the suite ID field
value is OPTIONAL. Where the binary format is not expected to
be used for a given hash algorithm, this field SHOULD be
omitted.</t>
<t>
<figure anchor="fig-ids" title="Suite Identifiers">
<artwork align="center">
<![CDATA[
ID Hash name String Value length Reference
0 Reserved
1 sha-256 256 bits [RFC4055]
2 sha-256-128 128 bits [RFC4055]
3 sha-256-120 120 bits [RFC4055]
4 sha-256-96 96 bits [RFC4055]
5 sha-256-64 64 bits [RFC4055]
6 sha-256-32 32 bits [RFC4055]
32 Reserved
]]></artwork></figure>
</t>
<t> The Suite ID value 32 is reserved for compatibility with ORCHIDs
<xref target="RFC4843"/>. The referenced hash algorithm matching to the Suite ID,
truncated to the length indicated, according to the description given
in <xref target="basics"/>, MUST be used for generating the hash.</t>
<t>[[Do we need sha-1 here? Its been asked for, but in a new standards
track spec is dodgy...]]</t>
</section>
</section>
<section title="Security Considerations" anchor="sec_cons">
<t>
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 for 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 de-referenced
using some protocol.
</t>
<t>
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 necessarily protect the confidentiality of the
object that was input to the hash.
</t>
<t>
The integrity of the referenced content would be compromised if
a weak hash function were used. So don't use those. SHA-256 is
currently our preferred hash algorithm which is why we've
only added SHA-256 based suites to the initial IANA registry.
</t>
<t>
If a truncated hash value is used, certain security properties
might be affected.
In general a hash algorithm is designed to produce sufficient
bits to prevent a 'birthday attack' collision occurring. To ensure 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
2nd 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.
</t>
</section>
<section title="Acknowledgements">
<t>
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.
</t>
<t> The authors would also like to thank Bob Moskowitz, Tero Kivinen,
Zach Shelby, Carsten Bormann, David McGrew, Eric Rescorla, Tobias Heer, Martin
Thomas and James Manger for their comments and input to the document. </t>
</section>
</middle>
<back>
<references title="Normative References">
<!--&RFC1035;-->
&RFC2119;
&RFC3986;
<!--&RFC4033;-->
&RFC4055;
&RFC4395;
&RFC4648;
<!--&RFC5395;-->
<!--&RFC5698;-->
&RFC5280;
&RFC5234;
&RFC5785;
</references>
<references title="Informative References">
&RFC4843;
&RFC5226;
<reference anchor="niexts">
<front>
<title>The Network Information (ni) URI Scheme: Parameters</title>
<author initials='P' surname='Hallam-Baker' fullname='Phillip Hallam-Baker'/>
<author initials='R' surname='Stradling' fullname='Rob Stradling'/>
<author initials='S' surname='Farrell' fullname='Stephen Farrell'> </author>
<author initials='C' surname='Kutscher' fullname='Dirk Kutscher'> </author>
<author initials='B' surname='Ohlman' fullname='Borje Ohlman'> </author>
<date month='April' year='2012' />
</front>
<seriesInfo name='Internet-Draft' value='draft-hallambaker-decade-ni-params-01' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-hallambaker-decade-ni-params-01.txt' />
</reference>
<!--
<reference anchor="NIST-ALGS">
<front>
<title>Cryptographic Algorithm Registration</title>
<author>
<organization abbrev="NIST">
National Institute of Standards and Technology
</organization>
</author>
<date day="11" month="March" year="2009"/>
</front>
<format type="HTML" target="http://csrc.nist.gov/groups/ST/crypto_apps_infra/csor/algorithms.html"/>
</reference>
-->
<reference anchor="ref.netinf-design">
<front>
<title>Design Considerations for a Network of Information</title>
<author surname="Ahlgren" fullname="Bengt Ahlgren"></author>
<author surname="D'Ambrosio" fullname="Matteo D'Ambrosio"></author>
<author surname="Dannewitz" fullname="Christian Dannewitz"></author>
<author surname="Marchisio" fullname="Marco Marchisio"></author>
<author surname="Marsh" fullname="Ian Marsh"></author>
<author surname="Ohlman" fullname="Boerje Ohlman"></author>
<author surname="Pentikousis" fullname="Kostas Pentikousis"></author>
<author surname="Rembarz" fullname="Rene Rembarz"></author>
<author surname="Strandberg" fullname="Ove Strandberg"></author>
<author surname="Vercellone" fullname="Vinicio Vercellone"></author>
<date month="December" year="2008"/>
</front>
<seriesInfo name="Re-Arch 2008 Workshop" value=""/>
</reference>
<reference anchor="ref.ccn">
<front>
<title>Networking Named Content</title>
<author surname="Jacobsen" fullname="Van Jacobsen"></author>
<author surname="K" fullname="Diana K. Smetters"></author>
<author surname="D" fullname="James D. Thornton"></author>
<author surname="F" fullname="Michael F. Plass"></author>
<author surname="H" fullname="Nicholas H. Briggs"></author>
<author surname="L" fullname="Rebecca L. Braynard"></author>
<date month="December" year="2009"/>
</front>
<seriesInfo name="CoNEXT 2009" value=""/>
</reference>
&RFC6454;
&I-D.ietf-dane-protocol;
<reference anchor="magnet" target="http://en.wikipedia.org/wiki/Magnet_link">
<front>
<title>Magnet URI Scheme</title>
<author surname="Wikipedia article" fullname="Wikipedia"/>
<date month="April" year="2012"/>
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 13:40:35 |