Re: Updated Digest Scheme URI

Cool. But my question is, given that domain owners have already lost
their sovereignty over /.well-known/, why bother with the URI scheme?

That is: suppose the registration for /.well-known/di/ laid out the
protocol, and said that responses to retrievals using those http: URIs
MUST have some property (like matching the hash code). How would these
http: URIs be any different from whatever properties the di: URIs
would have? Would there be any attack on one that would not also be an
attack on the other?

I guess di: is shorter and more beautiful than
http://.../.well-known/di/ , but if length and beauty were important,
we wouldn't be talking about hashes...

Same argument says one could put URNs, ark:, etc. under /.well-known/,
although conformance gets harder to check without a hash.

Jonathan

On Wed, Oct 5, 2011 at 5:15 PM, Larry Masinter <masinter@adobe.com> wrote:
> 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 22:12:49 UTC