[jose] encrypting AND signing a token

Dick Hardt <dick.hardt@gmail.com> Fri, 02 November 2012 15:21 UTC

Return-Path: <dick.hardt@gmail.com>
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 A131911E80A3 for <jose@ietfa.amsl.com>; Fri, 2 Nov 2012 08:21:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VGB7dd13F2G0 for <jose@ietfa.amsl.com>; Fri, 2 Nov 2012 08:21:47 -0700 (PDT)
Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2D5C411E8099 for <jose@ietf.org>; Fri, 2 Nov 2012 08:21:47 -0700 (PDT)
Received: by mail-pb0-f44.google.com with SMTP id ro8so2540996pbb.31 for <jose@ietf.org>; Fri, 02 Nov 2012 08:21:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version:x-mailer; bh=qK3UzxnlucdV5Iph4kSrc0adO1Tz9+Nslwn8lAsPSVg=; b=zyNCh/dAlNXawqtjUNu1tjtp0O7+97JL6CJ0utN5So03IDin0c3jtt2wHJx+X48nQd RAdyMokcg8vasGOS9bVcl+v1bcNvvRXVklYnAYVxO7nMTI2i3L6rMriDrs9vNgPUZzll HACgs1OZwHbQCnuBC7NLNYS1iq7LXeMfswhLk+9wJxWI+8Hc92n8z3uSghKpoqqKHpx6 uo7aj5Ci6RzRRsq0IW3IzBsf1Iuos0HBdx27uTQJSWmzv55jyWeXskJZK55ATmj7Dlsm EDDAvYe3oPX5NonW/ucFU69g1x4QVMIrfDu8HUqs116ZlDs6IbJYgLVsACUYv4Gcudeu LWXA==
Received: by 10.68.219.163 with SMTP id pp3mr7181403pbc.13.1351869706997; Fri, 02 Nov 2012 08:21:46 -0700 (PDT)
Received: from [10.0.0.4] (c-24-5-69-173.hsd1.ca.comcast.net. [24.5.69.173]) by mx.google.com with ESMTPS id e9sm5871460paz.28.2012.11.02.08.21.45 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 02 Nov 2012 08:21:46 -0700 (PDT)
From: Dick Hardt <dick.hardt@gmail.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Message-Id: <4ACFC778-31A9-4C79-9F4E-7C01719F51AD@gmail.com>
Date: Fri, 02 Nov 2012 08:21:44 -0700
To: "jose@ietf.org" <jose@ietf.org>
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
X-Mailer: Apple Mail (2.1499)
Subject: [jose] encrypting AND signing a token
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Fri, 02 Nov 2012 15:21:47 -0000

I am trying to figure out how to implement JWT/JWS/JWE to solve a real world problem.

1) Bob sends a token to Charlie via Alice. (Alice gets token from Bob and then Alice gives token to Charlie) 
2) Alice must be prevented from reading the token. (token needs to be encrypted)
3) Bob and Charlie can share a symmetric key.

I can solve this with JWE.

Now let's add another condition.

4) Charlie wants non-repuditation that Bob created the token. 
5) Bob has a private key and a public key

I don't see how to do this using JWE. It seems I have to sign the same token I had previously with JWS. This seems inefficient since I should be able to replace the JWE integrity computation done with the symmetric key with the private key -- but the "alg" parameter is the same in both encrypting and signing. 

Now let's expand this to replacing the symmetric key with a public/private key pair for encryption. Bob encrypts with Charlies public key and signs with Bob's private key (we also need to make sure we are not doing naive encryption and signing here, would be a really useful to specify what needs to be done there). Now we need to have parameters for both public/private key pairs in the header.

Am I missing something here?

Seems like we can do this if we change the header parameters to specify if they ("alg", "kid", et.c) are for token signing, payload encryption or content key encryption.

-- Dick