Re: [OAUTH-WG] Nested JWT (was: Re: [jose] "typ":"JWS")

John Bradley <ve7jtb@ve7jtb.com> Fri, 06 July 2012 19:07 UTC

Return-Path: <ve7jtb@ve7jtb.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 713D911E809F for <oauth@ietfa.amsl.com>; Fri, 6 Jul 2012 12:07:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.477
X-Spam-Level:
X-Spam-Status: No, score=-3.477 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZdkFhbIMqdwm for <oauth@ietfa.amsl.com>; Fri, 6 Jul 2012 12:07:06 -0700 (PDT)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8E82011E8079 for <oauth@ietf.org>; Fri, 6 Jul 2012 12:07:06 -0700 (PDT)
Received: by yhq56 with SMTP id 56so11394027yhq.31 for <oauth@ietf.org>; Fri, 06 Jul 2012 12:07:23 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=0BYjjYUKDT9+KC7yz99L39aYYEILSyTsFJZGBRFQH7U=; b=GlKpi3RdgmkooNrqNEMubdO8S9DPtChrHDv6eZ7Lf11pOVVUetOGn0WRDJ6SOp66sL l96KNaq94obl+gCPnBPOLXVVjN/ewddyjfT62Qv7pwG4xExvMjMqdyNeDorxwVEBQ8QD xJcrP/DbDslFPc9+NLO8MATWOQu3G+dTGTylwdytVZqujQD4VF0M1QWQK9dIaf/g5G/X URX6eY4nVeANViIV0bE8g8XwT0iOn7L5Li88X6h7x1wLYF5+MSNt/YU+e8KXCbUtkFmX w37L92CcovFQCf1741983nUHIJS6jv1mwx2vE8nFQYW6cgYphFmG19EdliJeMUosdeAv Firg==
Received: by 10.101.60.2 with SMTP id n2mr10758056ank.29.1341601643275; Fri, 06 Jul 2012 12:07:23 -0700 (PDT)
Received: from [192.168.1.211] (190-20-25-33.baf.movistar.cl. [190.20.25.33]) by mx.google.com with ESMTPS id i65sm37068884yhb.3.2012.07.06.12.07.19 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 06 Jul 2012 12:07:21 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1278)
Content-Type: multipart/signed; boundary="Apple-Mail=_6FC6FB6E-C971-412A-A485-2AC1F30403DF"; protocol="application/pkcs7-signature"; micalg="sha1"
From: John Bradley <ve7jtb@ve7jtb.com>
In-Reply-To: <CF974428-B673-40A6-A486-89060D0F2F5E@bbn.com>
Date: Fri, 06 Jul 2012 15:07:11 -0400
Message-Id: <4A66416B-701E-4CE9-B47B-091383DD4526@ve7jtb.com>
References: <4E1F6AAD24975D4BA5B16804296739436657A131@TK5EX14MBXC283.redmond.corp.microsoft.com> <F6ACB680-7E7D-43BF-A8D8-013B17A97F70@bbn.com> <4E1F6AAD24975D4BA5B16804296739436657A2B8@TK5EX14MBXC283.redmond.corp.microsoft.com> <CF974428-B673-40A6-A486-89060D0F2F5E@bbn.com>
To: "Richard L. Barnes" <rbarnes@bbn.com>
X-Mailer: Apple Mail (2.1278)
X-Gm-Message-State: ALoCoQlLuMv5eZBOxHjfqCvAXW1b2W3jGEOyjcOHA8Ver3Efl63gSlv3ULjydX7HxH9CZeP5mKn4
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Nested JWT (was: Re: [jose] "typ":"JWS")
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Jul 2012 19:07:07 -0000

In the security token case the outer signature may be checked by intermediate gateways.

Signing with RSA then encrypting would also fall into the same category.   

At the moment in SAML we have sign encrypt sign to prevent the padding oracle attack on authn responses. 
The use of AEAD admittedly covers a number of cases where people are doing an outer signing today but not all.

John B.
On 2012-07-06, at 2:41 PM, Richard L. Barnes wrote:

