Subject: [Uri-review] Request Review of SHA-1 and SHA-256 URIs

From: Sean Leonard <[email-masked]>
Date: Wed, 9 Sep 2015 15:24:51 -0700

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 <[email-masked]>

      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 <[email-masked]>

      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.

---

From: Graham Klyne <[email-masked]>
Date: Thu, 10 Sep 2015 08:36:07 +0100

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

---

From: Sean Leonard <[email-masked]>
Date: Thu, 10 Sep 2015 00:39:48 -0700

Yes, that is covered in the document. Sean

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

> 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
> --
>

---

From: Graham Klyne <[email-masked]>
Date: Thu, 10 Sep 2015 08:54:41 +0100

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
--

---

From: Sean Leonard <[email-masked]>
Date: Thu, 10 Sep 2015 10:07:09 -0700

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:
> 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
> -- 
>
>
>>> 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
>>> -- 
>>>
>>>> I request review of SHA-1 and SHA-256 URIs, per RFC 7595. The URI 
>>>> schemes are "sha1" and "sha256", respectively.
>>>>
>>>> URL: 
>>>> https://www.ietf.org/internet-drafts/draft-seantek-sha-uris-01.txt

---

From: [email-masked]
Date: Thu, 10 Sep 2015 17:30:36 +0000

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

S.

---

From: Chris Rebert <[email-masked]>
Date: Fri, 11 Sep 2015 02:22:40 -0700

> Relevant notifications and templates are below.
<snip>
> 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

---

From: Julian Reschke <[email-masked]>
Date: Fri, 11 Sep 2015 12:39:08 +0200

On 2015-09-10 19:07, Sean Leonard wrote:
> ...

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.

---

From: Sean Leonard <[email-masked]>
Date: Sat, 12 Sep 2015 20:26:46 -0700

> 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

---

From: Chris Rebert <[email-masked]>
Date: Sun, 13 Sep 2015 01:36:50 -0700

> 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

---

From: Sean Leonard <[email-masked]>
Date: Sun, 13 Sep 2015 08:20:39 -0700

> On Sat, Sep 12, 2015, at 08:26 PM, Sean Leonard wrote:
[SNIP]
> 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

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 20 Sep 2015 22:08:41 +0100

> 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

---

From: Melvin Carvalho <[email-masked]>
Date: Sun, 20 Sep 2015 23:18:40 +0200

> be published Experimental (and registered at least as provisional in the

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