Subject: Re: [jose] Proposed resolution of header criticality issue

From: Anthony Nadalin <[email-masked]>
Date: Tue, 12 Mar 2013 14:05:03 +0000

oh great now you are going to tell us what is crypto related and what is not, that is pretty much n application call not a spec call

Sent from Windows Mail

From: Mike Jones
Sent: ‎March‎ ‎12‎, ‎2013 ‎7‎:‎02‎ ‎AM
To: Jim Schaad, Richard Barnes
CC: John Bradley, Tim Bray, James H Manger, Karen O'Donoghue, jose
Subject: Re: [jose] Proposed resolution of header criticality issue

+1 to only putting crypto-related things in the headers.

From: Richard Barnes
Sent: ‎March‎ ‎12‎, ‎2013 ‎6‎:‎53‎ ‎AM
To: Jim Schaad
CC: John Bradley, Mike Jones, James H Manger, Tim Bray, jose, Karen O'Donoghue
Subject: Re: [jose] Proposed resolution of header criticality issue

Note that my proposed text did not say that the libraries would not return header stuff, only that you shouldn't cram non-crypto-related things in there.

On Tuesday, March 12, 2013, Jim Schaad wrote:
I am not truly happy with this idea.  If the application cares about who “owns” a key for a signature then it needs to somehow get that information.  That may be done by getting the way and key from the security library and that may be done by just returning the claims from the envelope.

Jim

From: [email-masked] [mailto:[email-masked]] On Behalf Of John Bradley
Sent: Tuesday, March 12, 2013 9:15 AM
To: Mike Jones
Cc: Richard Barnes; James H Manger; Tim Bray; jose; Karen O'Donoghue
Subject: Re: [jose] Proposed resolution of header criticality issue

I am OK with getting rid of it if we make it clear that claims from the envelope will not be passed on to applications.

If we don't do that we will compromise interoperability between libraries.   Envelope is for JOSE only and not made available, that makes things like timestamps and other things that the application layer needs to interpret can't go in the envelope they need to be in the body in some way.

I just want it one way or the other.

John B.

On 2013-03-12, at 9:06 AM, Mike Jones <[email-masked]> wrote:

I’m with Richard on this.  The application-specific-data/meta field isn’t needed.

-- Mike

From: Richard Barnes
Sent: March 11, 2013 10:02 PM
To: John Bradley
CC: Tim Bray, Manger, James H, Karen ODonoghue, jose
Subject: Re: [jose] Proposed resolution of header criticality issue

+1 to cheers.  I already high-fived Mike in person.

FWIW, my preference would be to get rid of "asd" or "meta" (part 5).  I don't think it's relevant to the criticality discussion, and it's just not needed.

--Richard

On Mon, Mar 11, 2013 at 11:01 PM, John Bradley <[email-masked]> wrote:

On 2013-03-11, at 10:48 PM, "Manger, James H" <[email-masked]> wrote:

I’ll add some cheers — this does look like substant

---

From: Dick Hardt <[email-masked]>
Date: Tue, 12 Mar 2013 10:07:16 -0700

Agreed.

In an implementation I am working on, I need an audience signal in a JWE so
that recipients of the JWE token know who can decrypt and process it.

While on that topic, it seems that I can't have 'aud' in the header, so I
would need to have a URI for that property such as 'aud.example.com'

btw: per Richard's comment, the code to use app specific payload data is
pretty ugly with

jwt.['prop.example.com']

but I put all the app properties in the one object so I do

jwt.['prop.example.com'].prop1

-- Dick

On Tue, Mar 12, 2013 at 7:05 AM, Anthony Nadalin <[email-masked]>wrote:

