Re: [jose] JOSE and signed REST requests

Justin Richer <> Tue, 02 August 2016 11:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8BD3C12D0EB for <>; Tue, 2 Aug 2016 04:18:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.487
X-Spam-Status: No, score=-5.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YIJf74Z_-Vgq for <>; Tue, 2 Aug 2016 04:18:03 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6AAEE12B013 for <>; Tue, 2 Aug 2016 04:18:03 -0700 (PDT)
X-AuditID: 12074425-bffff700000062f2-52-57a08169ec62
Received: from ( []) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id BC.B4.25330.96180A75; Tue, 2 Aug 2016 07:18:02 -0400 (EDT)
Received: from ( []) by (8.13.8/8.9.2) with ESMTP id u72BI0Fo000656; Tue, 2 Aug 2016 07:18:01 -0400
Received: from [] ( []) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by (8.13.8/8.12.4) with ESMTP id u72BHxHL008566 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 2 Aug 2016 07:18:00 -0400
To: Martin Thomson <>
References: <> <> <>
From: Justin Richer <>
Message-ID: <>
Date: Tue, 2 Aug 2016 07:17:54 -0400
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLIsWRmVeSWpSXmKPExsUixCmqrZvVuCDc4N1xAYs1a7qZLK6d+cfo wOSxc9Zddo8lS34yBTBFcdmkpOZklqUW6dslcGU8uXiUtWCCUkXfiiNMDYzXpbsYOTkkBEwk vp57x9rFyMUhJNDGJDH5+H9GCGcDo8Spa1OYIZzbTBLf226xgrQICxhKXFy3EswWEdCVWHT2 ATtE0RZGic97joElmAUkJHZ0P2UHsdkEVCWmr2lhArF5Bawklh28BmazCKhIzGldDbSOg0NU IEZifV8CRImgxMmZT1hAbE6BQIkFDy4zQ4w0k5i3+SGULS+x/e0c5gmMArOQtMxCUjYLSdkC RuZVjLIpuVW6uYmZOcWpybrFyYl5ealFuhZ6uZkleqkppZsYQaHK7qK6g3HOX69DjAIcjEo8 vAG588OFWBPLiitzDzFKcjApifK6fAEK8SXlp1RmJBZnxBeV5qQWH2KU4GBWEuENbVgQLsSb klhZlVqUD5OS5mBREufd/q09XEggPbEkNTs1tSC1CCYrw8GhJMFrAtIoWJSanlqRlplTgpBm 4uAEGc4DNFwEbHhxQWJucWY6RP4Uo6KUOO/deqCEAEgiozQPrheUShLeHjZ9xSgO9IowbypI Ow8wDcF1vwIazAQ0+IQB2OCSRISUVAPj6o/vfvSya5msv+U9dXL3BRPpPediS/7ZKTU1qDJX mG3gF9yhKryvarer0b0JB+dMKVp94812kVjdiMlCj2ZPuXipYOYvXdd4/QLeJRyHj80WLoj5 5LM3a+cXj73Jctn39R6EdylXbri0X+uExGrblqMss2uv3HNzniHJYbS88XD3l3sXhZ1klViK MxINtZiLihMBmL3n8QADAAA=
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:18:05 -0000

Those limitations are exactly what drove the work in this direction. I 
completely agree that it's always going to be a trade off, and we went 
in the direction of not having a universal solution but instead having a 
limited solution that would work for many (but not all) use cases. I've 
yet to see a universal solution that doesn't break under simple 

The fact that you can have unsigned elements that could be critical to 
your application is one such limitation. In those cases, you need to 
make sure that not only do the signature and hash validate, but also 
that the elements you care about were protected by it. That doesn't mean 
you can't pass on other parameters to other layers, but it does mean 
that you can't guarantee they were left alone in transit. This is an 
important note in the security considerations section, along with 
parameter ordering.

Side note about the percent encoding, is the spec not clear enough about 
that as input for the hash calculation? Happy to take suggested text.

  -- Justin

On 8/2/2016 7:10 AM, Martin Thomson wrote:
> 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
> three.
> 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