Re: Last Call: <draft-farrell-decade-ni-07.txt> (Naming Things with Hashes) to Proposed Standard

Stephen Farrell <stephen.farrell@cs.tcd.ie> Tue, 12 June 2012 14:21 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76C7F21F865A for <ietf@ietfa.amsl.com>; Tue, 12 Jun 2012 07:21:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.501
X-Spam-Level:
X-Spam-Status: No, score=-102.501 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qBjmLdAeiIPZ for <ietf@ietfa.amsl.com>; Tue, 12 Jun 2012 07:21:07 -0700 (PDT)
Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 0259821F8658 for <ietf@ietf.org>; Tue, 12 Jun 2012 07:21:07 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 5C6C8171805; Tue, 12 Jun 2012 15:21:06 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1339510865; bh=hRu9zfv3b99hzs iLcyBiT4eOu+YjyoiVomFWjtYE8hs=; b=hPi7zgl5Wx7lWyZszt8bRItPjzs0pb m8hvpPzhvJ76t8xd+JEyZPDwIvdEdWD9g3aZ0Z3xmF0wgJmZckqYZqSfA/9MxVnW NX6vyQymhiqhBqNtpHjtw7ra1jPluzujHPzaKQQ59HOZcTdkDTe8nUlFPl5mO3r3 VpoDPSBD3YRtjo0CowonT3GTNsQ2jV05Y+VbJ6rqAfatgVSYVrY+ynqC5O+Q+SPT 9C0QLt4I4ivCpO3++eN0fSqd79hQEcZA6kyfaDA98Wzsdek4xvXrLOsTWqm8Oir3 N8RgN4cRRqvNakXqIsu/Sj/C2fi4g9x48gr4V9u9n33h3RcRffnpes/A==
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id nuAoFvgbG9Qr; Tue, 12 Jun 2012 15:21:05 +0100 (IST)
Received: from [IPv6:2001:770:10:203:f0bb:fb89:d865:2639] (unknown [IPv6:2001:770:10:203:f0bb:fb89:d865:2639]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id C6A6A171800; Tue, 12 Jun 2012 15:21:05 +0100 (IST)
Message-ID: <4FD75051.10702@cs.tcd.ie>
Date: Tue, 12 Jun 2012 15:21:05 +0100
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: "Worley, Dale R (Dale)" <dworley@avaya.com>
Subject: Re: Last Call: <draft-farrell-decade-ni-07.txt> (Naming Things with Hashes) to Proposed Standard
References: <CD5674C3CD99574EBA7432465FC13C1B22726A0B76@DC-US1MBEX4.global.avaya.com>
In-Reply-To: <CD5674C3CD99574EBA7432465FC13C1B22726A0B76@DC-US1MBEX4.global.avaya.com>
X-Enigmail-Version: 1.4.2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: "ietf@ietf.org" <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Jun 2012 14:21:08 -0000

Hi Dale,

On 06/12/2012 03:04 PM, Worley, Dale R (Dale) wrote:
> Having never heard of this proposal before, I found the concept
> interesting, but the exposition in the draft was difficult to grasp in
> certain places.  I believe that it is because the text assumes that
> the reader already knows the underlying theory of what the process is
> intended to accomplish.

I'm not sure there's a theory:-)

> For example, in section 3, the syntax of the "ni" URI scheme is
> spelled out with admirable clarity and exactness, including:
> 
>    Digest Value [Required]  The digest value MUST be encoded using the
>       base64url [RFC4648] encoding.
> 
> Hmmm, "the digest value"...  The digest value *of what*?

The input to the digest is not defined by this draft, except
in the case of public keys. (See other comments wrt MIME &
Content Type as well.)

  "Other than in the above special case where public keys are used, we
   do not specify the hash function input here.  Other specifications
   are expected to define this."

> Considering the previous section 2, it seems that there is some
> implicit string, which when hashed by the algorithm specified in the
> "Digest Algorithm" part, produces the "Digest Value".  And given the
> discussion, it seems that this string is an *input* to the process of
> generating an ni URI, and that the ni URI is really a way of encoding
> this string.  The string itself is specified by some external reality,
> and seems to be expected to represent or specify some object in some
> way, and thus the ni URI is a "name" for that object.
> 
> So far, so good, although it would have been better if this was
> spelled out explicitly.
> 
> Going back to section 2 for a moment, there is:
> 
>    When the input to the hash algorithm is a public key value, as may be
>    used by various security protocols, the hash SHOULD be calculated
>    over the public key in an X.509 SubjectPublicKeyInfo structure
>    (Section 4.1 of [RFC5280]).
> 
> I can see what this means, but it's not very clear.  A better way to
> write it would be:
> 
>     When the input is intended to be a public key value, as may be
>     used by various security protocols, the input to the hash SHOULD
>     be an X.509 SubjectPublicKeyInfo structure (Section 4.1 of
>     [RFC5280]) containing the public key rather than the public key
>     value itself.

Have to say I prefer the existing text.

> 
> In section 8 is:
> 
>    The following ni URI references the text "Hello World!" (without the
>    quotes, being 12 characters), [...]
> 
> But the term "references" seems not to have been used in this sense
> before in the draft.  More clear would be:
> 
>    The following ni URI is generated from the string "Hello World!"
>    (without the quotes, being 12 characters), [...]

Ack. Thanks.

> 
> Unfortunately, the example is somewhat incongruous, as "Hello World!"
> is not obviously a name or reference to any object.  

In this case the object named is just those 12 characters.

> Thus while it
> still is clear how it can be input to the processes that are described
> in the draft, it doesn't seem to be a conceptually typical example.

Well, I could have said a file that contains "Hello World!" (12 chars:-)

But I don't think its much clearer, maybe less.

> Then we get to:
> 
>    Given the SubjectPublicKeyInfo in Figure 6 we derive the names shown
>    in Figure 7 for this value.
> 
> I can't tell what this means. What is "this value"?  Is it the
> immediately preceding URI
> (http://example.com/.well-known/ni/sha-256/f4OxZX_x_FO5LcGBSKHWXfwtSx-j1ncoSt3SABJtkGk)?
> In what manner does the "given" SubjectPublicKeyInfo affect the names?

No, the input value is the DER encoding of the SPKI as stated earlier.
I guess the following is a little more correct so I've changed it to:

   Given the DER-encoded SubjectPublicKeyInfo in Figure 6 we derive
   the names shown in Figure 7 for this value.

> If the input value was meant to be the SubjectPublicKeyInfo itself,
> the sentence would not add "this value", which strongly suggests a
> *different* value than the one mentioned just before in the same
> sentence.  Rather, one would say:
> 
>    We derive the names shown in Figure 7 from the SubjectPublicKeyInfo
>    in Figure 6.

I don't get the difference to be honest.

Cheers,
S.

> 
> Dale
> 
>