Re: [jose] encrypting AND signing a token

Dick Hardt <dick.hardt@gmail.com> Fri, 02 November 2012 16:30 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 6A33E11E809C for <jose@ietfa.amsl.com>; Fri, 2 Nov 2012 09:30:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.599
X-Spam-Level:
X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, 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 eFnJ+AIJiY7M for <jose@ietfa.amsl.com>; Fri, 2 Nov 2012 09:30:02 -0700 (PDT)
Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id CF9D811E809A for <jose@ietf.org>; Fri, 2 Nov 2012 09:30:02 -0700 (PDT)
Received: by mail-pa0-f44.google.com with SMTP id fb11so2582585pad.31 for <jose@ietf.org>; Fri, 02 Nov 2012 09:30:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=G8nJWtfbzg4/PhUea6OimvEbQEFsBJuYstqYVgvJQ5g=; b=KroVWxKuEq1zMPCR+meOMN2fcJYoQ/0r7kL/D+Lee3lWkKqsdDLFAdU2T1BbLetEAL 3VD2S16q+Jn3+kbXtJnU/Imqe0465RjDHBlFvmVFP4AK3zei61yMhYhmLz/lDB0nkdhq 5121V5es6IBsSI4pKm4ph4FnSOD1rE9vvcIfHp75LYWPOFRamklETmWnydkkx5bunvZp Ck/1uldqOdZdrfvUeEItyuRrbRXctTt3jzYmDMYU+J2jOJk10tw4trQIPWC1ezrvi7oq 0tR2oEwRW970mrtQgUop982jucDNRWOAGb28v2o3yVmUCy0DFlvMkdPmODw+egLOeXKB qqPQ==
Received: by 10.66.78.4 with SMTP id x4mr6659004paw.60.1351873802450; Fri, 02 Nov 2012 09:30:02 -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 hs1sm5984064pbc.33.2012.11.02.09.29.54 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 02 Nov 2012 09:29:55 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Dick Hardt <dick.hardt@gmail.com>
In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366887325@TK5EX14MBXC285.redmond.corp.microsoft.com>
Date: Fri, 02 Nov 2012 09:29:53 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <E73A223A-6546-4A3A-A839-8627B3DBCB8F@gmail.com>
References: <4ACFC778-31A9-4C79-9F4E-7C01719F51AD@gmail.com> <4E1F6AAD24975D4BA5B168042967394366887325@TK5EX14MBXC285.redmond.corp.microsoft.com>
To: Mike Jones <Michael.Jones@microsoft.com>
X-Mailer: Apple Mail (2.1499)
Cc: jose@ietf.org
Subject: Re: [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 16:30:03 -0000

Not only is my original token increasing in size by 4/3, I am also adding another header, payload and signature.

One of the objectives of JWT was to enabled compact tokens. It would seem that we should be able to support both signing and encryption of the same token.

All the encryption use cases I can think of involving asymmetric keys would also require signing with the senders private key. 

My suggestion is to be explicit in what the algorithm etc. is used for:

Rather than "alg" and "enc", we have:

"algs" - algorithm for token signing
"algk" - algorithm for content management key encryption
"alge" - algorithm for payload encryption

Similiarly,

"kids" - key id for signing
"kidk" - key id for content managment key encryption

We could probably make these three or even two letter codes if you want to save a couple bytes.

-- Dick

On Nov 2, 2012, at 8:46 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:

> The way you put it brings one straightforward solution to mind.  Solve 1-3 with a JWE.  Solve 4-5 by signing the JWE as a JWS payload.  Done.
> 
> I do understand that the 4/3 space blowup-of double base64url encoding the JWE motivates your earlier proposal about nested signing.  (See Dick's 10/29/12 message "[jose] signing an existing JWT".)  I also understand that if you could do integrity with the asymmetric signature then the integrity provided by the JWE itself may be redundant.  I don't have a specific proposal on how to do that.
> 
> 				-- Mike
> 
> -----Original Message-----
> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Dick Hardt
> Sent: Friday, November 02, 2012 8:22 AM
> To: jose@ietf.org
> Subject: [jose] encrypting AND signing a token
> 
> 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
> 
> 
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose