One document matched: draft-farrell-decade-ni-10.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 RFC2045 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2045.xml">
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2616 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2616.xml">
<!ENTITY RFC2818 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2818.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">
<!-- UTF-8 -->
<!ENTITY RFC3629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3629.xml">
<!ENTITY RFC3766 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3766.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">
<!ENTITY RFC4843 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4843.xml">
<!ENTITY RFC5513 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5513.xml">
<!ENTITY RFC6454 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6454.xml">
<!ENTITY RFC6149 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6149.xml">
<!ENTITY RFC6150 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6150.xml">
<!ENTITY RFC6151 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6151.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">
<!ENTITY I-D.hallambaker-decade-ni-params SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.hallambaker-decade-ni-params.xml">
<!ENTITY I-D.ietf-websec-strict-transport-sec SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-websec-strict-transport-sec">
<!ENTITY I-D.ietf-httpbis-p1-messaging SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-httpbis-p1-messaging">
<!ENTITY I-D.ietf-appsawg-media-type-regs SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-appsawg-media-type-regs">
]>
<?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-10">
<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 />
<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 (a digital object in
this case) using the output from a hash function, specifying a new URI scheme
for this, a way to map those 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. This work is motivated as a way to standardise current uses of hash outputs in
URLs and to support new information-centric applications and other uses of hash outputs
in protocols.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
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.
</t>
<t>
This document defines a "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.
</t>
<!--
<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. We begin
with a few example uses for the various ways to include a hash in a name as
they are defined later in this document, for example <xref target="fig-intro"/>
shows an example of the "Named Information" (ni) URI scheme defined here.
</t>
-->
<figure anchor="fig-intro" title="Example ni URI">
<artwork align="center">
<![CDATA[
ni:///sha-256;UyaQV-Ev4rdLoHyJJWCi11OHfrYv9E1aGQAlMO2X_-Q
]]></artwork></figure>
<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. In yet other situations people may have
to speak such values, e.g., in a voice call, (see
<xref target="niheg"/>), in order to confirm the presence or absence
of a resource.
</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 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.
</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 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
thry are 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-data mapping, but it is OPTIONAL for
implementations to do so when sending, receiving or processing
these name forms.
</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>
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 <xref target="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.
</t>
<t>
<!--
OLD:
The ni URI scheme also allows for the use of a query string, similar to the
way in which query strings are used in HTTP URLs. A companion specification <xref
target="I-D.hallambaker-decade-ni-params"/> describes specific values that can
be used in such query strings for various purposes and other extensions to this
basic format specification.
-->
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. A companion specification <xref
target="I-D.hallambaker-decade-ni-params"/> describes specific values that can
be used in such query strings for these various purposes and other extensions
to this basic format specification.
</t>
<t>
In addition, 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 (truncated) 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="Hashes are what Count">
<t>This section contains basic considerations related to how
we use hash function outputs that are common to all
formats.</t>
<t>
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.
</t>
<t>
The sha-256 algorithm as specified in <xref target="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).
</t>
<t>
Truncated hashes MAY be supported. 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. A 32-bit
truncated hash is essentially useless for security in almost all cases, but
might be useful for naming. With current best practices <xref
target="RFC3766"/> very few, if any, applications making use of names with less
than 100 bit long hashes will have useful security properties.
</t>
<t>
When a hash value is truncated to N bits the left-most 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 <xref target="fig-trunc"/>.
</t>
<figure anchor="fig-trunc" title="Example of Truncated Hash">
<artwork align="center">
<![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. 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 nine components:
</t>
<t>
<list style="hanging">
<t hangText="Scheme Name">The scheme name is 'ni'.
</t>
<t hangText="Colon and Slashes">The literal "://" </t>
<t hangText="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 <xref target="RFC3986"/> Section 3.2.2 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.
</t>
<t hangText="One slash">The literal "/" </t>
<t hangText="Digest Algorithm">
The name of the digest algorithm, as specified in the IANA registry
defined in <xref target="IANAbin"/> below.
</t>
<t hangText="Separator">The literal ";" </t>
<t hangText="Digest Value">
The digest value MUST be encoded using the
base64url <xref target="RFC4648"/> encoding, with no "=" padding characters.
</t>
<t hangText="Query Parameter separator '?'">
The query parameter separator acts as a separator between the
digest value and the query parameters (if specified). For compatibility with
IRIs, non-ASCII characters in the query part MUST be encoded as UTF-8, and the
resulting octets MUST be %-encoded (see <xref target="RFC3986"/> Section 2.1).
</t>
<t hangText="Query Parameters">
A tag=value list of optional query parameters as are used with HTTP URLs
<xref target="RFC2616"/>
with a separator character '&' between each. For example, "foo=bar&baz=bat"
</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>
<!--
Took this out in response to durst review.
<t>
The query segment of a URI is NOT hierarchical. Thus escape encoding of slash
'/' characters is NOT required. Note that application code often attempts to
enforce such encoding, and RFC 3896 requires decoders to 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." All of this
is as per RFC 3986, and should anything here conflict with that, RFC 3986 rules
apply.
</t>
-->
<!--
<t>
Note that when mapped to HTTP or HTTPS URLs, it might be advisable to
percent encode '/' and '?' characters in the query
string.
</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>
Escaping of characters follows the rules in RFC 3986. This means that
%-encoding is used to distinguish between reserved and unreserved
functions of the same character in the same URI component. As an
example, an ampersand ('&') is used in the query part to separate
attribute-value pairs; an ampersand in a value therefore 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.
</t>
<!--
<t>Old way:</t>
<t>
The Named Information URI has the following syntax:
</t>
<figure title="ni Name syntax" anchor="fig_abnfo">
<artwork type="abnf" align="center">
niname ="ni://" [ authority ] "/" algval [ "?" query ]
algval = alg ";" val
alg = 1*unreserved
val = 1*unreserved
unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
</artwork>
</figure>
-->
<t>
The Named Information URI adapts the URI definition from the URI
Generic Syntax <xref target="RFC3986"/>. We start with the base URI production:
</t>
<figure title="URI syntax" anchor="fig_uri">
<artwork type="abnf" align="center">
URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ]
; from RFC 3986
</artwork>
</figure>
<t>
Adapting that for the Named Information URI:
</t>
<!-- another version bites the dust;-)
<figure title="ni Name syntax" anchor="fig_niabnf_dust">
<artwork type="abnf" align="center">
NI-URI = ni-scheme ":" ni-hier-part [ "?" ni-query ]
; adapted from "URI" in RFC 3986
ni-scheme = "ni"
ni-hier-part = "//" [ authority ] "/" alg-val
alg-val = alg ";" val
; adapted from "hier-part" in RFC 3986
alg = 1*unreserved
val = 1*unreserved
ni-query = attr "=" value [*( "&" attr "=" value )]
attr = query-token
value = query-token
query-token = 1*( unreserved / pct-encoded )
unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
; directly from RFC 3986, section 2.3
; "authority" and "pct-encoded" are also from RFC 3986
</artwork>
</figure>
-->
<figure title="ni Name syntax" anchor="fig_niabnf">
<artwork type="abnf" align="center">
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
</artwork>
</figure>
<t>
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.
</t>
<t>
Relative ni URIs can occur. In such cases, the algorithm in <xref
target="RFC3986"/> Section 5 applies. As an example, in Figure 5, the absolute
URI for "this third document" is "ni://example.com/sha-256-128;...".
</t>
<figure anchor="fig_rel" title="Example HTML with relative ni URI">
<artwork align="center">
<![CDATA[
<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>
]]></artwork></figure>
<t>
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 cousrse have a strictly defined way to include the
hash value.
</t>
<!--
What's good enough for HTTP is good enough for us.
<section title="Internationalisation Considerations" anchor="i18n_cons">
<t>
[[This is a placeholder until I find something good to copy or reference
that says how i18n applies to text within ni URIs.]]
</t>
</section>
-->
<t>
Internationalisation of strings within ni names is handled
exactly as for http URIs - see
<xref target="I-D.ietf-httpbis-p1-messaging"/>
Section 2.7.
</t>
<section title="Content Type Query String Attribute">
<t>
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 meta
data such as the content type.
The Content Type "ct" parameter specifies the MIME Content Type of the
associated data as defined in <xref target="I-D.ietf-appsawg-media-type-regs"/>. See <xref
target="iana-ni-param"/> for the associated IANA registry for ni parameter
names.
as shown in <xref target="fig-ct"/>. Implementations of
this specification MUST support parsing the ct= query string attribute name.
</t>
<figure anchor="fig-ct" title="Example ni URI with Content Type">
<artwork align="center">
<![CDATA[
ni:///sha-256-32;f4OxZQ?ct=text/plain
]]></artwork></figure>
<t>
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.
</t>
<t>
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.
</t>
<t>
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 <xref target="RFC2045"/> Section 5.1.
</t>
</section>
</section>
<section title=".well-known URI">
<t>
We define a mapping between URIs following the ni URI scheme and HTTP <xref target="RFC2616"/> or
HTTPS <xref target="RFC2818"/> 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 with
support for ni URIs are not available.
</t>
<t>
Since the .well-known name-space is not intended for general
information retrieval, if an application de-references a .well-known/ni URL via
HTTP(S), then it will often receive a 3xx HTTP re-direction 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 <xref target="RFC2616"/> client.
</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 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.
</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 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
<xref target="I-D.ietf-websec-strict-transport-sec"/>
may dictate that data
might only be available over "https".
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 "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 <xref target="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.
</t>
</section>
<section anchor="binary-format" title="Binary Format">
<t>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 <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 and ignored on receipt.</t>
<t> 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
<xref target="IANAbin"/> for details.</t>
<t>
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.
</t>
</section>
<section anchor="nihsyntax" title="Human-speakable (nih) URI Format">
<t>
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 <xref target="niheg"/> is
the main current use-case for nih URIs.
</t>
<t>
The ni URI format is not well-suited for this, as, for example, base64url uses
both upper and lower case 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.
"nih" stands for "Named Information for Humans." (Or possibly "Not Invented
Here," which is clearly false, and therefore worth including <xref target="RFC5513"/>:-)
</t>
<t>
The justification for nih being a URI scheme is that that 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
check-digit to catch common errors, and allow for the inclusion of "-"
separators to make nih URIs more easy to read out.
</t>
<t>
Fields in nih URIs are separated by a semi-colon (;) character. The first field
is a hash algorithm string, as in the ni URI format. The hash value is
represented using lower-case 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 <xref target="RFC4648"/> except using
lower-case 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.
</t>
<t>
The hash value MAY be followed by a semi-colon ';' then a checkdigit.
The checkdigit MUST be calculated using Luhn's mod N algorithm (with N=16) as
defined in <xref target="ISOIEC7812"/>, (see also
http://en.wikipedia.org/wiki/Luhn_mod_N_algorithm). 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.
</t>
<figure title="Human-speakable syntax" anchor="fig_human_dig">
<artwork type="abnf" align="center">
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
</artwork>
</figure>
<t> For algorithms that have a Suite ID reserved (see <xref
target="fig-ids"/>), the alg field MAY contain the ID value as a
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.
</t>
<t>
There is no such thing as a relative nih URI.
</t>
</section>
<section title="Examples">
<section title="Hello World!">
<t>
The following ni URI is generated from the text
"Hello World!" (without the quotes, being 12 characters),
using the sha-256 algorithm
shown with and without an authority field:
</t>
<t>ni:///sha-256;f4OxZX_x_FO5LcGBSKHWXfwtSx-j1ncoSt3SABJtkGk</t>
<t>ni://example.com/sha-256;f4OxZX_x_FO5LcGBSKHWXfwtSx-j1ncoSt3SABJtkGk</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/f4OxZX_x_FO5LcGBSKHWXfwtSx-j1ncoSt3SABJtkGk</t>
</section>
<section title="Public Key Examples">
<t> Given the DER-encoded 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 align="center">
<![CDATA[
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 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
]]></artwork></figure>
<figure anchor="eg-names" title="Example Names">
<artwork align="center">
<![CDATA[
+-------------------------------------------------------------------+
| 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 |
+-------------------------------------------------------------------+
]]></artwork></figure>
</section>
<section title="nih Usage Example" anchor="niheg">
<t>
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.
</t>
<t>
Bob would like to believe that its 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.
</t>
<t>
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.
</t>
</section>
</section>
<section title="IANA Considerations" anchor="IANACons">
<section anchor="IANAscheme" title="Assignment of 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.
</t>
<t>
Interoperability considerations: Defined here.
</t>
<t>
Security considerations: See <xref target="sec_cons" />
</t>
<t>
Contact: Stephen Farrell, 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 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.
</t>
<t>
Interoperability considerations: Defined here.
</t>
<t>
Security considerations: See <xref target="sec_cons" />
</t>
<t>
Contact: Stephen Farrell, 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 'ni' URI">
<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="Creation of Named Information Hash Algorithm Registry">
<t>
IANA is requested to create a new registry for hash algorithms as used in the
name formats specified here and called the "Named Information Hash Algorithm Registry".
Future assignments are to be made through Expert Review <xref
target="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 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.
</t>
<t>
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.
</t>
<!-- SM comment
<t>
The Designated Expert MUST allow for IETF review before approving a request to mark an
entry as "deprecated." Such requests may simply take the form of a mail to the
Designated Expert (an RFC is not required). IETF review can be achieved if the
Designated Expert sends a mail to the IETF discussion list. At least two weeks
for comments MUST be allowed thereafter before the request is approved and
actioned.
</t>
-->
<t>
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.
</t>
<t>
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 for example
<xref target="RFC6149"/>,<xref target="RFC6150"/> and
<xref target="RFC6151"/> for some hash functions that are
considered obsolete in this sense.
</t>
<t>
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.
</t>
<t>
<figure anchor="fig-ids" title="Suite Identifiers">
<artwork align="center">
<![CDATA[
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
]]></artwork></figure>
</t>
<t> The Suite ID value 32 is reserved for compatibility with ORCHIDs
<xref target="RFC4843"/>.
</t>
<t>
The referenced hash algorithm matching to the Suite ID, truncated to the length
indicated, according to the description given in <xref target="basics"/>, 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."
</t>
<!--
<t>[[Do we need sha-1 here? Its been asked for, but in a new standards
track spec is dodgy...]]</t>
-->
</section>
<section title="Creation of Named Information Parameter Registry" anchor="iana-ni-param">
<t>
IANA is requested to create
a new registry entitled "Named Information URI
Parameter Definitions".
</t>
<t>
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 paramater definition meets
the "specification required" rule."
</t>
<t>
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 <xref target="syntax"/>.)
</t>
<t>
The initial contents of the registry are:
</t>
<figure>
<artwork>
<![CDATA[
Parameter Meaning Reference
----------- -------------------------------------------- ---------
ct Content Type [RFC-THIS]]]>
</artwork>
</figure>
</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 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. 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 will
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>
<t>
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.
</t>
<t>
The reason for this is that if an application treats those 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, 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.
</t>
<t>
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 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.
</t>
<t>
If name-data integrity is successfully validated, and the hash is strong and
long enough, then the "web origin" <xref target="RFC6454"/> for the bytes of
the named object is really going to be the place from which you got the ni name
and not the place from which you got the bytes of the object. This appears to
offer a potential benefit if using ni names for, for example, scripts included
from a HTML page accessed via server-authenticated https. 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.
</t>
<t>
Some implementations might mis-handle 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.
</t>
</section>
<section title="Acknowledgments">
<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
Carsten Bormann,
Martin Durst,
Tobias Heer,
Bjoern Hoehrmann,
Tero Kivinen,
Barry Leiba,
Larry Masinter,
David McGrew,
Alexey Melnikov,
Bob Moskowitz,
Jonathan Rees,
Eric Rescorla,
Zach Shelby,
Martin Thomas,
for their comments and input
to the document.
Thanks, in particular, to James Manger for correcting
the examples.
</t>
</section>
</middle>
<back>
<references title="Normative References">
<!--&RFC1035;-->
&RFC2119;
&RFC2616;
&RFC2818;
&RFC3986;
<!-- &RFC4288;-->
&I-D.ietf-appsawg-media-type-regs;
<!--&RFC4033;-->
&RFC4395;
&RFC4648;
<!--&RFC5395;-->
<!--&RFC5698;-->
&RFC5280;
&RFC5234;
&RFC2045;
&RFC5785;
&I-D.ietf-httpbis-p1-messaging;
<reference anchor="ISOIEC7812" target="http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=39698">
<front>
<title>
"ISO/IEC 7812-1:2006 Identification cards --
Identification of issuers -- Part 1: Numbering system",
</title>
<author surname="ISO"/>
<date month="October" year="2006"/>
</front>
</reference>
<reference anchor="SHA-256" target="http://csrc.nist.gov/publications/fips/fips180-3/fips180-3_final.pdf">
<front>
<title>
United States National
Institute of Standards and Technology (NIST), FIPS 180-3: Secure Hash
Standard
</title>
<author surname="NIST"/>
<date month="October" year="2008"/>
</front>
</reference>
</references>
<references title="Informative References">
&RFC4843;
&RFC5226;
&RFC5513;
&I-D.hallambaker-decade-ni-params;
<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="Jacobson at al." fullname="Van Jacobson"></author>
<date month="December" year="2009"/>
</front>
<seriesInfo name="CoNEXT 2009" value=""/>
</reference>
&RFC6454;
&RFC3766;
&RFC6149;
&RFC6150;
&RFC6151;
&I-D.ietf-dane-protocol;
&I-D.ietf-websec-strict-transport-sec;
<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-22 22:48:46 |