[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00

Network Working Group                                         S. Farrell
Internet-Draft                                    Trinity College Dublin
Intended status: Standards Track                            C. Dannewitz
Expires: September 29, 2011                      University of Paderborn
                                                               B. Ohlman
                                                             D. Kutscher
                                                          March 28, 2011

                       URIs for Named Information


   This document defines a URI-based name form for objects intended to
   be used for information-centric networking and more generally.  The
   name form defined here allows for the various forms of hash-based
   binding between the name and the named-object, as well as supporting
   human-readable and hierarchical names.

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 September 29, 2011.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   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

Farrell, et al.        Expires September 29, 2011               [Page 1]

Internet-Draft                   NI URIs                      March 2011

   carefully, as they describe your rights and restrictions with respect
   to this document.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Hash Strings . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  URI Scheme . . . . . . . . . . . . . . . . . . . . . . . . . .  6
   4.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . .  7
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  9
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     8.1.  Normative References . . . . . . . . . . . . . . . . . . .  9
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 10
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10

Farrell, et al.        Expires September 29, 2011               [Page 2]

Internet-Draft                   NI URIs                      March 2011

1.  Introduction

   [[Text in double square brackets (like this) is commentary.]]

   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.

   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.  There are also many
   other potential uses for these hash outputs, for example, in terms of
   binding the URI to an owner via signatures and public keys, mapping
   between names, handling versioning etc.  Many such uses can be based
   on "wrapping" the object with meta-data, e.g. including signatures,
   public key certificates etc.

   We therefore define the "ni" URI scheme that allows for, but does not
   insist upon, checking of the integrity of the URI/resource mapping.

   Hash-function outputs however are not human memorable, and cannot
   easily be used to construct a hierarchical namespace, which some
   protocols and applications may require.  The URI scheme therefore
   also allows for human-readable strings to be used with, or instead
   of, the hash function output strings.

   We expect it will be beneficial for applications to be able to map
   between human-readable URIs and URIs that allow for validation of
   integrity the URI/resource mapping.  However, in order to keep our
   scheme simple and more broadly applicable, all considerations for how
   to map between URIs and for how to access resources using these URIs
   are to be specified elsewhere.  In this memo, we simply define a form
   of URI that can be used hopefully in many different contexts.

   The URI scheme defined here could be thought of as being similar to
   URLs with the ability to verify the URL/resource mapping.  However,
   we envisage these URIs actually being of most use in applications
   where the resource is not located at a particular place in a network
   topology, but can rather be cached in many places.

Farrell, et al.        Expires September 29, 2011               [Page 3]

Internet-Draft                   NI URIs                      March 2011

   Syntax definitions in this memo are specified according to ABNF

2.  Hash Strings

   We start with specifying how the outputs from hash functions are

   Hash outputs are binary values that MUST be base64 encoded with line-
   feeds, spaces and terminating "=" characters removed.  These values
   MUST be immediately preceded with a hash algorithm identifier and a
   separator character (":").  For example, the start of such a value
   might look like: "sha256:NDc0NzgyMGVmOGQ3OGU0..."

   Hash values MAY be followed by a function identifier, naming the
   function to be used to verify that hash.  If the function identifier
   is omitted, then the application needs to know how to verify the URI/
   resource mapping if that is desired.

   In many cases the input to the hash function will the actual resource
   itself as presented by whatever protocol uses the name and this is
   the default when the function identifier is omitted.  This is what
   would be in the body of a HTTP response, were the URI used in a HTTP
   GET message and were the object returned in a 200 OK HTTP response
   with no fragmentation.

   The function identifier allows for cases where the resource is
   actually presented with additional information (e.g. meta-data) or is
   wrapped in other encoding.  One way in which this is expected to be
   used is when the resource is presented with an accompanying digital
   signature.  In that case the signature could be presented along with
   the resource and the hash function could be calculated over some
   combination of the resource and signature, or, just over the
   signature bits.  (Note that the signature bits themselves are not
   part of the name in this example.)

   Since we want to be able to verify the hash value against the
   resource, and since sometimes this will involve the resource being
   wrapped in some other format that allows inclusion of meta-data or
   security data, it may be the case that the protocol that presents the
   resource identifies it as having the "wrapped" type.  In order to
   support applications that require typing for the resource itself (as
   opposed to its "wrapped" form) we also allow a hash value to be
   accompanied with an "inner" type that identifies the type of the
   resource, rather than the wrapper.  We do this using MIME types
   appended after the function identifier.

Farrell, et al.        Expires September 29, 2011               [Page 4]

Internet-Draft                   NI URIs                      March 2011

   Note that the "/" character from the MIME type MUST be percent
   encoded in order to conform to the ABNF below.  That is "application/
   jpeg" will be presented as "application%2fjpeg".

   [[Should or must we allow "%2F" as well?]]

   The "default" function-identifier, which is the only one defined
   here, is denoted with the string "id" and means that the resource
   when returned can be directly fed into the hash function without any
   canonicalization required, so this is the "identity" function.  Of
   course, the hash based comparison may fail if some middlebox or
   access protocol has re-encoded the resource in some way.

   The "id" function identifier can be used if an "inner" MIME type
   should be added to the name.

   [["id" may not be the best tag for this, since it may confuse, not
   sure what else to use.]]

   Hash algorithm identifiers and function identifiers are to be
   registered, in an IANA registry (see the "IANA Considerations"
   section below).

   [[There may already be a usable hash function registry.  But if we're
   going to be interested in truncated hashes then we may need our

   Let's call a value encoded as above a "hash-string."  We could define
   it thusly:

   hash-string = hashalg ":" b64value
                     [ ":" function-identifier [ ":" mime-type ] ]

   hashalg = identifier

   function-identifier = identifier

   identifier = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." )

   mime-type = type %2f subtype

   b64value is a string based on the 64-character subset of US-ASCII as
   defined in [RFC4648]. mime-type is based on the Content-Type header
   field syntax as specified in [RFC2045], but using %2f as a delimiter
   between type and subtype instead of "/", and without parameters.

   [[Complete formal ABNF spec of b64value to be provided in a future
   revision of this memo.]]

Farrell, et al.        Expires September 29, 2011               [Page 5]

Internet-Draft                   NI URIs                      March 2011

   It is important to note that implementations are NOT REQUIRED to
   support any cryptographic operations, that is, as necessary, they
   need to be able to parse, route, log, and resolve names with any of
   the above fields, but do not have to verify anything cryptographic.

   Implementations that do support cryptographic operations MUST offer
   applications a way (e.g. via an API) to compare an ni name with a
   resource.  The set of cryptographic operations to be supported (e.g.
   the set of supported function identifiers), is an implementation
   decision and is not further specified.  Where an implementation does
   not support the operation needed to verify a ni object, it MUST
   return an error distinct from the case where the name-to-object
   comparison failed, e.g. due to a hash mismatch.

   Implementations that create names such as these MUST ensure that it
   is possible to validate the mapping from the name to the resource,
   should other implementations choose to do that validation.  That is,
   when creating a name like this, make sure that you do it right!

   Note that not all protocols and applications making use of this URI
   form will require strong integrity assurances when doing name/
   resource comparisons.  For this reason, we expect it to be relatively
   common to use truncated hashes in URIs.

3.  URI Scheme

   Our URIs consist of the scheme, an optional authority part and then a
   "local" part which is a possibly empty sequence of either hash-
   strings or any other string who's encoding is allowed.  As with the
   local part, the authority part may be either a hash-string or any
   other string who's encoding is allowed.

   The semantics of the authority part are not further defined here, but
   MUST be specified by any protocol or application making use of these

   The "local" part is intended to contain an identifier for the
   resource in question that is meaningful in the context of the

   Note that where the authority part is omitted and where the local
   part is not a hash-string, then this may be a significant probability
   for accidental name collisions.  Protocols and applications using
   this URI scheme MUST take care of such collisions, if they matter.
   Note that this is also true, even if the authority part is present,
   unless there is some strict authority-part registration scheme in
   force and where spoofing is hard.

Farrell, et al.        Expires September 29, 2011               [Page 6]

Internet-Draft                   NI URIs                      March 2011

   One obvious thing to use for the authority part is a Fully Qualified
   Domain Name (FQDN), possibly with a port number, in which case
   applications using these URIs could make use of the Domain Name
   System (DNS) and TCP.  Again though - such uses are outside the scope
   of this specification.  In general, there will be no guarantee that
   the resource can be accessed at that host:port even in that case.

   [[ABNF to be fixed later.  Note that the syntax below allows "ni:///"
   as a valid name - whether that is good or bad, and if good, what
   "ni:///" might mean is for future study.]]

   ni-name = scheme ":" hier-part
   hier-part = "//" [authority] "/" *(local-part "/") ["/"]

   scheme = "ni"

   authority = hash-string | other-string ;(delimiters %-encoded)

   local-part = hash-string | other-string ;(delimiters %-encoded)

   [[Formal ABNF of other-string to be specified in a future revision of
   this memo.]]

4.  Examples

   The longer examples in this section flow over lines, but the meaning
   should be clear enough.

   1) ni://tcd.ie/cs8053-exam-2012

   Example 1 is quite like a HTTP URL, and simply shows that "normal"
   URI forms can be used with ni names.

   2) ni:///weather-in-dublin-today

   Example 2 shows an example of an "intentional" name, where the
   resource returned will likely change from time to time.  This example
   has no authority part, which presumably would mean that the requester
   doesn't really care much about the source of the weather information.

   3) ni://tcd.ie/sha256:NDVmZTMzOGVkY2JjZGQ0ZmNmZGFlODQ5MjkyZ

   4) ni:///sha256:NDVmZTMzOGVkY2JjZGQ0ZmNmZGFlODQ5MjkyZDM0ZTg

