Request Review of SHA-1 and SHA-256 URIs

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

Request Review of SHA-1 and SHA-256 URIs

Sean Leonard-4
Hello URI Review:

I request review of SHA-1 and SHA-256 URIs, per RFC 7595. The URI schemes are "sha1" and "sha256", respectively.

Relevant notifications and templates are below.

Thank you,

Sean

***

4.1.  Assignment of sha1 URI Scheme

      URI scheme name: sha1

      Status: Permanent

      Applications/protocols that use this URI scheme name:
        General applicability. Some examples include security
        applications and systems, database and forensic lookup
        tools, and distributed peer-to-peer protocols.

      Contact: Sean Leonard <[hidden email]>

      Change controller: IETF

      References: This document.

4.2.  Assignment of sha256 URI Scheme

      URI scheme name: sha256

      Status: Permanent

      Applications/protocols that use this URI scheme name:
        General applicability. Some examples include security
        applications and systems, database and forensic lookup
        tools, and distributed peer-to-peer protocols.

      Contact: Sean Leonard <[hidden email]>

      Change controller: IETF

      References: This document.

***


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

Abstract:
  This document registers Uniform Resource Indicator schemes for use
  with certain Secure Hash Algorithm (SHA) functions, namely SHA-1 and
  SHA-256. The purpose is to identify data streams 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 Review of SHA-1 and SHA-256 URIs

Graham Klyne-2
Sean,

re: https://tools.ietf.org/html/draft-seantek-sha-uris-01

I've only read the intro to your document, but before going any further I want
to check that you are aware of the ni: scheme [1], and would ask that you
provide some explanation as to why we need yet another hash-based URI scheme.

#g
--

[1] https://tools.ietf.org/html/rfc6920


On 09/09/2015 23:24, Sean Leonard wrote:

> Hello URI Review:
>
> I request review of SHA-1 and SHA-256 URIs, per RFC 7595. The URI schemes are "sha1" and "sha256", respectively.
>
> Relevant notifications and templates are below.
>
> Thank you,
>
> Sean
>
> ***
>
> 4.1.  Assignment of sha1 URI Scheme
>
>        URI scheme name: sha1
>
>        Status: Permanent
>
>        Applications/protocols that use this URI scheme name:
>          General applicability. Some examples include security
>          applications and systems, database and forensic lookup
>          tools, and distributed peer-to-peer protocols.
>
>        Contact: Sean Leonard <[hidden email]>
>
>        Change controller: IETF
>
>        References: This document.
>
> 4.2.  Assignment of sha256 URI Scheme
>
>        URI scheme name: sha256
>
>        Status: Permanent
>
>        Applications/protocols that use this URI scheme name:
>          General applicability. Some examples include security
>          applications and systems, database and forensic lookup
>          tools, and distributed peer-to-peer protocols.
>
>        Contact: Sean Leonard <[hidden email]>
>
>        Change controller: IETF
>
>        References: This document.
>
> ***
>
>
> Name: draft-seantek-sha-uris
> Revision: 01
> Title: URI Schemes for SHA-1 and SHA-256
> Document date: 2015-09-09
> Group: Individual Submission
> Pages: 8
> URL:            https://www.ietf.org/internet-drafts/draft-seantek-sha-uris-01.txt
> Status:         https://datatracker.ietf.org/doc/draft-seantek-sha-uris/
> Htmlized:       https://tools.ietf.org/html/draft-seantek-sha-uris-01
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-seantek-sha-uris-01
>
> Abstract:
>    This document registers Uniform Resource Indicator schemes for use
>    with certain Secure Hash Algorithm (SHA) functions, namely SHA-1 and
>    SHA-256. The purpose is to identify data streams 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 Review of SHA-1 and SHA-256 URIs

Sean Leonard-4
Yes, that is covered in the document. Sean

On Sep 10, 2015, at 12:36 AM, Graham Klyne <[hidden email]> wrote:

> Sean,
>
> re: https://tools.ietf.org/html/draft-seantek-sha-uris-01
>
> I've only read the intro to your document, but before going any further I want to check that you are aware of the ni: scheme [1], and would ask that you provide some explanation as to why we need yet another hash-based URI scheme.
>
> #g
> --
>
> [1] https://tools.ietf.org/html/rfc6920
>
>
> On 09/09/2015 23:24, Sean Leonard wrote:
>> Hello URI Review:
>>
>> I request review of SHA-1 and SHA-256 URIs, per RFC 7595. The URI schemes are "sha1" and "sha256", respectively.
>>
>> Relevant notifications and templates are below.
>>
>> Thank you,
>>
>> Sean
>>
>> ***
>>
>> 4.1.  Assignment of sha1 URI Scheme
>>
>>       URI scheme name: sha1
>>
>>       Status: Permanent
>>
>>       Applications/protocols that use this URI scheme name:
>>         General applicability. Some examples include security
>>         applications and systems, database and forensic lookup
>>         tools, and distributed peer-to-peer protocols.
>>
>>       Contact: Sean Leonard <[hidden email]>
>>
>>       Change controller: IETF
>>
>>       References: This document.
>>
>> 4.2.  Assignment of sha256 URI Scheme
>>
>>       URI scheme name: sha256
>>
>>       Status: Permanent
>>
>>       Applications/protocols that use this URI scheme name:
>>         General applicability. Some examples include security
>>         applications and systems, database and forensic lookup
>>         tools, and distributed peer-to-peer protocols.
>>
>>       Contact: Sean Leonard <[hidden email]>
>>
>>       Change controller: IETF
>>
>>       References: This document.
>>
>> ***
>>
>>
>> Name: draft-seantek-sha-uris
>> Revision: 01
>> Title: URI Schemes for SHA-1 and SHA-256
>> Document date: 2015-09-09
>> Group: Individual Submission
>> Pages: 8
>> URL:            https://www.ietf.org/internet-drafts/draft-seantek-sha-uris-01.txt
>> Status:         https://datatracker.ietf.org/doc/draft-seantek-sha-uris/
>> Htmlized:       https://tools.ietf.org/html/draft-seantek-sha-uris-01
>> Diff:           https://www.ietf.org/rfcdiff?url2=draft-seantek-sha-uris-01
>>
>> Abstract:
>>   This document registers Uniform Resource Indicator schemes for use
>>   with certain Secure Hash Algorithm (SHA) functions, namely SHA-1 and
>>   SHA-256. The purpose is to identify data streams 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 Review of SHA-1 and SHA-256 URIs