> So, first of all, it seems like an abuse of terminology to say "JWT within a JWT", unless you really want to create an infinite recursion.
> 
> What's the use case for sign/encrypt/sign, as opposed to just sign/encrypt?
> 
> 
> 
> 
> On Jul 6, 2012, at 2:31 PM, Mike Jones wrote:
> 
>> A nested JWT is one where a JWT is used as the payload of another JWT, for instance, so you can do sign/encrypt/sign.  See http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-01#section-7 and http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-01#section-5.2.
>> 
>> I wouldn't use it for multiple signatures - I'd use http://tools.ietf.org/html/draft-jones-json-web-signature-json-serialization-02 or similar for that.
>> 
>> 				-- Mike
>> 
>> -----Original Message-----
>> From: Richard L. Barnes [mailto:rbarnes@bbn.com] 
>> Sent: Friday, July 06, 2012 11:23 AM
>> To: Mike Jones
>> Cc: Manger, James H; jose@ietf.org
>> Subject: Nested JWT (was: Re: [jose] "typ":"JWS")
>> 
>> Not sure what the appropriate list is for this, so I'm just going to ask it here:
>> 
>> What is a "nested JWT"?  I'm guessing it's a JWT claim set wrapped in JWS multiple times, as in the example we were discussing earlier?
>> 
>> Why would you want to do that instead of having parallel signatures?
>> 
>> 
>> 
>> 
>> On Jul 6, 2012, at 2:19 PM, Mike Jones wrote:
>> 
>>> Thanks for the thought on this, James.
>>> 
>>> In the -03 drafts there is now a clear distinction between "typ" (type) - information about this object and the new "cty" (content type) - information about the secured object.  Besides being semantically cleaner, this also simplified nested JWTs.
>>> 
>>> I then was able to make changes in the spirit of the ones you suggested below, although using slightly different wording in some cases.
>>> 
>>>                                                               -- 
>>> Mike
>>> 
>>> From: Manger, James H [mailto:James.H.Manger@team.telstra.com]
>>> Sent: Tuesday, May 15, 2012 5:40 PM
>>> To: Mike Jones; jose@ietf.org
>>> Subject: RE: "typ":"JWS"
>>> 
>>>>> draft-ietf-jose-json-web-signature-02 §7.2 registers the "JWS" type 
>>>>> value (for the "typ" header field) . Perhaps "typ":"JWS" is more 
>>>>> useful in a JWE header when encrypting signed content (sign-then-encrypt). If this is the intention, then mentioning the "JWS" type value when defining the "typ" header for a JWS is misleading. It would be better to mention it where the JWE spec defines "typ".
>>>>> .
>>> 
>>>> Your second paragraph correctly describes the intended usage.  For instance, see http://tools.ietf.org/html/draft-jones-json-web-token-10#section-5.1 for this usage in action.  The value is registered per the working group decision relating "typ" values to MIME types.
>>> 
>>> Good. So let's say that. Suggested text changes:
>>> 
>>> * draft-ietf-jose-json-web-signature-02, section 4.1.8 "typ" (Type) Header Parameter: delete the 2nd sentence because signing a signature is not what we are talking about (and JWS-JS recommends a different approach for multiple signatures anyway).
>>> 
>>> * section 7.1 Registration of application/jws MIME Media Type: add a phrase explicitly stating the syntax (since the spec mentions two: compact, and JWS JS) so the section says:
>>> This specification registers the "application/jws" MIME Media Type [RFC 2045]
>>> to identify content that uses the JWS compact serialization.
>>> 
>>> * section 7.2 Registration of "JWS" Type Value: mention the intended use of encrypting signed content by adding this sentence.
>>> The "typ" parameter can be set to "JWS" in a JSON Web Encryption [JWE] header when encrypting signed content.
>>> 
>>> * draft-ietf-jose-json-web-encryption-02, section 4.1.13 "typ" (Type) Header Parameter, section 11.1 Registration of application/jwe MIME Media Type, section 11.2 Registration of "JWE" type Value: make equivalent changes.
>>> 
>>> --
>>> James Manger
>>> 
>>> _______________________________________________
>>> jose mailing list
>>> jose@ietf.org
>>> https://www.ietf.org/mailman/listinfo/jose
>> 
>> 
>> 
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth