Subject: [Uri-review] Request -02 review of SHA URIs

From: Sean Leonard <[email-masked]>
Date: Fri, 25 Sep 2015 15:58:03 -0700

Hello URI Reviewers:

I request review of the SHA URIs in this draft-02, per RFC 7595. The URI schemes are "sha1", "sha256", "sha1msg", and "sha256msg", respectively.

Most feedback was incorporated, or at least considered, in this document. If folks feel that their feedback is not reflected please contact me and I will look into it further.

Thank you,

Sean

Begin forwarded message:

> From: [email-masked]
> Subject: New Version Notification for draft-seantek-sha-uris-02.txt
> Date: September 25, 2015 at 3:51:02 PM PDT
> 

A new version of I-D, draft-seantek-sha-uris-02.txt
has been successfully submitted by Sean Leonard and posted to the
IETF repository.

Name:		draft-seantek-sha-uris
Revision:	02
Title:		URI Schemes for SHA-1 and SHA-256
Document date:	2015-09-25
Group:		Individual Submission
Pages:		13
URL:            https://www.ietf.org/internet-drafts/draft-seantek-sha-uris-02.txt
Status:         https://datatracker.ietf.org/doc/draft-seantek-sha-uris/
Htmlized:       https://tools.ietf.org/html/draft-seantek-sha-uris-02
Diff:           https://www.ietf.org/rfcdiff?url2=draft-seantek-sha-uris-02

Abstract:
  This document registers Uniform Resource Identifier schemes for use
  with certain Secure Hash Algorithm (SHA) functions, namely SHA-1 and
  SHA-256. The purpose is to identify data streams and content in a
  simple, "drop-in" way within the URI infrastructure.

---

From: Graham Klyne <[email-masked]>
Date: Sat, 26 Sep 2015 15:50:24 +0100

Sean,

On the basis of the muted level of support seen so far, I would anticipate this 
not reaching the bar for *permanent* registration of the URI schemes.  I think 
it would be fine as is for *provisional* registration.

In particular, I don't think the draft has demonstrated "Demonstrable, New, 
Long-Lived Utility" (https://tools.ietf.org/html/rfc7595#section-3.1), and I 
would in general expect such a judgement to be backed by a clear IETF consensus 
or widespread deployment, neither of which I am aware of for this proposal.  In 
particular, notwithstanding your brief comments in section 2, I'm not seeing any 
essential utility here that is not provided by the ni: scheme.  The comment "the 
URI semantics may differ" is not substantiated in any way that I can recognize.

Further, given the restrictions of the URI scheme namespace (ibid), I think the 
approach of registering different URI schemes for each hash algorithm is not 
appropriate.

#g
--

On 25/09/2015 23:58, Sean Leonard wrote:
> _______________________________________________
> Uri-review mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uri-review
>

---

From: Sean Leonard <[email-masked]>
Date: Sat, 26 Sep 2015 14:05:28 -0700

Graham,

FWIW I don't have a problem with it being a provisional registration. 
Making a provisional registration as an intermediate step to permanent 
registration is an envisioned use case (RFC 7595 Section 4) anyway.

That being said, this draft hasn't really been circulated broadly 
outside of [email-masked] do not recall even posting it to the 
apps or security-related mailing lists. Therefore discussion opportunity 
simply hasn't been had yet.

I should be upfront that these SHA schemes were part of a broader 
initiative to identify security objects such as certificates with URIs 
(draft-seantek-certspec). The original proposal was to create a cert 
namespace URN (urn:cert:...); however, the URN people did not like that, 
so it's up to the top instead.

Sean

