Re: [apps-discuss] [http-auth] Web Keys and HTTP Signatures

Stephen Farrell <stephen.farrell@cs.tcd.ie> Fri, 19 April 2013 10:58 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FF4B21F9305; Fri, 19 Apr 2013 03:58:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 d6jXXMTEmCnh; Fri, 19 Apr 2013 03:58:29 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 93D3D21F8F28; Fri, 19 Apr 2013 03:58:28 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 16AABBE70; Fri, 19 Apr 2013 11:58:05 +0100 (IST)
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d6fUiIlILzr9; Fri, 19 Apr 2013 11:58:05 +0100 (IST)
Received: from [IPv6:2001:770:10:203:b90d:e185:2958:9b0] (unknown [IPv6:2001:770:10:203:b90d:e185:2958:9b0]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id DAE5CBE6E; Fri, 19 Apr 2013 11:58:04 +0100 (IST)
Message-ID: <5171233D.303@cs.tcd.ie>
Date: Fri, 19 Apr 2013 11:58:05 +0100
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5
MIME-Version: 1.0
To: Manu Sporny <msporny@digitalbazaar.com>
References: <5170652F.60609@digitalbazaar.com>
In-Reply-To: <5170652F.60609@digitalbazaar.com>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: IETF HTTP Auth <http-auth@ietf.org>, Web Payments CG <public-webpayments@w3.org>, IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] [http-auth] Web Keys and HTTP Signatures
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Apr 2013 10:58:30 -0000

Hi Manu,

Just on the HOBA bit...

On 04/18/2013 10:27 PM, Manu Sporny wrote:
> 
> HTTP Origin-Bound Authentication (HOBA)
> http://tools.ietf.org/id/draft-farrell-httpbis-hoba-02.txt
> 
> We had considered signatures in the URL in the second approach to the
> problem in the Web Keys spec. We eventually rejected the solution
> because of limitations in the URL length in some browsers and because we
> wanted the semantics of the HTTP headers to be able to be a part of the
> digital signature. We also didn't want large signed messages being
> dumped to the webserver logs (the request line is typically included).
> So, while HOBA does solve the problem, it doesn't solve it in a way that
> is acceptable to us.

I think you're misreading the spec a little, or we've written
it badly:-)

The HTTP scheme in HOBA is an HTTP authentication scheme so I
don't know what you mean when you say putting the signatures
in the URLs, since we don't do that. I think its that part
(section 4 of the HOBA draft) where there's most in common
between these, but also section 6.

The non-normative JS stuff does say to put the signature in
the URL though yes, but is quite a work-in-progress. That
section is really there to demonstrate that a site could do
the moral equivalent of HOBA without waiting for all UAs
to implement the spec. so e.g., if forms made for a better
example that'd be ok too I think (not sure if my co-authors
agree though). But your points about message size and logs
are reasonable.

HOBA is just about public key methods, not HMAC which is
a real difference.

All in all your stuff and this looks quite similar to me, so
I'd say we should talk all right.

Cheers,
S.