Re: Standardizing Firefox's Implementation of Link Fingerprints

Philip Guenther <guenther+ietf@sendmail.com> Tue, 03 July 2007 03:22 UTC

Return-path: <discuss-bounces@apps.ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5Yyb-00026h-M2; Mon, 02 Jul 2007 23:22:53 -0400
Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1I5Yya-00024w-Di for discuss-confirm+ok@megatron.ietf.org; Mon, 02 Jul 2007 23:22:52 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5Yya-00024o-3o for discuss@apps.ietf.org; Mon, 02 Jul 2007 23:22:52 -0400
Received: from tls.sendmail.com ([209.246.26.40] helo=foon.sendmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5YyT-0005v0-G8 for discuss@apps.ietf.org; Mon, 02 Jul 2007 23:22:52 -0400
Received: from [10.201.0.49] (adsl-64-58-1-252.mho.net [64.58.1.252] (may be forged)) (authenticated bits=0) by foon.sendmail.com (Switch-3.2.5/Switch-3.2.0) with ESMTP id l633PLBM002082 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Jul 2007 20:25:27 -0700
X-DKIM: Sendmail DKIM Filter v1.0.0 foon.sendmail.com l633PLBM002082
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sendmail.com; s=tls.dkim; t=1183433129; bh=0vM3JkZvBp16FJ9wq34BnkRuUiYgaZvvGjvAAD VggGc=; h=X-DomainKeys:DomainKey-Signature:Date:From:X-X-Sender:To: cc:Subject:In-Reply-To:Message-ID:References:MIME-Version: Content-Type; b=OILVUPX5Hzrd237odJXmgQ+Rbzu4SK1qfT/JP8ejGwguDw91GF zLku4h/KUDyB+3tpOhB6BW60qz7R2AJ5e9VVl2Jr7ynwBN1DZIAdG8HQRsKdP7XUmVn V5hDkFZAoOuWviEGy6ONd6sPsmpIiFsgZqrDfxEIS8GGCK4b2IOx8o=
X-DomainKeys: Sendmail DomainKeys Filter v0.6.0 foon.sendmail.com l633PLBM002082
DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; h=date:from:x-x-sender:to:cc:subject:in-reply-to:message-id: references:mime-version:content-type; b=M2aPN/1tjmQ6rZm9RrubABByMCbJ7b+C9R7ZchJvTUITfl/hNT9KdVNwG7RnykSya Qtyzw5U2Wh5ofiFw4pyXANb9pFBFTr9Ae18J4AULF28ZBMNjm32B4btX5vXvU2X6BS/ 9+HPa82Y+eWuAWtWov6Y/mO+QM5xCOkc2fDfIYU=
Date: Mon, 2 Jul 2007 21:22:32 -0600
From: Philip Guenther <guenther+ietf@sendmail.com>
X-X-Sender: guenther@vanye.mho.net
To: Edward Lee <edilee@mozilla.com>
Subject: Re: Standardizing Firefox's Implementation of Link Fingerprints
In-Reply-To: <dc07ed930707021624h25cb377dm1feb52d4dc02c2a8@mail.gmail.com>
Message-ID: <Pine.BSO.4.64.0707022121410.31419@vanye.mho.net>
References: <dc07ed930707021624h25cb377dm1feb52d4dc02c2a8@mail.gmail.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a
Cc: discuss@apps.ietf.org
X-BeenThere: discuss@apps.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: general discussion of application-layer protocols <discuss.apps.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/discuss>, <mailto:discuss-request@apps.ietf.org?subject=unsubscribe>
List-Post: <mailto:discuss@apps.ietf.org>
List-Help: <mailto:discuss-request@apps.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/discuss>, <mailto:discuss-request@apps.ietf.org?subject=subscribe>
Errors-To: discuss-bounces@apps.ietf.org

On Mon, 2 Jul 2007, Edward Lee wrote:
> For Firefox 3, there are patches [1] that implement Link Fingerprints,
> which provide automatic resource verification for URIs that look like
> http://site.com/file#hash(sha256:abc123) so that link providers can be
> sure that end users download the exact file that the provider intended
> (and not a trojaned download).

This sounds a lot like the hash-scheme for making text fragment 
identifiers robust that's proposed in

    http://www.ietf.org/internet-drafts/draft-wilde-text-fragment-06.txt

The goals are not quite parallel as the above doesn't support hashing 
without also specifying a position, while your draft pictures a general 
syntax for schema and content-type independent signing.  The overlap does 
seem considerably though, if just because a content-type independent 
method would render the text/plain specific one obsolete.

Putting general object metadata in the fragment seems contorted though. 
For the hash-scheme stuff in draft-wilde-text-fragment there's at least a 
tenuous association with positioning information, but even then it's a 
stretch.

(Is there any normal textual representation for an http URL plus an etag 
or other identity verifier?  imap URLs put the mailbox UIDVALIDITY, which 
is an identity verifier for the mailbox as an object, in the path part.)


Philip Guenther
Sendmail, Inc.