One document matched: draft-farrell-decade-ni-00.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">
<!-- 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">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?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-00">
<front>
<title abbrev="ni URI Core">The Named Information (ni) URI Scheme: Core Syntax</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 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="October" year="2011" />
<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 URI-based name form that identifies a
named object via hash-based binding. The URI
name form defined is intended for use in applications that
need to uniquely identify resources in a location-independent
way such as accessing in-network storage (DECADE),
information-centric networking and more generally. The format
is designed to support 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>
URIs <xref target="RFC3986"/> are used in various protocols
for identifying resources. In many deployments those URIs
contain strings that are hash function outputs in order to
ensure uniqueness in terms of mapping the URI to a specific
resource, or to make URIs hard to guess for security
reasons. However, there is no standard way to interpret
those strings, and so today in general only the creator of
the URI knows how to use the hash function output.
</t>
<t>
For example, protocols for accessing in-network storage
servers (as defined in the IETF DECADE WG) need a way to
identify the 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 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 de-referenced 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,
CRLs, OCSP tokens and other signed data objects.
</t>
<t>
Accordingly, the "ni" URI scheme allows for checking of the
integrity of the URI/resource mapping, but it is OPTIONAL for
implementations to do so when sending, receiving or processing
"ni" URIs.
</t>
<t>
The URI scheme defined here allows for the use of a
query-string, simiilar 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 in for various purposese.
That document also specifies additional
optional algorithms for truncated hashes and for hashing of
dynamic objects.
</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="RFC4648"/>.
</t>
<t>[[Comments are included in double-square brackets, like this.]]</t>
</section>
<section title="Format">
<t>
In this section we provide an informal description of the ni name syntax.
An 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 titled
"Data Structure for the Security Suitability of Cryptographic Algorithms
registry 'Cryptographic Algorithms'"
<xref target="RFC5698" />.
</t>
<t hangText="Separator [Required]">The literal ";" </t>
<t hangText="Digest Value [Required]">
The digest value encoded in the specified encoding. The digest value MAY be
trucated at a 64 byte boundary.
</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>
</section>
<section title="Processing NI URIs">
<section title="Verifying URI/Resource Mappings">
<t>
It is OPTIONAL for implementations to check the integrity of the
URI/resource mapping when sending, receiving or processing "ni"
URIs.
</t>
</section>
<section title="Testing for Equality">
<t>
When verifying whether two NI URIs 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 or any parameters.
</t>
</section>
<section title="Mapping to HTTP(S) URLs">
<t>
We define a bidirectional
mapping between the ni URI scheme and a subset of the the HTTP scheme
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 legacy clients
without support for ni indentifiers is required without loss
of interoperability or functionality. A legacy client interprets
the ni identifier as an ordinary HTTP(s) URL while a ni aware client
can determine the corresponding ni form of the URI and apply
ni processing.
</t>
<t>
Implementations SHOULD support this mapping, in both directions.
[[Not sure if we really want 2119 language for the mapping, nor
if we need to specify both directions, so this
is kind of a placeholder.]]
</t>
<t>
For an ni name of the form "ni://n-authority/alg;val?query-string"
the corresponding HTTP URL produced by this algorithm is
"http://h-authority/.well-known/ni/alg/val?query-string". If the ni
name has a specified authority 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 applicaiton
context. For example, if the mapping is being done in the context of a web page
then the origin <xref target="websec-origin"/> for that web site can be used. Of course, there are in
general no guarantees that the object named by the ni name will be available at
the corresponding HTTP URL. But in the case that any data is returned, the
retreiver can determine if it is the correct content.
</t>
<!-- <t>
[[I made some changes to the above to try to bring out the most
important part that it doth not matter where the bits come from,
you can always tell if they are th eright ones.]]
</t> -->
<t>
If an application is presented with a HTTP URL with "/.well-known/ni/"
as the start of its pathname component, then the reverse mapping to an
ni name either including or excluding the authority might produce an ni name
that is meaningful depending on the application.
</t>
<t>
In all of the above the application MAY use the "https" URI scheme
if security considerations warrant use of TLS.
</t>
<!--
<t>
[[The scheme part of the generated URL could also be specified by an
ni URI parameter, which is currently under discussion.]]
[[SF: I think that belongs in [niexts] only though. If needed here
then we ought move it here. ]]
</t>
-->
</section>
</section>
<section title="Examples">
<t>[[Note: check examples and make sure they're correct sometime.]]
</t>
<t>
The following digest URI specifies a reference to
the text "Hello World !" using the SHA-2 algorithm with 256
bit output and no authority field:
</t>
<t>ni:///sha-256;B_K97zTtFuOhug27fke4_Zgc4Myz4b_lZNgsQjy6fkc</t>
<t>And the same example shown with an authority would be:</t>
<t>ni://example.com/sha-256;B_K97zTtFuOhug27fke4_Zgc4Myz4b_lZNgsQjy6fkc</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/B_K97zTtFuOhug27fke4_Zgc4Myz4b_lZNgsQjy6fkc</t>
</section>
<section title="The Named Information URI TYPE">
<section title="Encoding Considerations" anchor="encoding">
<t>
[[Note that this section may change. However, the intent is
that there be one and only one well defined encoding scheme
for ni names. However, getting the right scheme for that,
and for the URL mapping may be tricky.]]
</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.
Section 3.4 of <xref target="RFC3986" /> states
that "The characters slash ("/") and question mark ("?") may represent data
within the query component."
</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 accept any
URIs that employ URI character escaping.
[[That might need to be more specific.]]
</t>
</section>
<section title="Syntax" anchor="syntax">
<t>
The Named Information URI has the following syntax:
</t>
<figure title="ni Name syntax" anchor="fig_abnf">
<artwork type="abnf">
niname ="ni://" [ authority ] "/" alg ";" val [ "?" query ]
alg = 1*CHAR
val = 1*CHAR
</artwork>
</figure>
<t>The "authority" and "query" types are as in the URI specification. <xref target="RFC3986"/> </t>
<t>
Implementations MUST support the sha-256 algorithm as specified in
<xref target="RFC4055" />.
</t>
<t>
Implementations MAY support other algorithms specified in the
Data Structure for the Security Suitability of Cryptographic Algorithms
registry 'Cryptographic Algorithms'
<xref target="RFC5698" />.
</t>
<t>Note that additional algorithms are specified in the
companion document to this one <xref target="niexts"/> that
implementations can choose to support if they wish. Those
algorithms use a different IANA registry defined in that
document.
</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 de-referenced.
</t>
</section>
</section>
<section title="Security Considerations" anchor="sec_cons">
<t>
No secret information is required to
generate or verify an ni URI. Therefore
an ni URI only provides a proof of integrity for the
referenced object and the proof of integrity provided is
only as good as the proof of integrity for the ni URI.
In other words, the digest value can provide
name-data integrity binding the ni name value to the
object bytes returned when the ni name is de-referenced
using some protocol.
</t>
<t>
Disclosure of an ni URI 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 highly formatted object with little variation,
by simply guessing the value and checking if the digest
value matches.
</t>
<t>
The integrity of the referenced content would be compromised if
a weak digest were used.
</t>
<t>
If a truncated digest is used, certain security properties
MAY be affected.
In general a digest algorithm is designed to produce sufficient
bits to prevent a 'birthday attac' collision occuring. 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.
</t>
<t>
[[Don't reduce too much, and don't rely on a digest that has been
truncated as being the strength of the original digest alg.]]
</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>
[[Mention folk on the WebSec list who contributed to the
discussions]]
</t>
</section>
<section title="IANA Considerations" anchor="IANACons">
<section title="Assignment of Network 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="encoding" />
</t>
<t>
Applications/protocols that use this URI scheme name:
General applicability with initial use cases provided by WEBSEC
and DECADE
</t>
<t>
Interoperability considerations: TBS
</t>
<t>
Security considerations: See <xref target="sec_cons" />
</t>
<t>
Contact: TBD
</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>
</middle>
<back>
<references title="Normative References">
<!--&RFC1035;-->
&RFC2119;
&RFC3986;
<!--&RFC4033;-->
&RFC4055;
&RFC4395;
&RFC4648;
<!--&RFC5395;-->
&RFC5698;
&RFC5785;
</references>
<references title="Informative References">
<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='October' year='2011' />
</front>
<seriesInfo name='Internet-Draft' value='draft-hallambaker-decade-ni-params-00' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-hallambaker-decade-ni-params-00.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>
<reference anchor='websec-origin'>
<front>
<title>The Web Origin Concept</title>
<author initials='A' surname='Barth' fullname='Adam Barth'>
<organization />
</author>
<date month='October' day='3' year='2011' />
<abstract><t>This document defines the concept of an "origin", which is often used as the scope of authority or privilege by user agents. Typically, user agents isolate content retrieved from different origins to prevent malicious web site operators from interfering with the operation of benign web sites. In addition to outlining the principles that underlie the concept of origin, this document defines how to determine the origin of a URI, how to serialize an origin into a string, and an HTTP header field, named "Origin", that indicates which origins are associated with an HTTP request.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-websec-origin-06' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-websec-origin-06.txt' />
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 13:41:17 |