Re: Web Keys and HTTP Signatures

Manu Sporny <> Thu, 18 April 2013 16:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EAB8021F8FF0 for <>; Thu, 18 Apr 2013 09:21:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gf1fW22z28ql for <>; Thu, 18 Apr 2013 09:21:18 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id F016521F8FD7 for <>; Thu, 18 Apr 2013 09:21:17 -0700 (PDT)
Received: from lists by with local (Exim 4.72) (envelope-from <>) id 1USrZD-0000bR-4p for; Thu, 18 Apr 2013 16:20:11 +0000
Resent-Date: Thu, 18 Apr 2013 16:20:11 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1USrZ9-0000aR-Cp; Thu, 18 Apr 2013 16:20:07 +0000
Received: from [] ( by with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <>) id 1USrZ7-0000eF-SD; Thu, 18 Apr 2013 16:20:07 +0000
Received: from ([] ident=msporny) by with esmtp (Exim 4.72) (envelope-from <>) id 1USrYm-0003sV-MJ; Thu, 18 Apr 2013 12:19:44 -0400
Message-ID: <>
Date: Thu, 18 Apr 2013 12:19:44 -0400
From: Manu Sporny <>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.5) Gecko/20120624 Icedove/10.0.5
MIME-Version: 1.0
To: Carsten Bormann <>
CC: Web Payments CG <>,
References: <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Received-SPF: none client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-2.8
X-W3C-Hub-Spam-Report: AWL=-4.075, RDNS_NONE=1.274
X-W3C-Scan-Sig: 1USrZ7-0000eF-SD 680235440bb512f5271d65f728de99f0
Subject: Re: Web Keys and HTTP Signatures
Archived-At: <>
X-Mailing-List: <> archive/latest/17338
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On 04/18/2013 01:54 AM, Carsten Bormann wrote:
> On Apr 18, 2013, at 02:22, "David I. Lehn" <> wrote:
>> if you find security issues
> Wrong question.
> A security spec is worthless if it doesn't establish useful security
>  properties.

Correct. I think Dave Lehn was making a general statement "If you find
more issues, please let us know.", he was not asking a question. I
believe that you are talking past what he was saying.

You also seem to be implying that you know of which security properties
are not being established by http-signatures. Could you please elaborate?

> The spec needs a good look from people with more security mojo.

We agree, which is why we published an implementation, pointed to the
spec, and cc'd the IETF HTTP WG. A very positive thing has come out of
that, which is that an issue was found with the spec and implementation.

> (Or maybe it can simply be replaced by one of the more learned 
> attempts under discussion, see 
> for 
> some links.)

Thanks for the link. We've looked at a number of those before, or
variants of the approaches. Here's feedback on each:

HTTP Origin-Bound Authentication (HOBA)

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.

HTTP Mutual Authentication

Overkill for our purposes and requires multiple bounces back and forth
between the client and the server. Key exchange isn't required since
that's taken care of by the Web Keys PKI framework. We don't intend the
Web Keys HTTP signature protocol to be session-based, as a session-based
value can be built on top of HTTP signatures pretty easily.

HTTP Multilegged Auth

Seems like overkill for our needs and is fairly specific to HTTP 2.0. We
wanted something that could work for HTTP 1.0. Multi-legged
authentication is something that we're not interested in solving using
HTTP Signatures. Putting state into the protocol is something we'd like
to avoid if possible.

HTTP Salted Challenge Response

Uses HMACs, doesn't use public key crypto, which is a requirement for
Web Keys and the Web Payments work.


This was the solution that seemed to be most interesting to the Web Keys
and Web Payments work. However, it requires quite a bit of state to be
remembered by the server (the Session URIs). Keeping the state of a
"session" around isn't desirable. We didn't want there to be a concept
of logging in and logging out of a website w/ the HTTP Signature stuff.
We'd rather that sessions are built on top of HTTP Signatures via a HTTP
header or cookie. Again, if we had to pick a back-up solution, HTTP REST
Auth seems like it might work for us, but we'd rather not use if we
don't have to.

Hopefully this explains why we haven't picked any of the solutions that
you outlined in your response. Web Keys + HTTP Signatures are simpler,
and we're now in the discovery phase to see if the protocol will stand
up to scrutiny by the security community.

-- manu

Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: Meritora - Web payments commercial launch