Farrell, et al.        Expires September 29, 2011               [Page 7]

Internet-Draft                   NI URIs                      March 2011

   Examples 3 and 4 are the same, one with, and one without, an
   authority part.  In both cases, we have no idea what was hashed if we
   only know the ni name.  Some higher layer protocol may of course be
   able to understand what's going on.

   It may be that the authority part of example 3 allows for more
   scalable name-based routing of a request to get, or do something
   with, that resource.

   5) ni://sha256:NDc0NzgyMGVmOGQ3OGU0MmI2MWYwZjY3MDAzNDJmZTY

   The authority for example 5 is a hash-string of a public key as
   stored in a file by openssh.  Though we know that from the URI, there
   is no implication that we need to, or can, do anything special about
   that fact.  Some protocol making use of this name however, might
   expect that the resource contain a signature verifiable with a public
   key that matches that hash.

   6) ni://tcd.ie/sha256:NDVmZTMzOGVkY2JjZGQ0ZmNmZGFlODQ

   Example 6 is a ni name for a jpeg file that contains a hash of the
   file contents where we expect to receive the image in a CMS
   SignedData wrapper.

   Note that the function identifier signeddata could be defined to also
   accept a PGP or XMLDSIG or other wrapper - what's identified is a
   function, and not directly a format.  The signeddata function is
   something that would have to be defined elsewhere.  That is, another
   specification would need to be written for each such function.  [[Or,
   something basic might be included here, but not as a mandatory-to-
   implement feature.]]