>  oh great now you are going to tell us what is crypto related and what is
> not, that is pretty much n application call not a spec call
>
> Sent from Windows Mail
>
>  *From:* Mike Jones
> *Sent:* March 12, 2013 7:02 AM
> *To:* Jim Schaad, Richard Barnes
> *CC:* John Bradley, Tim Bray, James H Manger, Karen O'Donoghue, jose
>
> *Subject:* Re: [jose] Proposed resolution of header criticality issue
>
>  *From:* Richard Barnes
> *Sent:* March 12, 2013 6:53 AM
> *To:* Jim Schaad
> *CC:* John Bradley, Mike Jones, James H Manger, Tim Bray, jose, Karen
> O'Donoghue
> *Subject:* Re: [jose] Proposed resolution of header criticality issue
>
> Note that my proposed text did not say that the libraries would not return
> header stuff, only that you shouldn't cram non-crypto-related things in
> there.
>
>
>
>>  I am not truly happy with this idea.  If the application cares about
>> who “owns” a key for a signature then it needs to somehow get that
>> information.  That may be done by getting the way and key from the security
>> library and that may be done by just returning the claims from the envelope.
>> ****
>>
>> ** **
>>
>> Jim****
>>
>> ** **
>>
>> ** **
>>
>> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
>> Of *John Bradley
>> *Sent:* Tuesday, March 12, 2013 9:15 AM
>> *To:* Mike Jones
>> *Cc:* Richard Barnes; James H Manger; Tim Bray; jose; Karen O'Donoghue
>> *Subject:* Re: [jose] Proposed resolution of header criticality issue****
>>
>> ** **
>>
>> I am OK with getting rid of it if we make it clear that claims from the
>> envelope will not be passed on to applications.****
>>
>> ** **
>>
>> If we don't do that we will compromise interoperability between
>> libraries.   Envelope is for JOSE only and not made available, that makes
>> things like timestamps and other things that the application layer needs to
>> interpret can't go in the envelope they need to be in the body in some way.
>> ****
>>
>> ** **
>>
>> I just want it one way or the other.****
>>
>> ** **
>>
>> John B.****
>>
>> ** **
>>
>> ** **
>>
>> On 2013-03-12, at 9:06 AM, Mike Jones <[email-masked]>
>> wrote:****
>>
>>
>>
>> ****
>>
>> I’m with Richard on this.  The application-specific-data/meta field isn’t
>> needed.****
>>
>>  ****
>>
>> -- Mike****
>>
>>  ****
>>
>> *From:* Richard Barnes
>> *Sent:* March 11, 2013 10:02 PM
>> *To:* John Bradley
>> *CC:* Tim Bray, Manger, James H, Karen ODonoghue, jose
>> *Subject:* Re: [jose] Proposed resolution of header criticality issue****
>>
>>  ****
>>
>> +1 to cheers.  I already high-fived Mike in person. ****
>>
>> ** **
>>
>> FWIW, my preference would be to get rid of "asd" or "meta" (part 5).  I
>> don't think it's relevant to the criticality discussion, and it's just not
>> needed.  ****
>>
>> ** **
>>
>> --Richard****
>>
>> ** **
>>
>> ** **
>>
>> ****
>> ** **
>> On 2013-03-11, at 10:48 PM, "Manger, James H" <
>> [email-masked]> wrote:****
>>
>> ** **
>>
> _______________________________________________
> jose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose
>
>

-- 
-- Dick

---

From: Richard Barnes <[email-masked]>
Date: Tue, 12 Mar 2013 18:29:38 -0400

Hi Dick,

If I understand your use case correctly, what you're actually looking for
is a way to populate the "additional data" that's protected under the AEAD
algorithm.  Unfortunately, under current JWE, that's conflated with the
header.  I think the correct resolution to this problem is to remove the
JWE header from the integrity check, and add a separate field to JWE for
additional data.

--Richard

On Tue, Mar 12, 2013 at 1:07 PM, Dick Hardt <[email-masked]> wrote:

> Agreed.
>
> In an implementation I am working on, I need an audience signal in a JWE
> so that recipients of the JWE token know who can decrypt and process it.
>
>>  oh great now you are going to tell us what is crypto related and what
>> is not, that is pretty much n application call not a spec call
>>
>> Sent from Windows Mail
>>
>>  *From:* Mike Jones
>> Note that my proposed text did not say that the libraries would not
>> return header stuff, only that you shouldn't cram non-crypto-related things
>> in there.
>>
>>
>>
>>> I’m with Richard on this.  The application-specific-data/meta field
>>> isn’t needed.****
>>>
>>>  ****
>>>
>>> -- Mike****
>>>
>>>  ****
>>>
>>> *From:* Richard Barnes
>>> On Mon, Mar 11, 2013 at 11:01 PM, John Bradley <[email-masked]>
>>> wrote:****
>>>
>>> ** **
>>>

---

From: Dick Hardt <[email-masked]>
Date: Tue, 12 Mar 2013 15:57:01 -0700

Hi Richard

I know enough about crypto to follow the directions in the spec and get something that interoperates with other implementations. i.e., I don't know if your statement below is what I am actually looking for.

Here is the protocol:

1) Alice gives Bob a JWE where Charlie, Dennis or Eric may be the audience

