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

Versions: 00 01 02 03 04 05 06 07 08 09 10 RFC 6920

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]


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