Re: [jose] encrypting AND signing a token
"Jim Schaad" <ietf@augustcellars.com> Sun, 04 November 2012 20:51 UTC
Return-Path: <ietf@augustcellars.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 88E1E21F88A1 for <jose@ietfa.amsl.com>; Sun, 4 Nov 2012 12:51:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.599
X-Spam-Level:
X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[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 niAkP5a2GGSr for <jose@ietfa.amsl.com>; Sun, 4 Nov 2012 12:51:56 -0800 (PST)
Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id 9341221F8813 for <jose@ietf.org>; Sun, 4 Nov 2012 12:51:53 -0800 (PST)
Received: from Philemon (dhcp-469b.meeting.ietf.org [130.129.70.155]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id E06622C9BC; Sun, 4 Nov 2012 12:51:52 -0800 (PST)
From: Jim Schaad <ietf@augustcellars.com>
To: 'Dick Hardt' <dick.hardt@gmail.com>
References: <4ACFC778-31A9-4C79-9F4E-7C01719F51AD@gmail.com> <4E1F6AAD24975D4BA5B168042967394366887325@TK5EX14MBXC285.redmond.corp.microsoft.com> <E73A223A-6546-4A3A-A839-8627B3DBCB8F@gmail.com> <000b01cdbab9$967ef070$c37cd150$@augustcellars.com> <210E03E3-FD49-449A-8953-571ECA9E5FBE@gmail.com>
In-Reply-To: <210E03E3-FD49-449A-8953-571ECA9E5FBE@gmail.com>
Date: Sun, 04 Nov 2012 15:51:45 -0500
Message-ID: <001101cdbace$34906500$9db12f00$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQJk3UBi+7c9NJolq0gv1z0r2pGfkgJRTlTwAoSEM20BgKfcgQFj4EGHlm4O9uA=
Content-Language: en-us
Cc: 'Mike Jones' <Michael.Jones@microsoft.com>, 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: Sun, 04 Nov 2012 20:51:58 -0000
> -----Original Message----- > From: Dick Hardt [mailto:dick.hardt@gmail.com] > Sent: Sunday, November 04, 2012 2:56 PM > To: Jim Schaad > Cc: 'Dick Hardt'; 'Mike Jones'; jose@ietf.org > Subject: Re: [jose] encrypting AND signing a token > > Thanks Jim. An interesting historical reference. > > In my use case, who signed or who the token is for is not a secret. The > payload needs to be kept a secret. > > Does no one sign and encrypt SAML tokens? > Is this not a common use case? Everything I have seen does this as independent operations. Jim > > If it does need to be solved, it would seem to me that a standards body > would be the place to have lots of eyes look at how to sign and encrypt a > token so that people do not do naive sign and encrypt. > > Q: does anyone else need to sign and encrypt? > > -- Dick > > On Nov 4, 2012, at 10:24 AM, "Jim Schaad" <ietf@augustcellars.com> wrote: > > > <personal> > > > > I would note that the original PKCS#7 specifications had a mode that > > provided a similar sign and encrypt as a single operation mode. When > > the > > PKCS#7 specifications where adopted by the IETF as part of the CMS > > work, this mode was discussed and very deliberately dropped because of > > numerous security problems that had been found. These included (but > > are not limited > > to) the fact that it was signed or who signed it was sometimes a > > security leak. Also there were attacks where the signed and encrypted > > mode could be converted to just an encrypted mode. > > > > I would think that there would be a need for a very detailed security > > analysis that we are not prepared to do in order to support a signed > > and encrypted mode. > > > > Jim > > > > > >> -----Original Message----- > >> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf > >> Of Dick Hardt > >> Sent: Friday, November 02, 2012 12:30 PM > >> To: Mike Jones > >> Cc: jose@ietf.org > >> Subject: Re: [jose] encrypting AND signing a token > >> > >> 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 > >> > >> _______________________________________________ > >> jose mailing list > >> jose@ietf.org > >> https://www.ietf.org/mailman/listinfo/jose > >
- [jose] encrypting AND signing a token Dick Hardt
- Re: [jose] encrypting AND signing a token Mike Jones
- Re: [jose] encrypting AND signing a token Dick Hardt
- Re: [jose] encrypting AND signing a token Jim Schaad
- Re: [jose] encrypting AND signing a token Dick Hardt
- Re: [jose] encrypting AND signing a token Jim Schaad
- Re: [jose] encrypting AND signing a token Mike Scott
- Re: [jose] encrypting AND signing a token Axel.Nennker
- Re: [jose] encrypting AND signing a token Dick Hardt
- Re: [jose] encrypting AND signing a token Axel.Nennker
- Re: [jose] encrypting AND signing a token Axel.Nennker
- Re: [jose] encrypting AND signing a token John Bradley
- Re: [jose] encrypting AND signing a token John Bradley
- Re: [jose] encrypting AND signing a token Jim Schaad
- Re: [jose] encrypting AND signing a token Richard L. Barnes
- Re: [jose] encrypting AND signing a token John Bradley
- Re: [jose] encrypting AND signing a token John Bradley
- Re: [jose] encrypting AND signing a token Dick Hardt
- Re: [jose] encrypting AND signing a token Dick Hardt