Graham Klyne-2
Sean,

OK, I'm seeing this:

[[
    Other URI schemes such as ni: [RFC6920] include or incorporate
    hashes. Software may be written to convert URIs between such schemes.
    Although the bits of the resource may be equivalent, the URI
    semantics may differ. The SHA-1 and SHA-256 URIs in this document
    identify binary data streams (i.e., an ordered sequence of bits).
]]

But that ("identify binary data streams") is exactly what (according to my
understanding) the ni: scheme does.  So I'm still not seeing what new capability
your proposal is adding.  The language in RFC6920 may be different (e.g.
"verifying the binding between the data and the name"), but I submit the effect
is the same).  I'm not seeing here how the "URI semantics" of your proposal are
not subsumed by ni:.

(If I'm missing a more detailed coverage of this topic, please provide a section
reference.)

#g
--


On 10/09/2015 08:39, Sean Leonard wrote:

> Yes, that is covered in the document. Sean
>
> On Sep 10, 2015, at 12:36 AM, Graham Klyne <[hidden email]> wrote:
>
>> Sean,
>>
>> re: https://tools.ietf.org/html/draft-seantek-sha-uris-01
>>
>> I've only read the intro to your document, but before going any further I want to check that you are aware of the ni: scheme [1], and would ask that you provide some explanation as to why we need yet another hash-based URI scheme.
>>
>> #g
>> --
>>
>> [1] https://tools.ietf.org/html/rfc6920
>>
>>
>> On 09/09/2015 23:24, Sean Leonard wrote:
>>> Hello URI Review:
>>>
>>> I request review of SHA-1 and SHA-256 URIs, per RFC 7595. The URI schemes are "sha1" and "sha256", respectively.
>>>
>>> Relevant notifications and templates are below.
>>>
>>> Thank you,
>>>
>>> Sean
>>>
>>> ***
>>>
>>> 4.1.  Assignment of sha1 URI Scheme
>>>
>>>        URI scheme name: sha1
>>>
>>>        Status: Permanent
>>>
>>>        Applications/protocols that use this URI scheme name:
>>>          General applicability. Some examples include security
>>>          applications and systems, database and forensic lookup
>>>          tools, and distributed peer-to-peer protocols.
>>>
>>>        Contact: Sean Leonard <[hidden email]>
>>>
>>>        Change controller: IETF
>>>
>>>        References: This document.
>>>
>>> 4.2.  Assignment of sha256 URI Scheme
>>>
>>>        URI scheme name: sha256
>>>
>>>        Status: Permanent
>>>
>>>        Applications/protocols that use this URI scheme name:
>>>          General applicability. Some examples include security
>>>          applications and systems, database and forensic lookup
>>>          tools, and distributed peer-to-peer protocols.
>>>
>>>        Contact: Sean Leonard <[hidden email]>
>>>
>>>        Change controller: IETF
>>>
>>>        References: This document.
>>>
>>> ***
>>>
>>>
>>> Name: draft-seantek-sha-uris
>>> Revision: 01
>>> Title: URI Schemes for SHA-1 and SHA-256
>>> Document date: 2015-09-09
>>> Group: Individual Submission
>>> Pages: 8
>>> URL:            https://www.ietf.org/internet-drafts/draft-seantek-sha-uris-01.txt
>>> Status:         https://datatracker.ietf.org/doc/draft-seantek-sha-uris/
>>> Htmlized:       https://tools.ietf.org/html/draft-seantek-sha-uris-01
>>> Diff:           https://www.ietf.org/rfcdiff?url2=draft-seantek-sha-uris-01
>>>
>>> Abstract:
>>>    This document registers Uniform Resource Indicator schemes for use
>>>    with certain Secure Hash Algorithm (SHA) functions, namely SHA-1 and
>>>    SHA-256. The purpose is to identify data streams 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 Review of SHA-1 and SHA-256 URIs

Sean Leonard-4
Hi Graham,

