One document matched: draft-farrell-decade-ni-00.txt
Internet Engineering Task Force S. Farrell
Internet-Draft Trinity College Dublin
Intended status: Standards Track D. Kutscher
Expires: April 26, 2012 NEC
C. Dannewitz
University of Paderborn
B. Ohlman
Ericsson
P. Hallam-Baker
Comodo Group Inc.
October 24, 2011
The Named Information (ni) URI Scheme: Core Syntax
draft-farrell-decade-ni-00
Abstract
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.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 26, 2012.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
Farrell, et al. Expires April 26, 2012 [Page 1]
Internet-Draft ni URI Core October 2011
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Processing NI URIs . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Verifying URI/Resource Mappings . . . . . . . . . . . . . 4
3.2. Testing for Equality . . . . . . . . . . . . . . . . . . . 5
3.3. Mapping to HTTP(S) URLs . . . . . . . . . . . . . . . . . 5
4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. The Named Information URI TYPE . . . . . . . . . . . . . . . . 6
5.1. Encoding Considerations . . . . . . . . . . . . . . . . . 6
5.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8.1. Assignment of Network Information (ni) URI Scheme . . . . 8
8.2. Assignment of Well Known URI prefix ni . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . . 9
9.2. Informative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Farrell, et al. Expires April 26, 2012 [Page 2]
Internet-Draft ni URI Core October 2011
1. Introduction
URIs [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.
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.
Similarly, in the context of information-centric networking
[ref.netinf-design] [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.
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.
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.
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 [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.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Syntax definitions in this memo are specified according to ABNF
Farrell, et al. Expires April 26, 2012 [Page 3]
Internet-Draft ni URI Core October 2011
[RFC4648].
[[Comments are included in double-square brackets, like this.]]
2. Format
In this section we provide an informal description of the ni name
syntax. An ni URI consists of the following components:
Scheme Name [Required] The scheme name is 'ni'.
Colon and Slashes [Required] The literal "://"
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.
One slash [Required] The literal "/"
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'" [RFC5698].
Separator [Required] The literal ";"
Digest Value [Required] The digest value encoded in the specified
encoding. The digest value MAY be trucated at a 64 byte boundary.
Query Parameter separator [Optional] '?' The query parameter
separator acts a separator between the digest value and the query
parameters (if specified).
Query Parameters [Optional] A tag=value list of optional query
parameters as are used with HTTP URLs.
3. Processing NI URIs
3.1. Verifying URI/Resource Mappings
It is OPTIONAL for implementations to check the integrity of the URI/
resource mapping when sending, receiving or processing "ni" URIs.
Farrell, et al. Expires April 26, 2012 [Page 4]
Internet-Draft ni URI Core October 2011
3.2. Testing for Equality
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.
3.3. Mapping to HTTP(S) URLs
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
[RFC5785] by defining an "ni" suffix (see Section 8).
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.
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.]]
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 [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.
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.
In all of the above the application MAY use the "https" URI scheme if
security considerations warrant use of TLS.
Farrell, et al. Expires April 26, 2012 [Page 5]
Internet-Draft ni URI Core October 2011
4. Examples
[[Note: check examples and make sure they're correct sometime.]]
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:
ni:///sha-256;B_K97zTtFuOhug27fke4_Zgc4Myz4b_lZNgsQjy6fkc
And the same example shown with an authority would be:
ni://example.com/sha-256;B_K97zTtFuOhug27fke4_Zgc4Myz4b_lZNgsQjy6fkc
The following HTTP URL represents a mapping from the previous ni name
based on the algorithm outlined above.
http://example.com/.well-known/ni/sha-256/
B_K97zTtFuOhug27fke4_Zgc4Myz4b_lZNgsQjy6fkc
5. The Named Information URI TYPE
5.1. Encoding Considerations
[[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.]]
The digest value MUST be encoded using base64url [RFC4648] encoding.
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 [RFC3986] states that
"The characters slash ("/") and question mark ("?") may represent
data within the query component."
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.]]
Farrell, et al. Expires April 26, 2012 [Page 6]
Internet-Draft ni URI Core October 2011
5.2. Syntax
The Named Information URI has the following syntax:
niname ="ni://" [ authority ] "/" alg ";" val [ "?" query ]
alg = 1*CHAR
val = 1*CHAR
Figure 1: ni Name syntax
The "authority" and "query" types are as in the URI specification.
[RFC3986]
Implementations MUST support the sha-256 algorithm as specified in
[RFC4055].
Implementations MAY support other algorithms specified in the Data
Structure for the Security Suitability of Cryptographic Algorithms
registry 'Cryptographic Algorithms' [RFC5698].
Note that additional algorithms are specified in the companion
document to this one [niexts] that implementations can choose to
support if they wish. Those algorithms use a different IANA registry
defined in that document.
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.
6. Security Considerations
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.
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.
The integrity of the referenced content would be compromised if a
Farrell, et al. Expires April 26, 2012 [Page 7]
Internet-Draft ni URI Core October 2011
weak digest were used.
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.
[[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.]]
7. Acknowledgements
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.
[[Mention folk on the WebSec list who contributed to the
discussions]]
8. IANA Considerations
8.1. Assignment of Network Information (ni) URI Scheme
The procedures for registration of a URI scheme are specified in RFC
4395 [RFC4395]. The following is the proposed assignment template.
URI scheme name: ni
Status: Permanent
URI scheme syntax. See Section 5.2
URI scheme semantics. See Section 5.2
Encoding considerations. See Section 5.1
Applications/protocols that use this URI scheme name: General
applicability with initial use cases provided by WEBSEC and DECADE
Interoperability considerations: TBS
Security considerations: See Section 6
Farrell, et al. Expires April 26, 2012 [Page 8]
Internet-Draft ni URI Core October 2011
Contact: TBD
Author/Change controller: IETF
References: As specified in this document
8.2. Assignment of Well Known URI prefix ni
The procedures for registration of a Well Known URI entry are
specified in RFC 5785 [RFC5785]. The following is the proposed
assignment template.
URI suffix: ni
Change controller: IETF
Specification document(s): This document
Related information: None
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005.
[RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional
Algorithms and Identifiers for RSA Cryptography for use in
the Internet X.509 Public Key Infrastructure Certificate
and Certificate Revocation List (CRL) Profile", RFC 4055,
June 2005.
[RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
Registration Procedures for New URI Schemes", BCP 35,
RFC 4395, February 2006.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006.
[RFC5698] Kunz, T., Okunick, S., and U. Pordesch, "Data Structure
for the Security Suitability of Cryptographic Algorithms
(DSSC)", RFC 5698, November 2009.
Farrell, et al. Expires April 26, 2012 [Page 9]
Internet-Draft ni URI Core October 2011
[RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known
Uniform Resource Identifiers (URIs)", RFC 5785,
April 2010.
9.2. Informative References
[niexts] Hallam-Baker, P., Stradling, R., Farrell, S., Kutscher,
C., and B. Ohlman, "The Network Information (ni) URI
Scheme: Parameters", draft-hallambaker-decade-ni-params-00
(work in progress), October 2011.
[ref.ccn] Jacobsen, K, D, F, H, and L, "Networking Named Content",
CoNEXT 2009 , December 2009.
[ref.netinf-design]
Ahlgren, D'Ambrosio, Dannewitz, Marchisio, Marsh, Ohlman,
Pentikousis, Rembarz, Strandberg, and Vercellone, "Design
Considerations for a Network of Information", Re-Arch 2008
Workshop , December 2008.
[websec-origin]
Barth, A., "The Web Origin Concept",
draft-ietf-websec-origin-06 (work in progress),
October 2011.
Authors' Addresses
Stephen Farrell
Trinity College Dublin
Dublin, 2
Ireland
Phone: +353-1-896-2354
Email: stephen.farrell@cs.tcd.ie
Dirk Kutscher
NEC
Kurfuersten-Anlage 36
Heidelberg,
Germany
Phone:
Email: kutscher@neclab.eu
Farrell, et al. Expires April 26, 2012 [Page 10]
Internet-Draft ni URI Core October 2011
Christian Dannewitz
University of Paderborn
Paderborn
Germany
Email: cdannewitz@upb.de
Borje Ohlman
Ericsson
Stockholm S-16480
Sweden
Email: Borje.Ohlman@ericsson.com
Phillip Hallam-Baker
Comodo Group Inc.
Email: philliph@comodo.com
Farrell, et al. Expires April 26, 2012 [Page 11]
| PAFTECH AB 2003-2026 | 2026-04-24 12:02:55 |