On 9/26/2015 7:50 AM, Graham Klyne wrote:
> Sean,
>
> On the basis of the muted level of support seen so far, I would 
> anticipate this not reaching the bar for *permanent* registration of 
> the URI schemes.  I think it would be fine as is for *provisional* 
> registration.
>
> In particular, I don't think the draft has demonstrated "Demonstrable, 
> New, Long-Lived Utility" 
> (https://tools.ietf.org/html/rfc7595#section-3.1), and I would in 
> general expect such a judgement to be backed by a clear IETF consensus 
> or widespread deployment, neither of which I am aware of for this 
> proposal.  In particular, notwithstanding your brief comments in 
> section 2, I'm not seeing any essential utility here that is not 
> provided by the ni: scheme.  The comment "the URI semantics may 
> differ" is not substantiated in any way that I can recognize.
>
> Further, given the restrictions of the URI scheme namespace (ibid), I 
> think the approach of registering different URI schemes for each hash 
> algorithm is not appropriate.
>
> #g
> -- 
>
>
>> I request review of the SHA URIs in this draft-02, per RFC 7595. The 
>> URI schemes are "sha1", "sha256", "sha1msg", and "sha256msg", 
>> respectively.
>>
>> Most feedback was incorporated, or at least considered, in this 
>> document. If folks feel that their feedback is not reflected please 
>> contact me and I will look into it further.
>>
>> Thank you,
>>
>> Sean
>>
>> Begin forwarded message:
>>

---

From: Graham Klyne <[email-masked]>
Date: Sun, 27 Sep 2015 08:20:15 +0100

Sean,

That's fine.  I was responding mainly to the fact that your draft requests 
permanent registration.  Though I still think the notion of using multiple URI 
scheme names to handle different algorithms is a poor call.

I still want to ask why you don't just use [an appropriate profile of] ni: URIs. 
  It seems to me it might be less effort, even if there's marginally more code 
to write for your particular application.  I think you mentioned that one of 
your desires is to use hex encoding rather than base64?  I'd be more supportive 
of an effort to re-use the ni: structure in a new scheme that uses hex encoding 
(a bit like the nih: scheme uses "human" encoding).

(I'm also surprised that "the URN people did not like" a proposal based on 
"urn:cert:...".  I recall suggesting something similar for ni:, but I think 
there were some issues with the syntactic constraints of URNs.  I think it's 
unfortunate that the URI/URN worlds seem to be diverging, but that's a whole 
different discussion.)

#g
--

On 26/09/2015 22:05, Sean Leonard wrote:
> Graham,
>
> FWIW I don't have a problem with it being a provisional registration. Making a
> provisional registration as an intermediate step to permanent registration is an
> envisioned use case (RFC 7595 Section 4) anyway.
>
> That being said, this draft hasn't really been circulated broadly outside of
> [email-masked] do not recall even posting it to the apps or
> security-related mailing lists. Therefore discussion opportunity simply hasn't
> been had yet.
>
> I should be upfront that these SHA schemes were part of a broader initiative to
> identify security objects such as certificates with URIs
> (draft-seantek-certspec). The original proposal was to create a cert namespace
> URN (urn:cert:...); however, the URN people did not like that, so it's up to the
> top instead.
>
> Sean
>
>> On the basis of the muted level of support seen so far, I would anticipate
>> this not reaching the bar for *permanent* registration of the URI schemes.  I
>> think it would be fine as is for *provisional* registration.
>>
>> would in general expect such a judgement to be backed by a clear IETF
>> consensus or widespread deployment, neither of which I am aware of for this
>> proposal.  In particular, notwithstanding your brief comments in section 2,
>> I'm not seeing any essential utility here that is not provided by the ni:
>> scheme.  The comment "the URI semantics may differ" is not substantiated in
>> any way that I can recognize.
>>
>> Further, given the restrictions of the URI scheme namespace (ibid), I think
>> the approach of registering different URI schemes for each hash algorithm is
>> not appropriate.
>>
>> #g
>> --
>>
>>
>>> I request review of the SHA URIs in this draft-02, per RFC 7595. The URI
>>> schemes are "sha1", "sha256", "sha1msg", and "sha256msg", respectively.
>>>
>>> Most feedback was incorporated, or at least considered, in this document. If
>>> folks feel that their feedback is not reflected please contact me and I will
>>> look into it further.
>>>
>>> Thank you,
>>>
>>> Sean
>>>
>>> Begin forwarded message:
>>>

---

From: Sean Leonard <[email-masked]>
Date: Sun, 27 Sep 2015 15:10:16 -0700

On 9/27/2015 12:20 AM, Graham Klyne wrote:
> [...]
>
> (I'm also surprised that "the URN people did not like" a proposal 
> based on "urn:cert:...".  I recall suggesting something similar for 
> ni:, but I think there were some issues with the syntactic constraints 
> of URNs.  I think it's unfortunate that the URI/URN worlds seem to be 
> diverging, but that's a whole different discussion.)

I'm not really privvy to all of the ni: / URN conversations, although I 
am sure they are in the archives. The certspec (urn:cert:) / URN 
conversations are mostly circa 2013 and 2014.

Without poking too many sacred cows, the URN people tend to find a lot 
of pedantic reasons to resist incorporating new things...as evidenced by 
DOI and the fact that the WG has been working on their thing for 4+ years.

Ultimately I ended up agreeing with the URN people, on the basis that 
there is no way to guarantee that a hash "name" corresponds to exactly 
one resource. The pigeonhole principle (see draft-02) clearly shows that 
there are an infinite number of resources that hash to a particular 
value. The point of hashes is not to guarantee a unique identifier, but 
merely to make the discovery of those other resources computationally 
infeasible. This is fine for URIs but (depending on your philosophy) may 
not be satisfactory for URNs. However, once an algorithm is 
cryptanalyzed, even that bet is off.

Sean