Re: [jose] JOSE and signed REST requests

Carsten Bormann <cabo@tzi.org> Tue, 02 August 2016 06:12 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: jose@ietfa.amsl.com
Delivered-To: jose@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B00512D0BF; Mon, 1 Aug 2016 23:12:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nkna6ZTdjzEk; Mon, 1 Aug 2016 23:12:16 -0700 (PDT)
Received: from relay2-d.mail.gandi.net (relay2-d.mail.gandi.net [IPv6:2001:4b98:c:538::194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3A3712B068; Mon, 1 Aug 2016 23:12:12 -0700 (PDT)
Received: from mfilter21-d.gandi.net (mfilter21-d.gandi.net [217.70.178.149]) by relay2-d.mail.gandi.net (Postfix) with ESMTP id 377E6C5A5A; Tue, 2 Aug 2016 08:12:11 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at mfilter21-d.gandi.net
Received: from relay2-d.mail.gandi.net ([IPv6:::ffff:217.70.183.194]) by mfilter21-d.gandi.net (mfilter21-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id ejHJWIOANh_K; Tue, 2 Aug 2016 08:12:09 +0200 (CEST)
X-Originating-IP: 93.199.227.76
Received: from nar-3.local (p5DC7E34C.dip0.t-ipconnect.de [93.199.227.76]) (Authenticated sender: cabo@cabo.im) by relay2-d.mail.gandi.net (Postfix) with ESMTPSA id 28825C5A5D; Tue, 2 Aug 2016 08:12:05 +0200 (CEST)
Message-ID: <57A039B3.9010406@tzi.org>
Date: Tue, 02 Aug 2016 08:12:03 +0200
From: Carsten Bormann <cabo@tzi.org>
User-Agent: Postbox 4.0.8 (Macintosh/20151105)
MIME-Version: 1.0
To: Anders Rundgren <anders.rundgren.net@gmail.com>
References: <216bb90e-15d5-efd6-e014-024f06af24f2@gmail.com>
In-Reply-To: <216bb90e-15d5-efd6-e014-024f06af24f2@gmail.com>
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/jose/USel_dUQF4qZQR9PuOhHZK7sW6w>
Cc: draft-selander-ace-object-security@ietf.org, "jose@ietf.org" <jose@ietf.org>
Subject: Re: [jose] JOSE and signed REST requests
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Javascript Object Signing and Encryption <jose.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jose>, <mailto:jose-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/jose/>
List-Post: <mailto:jose@ietf.org>
List-Help: <mailto:jose-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jose>, <mailto:jose-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Aug 2016 06:12:18 -0000

> [...] 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:
> https://tools.ietf.org/html/draft-cavage-http-signatures-05

I'm don't think that this will help you with your payment project, but,
you said REST and didn't specifically ask for HTTP, so here is another
standards effort you might want to be aware of:

draft-selander-ace-object-security–05

In the Berlin CoRE WG meeting, there was in-room consensus to adopt this
as a WG document (to be confirmed on the mailing list), so this should
not be too far out.  [Sorry about the WG name confusion -- ACE is
focusing on how to do OAuth in constrained-node networks, but the
protected CoAP exchanges themselves actually are a CoRE WG issue, where
we use COSE formats for the actual protection.]

> I would rather have dropped REST in favor of transport-independent
> schemes using self-contained JSON-encoded signed message objects.

[Pet peeve: HTTP is not a transport protocol.]
This removes the REST abstraction that is quite useful to the
application designer.  Having the application designer create the
security protocol around signed message objects also has increased
potential for mistakes around freshness, context binding etc.  You get
to verify your whole application-layer message interaction against the
security objectives; you need a larger amount of luck with that than
with protected REST primitives.

Grüße, Carsten