2) Bob knows how to talk to Charlie but not Dennis or Eric, so Bob gives the JWE to Charlie

3) Charlie needs to be able to look at the JWE and see who the audience is to determine if he can process it, or if he needs to hand it to Dennis or Eric.

In JWE, the only plaintext metadata that is available is the JWE header, so I would like an audience signal there, as it enables a token recipient to know if they are the recipient or not. Currently a recipient can guess they are not if the KID is not understood, but that does not help signal who will understand, and also does assist developers in detecting they have an old key vs signed for the wrong recipient.

I don't want to add another plaintext field. In my implementation (assuming I did it correctly) the header has integrity protection.

-- Dick

On Mar 12, 2013, at 3:29 PM, Richard Barnes <[email-masked]> wrote:

> Hi Dick,
> 
> If I understand your use case correctly, what you're actually looking for is a way to populate the "additional data" that's protected under the AEAD algorithm.  Unfortunately, under current JWE, that's conflated with the header.  I think the correct resolution to this problem is to remove the JWE header from the integrity check, and add a separate field to JWE for additional data.
> 
> --Richard
> 
> 
> 
> In an implementation I am working on, I need an audience signal in a JWE so that recipients of the JWE token know who can decrypt and process it.
> 
> While on that topic, it seems that I can't have 'aud' in the header, so I would need to have a URI for that property such as 'aud.example.com'
> 
> btw: per Richard's comment, the code to use app specific payload data is pretty ugly with
> 
> jwt.['prop.example.com']
> 
> On Tue, Mar 12, 2013 at 7:05 AM, Anthony Nadalin <[email-masked]> wrote:
> Sent: March 12, 2013 7:02 AM
> 
> Sent: March 12, 2013 6:53 AM
> 
> To: Jim Schaad

---

From: John Bradley <[email-masked]>
Date: Tue, 12 Mar 2013 19:13:18 -0400

Currently the header has integrity protection.

The proposed changes to the spec allow what you are doing.   The thing is that a standard JWE library is not going to know about your forwarding rules. 
My proposal was to add a containing element for all the additional claims intended for processing outside of the JWE/JWS crypto library.
That reduces namespace collision and allows the library to pass back to the application any claims in the header that are not intended for JWEJWS.

