Request -02 review of SHA URIs

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Request -02 review of SHA URIs

Sean Leonard-4
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: [hidden email]
> 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.



_______________________________________________
Uri-review mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/uri-review

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Request -02 review of SHA URIs

Graham Klyne-2
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:

> 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: [hidden email]
>> 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.
>
>
>
>
> _______________________________________________
> Uri-review mailing list
> [hidden email]
> https://www.ietf.org/mailman/listinfo/uri-review
>

_______________________________________________
Uri-review mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/uri-review
Reply | Threaded
Open this post in threaded view
|

Re: Request -02 review of SHA URIs

Sean Leonard-4
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 [hidden email]--I 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
> --
>
>
> On 25/09/2015 23:58, Sean Leonard wrote:
>> 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: [hidden email]
>>> 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.
>>
>>
>>
>>
>> _______________________________________________
>> Uri-review mailing list
>> [hidden email]
>> https://www.ietf.org/mailman/listinfo/uri-review
>>


_______________________________________________
Uri-review mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/uri-review

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Request -02 review of SHA URIs

Graham Klyne-2
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
> [hidden email]--I 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
>> --
>>
>>
>> On 25/09/2015 23:58, Sean Leonard wrote:
>>> 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: [hidden email]
>>>> 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.
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Uri-review mailing list
>>> [hidden email]
>>> https://www.ietf.org/mailman/listinfo/uri-review
>>>
>
>

_______________________________________________
Uri-review mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/uri-review
Reply | Threaded
Open this post in threaded view
|

Re: Request -02 review of SHA URIs

Sean Leonard-4
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



_______________________________________________
Uri-review mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/uri-review

smime.p7s (4K) Download Attachment