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

From: Dick Hardt <[email-masked]>
Date: Mon, 25 Mar 2013 15:53:11 -0700

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

---

From: John Bradley <[email-masked]>
Date: Mon, 25 Mar 2013 20:02:35 -0300

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 <[email-masked]> wrote:

> _______________________________________________
> jose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose

---

From: Dick Hardt <[email-masked]>
Date: Mon, 25 Mar 2013 16:09:01 -0700

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.

---

From: John Bradley <[email-masked]>
Date: Mon, 25 Mar 2013 20:19:34 -0300

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.

---

From: Dick Hardt <[email-masked]>
Date: Mon, 25 Mar 2013 16:27:03 -0700

'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.

---

From: Dick Hardt <[email-masked]>
Date: Tue, 26 Mar 2013 10:57:58 -0700

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?

-- Dick

---

From: Richard Barnes <[email-masked]>
Date: Tue, 26 Mar 2013 14:01:28 -0400

It doesn't seem harmful to me to have these parameters in there.  It just
seems like they won't be useful in a lot of cases.

Is there any particular reason that these fields have to be in the header
itself?  John Bradley had proposed earlier defining a separate container
for things that aren't necessarily of general use for JWE.

Perhaps we should set up a registry for JWE/JWS header parameters, with a
liberal inclusion policy (e.g., Specification Required), so that things
like this could be added easily.

--Richard

On Tue, Mar 26, 2013 at 1:57 PM, Dick Hardt <[email-masked]> 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.
>
> > '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.
> >
> >> 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.
> >>> 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.
> >>>
> >>>
> >>>>> 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'.
> >>>>>
> >>>>> 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

---

From: "Matt Miller (mamille2)" <[email-masked]>
Date: Tue, 26 Mar 2013 18:12:05 +0000

> 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 < [email-masked] >
Cisco Systems, Inc.

---

From: Dick Hardt <[email-masked]>
Date: Tue, 26 Mar 2013 11:43:59 -0700

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.