Re: Updated Digest Scheme URI

That would suggest an identifier that is primarily a locator.

There is nothing wrong with that for a single, point application. But
making the digest primary and making it the starting point for the
discovery processes means that it is possible to provide hints for
more than just a 'http' based retrieval scheme - or for no scheme at
all.

For example, let us imagine that someone came up with an interesting
cache scheme protocol (like DECADE is working on) it is easy to add a
locator for that.


The loss of 'sovereignty' is an interesting notion however. If the
semantics of 'well-known' are in fact bound that means that Web pages
could include the http://example.com/.well-known/di/ form of the URI
in a Web page and get full compatibility with legacy browsers BUT an
aware browser could look at that and say 'hold on, I know what that
is, lets look in the local cache' or alternatively it could try the
indicated location first and then look for the content in more
'imaginative' places.

This capability would be exceptionally important for censorship
resistant networks which is the non-Comodo work I am working on.

That could make for a very interesting backwards compatibility path for DECADE.


On Wed, Oct 5, 2011 at 6:12 PM, Jonathan Rees <jar@creativecommons.org> wrote:
> 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/
>>
>>
>



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

Received on Thursday, 6 October 2011 00:22:09 UTC