The three alternatives are:
1 preclude non JWE/S claims in the header  (won't work for you)
2 a dedicated JSON member that contains claims intended for applications or external extensions
3 throw in everything as a top level claim and have applications sniff the header looking for what they need.

The proposal going to the meeting tomorrow is 2 based on it being the cleanest way to pass on the additional claims to applications using a general purpose JOSE lib.

John B.

---

From: Dick Hardt <[email-masked]>
Date: Tue, 12 Mar 2013 16:39:01 -0700

> Currently the header has integrity protection.

Glad to hear I did that right.

> The proposed changes to the spec allow what you are doing.   The thing is that a standard JWE library is not going to know about your forwarding rules. 

I would hope that a standard JWE library would ignore my forwarding rules. That is done at the protocol layer (which should be obvious since the JWE library won't know how to forward)

In my libraries, I have a JWT parser that will give me the header and the payload if a JWS. Hopefully other libraries will have parsers so that the App can make decision about what to do.

> My proposal was to add a containing element for all the additional claims intended for processing outside of the JWE/JWS crypto library.

Or I could just add an app specific claim like I do in the payload.

> That reduces namespace collision and allows the library to pass back to the application any claims in the header that are not intended for JWEJWS.

We already have a mechanism for namespace collision in the payload. Why invent a new one?

btw: I like my parsing implementation just fine -- passing back just the claims does not meet my purpose -- I want to see all of the header, and see the payload if it is a JWS

> 3 throw in everything as a top level claim and have applications sniff the header looking for what they need.

Why not use the same extension mechanism that is being used for the payload? Or allow me to put payload properties into the header as well? There is no namespace collision since it is a reserved property value.

> The proposal going to the meeting tomorrow is 2 based on it being the cleanest way to pass on the additional claims to applications using a general purpose JOSE lib.

I don't just want the additional claims, I want the full header parsed and be able to look at all of it.

-- Dick

---

From: John Bradley <[email-masked]>
Date: Tue, 12 Mar 2013 19:46:59 -0400

The application wanting to see the whole header is also a valid perspective.

I guess the question is if every application should have to create its own way to extract the header info or should a lib be expected to make them available.

Some of this discussion comes from CMS where the crypto info/header info is not exposed to applications.

I think that is not the right thing to do.

If we are going with adding top level claims then we should probably say there is an expectation that the header is also available to applications, which is what I think you expect.

John B.

---

From: Dick Hardt <[email-masked]>
Date: Tue, 12 Mar 2013 17:24:43 -0700

I expect to look at the header to see the 'kid' so I know what key to fetch
to hand to the library. Does not make sense for the library to store and
manage keys -- I expect the keys are handed to the library as needed.

On Tue, Mar 12, 2013 at 4:46 PM, John Bradley <[email-masked]> wrote:

> I guess the question is if every application should have to create its own
> way to extract the header info or should a lib be expected to make them
> available.
>
> If we are going with adding top level claims then we should probably say
> there is an expectation that the header is also available to applications,
> which is what I think you expect.
>
> John B.
>
> >> The proposed changes to the spec allow what you are doing.   The thing
> is that a standard JWE library is not going to know about your forwarding
> rules.
> >
> > I would hope that a standard JWE library would ignore my forwarding
> rules. That is done at the protocol layer (which should be obvious since
> the JWE library won't know how to forward)
> >
> > In my libraries, I have a JWT parser that will give me the header and
> the payload if a JWS. Hopefully other libraries will have parsers so that
> the App can make decision about what to do.
> >
> >> My proposal was to add a containing element for all the additional
> claims intended for processing outside of the JWE/JWS crypto library.
> >
> >> That reduces namespace collision and allows the library to pass back to
> the application any claims in the header that are not intended for JWEJWS.
> >
> > btw: I like my parsing implementation just fine -- passing back just the
> claims does not meet my purpose -- I want to see all of the header, and see
> the payload if it is a JWS
> >
> >>
> > Why not use the same extension mechanism that is being used for the
> payload? Or allow me to put payload properties into the header as well?
> There is no namespace collision since it is a reserved property value.
> >
> >>
> >> The proposal going to the meeting tomorrow is 2 based on it being the
> cleanest way to pass on the additional claims to applications using a
> general purpose JOSE lib.
> >

-- 
-- Dick

---

From: Brian Campbell <[email-masked]>
Date: Tue, 12 Mar 2013 21:34:14 -0400

Yeah, I'm with Dick on this one. There will be stuff in the header that
helps identify the key but the more general concern of managing and storing
keys will not be done by the JOSE library itself but rather by the
application using it. And that application will need to have access to
headers like "kid" to be able to do that.

On Tue, Mar 12, 2013 at 8:24 PM, Dick Hardt <[email-masked]> wrote:

> I expect to look at the header to see the 'kid' so I know what key to
> fetch to hand to the library. Does not make sense for the library to store
> and manage keys -- I expect the keys are handed to the library as needed.
>
>
>> I guess the question is if every application should have to create its
>> own way to extract the header info or should a lib be expected to make them
>> available.
>>
>> >> That reduces namespace collision and allows the library to pass back
>> to the application any claims in the header that are not intended for
>> JWEJWS.
>> >
>> > btw: I like my parsing implementation just fine -- passing back just
>> the claims does not meet my purpose -- I want to see all of the header, and
>> see the payload if it is a JWS
>> >
>> >>

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 15 Mar 2013 14:07:23 -0400

I cannot speak to all CMS implementations, however all of the header
information was exposed in everyone that I either wrote or have used todate.

Jim

> -----Original Message-----
> From: John Bradley [mailto:[email-masked]]
> Sent: Tuesday, March 12, 2013 7:47 PM
> To: Dick Hardt
> Cc: Richard Barnes; Anthony Nadalin; Jim Schaad; Mike Jones; James H
> Manger; Tim Bray; jose; Karen O'Donoghue
way
> to extract the header info or should a lib be expected to make them
> available.
> 
is
> that a standard JWE library is not going to know about your forwarding
rules.
> rules. That is done at the protocol layer (which should be obvious since
the
> JWE library won't know how to forward)
> >
the
> payload if a JWS. Hopefully other libraries will have parsers so that the
App
> can make decision about what to do.
> >
claims
> intended for processing outside of the JWE/JWS crypto library.
> >
> >> 3 throw in everything as a top level claim and have applications sniff
the
> header looking for what they need.
> >
general
> purpose JOSE lib.
> >
> > I don't just want the additional claims, I want the full header parsed
and
> be able to look at all of it.
> >
> > -- Dick