Re: [jose] JOSE and signed REST requests

Martin Thomson <> Tue, 02 August 2016 11:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9B06712B049 for <>; Tue, 2 Aug 2016 04:10:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Vx0TWs-JWwyG for <>; Tue, 2 Aug 2016 04:10:29 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E2F3412B076 for <>; Tue, 2 Aug 2016 04:10:28 -0700 (PDT)
Received: by with SMTP id f65so404436227wmi.0 for <>; Tue, 02 Aug 2016 04:10:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Kq8pnnL7PNFkj/lL1G+O2xjKxGAucoAKxjjWwiUeLKw=; b=NYBh8rQkySDRqKNe9Ni5jKYMuIwEtRC2YIDhIq1Y8lBbMFrepVMS2qvbiRLXLYOEdi maoF8g1wlT8pzyliulJhfcpudyJHEurzgKVx7TrWndhBDSO+m06UHSTl2eCoCQJJJwcT nYCvegNfr6UcZhkZKynNvRqOWsorF2JeC0wLC2elvnLMbyoz7jE5GeMMwE8z60YG/9UY JeIFI/mfXR6bBAE39G+z5jq2DT21LwsGVH1tIzQ8g0WsYh/5O0NWjxG6aCcIBva79giL sO6yOYt8qcu3AfZOiwQhZh5lZwTZzVEkdHAO0hi4rpZzaZmpMp4KgsWoOxOxyKraJ8HN G/QA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Kq8pnnL7PNFkj/lL1G+O2xjKxGAucoAKxjjWwiUeLKw=; b=bYDpFLE0gqlmCFDRGPUfIeiJpbNvSd5v7UzJ1m0UzL/wlTqc3ttsQayPC62QaPue16 DaWhuOCiVIWOt7JywufhKmQgQfkdl8wP7EhRFB+XMpvHbUQnSHiqXgxnZmTseHo3UZ4K KXvQAwX5tzNf6OCz/d56tiHhwbDFfWKo6AV80mBSjc+QE6tOOI7UHrjI7GRl9I2qaG/N /DLKQPHBOj56x5rWVjlahXah+cyWRc+psjgbvFp7YV250hFqz4YzUueKKeKvRCXJJfJT sFGjOwnd1fY6UuPta4ukbMD6N0XUEW0IK78FAmbm/9eWv7sHrAdLrDr8YcMQicmxKBqW vwKg==
X-Gm-Message-State: AEkoous+bl283o3QjNFjnNqhBOajoVd9ynXkqQDTDHcZEuN7iGj+dJ8y24faCtGXqd9/aIV9Ucv2jxiOq7a8Qw==
X-Received: by with SMTP id b202mr64920054wmb.12.1470136227246; Tue, 02 Aug 2016 04:10:27 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 2 Aug 2016 04:10:26 -0700 (PDT)
In-Reply-To: <>
References: <> <>
From: Martin Thomson <>
Date: Tue, 2 Aug 2016 21:10:26 +1000
Message-ID: <>
To: Justin Richer <>
Content-Type: text/plain; charset=UTF-8
Archived-At: <>
Cc: jose <>
Subject: Re: [jose] JOSE and signed REST requests
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Javascript Object Signing and Encryption <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 02 Aug 2016 11:10:32 -0000

Clearly this is a windmill that many like to tilt at.  After seeing
the long procession of failed attempts, my conclusion was that signing
HTTP messages in a generic fashion was an enterprise doomed to fail.

The main problem is that it's really hard to work out what to protect.
Header fields are especially difficult to protect because they lack a
stable encoding and they change in transit.  The first means that even
the most careful spec ends up with spurious signature failures; the
second means that things that should be protected, can't be.  In the
end, you get something with byzantine complexity, an overly
restrictive applicability, security failures, or combinations of all

Taking the OAuth work and the "q" parameter:
 - the method for creating a canonical encoding of the query string is
quite complex,
 - but it's not complex enough yet because it doesn't handle percent-encoding;
 - also, if the "q" parameter is omitted, but the query string happens
to be security critical you get failures.

Clearly the more limited focus helps here, but the point is that you
have to accept those limitations, which is a whole new set of problems
for an implementation.  Say you successfully validate a request, that
means that you cannot pass anything that was unvalidated to the next
processing stage or you create a side-channel.  And are you sure that
there isn't some significance to the information you erased during the
validation process that might then be used by the next stage?

On 2 August 2016 at 20:43, Justin Richer <> wrote:
> There's also this approach:
> It's more limited than a general HTTP signing mechanism, but as a
> consequence it's more robust for systems that mess with the HTTP message in
> transit (which we know happens in the real world).
>  -- Justin
> On 8/2/2016 1:32 AM, Anders Rundgren wrote:
>> Hi All,
>> I was recently involved in an inter-bank payment project based on a REST
>> API.
>> Since my role was "cryptography" I recommended the following approach
>> since an operation is defined not only by the message payload, but also by
>> the HTTP verb, URI, and header parameters.
>> The only related standards effort I'm aware of is this:
>> Unfortunately the methods above get rather awkward if you have a system
>> where requests are supposed to be embedded in other messages or just proxied
>> to another server.
>> I would rather have dropped REST in favor of transport-independent schemes
>> using self-contained JSON-encoded signed message objects.
>> WDYT?
>> Anders
>> _______________________________________________
>> jose mailing list
> _______________________________________________
> jose mailing list