RE: Updated Digest Scheme URI

Another way of 'fixing' URIs by adding a hash of their content with a new scheme (only vaguely related to tdb/duri).

---------- Forwarded message ----------
From: Phillip Hallam-Baker <hallam@gmail.com>
Date: Mon, Oct 3, 2011 at 4:40 PM
Subject: Updated Digest Scheme URI
To: websec <websec@ietf.org>, khare@alumni.caltech.edu, decade@ietf.org


I have made major modifications to the digest scheme from the first version:

http://www.ietf.org/id/draft-hallambaker-digesturi-01.txt


The main changes relevant to the initial WebSEC use cases are:

* Identifiers are now text strings using the IANA crypto algs registry
* A 'start' has been made on getting the URI template filled in
* The encoding scheme base64url encoding is used to comply with URI requirements
* The content type is specified as a parameter

In addition the following features have been outlined to demonstrate that it is possible to create a digest URI that WebSec and DECADE could both use:

* Optional parameters section
* Scheme for specifying one or more locations for retrieval
* Scheme for decrypting encrypted stored content.

Note that these particular use cases actually address recurring WEBSEC type issues, namely how to securely reference content stored on an untrusted server. Simply saying 'SSL' does not in fact solve this question since the linked content may be in a different trust zone.
this turns up all the time with 'rickrolling' and general Slashdot fun.


The main difference between my approach and Stephen's is that Stephen puts the domain portion first as is traditional for a URL. I throw it in as a parameter. Why? Well for static data (as we are doping here) the digest is a far more permanent and specific identifier of the content than one location that might return the data. So it really makes sense to put that up front and make it the first thing in the digest.

Some form of URL transformation is going to be required in either scheme. As has been discussed on the list, relativity really does not provide much leverage here.

The big payoff in my mind for DECADE is that this makes specifying more than one download location easy as well. It also makes it easy for aware applications to add and subtract locations as is sensible.
If content is deposited in a cache, the cache can add its domain into the URI scheme.


So the simplest URI described in the paper is:
di:sha-256:B_K97zTtFuOhug27fke4_Zgc4Myz4b_lZNgsQjy6fkc

The simplest secure reference is:
di:sha-256:B_K97zTtFuOhug27fke4_Zgc4Myz4b_lZNgsQjy6fkc?ct=text/plain


Addressing DECADE type use cases:

A reference can be specified to external content:
di:sha-256:B_K97zTtFuOhug27fke4_Zgc4Myz4b_lZNgsQjy6fkc?http=di.example.com

This maps to the following URL:
http://di.example.com/.well-known/B_K97zTtFuOhug27fke4_Zgc4Myz4b_lZNgsQjy6fkc


And the scheme can be extended to cover encrypted content as well:
di:sha-128:B_K97zTtFuOhug27fke4_Q?enc=aes-cbc:Fw3x20nEKfq6FDGzq7ttIQ

Have to credit Rohit Khare's work here as we both played around with this stuff back in 1995 when we were working for the Web Consortium.


Note that the parameter schemes are proposed as illustration, not as something that I insist on. The point I want to make here is purely about the extensibility of the format proposed. If people want to only consider the WEBSEC use cases in that WG and ignore DECADE, then we could strip them out for the base draft and then have a supplemental draft that describes the extra features.

My view is that the locator hints are actually very useful in the WEBSEC cert pinning context as they allow means for downloading the related certs.

The encryption stuff is likely very interesting in DECADE as it means that the identifier is essentially a self contained capability for the referenced content.

--
Website: http://hallambaker.com/

Received on Wednesday, 5 October 2011 21:16:14 UTC