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

Jonathan A Rees <> Tue, 12 June 2012 15:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5517C21F86A4 for <>; Tue, 12 Jun 2012 08:23:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KgkBN1QsKRG5 for <>; Tue, 12 Jun 2012 08:23:20 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id D66C821F8513 for <>; Tue, 12 Jun 2012 08:23:19 -0700 (PDT)
Received: by dacx6 with SMTP id x6so7016439dac.31 for <>; Tue, 12 Jun 2012 08:23:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=OdvBhWF178b7JqQpA255DMlpRMUHC2XwzN9q6gPFMH8=; b=Jqns7GjNJQN9OTskyvGTswea+HQos6TvDrOJXKkaM9B4JvoCQtWd69TMD2hQcEAUAN op6AcyWKq/I+JNYYgNEQdAPVaElKrcKL+/J1VjnF8tySKz/4f/C4tYuIOQAHYsgWchAq j16USBhNgfDJP4NJ28KGvGGiGuexLPOlKs5v8u1TM9gyVqSCSCf3fs3zN/k+LmnzTnbz bGPFSrW1FcdImSAcF+uw+snoV3XU40QKkAsYBnc4BPUUCXi0MZFEygXcklP36pGnz5mV jHXg/aiGSzaPnj9Q7wwp1T2/q43YhrF9kNl3V/82OB/ww44zVbXekWbxMIWc59IF2j4v VVyA==
MIME-Version: 1.0
Received: by with SMTP id sm2mr39304733pbc.57.1339514599382; Tue, 12 Jun 2012 08:23:19 -0700 (PDT)
Received: by with HTTP; Tue, 12 Jun 2012 08:23:19 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <>
Date: Tue, 12 Jun 2012 11:23:19 -0400
X-Google-Sender-Auth: FJy4gIrq2K79r-H0fJzV3PwqEXI
Message-ID: <>
Subject: Re: [decade] FW: Last Call: <draft-farrell-decade-ni-07.txt> (Naming Things with Hashes) to Proposed Standard
From: Jonathan A Rees <>
To: Stephen Farrell <>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Wed, 13 Jun 2012 09:30:54 -0700
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 12 Jun 2012 15:23:21 -0000

On Fri, Jun 8, 2012 at 9:45 PM, Stephen Farrell
<> wrote:
> Hi Sam,
> On 06/09/2012 01:43 AM, Sam Hartman wrote:
>> Add me as a +1 for the idea that content-type is important for this.
>> I tend to agree with the arguments given so far. Namely, for some
>> important use cases you're going to want to know the content type and
>> guessing is  really a bad idea.
> Thusly counted:-)
>> That said, there are security considerations associated with specifying
>> a content type too.  I'm particularly imagining a situation where some
>> sort of deep inspection security appliance uses a different procedure
>> for deciding what kind of foo it is than the ultimate application. One
>> guesses based on byte stream another looks at a content type.  This is
>> well known; it's not new; it's probably even so documented that any
>> reasonably current set of MIME security considerations already includes
>> a reference.
> My only real concern with adding this is the issue of complexity
> related to c14n of input to the hash function. While CMS does (I
> think) define that well, imposing that burden on anyone that might
> want to write code that validates name-data integrity is an issue.
> Anyway, if we want to add it we'll look that over and figure how
> it might best be done.

OK, I agree that's an issue. My feeling is that it's not much of a
burden, and to the extent it is a burden it's important to take on.
I'm not sure but wouldn't the burden just be: If (1) the client is
sensitive to media type, and (2) it gets a media type from the server,
and (3) ct= is provided, and (4) they don't match, you either ignore
the type from the server, or treat it as spoofing.  Otherwise - you
just do what you would have done, had ct= not been mentioned in the
spec. Clients or protocols for which either (1) or (2) doesn't apply
are unaffected; if (1-2-3) apply then the situation is important.

(Come to think of it the  same consideration applies to data: ... of
course it's not common to use a data: URI as the request URI in an
HTTP request.)