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

"Worley, Dale R (Dale)" <dworley@avaya.com> Tue, 12 June 2012 14:04 UTC

Return-Path: <dworley@avaya.com>
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 1120F21F85B8 for <ietf@ietfa.amsl.com>; Tue, 12 Jun 2012 07:04:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.099
X-Spam-Level:
X-Spam-Status: No, score=-104.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 X8XZ+Rzs08NI for <ietf@ietfa.amsl.com>; Tue, 12 Jun 2012 07:04:24 -0700 (PDT)
Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 0F41621F85AE for <ietf@ietf.org>; Tue, 12 Jun 2012 07:04:24 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgAFAJJL10/GmAcF/2dsb2JhbABFEwEBtSKBB4IfEihRAQgNKUInBBsah2kLl3qEIpx4kFhgA5YxhGOKBoJ8
X-IronPort-AV: E=Sophos;i="4.77,397,1336363200"; d="scan'208";a="352308869"
Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 12 Jun 2012 10:01:49 -0400
Received: from dc-us1hcex2.us1.avaya.com (HELO DC-US1HCEX2.global.avaya.com) ([135.11.52.21]) by co300216-co-erhwest-out.avaya.com with ESMTP; 12 Jun 2012 10:02:46 -0400
Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.202]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Tue, 12 Jun 2012 10:04:19 -0400
From: "Worley, Dale R (Dale)" <dworley@avaya.com>
To: "ietf@ietf.org" <ietf@ietf.org>
Date: Tue, 12 Jun 2012 10:04:18 -0400
Subject: Re: Last Call: <draft-farrell-decade-ni-07.txt> (Naming Things with Hashes) to Proposed Standard
Thread-Topic: Last Call: <draft-farrell-decade-ni-07.txt> (Naming Things with Hashes) to Proposed Standard
Thread-Index: AQHNSKGW//NxWPLhvkiovEghRhUVLQ==
Message-ID: <CD5674C3CD99574EBA7432465FC13C1B22726A0B76@DC-US1MBEX4.global.avaya.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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:04:25 -0000

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.

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

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.

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), [...]

Unfortunately, the example is somewhat incongruous, as "Hello World!"
is not obviously a name or reference to any object.  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.

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?

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.

Dale