Re: [jose] 'aud' and 'iss' in JWE header

Dick Hardt <dick.hardt@gmail.com> Tue, 26 March 2013 18:44 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 D4BF721F877B for <jose@ietfa.amsl.com>; Tue, 26 Mar 2013 11:44:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.267
X-Spam-Level:
X-Spam-Status: No, score=-3.267 tagged_above=-999 required=5 tests=[AWL=0.332, 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 9r+rIuuKsT88 for <jose@ietfa.amsl.com>; Tue, 26 Mar 2013 11:44:11 -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 DCF3A21F8765 for <jose@ietf.org>; Tue, 26 Mar 2013 11:44:08 -0700 (PDT)
Received: by mail-pa0-f44.google.com with SMTP id bi5so1754600pad.17 for <jose@ietf.org>; Tue, 26 Mar 2013 11:44:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=fzXTCoHeQzP2nWO0p9ONnu9Q/pzR7W5X3+MxCxm0Vnw=; b=Dw9DGCYGtgSwPFcCz57NpG8VQCJl9fKENdZiLlNHgjJTKREh4mTXipCrfXMp8H7HrH WPplH35uTJSwthpNTeWX0m7gy+o/MQvoiSirlVmEtIo9TFdE8E2pjvyeKmKVzVLJewex 4LoZT6iZsvYFdh/Cxo00CPr2FQPKGortEIi9avTl1qgEb1AfbWFfimXeW1vp0UbgcNXt 0LzUhgLINzM6npu6Ak2wlK4sJaqHNr8ekLNjMmxIhEVeqaQYma0R8crhNV9NW4zR8izi mM84iN9mIR14olXm5kQ0IgQAS1bJIWRB3OCHl0PUlGbxWL/eWTGF6RARaGlaTDOoPKRZ 001w==
X-Received: by 10.68.204.164 with SMTP id kz4mr22791625pbc.158.1364323446538; Tue, 26 Mar 2013 11:44:06 -0700 (PDT)
Received: from [10.0.0.89] (c-24-5-69-173.hsd1.ca.comcast.net. [24.5.69.173]) by mx.google.com with ESMTPS id zm1sm18384703pbc.26.2013.03.26.11.44.01 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 26 Mar 2013 11:44:02 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Dick Hardt <dick.hardt@gmail.com>
In-Reply-To: <BF7E36B9C495A6468E8EC573603ED9411518B28C@xmb-aln-x11.cisco.com>
Date: Tue, 26 Mar 2013 11:43:59 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <BE9D3E17-2C24-4F6F-9DAF-9DC44695C4B2@gmail.com>
References: <57A4986E-4AA7-4E96-8EE6-53F3CE2D73EA@gmail.com> <BD041F81-FDEE-4917-86C9-A67B1A62D19F@ve7jtb.com> <AFBB0F6B-FB11-4F01-8F68-218EB211230F@gmail.com> <942E1B2E-1469-4472-83A4-3884CF21F5EB@ve7jtb.com> <A7EC3B59-824E-4413-914E-8298036CC0CD@gmail.com> <EAA32C99-3498-407C-80FC-DF63EA40963A@gmail.com> <BF7E36B9C495A6468E8EC573603ED9411518B28C@xmb-aln-x11.cisco.com>
To: "Matt Miller (mamille2)" <mamille2@cisco.com>
X-Mailer: Apple Mail (2.1503)
Cc: John Bradley <ve7jtb@ve7jtb.com>, jose@ietf.org
Subject: Re: [jose] 'aud' and 'iss' in JWE header
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: Tue, 26 Mar 2013 18:44:12 -0000

I would expect that you could ignore them, but if they were present, would you not want to check that they are the same values as what is in the payload?

For example, if 'kid' is present, then one would expect that to be needed and that you would not ignore it as a signal as to what key was used to encrypt the JWE. If there is no 'kid', then you must know what key to use without it.

On Mar 26, 2013, at 11:12 AM, "Matt Miller (mamille2)" <mamille2@cisco.com> wrote:

> 
> On Mar 26, 2013, at 11:57 AM, Dick Hardt <dick.hardt@gmail.com>
> wrote:
> 
>> My other option would be to hack the 'kid' value to include both the 'iss' value and the 'aud' value so that a recipient would be able to determine if they are the audience and who the issuer is by cracking the 'kid' => but that seems like such a hack given that I have the ability to put the 'aud' and 'iss' in the header.
>> 
>> Am I the only one that sees the value in having the 'aud' and 'iss' in the header for JWE?
>> 
> 
> In my case (XMPP E2E), I have addressing information that exists completely separate from the protected.  Including 'aud' and 'iss' is of no benefit to me.  That doesn't mean it causes me harm, provided I can ignore them.
> 
> 
> - m&m
> 
> Matt Miller < mamille2@cisco.com >
> Cisco Systems, Inc.
> 
>> -- Dick
>> 
>> On Mar 25, 2013, at 4:27 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
>> 
>>> 'iss' and 'aud' are not reserved header parameter names, so if I used them, then they would be private names subject to collision. 
>>> 
>>> Unless there is a reason why they should not be allowed, I'd like them to be reserved header parameter names so that their meaning is clear to an implementation or library. I would like to write my libraries to look at the header for those parameters if they are there.
>>> 
>>> On Mar 25, 2013, at 4:19 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
>>> 
>>>> That will be compliant.  The spec won't call out those particular properties from JWT.   
>>>> 
>>>> If you think that they should be called out as optional parameters that could be considered.  However that is not a open issue at this point.
>>>> 
>>>> John B.
>>>> On 2013-03-25, at 8:09 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
>>>> 
>>>>> Will that be compliant though? I would like to spec to say that I can optionally include those properties in the header of a JWE.
>>>>> 
>>>>> 
>>>>> On Mar 25, 2013, at 4:02 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
>>>>> 
>>>>>> Once the change to ignore additional elements in the header there is nothing to stop you from doing that.
>>>>>> 
>>>>>> You make a good point about scoping the 'kid' to the 'iss'. 
>>>>>> 
>>>>>> John B.
>>>>>> 
>>>>>> On 2013-03-25, at 7:53 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
>>>>>> 
>>>>>>> Hello everyone
>>>>>>> 
>>>>>>> As I am implementing JOSE JWE, I would like to know who the 'iss' and 'aud' is. I am using symmetric, shared keys and the 'aud' party would like to know they really are the intended 'aud' and who the 'isa' is. Otherwise the 'iss' is inferred from the 'kid', and there is no guarantee that two 'iss' won't have the same 'kid' for different keys from different 'iss'.
>>>>>>> 
>>>>>>> I don't see an issue with disclosure of who 'iss' and 'aud' are as any party able to intercept the token will have a pretty good idea of where it is coming from and where it is going to. Knowing the 'iss' and 'aud' allows the 'aud' to return an error before doing any crypto if the 'aud' does not match or if there is no 'kid' for the 'iss'.
>>>>>>> 
>>>>>>> Is there a reason why I cannot have 'iss' and 'aud' in the header?
>>>>>>> 
>>>>>>> This is not an issue with JWS since the payload is clear and the 'aud' can evaluate the 'iss' and 'aud' properties before doing crypto.
>>>>>>> 
>>>>>>> -- 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
>