Well, I would encourage you to read RFC 6920 to compare, if it matters. Basically the applications are different. (And even if there is application overlap, it shouldn't matter.)

Neither NI nor SHAx nor any other URI scheme has a monopoly on hash algorithms. So the fact that one uses hashes or is designed to use hashes has no bearing on the other. Plenty of other URIs use hashes in some way.

The SHAx schemes are designed to be simple, intuitive, trivial, and complete. Key features:
  • hash algorithm is fixed
  • hash length is fixed (no truncation)
  • format is hex -- copy-and-pastable
  • no authority component--it's just a hash
  • no query parameters
  • can identify bit streams (not integral of 8 bits)

I suppose that I should add a section on what it means to dereference SHAx URIs, although I note that RFC 7595 doesn't strictly require it. It would be good, though (Section 3.4 of [RFC7595]). Since SHAx URIs only identify data streams, dereferencing does not convey any Internet media type information. This type of information needs to be inferred from the content or the context.

Sean

On 9/10/2015 12:54 AM, Graham Klyne wrote:
Sean,

OK, I'm seeing this:

[[
   Other URI schemes such as ni: [RFC6920] include or incorporate
   hashes. Software may be written to convert URIs between such schemes.
   Although the bits of the resource may be equivalent, the URI
   semantics may differ. The SHA-1 and SHA-256 URIs in this document
   identify binary data streams (i.e., an ordered sequence of bits).
]]

But that ("identify binary data streams") is exactly what (according to my understanding) the ni: scheme does.  So I'm still not seeing what new capability your proposal is adding.  The language in RFC6920 may be different (e.g. "verifying the binding between the data and the name"), but I submit the effect is the same).  I'm not seeing here how the "URI semantics" of your proposal are not subsumed by ni:.

(If I'm missing a more detailed coverage of this topic, please provide a section reference.)

#g
--


On 10/09/2015 08:39, Sean Leonard wrote:
Yes, that is covered in the document. Sean

On Sep 10, 2015, at 12:36 AM, Graham Klyne [hidden email] wrote:

Sean,

re: https://tools.ietf.org/html/draft-seantek-sha-uris-01

I've only read the intro to your document, but before going any further I want to check that you are aware of the ni: scheme [1], and would ask that you provide some explanation as to why we need yet another hash-based URI scheme.

#g
--

[1] https://tools.ietf.org/html/rfc6920


On 09/09/2015 23:24, Sean Leonard wrote:
Hello URI Review:

I request review of SHA-1 and SHA-256 URIs, per RFC 7595. The URI schemes are "sha1" and "sha256", respectively.

Relevant notifications and templates are below.

Thank you,

Sean

***

4.1.  Assignment of sha1 URI Scheme

       URI scheme name: sha1

       Status: Permanent

       Applications/protocols that use this URI scheme name:
         General applicability. Some examples include security
         applications and systems, database and forensic lookup
         tools, and distributed peer-to-peer protocols.

       Contact: Sean Leonard [hidden email]

       Change controller: IETF

       References: This document.

4.2.  Assignment of sha256 URI Scheme

       URI scheme name: sha256

       Status: Permanent

       Applications/protocols that use this URI scheme name:
         General applicability. Some examples include security
         applications and systems, database and forensic lookup
         tools, and distributed peer-to-peer protocols.

       Contact: Sean Leonard [hidden email]

       Change controller: IETF

       References: This document.

***


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

Abstract:
   This document registers Uniform Resource Indicator schemes for use
   with certain Secure Hash Algorithm (SHA) functions, namely SHA-1 and
   SHA-256. The purpose is to identify data streams 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 Review of SHA-1 and SHA-256 URIs

Stephen Farrell
Fwiw, I read Sean's draft and these mails and don't see any point in doing this again (again).

S.


On Thu Sep 10 18:07:09 2015 GMT+0100, Sean Leonard wrote:

> Hi Graham,
>
> Well, I would encourage you to read RFC 6920 to compare, if it matters.
> Basically the applications are different. (And even if there is
> application overlap, it shouldn't matter.)
>
> Neither NI nor SHAx nor any other URI scheme has a monopoly on hash
> algorithms. So the fact that one uses hashes or is designed to use
> hashes has no bearing on the other. Plenty of other URIs use hashes in
> some way.
>
> The SHAx schemes are designed to be simple, intuitive, trivial, and
> complete. Key features:
>
>   * hash algorithm is fixed
>   * hash length is fixed (no truncation)
>   * format is hex -- copy-and-pastable
>   * no authority component--it's just a hash
>   * no query parameters
>   * can identify bit streams (not integral of 8 bits)
>
>
> I suppose that I should add a section on what it means to dereference
> SHAx URIs, although I note that RFC 7595 doesn't strictly require it. It
> would be good, though (Section 3.4 of [RFC7595]). Since SHAx URIs only
> identify data streams, dereferencing does not convey any Internet media
> type information. This type of information needs to be inferred from the
> content or the context.
>
> Sean
>
> On 9/10/2015 12:54 AM, Graham Klyne wrote:
> > Sean,
> >
> > OK, I'm seeing this:
> >
> > [[
> >    Other URI schemes such as ni: [RFC6920] include or incorporate
> >    hashes. Software may be written to convert URIs between such schemes.
> >    Although the bits of the resource may be equivalent, the URI
> >    semantics may differ. The SHA-1 and SHA-256 URIs in this document
> >    identify binary data streams (i.e., an ordered sequence of bits).
> > ]]
> >
> > But that ("identify binary data streams") is exactly what (according
> > to my understanding) the ni: scheme does.  So I'm still not seeing
> > what new capability your proposal is adding.  The language in RFC6920
> > may be different (e.g. "verifying the binding between the data and the
> > name"), but I submit the effect is the same).  I'm not seeing here how
> > the "URI semantics" of your proposal are not subsumed by ni:.
> >
> > (If I'm missing a more detailed coverage of this topic, please provide
> > a section reference.)
> >
> > #g
> > --
> >
> >
> > On 10/09/2015 08:39, Sean Leonard wrote:
> >> Yes, that is covered in the document. Sean
> >>
> >> On Sep 10, 2015, at 12:36 AM, Graham Klyne <[hidden email]> wrote:
> >>
> >>> Sean,
> >>>
> >>> re: https://tools.ietf.org/html/draft-seantek-sha-uris-01
> >>>
> >>> I've only read the intro to your document, but before going any
> >>> further I want to check that you are aware of the ni: scheme [1],
> >>> and would ask that you provide some explanation as to why we need
> >>> yet another hash-based URI scheme.
> >>>
> >>> #g
> >>> --
> >>>
> >>> [1] https://tools.ietf.org/html/rfc6920
> >>>
> >>>
> >>> On 09/09/2015 23:24, Sean Leonard wrote:
> >>>> Hello URI Review:
> >>>>
> >>>> I request review of SHA-1 and SHA-256 URIs, per RFC 7595. The URI
> >>>> schemes are "sha1" and "sha256", respectively.
> >>>>
> >>>> Relevant notifications and templates are below.
> >>>>
> >>>> Thank you,
> >>>>
> >>>> Sean
> >>>>
> >>>> ***
> >>>>
> >>>> 4.1.  Assignment of sha1 URI Scheme
> >>>>
> >>>>        URI scheme name: sha1
> >>>>
> >>>>        Status: Permanent
> >>>>
> >>>>        Applications/protocols that use this URI scheme name:
> >>>>          General applicability. Some examples include security
> >>>>          applications and systems, database and forensic lookup
> >>>>          tools, and distributed peer-to-peer protocols.
> >>>>
> >>>>        Contact: Sean Leonard <[hidden email]>
> >>>>
> >>>>        Change controller: IETF
> >>>>
> >>>>        References: This document.
> >>>>
> >>>> 4.2.  Assignment of sha256 URI Scheme
> >>>>
> >>>>        URI scheme name: sha256
> >>>>
> >>>>        Status: Permanent
> >>>>
> >>>>        Applications/protocols that use this URI scheme name:
> >>>>          General applicability. Some examples include security
> >>>>          applications and systems, database and forensic lookup
> >>>>          tools, and distributed peer-to-peer protocols.
> >>>>
> >>>>        Contact: Sean Leonard <[hidden email]>
> >>>>
> >>>>        Change controller: IETF
> >>>>
> >>>>        References: This document.
> >>>>
> >>>> ***
> >>>>
> >>>>
> >>>> Name:        draft-seantek-sha-uris
> >>>> Revision:    01
> >>>> Title:        URI Schemes for SHA-1 and SHA-256
> >>>> Document date:    2015-09-09
> >>>> Group:        Individual Submission
> >>>> Pages:        8
> >>>> URL:
> >>>> https://www.ietf.org/internet-drafts/draft-seantek-sha-uris-01.txt
> >>>> Status: https://datatracker.ietf.org/doc/draft-seantek-sha-uris/
> >>>> Htmlized: https://tools.ietf.org/html/draft-seantek-sha-uris-01
> >>>> Diff: https://www.ietf.org/rfcdiff?url2=draft-seantek-sha-uris-01
> >>>>
> >>>> Abstract:
> >>>>    This document registers Uniform Resource Indicator schemes for use
> >>>>    with certain Secure Hash Algorithm (SHA) functions, namely SHA-1
> >>>> and
> >>>>    SHA-256. The purpose is to identify data streams 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 Review of SHA-1 and SHA-256 URIs

Chris Rebert-4
In reply to this post by Sean Leonard-4
On Wed, Sep 9, 2015, at 03:24 PM, Sean Leonard wrote:
> Hello URI Review:
>
> I request review of SHA-1 and SHA-256 URIs, per RFC 7595. The URI schemes
> are "sha1" and "sha256", respectively.
>
> Relevant notifications and templates are below.
<snip>

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

>From your I-D:
> this specification RECOMMENDS that generators emit uppercase hexadecimal and use no delimiters.

Why uppercase? The I-D doesn't seem to give any explicit reasoning for
this. Every tool or library that I can recall encountering that emits
SHA hexadecimal digests uses lowercase, not uppercase.

Sincerely,
Chris

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

Re: Request Review of SHA-1 and SHA-256 URIs

Julian Reschke
In reply to this post by Sean Leonard-4
On 2015-09-10 19:07, Sean Leonard wrote:

> Hi Graham,
>
> Well, I would encourage you to read RFC 6920 to compare, if it matters.
> Basically the applications are different. (And even if there is
> application overlap, it shouldn't matter.)
>
> Neither NI nor SHAx nor any other URI scheme has a monopoly on hash
> algorithms. So the fact that one uses hashes or is designed to use
> hashes has no bearing on the other. Plenty of other URIs use hashes in
> some way.
>
> The SHAx schemes are designed to be simple, intuitive, trivial, and
> complete. Key features:
>
>   * hash algorithm is fixed
>   * hash length is fixed (no truncation)
>   * format is hex -- copy-and-pastable
>   * no authority component--it's just a hash
>   * no query parameters
>   * can identify bit streams (not integral of 8 bits)
> ...

I would recommend that you go through this list and check whether RFC
6920 has the same properties (or potentially could be extended to have
them).

URI schemes may be cheap, but adding new schemes when an existing scheme
could be used instead increases the overall complexity of our protocols.
If you really really believe you need new schemes by all means add an
appendix that clearly explains the difference to "ni".

Best regards, Julian

PS: I wouldn't consider the hash algo to be fixed to be a feature.

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

Re: Request Review of SHA-1 and SHA-256 URIs

Sean Leonard-4
In reply to this post by Chris Rebert-4
On 9/11/2015 2:22 AM, Chris Rebert wrote:

> On Wed, Sep 9, 2015, at 03:24 PM, Sean Leonard wrote:
>> Hello URI Review:
>>
>> I request review of SHA-1 and SHA-256 URIs, per RFC 7595. The URI schemes
>> are "sha1" and "sha256", respectively.
>>
>> Relevant notifications and templates are below.
> <snip>
>> Name:           draft-seantek-sha-uris
>> Revision:       01
>> Title:          URI Schemes for SHA-1 and SHA-256
>> Document date:  2015-09-09
>> Group:          Individual Submission
>> Pages:          8
>> URL:
>> https://www.ietf.org/internet-drafts/draft-seantek-sha-uris-01.txt
>> Status:         https://datatracker.ietf.org/doc/draft-seantek-sha-uris/
>> Htmlized:       https://tools.ietf.org/html/draft-seantek-sha-uris-01
>> Diff:
>> https://www.ietf.org/rfcdiff?url2=draft-seantek-sha-uris-01
> >From your I-D:
>> this specification RECOMMENDS that generators emit uppercase hexadecimal and use no delimiters.
> Why uppercase? The I-D doesn't seem to give any explicit reasoning for
> this. Every tool or library that I can recall encountering that emits
> SHA hexadecimal digests uses lowercase, not uppercase.
It's a fair point. I believe the tools that I was looking at emitted
uppercase. Additionally, these schemes are a piece of a larger prior
objective, to represent certificates and other security objects as URIs.
It used to be urn:cert:SHA-1:EABE019D5B42480F48709CECD12404EBB4ADF00D
but I have since abandoned the urn:cert route in favor of direct URIs.
(See <https://tools.ietf.org/html/draft-seantek-certspec-04>, expired.)

Given that the hash identifier is just the scheme,
sha1:eabe019d5b42480f48709cecd12404ebb4adf00d seems just as acceptable
to me as sha1:EABE019D5B42480F48709CECD12404EBB4ADF00D.

I felt that there should be a recommended style if for no other reason
than to generate consistency between tool outputs when there are no
contextual style considerations. I am willing to revise the text
accordingly.

Can you cite specific tools or libraries, however?

Thank you,

Sean


_______________________________________________
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 Review of SHA-1 and SHA-256 URIs

Chris Rebert-4
On Sat, Sep 12, 2015, at 08:26 PM, Sean Leonard wrote:

> On 9/11/2015 2:22 AM, Chris Rebert wrote:
> > On Wed, Sep 9, 2015, at 03:24 PM, Sean Leonard wrote:
> >> Hello URI Review:
> >>
> >> I request review of SHA-1 and SHA-256 URIs, per RFC 7595. The URI schemes
> >> are "sha1" and "sha256", respectively.
> >>
> >> Relevant notifications and templates are below.
> > <snip>
> >> Name:           draft-seantek-sha-uris
> >> Revision:       01
> >> Title:          URI Schemes for SHA-1 and SHA-256
> >> Document date:  2015-09-09
> >> Group:          Individual Submission
> >> Pages:          8
> >> URL:
> >> https://www.ietf.org/internet-drafts/draft-seantek-sha-uris-01.txt
> >> Status:         https://datatracker.ietf.org/doc/draft-seantek-sha-uris/
> >> Htmlized:       https://tools.ietf.org/html/draft-seantek-sha-uris-01
> >> Diff:
> >> https://www.ietf.org/rfcdiff?url2=draft-seantek-sha-uris-01
> > >From your I-D:
> >> this specification RECOMMENDS that generators emit uppercase hexadecimal and use no delimiters.
> > Why uppercase? The I-D doesn't seem to give any explicit reasoning for
> > this. Every tool or library that I can recall encountering that emits
> > SHA hexadecimal digests uses lowercase, not uppercase.
>
> It's a fair point. I believe the tools that I was looking at emitted
> uppercase. Additionally, these schemes are a piece of a larger prior
> objective, to represent certificates and other security objects as URIs.
> It used to be urn:cert:SHA-1:EABE019D5B42480F48709CECD12404EBB4ADF00D
> but I have since abandoned the urn:cert route in favor of direct URIs.
> (See <https://tools.ietf.org/html/draft-seantek-certspec-04>, expired.)
>
> Given that the hash identifier is just the scheme,
> sha1:eabe019d5b42480f48709cecd12404ebb4adf00d seems just as acceptable
> to me as sha1:EABE019D5B42480F48709CECD12404EBB4ADF00D.
>
> I felt that there should be a recommended style if for no other reason
> than to generate consistency between tool outputs when there are no
> contextual style considerations. I am willing to revise the text
> accordingly.
>
> Can you cite specific tools or libraries, however?

Yes, readily.

shasum:
$ shasum example.txt
da39a3ee5e6b4b0d3255bfef95601890afd80709  example.txt

OpenSSL:
$ openssl dgst -sha1 example.txt
SHA1(example.txt)= da39a3ee5e6b4b0d3255bfef95601890afd80709

Python:
$ python
Python 2.7.10 (default, Jul 17 2015, 01:43:42)
[GCC 4.2.1 Compatible Apple LLVM 6.1.0 (clang-602.0.53)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from hashlib import sha1
>>> print sha1("foo").hexdigest()
0beec7b5ea3f0fdbc95d0dd47f3c5bc275da8a33

Ruby:
$ irb
irb(main):001:0> require 'digest'
=> true
irb(main):002:0> puts Digest::SHA1.hexdigest('foo')
0beec7b5ea3f0fdbc95d0dd47f3c5bc275da8a33
=> nil

The popular Bouncy Castle cryptography API for Java:
http://www.bouncycastle.org/docs/docs1.5on/org/bouncycastle/util/encoders/Hex.html#toHexString(byte[])
(Example omitted due to verbosity)

Node.js:
$ node
> var crypto = require('crypto');
undefined
> var hash = crypto.createHash('sha1');
undefined
> hash.update('foo');
{ _handle: {}, _options: undefined }
> console.log(hash.digest('hex'))
0beec7b5ea3f0fdbc95d0dd47f3c5bc275da8a33

Cheers,
Chris
--
http://chrisrebert.com

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

Re: Request Review of SHA-1 and SHA-256 URIs

Sean Leonard-4
On 9/13/2015 1:36 AM, Chris Rebert wrote:
> On Sat, Sep 12, 2015, at 08:26 PM, Sean Leonard wrote:
[SNIP]

>> I felt that there should be a recommended style if for no other reason
>> than to generate consistency between tool outputs when there are no
>> contextual style considerations. I am willing to revise the text
>> accordingly.
>>
>> Can you cite specific tools or libraries, however?
> Yes, readily.
>
> shasum:
> $ shasum example.txt
> da39a3ee5e6b4b0d3255bfef95601890afd80709  example.txt
>
> OpenSSL:
> $ openssl dgst -sha1 example.txt
> SHA1(example.txt)= da39a3ee5e6b4b0d3255bfef95601890afd80709
>
> Python:
> $ python
> Python 2.7.10 (default, Jul 17 2015, 01:43:42)
> [GCC 4.2.1 Compatible Apple LLVM 6.1.0 (clang-602.0.53)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
>>>> from hashlib import sha1
>>>> print sha1("foo").hexdigest()
> 0beec7b5ea3f0fdbc95d0dd47f3c5bc275da8a33
>
> Ruby:
> $ irb
> irb(main):001:0> require 'digest'
> => true
> irb(main):002:0> puts Digest::SHA1.hexdigest('foo')
> 0beec7b5ea3f0fdbc95d0dd47f3c5bc275da8a33
> => nil
>
> The popular Bouncy Castle cryptography API for Java:
> http://www.bouncycastle.org/docs/docs1.5on/org/bouncycastle/util/encoders/Hex.html#toHexString(byte[])
> (Example omitted due to verbosity)
>
> Node.js:
> $ node
>> var crypto = require('crypto');
> undefined
>> var hash = crypto.createHash('sha1');
> undefined
>> hash.update('foo');
> { _handle: {}, _options: undefined }
>> console.log(hash.digest('hex'))
> 0beec7b5ea3f0fdbc95d0dd47f3c5bc275da8a33
Thank you. This is helpful and I will cite such a list in the next
revision. I am leaning slightly towards lowercase now as the default.

I will compile a list and put it somewhere public, where others can
revise and/or comment on it...is there an IETF wiki for URIs or uri-review?

Best regards,

Sean


_______________________________________________
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 Review of SHA-1 and SHA-256 URIs

Alexey Melnikov
In reply to this post by Stephen Farrell
On 10/09/2015 18:30, [hidden email] wrote:
> Fwiw, I read Sean's draft and these mails and don't see any point in doing this again (again).

Stephen,

While Sean's proposal is somewhat similar to nih, use cases and
technical details are different. Most implementations I've seen are
using hex encoding for hashes, not base64. Sean's proposal has a
convenient property that it is possible to cut & paste text from other
tools to easily construct URIs, without the need to reencode anything.

I am not convinced that defining a new top level URI scheme for each
hash is a good idea (I think I prefer a single URN-type scheme with the
hash type being the first component), but otherwise I think this should
be published Experimental (and registered at least as provisional in the
URI registry).

Best Regards,
Alexey

> On Thu Sep 10 18:07:09 2015 GMT+0100, Sean Leonard wrote:
>> Hi Graham,
>>
>> Well, I would encourage you to read RFC 6920 to compare, if it matters.
>> Basically the applications are different. (And even if there is
>> application overlap, it shouldn't matter.)
>>
>> Neither NI nor SHAx nor any other URI scheme has a monopoly on hash
>> algorithms. So the fact that one uses hashes or is designed to use
>> hashes has no bearing on the other. Plenty of other URIs use hashes in
>> some way.
>>
>> The SHAx schemes are designed to be simple, intuitive, trivial, and
>> complete. Key features:
>>
>>   * hash algorithm is fixed
>>   * hash length is fixed (no truncation)
>>   * format is hex -- copy-and-pastable
>>   * no authority component--it's just a hash
>>   * no query parameters
>>   * can identify bit streams (not integral of 8 bits)
>>
>>
>> I suppose that I should add a section on what it means to dereference
>> SHAx URIs, although I note that RFC 7595 doesn't strictly require it. It
>> would be good, though (Section 3.4 of [RFC7595]). Since SHAx URIs only
>> identify data streams, dereferencing does not convey any Internet media
>> type information. This type of information needs to be inferred from the
>> content or the context.
>>
>> Sean
>>
>> On 9/10/2015 12:54 AM, Graham Klyne wrote:
>>> Sean,
>>>
>>> OK, I'm seeing this:
>>>
>>> [[
>>>    Other URI schemes such as ni: [RFC6920] include or incorporate
>>>    hashes. Software may be written to convert URIs between such schemes.
>>>    Although the bits of the resource may be equivalent, the URI
>>>    semantics may differ. The SHA-1 and SHA-256 URIs in this document
>>>    identify binary data streams (i.e., an ordered sequence of bits).
>>> ]]
>>>
>>> But that ("identify binary data streams") is exactly what (according
>>> to my understanding) the ni: scheme does.  So I'm still not seeing
>>> what new capability your proposal is adding.  The language in RFC6920
>>> may be different (e.g. "verifying the binding between the data and the
>>> name"), but I submit the effect is the same).  I'm not seeing here how
>>> the "URI semantics" of your proposal are not subsumed by ni:.
>>>
>>> (If I'm missing a more detailed coverage of this topic, please provide
>>> a section reference.)
>>>
>>> #g
>>> --
>>>
>>>
>>> On 10/09/2015 08:39, Sean Leonard wrote:
>>>> Yes, that is covered in the document. Sean
>>>>
>>>> On Sep 10, 2015, at 12:36 AM, Graham Klyne <[hidden email]> wrote:
>>>>
>>>>> Sean,
>>>>>
>>>>> re: https://tools.ietf.org/html/draft-seantek-sha-uris-01
>>>>>
>>>>> I've only read the intro to your document, but before going any
>>>>> further I want to check that you are aware of the ni: scheme [1],
>>>>> and would ask that you provide some explanation as to why we need
>>>>> yet another hash-based URI scheme.
>>>>>
>>>>> #g
>>>>> --
>>>>>
>>>>> [1] https://tools.ietf.org/html/rfc6920
>>>>>
>>>>>
>>>>> On 09/09/2015 23:24, Sean Leonard wrote:
>>>>>> Hello URI Review:
>>>>>>
>>>>>> I request review of SHA-1 and SHA-256 URIs, per RFC 7595. The URI
>>>>>> schemes are "sha1" and "sha256", respectively.
>>>>>>
>>>>>> Relevant notifications and templates are below.
>>>>>>
>>>>>> Thank you,
>>>>>>
>>>>>> Sean
>>>>>>
>>>>>> ***
>>>>>>
>>>>>> 4.1.  Assignment of sha1 URI Scheme
>>>>>>
>>>>>>        URI scheme name: sha1
>>>>>>
>>>>>>        Status: Permanent
>>>>>>
>>>>>>        Applications/protocols that use this URI scheme name:
>>>>>>          General applicability. Some examples include security
>>>>>>          applications and systems, database and forensic lookup
>>>>>>          tools, and distributed peer-to-peer protocols.
>>>>>>
>>>>>>        Contact: Sean Leonard <[hidden email]>
>>>>>>
>>>>>>        Change controller: IETF
>>>>>>
>>>>>>        References: This document.
>>>>>>
>>>>>> 4.2.  Assignment of sha256 URI Scheme
>>>>>>
>>>>>>        URI scheme name: sha256
>>>>>>
>>>>>>        Status: Permanent
>>>>>>
>>>>>>        Applications/protocols that use this URI scheme name:
>>>>>>          General applicability. Some examples include security
>>>>>>          applications and systems, database and forensic lookup
>>>>>>          tools, and distributed peer-to-peer protocols.
>>>>>>
>>>>>>        Contact: Sean Leonard <[hidden email]>
>>>>>>
>>>>>>        Change controller: IETF
>>>>>>
>>>>>>        References: This document.
>>>>>>
>>>>>> ***
>>>>>>
>>>>>>
>>>>>> Name:        draft-seantek-sha-uris
>>>>>> Revision:    01
>>>>>> Title:        URI Schemes for SHA-1 and SHA-256
>>>>>> Document date:    2015-09-09
>>>>>> Group:        Individual Submission
>>>>>> Pages:        8
>>>>>> URL:
>>>>>> https://www.ietf.org/internet-drafts/draft-seantek-sha-uris-01.txt
>>>>>> Status: https://datatracker.ietf.org/doc/draft-seantek-sha-uris/
>>>>>> Htmlized: https://tools.ietf.org/html/draft-seantek-sha-uris-01
>>>>>> Diff: https://www.ietf.org/rfcdiff?url2=draft-seantek-sha-uris-01
>>>>>>
>>>>>> Abstract:
>>>>>>    This document registers Uniform Resource Indicator schemes for use
>>>>>>    with certain Secure Hash Algorithm (SHA) functions, namely SHA-1
>>>>>> and
>>>>>>    SHA-256. The purpose is to identify data streams in a simple,
>>>>>> "drop-
>>>>>>    in" way within the URI infrastructure.


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

Re: Request Review of SHA-1 and SHA-256 URIs

Melvin Carvalho


On 20 September 2015 at 23:08, Alexey Melnikov <[hidden email]> wrote:
On 10/09/2015 18:30, [hidden email] wrote:
> Fwiw, I read Sean's draft and these mails and don't see any point in doing this again (again).

Stephen,

While Sean's proposal is somewhat similar to nih, use cases and
technical details are different. Most implementations I've seen are
using hex encoding for hashes, not base64. Sean's proposal has a
convenient property that it is possible to cut & paste text from other
tools to easily construct URIs, without the need to reencode anything.

I am not convinced that defining a new top level URI scheme for each
hash is a good idea (I think I prefer a single URN-type scheme with the
hash type being the first component), but otherwise I think this should
be published Experimental (and registered at least as provisional in the
URI registry).

I use base64 for nih (it's not to hard in most languages to switch back and forth, maybe 6-10 lines of code), mainly because it makes more manageable URIs, especially when you use the .well-known pattern to match an nih to http
 

Best Regards,
Alexey

> On Thu Sep 10 18:07:09 2015 GMT+0100, Sean Leonard wrote:
>> Hi Graham,
>>
>> Well, I would encourage you to read RFC 6920 to compare, if it matters.
>> Basically the applications are different. (And even if there is
>> application overlap, it shouldn't matter.)
>>
>> Neither NI nor SHAx nor any other URI scheme has a monopoly on hash
>> algorithms. So the fact that one uses hashes or is designed to use
>> hashes has no bearing on the other. Plenty of other URIs use hashes in
>> some way.
>>
>> The SHAx schemes are designed to be simple, intuitive, trivial, and
>> complete. Key features:
>>
>>   * hash algorithm is fixed
>>   * hash length is fixed (no truncation)
>>   * format is hex -- copy-and-pastable
>>   * no authority component--it's just a hash
>>   * no query parameters
>>   * can identify bit streams (not integral of 8 bits)
>>
>>
>> I suppose that I should add a section on what it means to dereference
>> SHAx URIs, although I note that RFC 7595 doesn't strictly require it. It
>> would be good, though (Section 3.4 of [RFC7595]). Since SHAx URIs only
>> identify data streams, dereferencing does not convey any Internet media
>> type information. This type of information needs to be inferred from the
>> content or the context.
>>
>> Sean
>>
>> On 9/10/2015 12:54 AM, Graham Klyne wrote:
>>> Sean,
>>>
>>> OK, I'm seeing this:
>>>
>>> [[
>>>    Other URI schemes such as ni: [RFC6920] include or incorporate
>>>    hashes. Software may be written to convert URIs between such schemes.
>>>    Although the bits of the resource may be equivalent, the URI
>>>    semantics may differ. The SHA-1 and SHA-256 URIs in this document
>>>    identify binary data streams (i.e., an ordered sequence of bits).
>>> ]]
>>>
>>> But that ("identify binary data streams") is exactly what (according
>>> to my understanding) the ni: scheme does.  So I'm still not seeing
>>> what new capability your proposal is adding.  The language in RFC6920
>>> may be different (e.g. "verifying the binding between the data and the
>>> name"), but I submit the effect is the same).  I'm not seeing here how
>>> the "URI semantics" of your proposal are not subsumed by ni:.
>>>
>>> (If I'm missing a more detailed coverage of this topic, please provide
>>> a section reference.)
>>>
>>> #g
>>> --
>>>
>>>
>>> On 10/09/2015 08:39, Sean Leonard wrote:
>>>> Yes, that is covered in the document. Sean
>>>>
>>>> On Sep 10, 2015, at 12:36 AM, Graham Klyne <[hidden email]> wrote:
>>>>
>>>>> Sean,
>>>>>
>>>>> re: https://tools.ietf.org/html/draft-seantek-sha-uris-01
>>>>>
>>>>> I've only read the intro to your document, but before going any
>>>>> further I want to check that you are aware of the ni: scheme [1],
>>>>> and would ask that you provide some explanation as to why we need
>>>>> yet another hash-based URI scheme.
>>>>>
>>>>> #g
>>>>> --
>>>>>
>>>>> [1] https://tools.ietf.org/html/rfc6920
>>>>>
>>>>>
>>>>> On 09/09/2015 23:24, Sean Leonard wrote:
>>>>>> Hello URI Review:
>>>>>>
>>>>>> I request review of SHA-1 and SHA-256 URIs, per RFC 7595. The URI
>>>>>> schemes are "sha1" and "sha256", respectively.
>>>>>>
>>>>>> Relevant notifications and templates are below.
>>>>>>
>>>>>> Thank you,
>>>>>>
>>>>>> Sean
>>>>>>
>>>>>> ***
>>>>>>
>>>>>> 4.1.  Assignment of sha1 URI Scheme
>>>>>>
>>>>>>        URI scheme name: sha1
>>>>>>
>>>>>>        Status: Permanent
>>>>>>
>>>>>>        Applications/protocols that use this URI scheme name:
>>>>>>          General applicability. Some examples include security
>>>>>>          applications and systems, database and forensic lookup
>>>>>>          tools, and distributed peer-to-peer protocols.
>>>>>>
>>>>>>        Contact: Sean Leonard <[hidden email]>
>>>>>>
>>>>>>        Change controller: IETF
>>>>>>
>>>>>>        References: This document.
>>>>>>
>>>>>> 4.2.  Assignment of sha256 URI Scheme
>>>>>>
>>>>>>        URI scheme name: sha256
>>>>>>
>>>>>>        Status: Permanent
>>>>>>
>>>>>>        Applications/protocols that use this URI scheme name:
>>>>>>          General applicability. Some examples include security
>>>>>>          applications and systems, database and forensic lookup
>>>>>>          tools, and distributed peer-to-peer protocols.
>>>>>>
>>>>>>        Contact: Sean Leonard <[hidden email]>
>>>>>>
>>>>>>        Change controller: IETF
>>>>>>
>>>>>>        References: This document.
>>>>>>
>>>>>> ***
>>>>>>
>>>>>>
>>>>>> Name:        draft-seantek-sha-uris
>>>>>> Revision:    01
>>>>>> Title:        URI Schemes for SHA-1 and SHA-256
>>>>>> Document date:    2015-09-09
>>>>>> Group:        Individual Submission
>>>>>> Pages:        8
>>>>>> URL:
>>>>>> https://www.ietf.org/internet-drafts/draft-seantek-sha-uris-01.txt
>>>>>> Status: https://datatracker.ietf.org/doc/draft-seantek-sha-uris/
>>>>>> Htmlized: https://tools.ietf.org/html/draft-seantek-sha-uris-01
>>>>>> Diff: https://www.ietf.org/rfcdiff?url2=draft-seantek-sha-uris-01
>>>>>>
>>>>>> Abstract:
>>>>>>    This document registers Uniform Resource Indicator schemes for use
>>>>>>    with certain Secure Hash Algorithm (SHA) functions, namely SHA-1
>>>>>> and
>>>>>>    SHA-256. The purpose is to identify data streams 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