5.  Security Considerations

   [[More needed for sure.]]

   Network elements that do attempt to verify the mapping from the name
   to the resource are doing more work that those that don't, both in
   terms of CPU, (for the hash and function identifier calculations) and
   possibly also in terms of network access and/or storage, since they
   need the resource, and possibly meta-data that might have to be
   separately requested.  An example of the latter kind of meta-data
   might be a public key certificate or CRL.  This additional load could
   be leveraged in some kinds of DoS attack.  Protocols that call for

Farrell, et al.        Expires September 29, 2011               [Page 8]

Internet-Draft                   NI URIs                      March 2011

   validation of the name/resource mapping SHOULD specify how to handle
   any such DoS that may be relevant.

6.  IANA Considerations

   Two registries will be required for this specification.  The first
   will be for function identifiers, with a FCFS update rule and one
   initially registered value, the "id" function identifier.  The second
   registry will be for hash functions and may exist already.  If not,
   then, we will want a hash function registry with RFC required as the
   update rule.  Most likely the only reason a new hash function
   registry would be required would be if we wanted a few relatively
   weak truncated hash functions registered, but where that would be
   wrong for the existing hash function registries.

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.

8.  References

8.1.  Normative References

   [RFC2045]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
              Extensions (MIME) Part One: Format of Internet Message
              Bodies", RFC 2045, November 1996.

   [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.

   [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
              Encodings", RFC 4648, October 2006.

   [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234, January 2008.

Farrell, et al.        Expires September 29, 2011               [Page 9]

Internet-Draft                   NI URIs                      March 2011

8.2.  Informative References

   [RFC5050]  Scott, K. and S. Burleigh, "Bundle Protocol
              Specification", RFC 5050, November 2007.

   [ref.caw]  Chapweske, "HTTP Extensions for a Content-Addressable
              Web", October 2001.


   [ref.ccn]  Jacobsen, K, D, F, H, and L, "Networking Named Content",
              CoNEXT 2009 , December 2009.

              Mohr, "MAGNET", June 2002.


              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.

Authors' Addresses

   Stephen Farrell
   Trinity College Dublin
   Dublin,   2

   Phone: +353-1-896-2354
   Email: stephen.farrell@cs.tcd.ie

   Christian Dannewitz
   University of Paderborn

   Email: cdannewitz@upb.de

Farrell, et al.        Expires September 29, 2011              [Page 10]

Internet-Draft                   NI URIs                      March 2011

   Borje Ohlman
   Stockholm  S-16480

   Email: Borje.Ohlman@ericsson.com

   Dirk Kutscher
   Kurfuersten-Anlage 36

   Email: kutscher@neclab.eu

Farrell, et al.        Expires September 29, 2011              [Page 11]

Html markup produced by rfcmarkup 1.121, available from https://tools.ietf.org/tools/rfcmarkup/