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

From: Anthony Nadalin <[email-masked]>
Date: Tue, 12 Mar 2013 13:59:04 +0000

I would agree, as who is to say what is related or not relative to envelope contents

Sent from Windows Mail

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

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

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

I’ll add some cheers — this does look like substantial progress.

I assume the fields such as “epk”, “apu” etc that sometimes must be understood, and at other times must be ignored (depending on “alg” or “enc” value) would NOT be listed in the “crit” field as they are defined in the “base specs”.

Correct

Being in the “base specs” is the right criteria for whether a field should be listed in “crit” as long as “base specs” means: “base specifications for the particular “alg”/”enc” values”. It shouldn’t mean (and doesn’t have to mean) the base spec for the whole JOSE system.

Crit is only for extensions, it is up to the extension definition to decide if the field needs to be in crit.

P.S. “meta” might be a nicer label than “asd”.

I don't have any particular attachment to the name.   Some places things like this are called associated data, though not the places normal people go I grant you.
Meta-data about the payload is what it is,  The current practice is to use three character names.   I am fine with met or meta (I suspect that if you are throwing crap into the envelope the single character won't kill anyone.

James if you like the solution and want it to be meta I will back you on it :)

John B.

--
James Manger

From: [email-masked]<mailto:[email-masked]> [mailto:jose-<mailto:jose->[email-masked]<mailto:[email-masked]>] On Behalf Of Tim Bray
Sent: Tuesday, 12 March 2013 12:43 PM
To: Karen ODonoghue
Cc: jose
Subject: Re: [jose] Proposed resolution of header criticality issue

Cue wild cheers from the peanut gallery where non-cryptographers sit.  MustIgnore is infinitely more robust and open-ended than MustUnderstand.  -T

On Mon, Mar 11, 2013 at 5:31 PM, Karen O'Donoghue <[email-masked]<mailto:[email-masked]>> wrote:

Folks,

A side meeting was held Sunday with a number of jose working group participants to try to resolve the open issue related to header criticality. The following are the proposed resolutions from the meeting. Point 5 of the proposed resolution below is actually independent of the other 4 points, and could be considered separately. This will all be discussed in Wednesday's meeting.

In addition to the text below, there was some agreement to replace the "understand" text with something a bit more explicit like "must process". However, that text has not been rolled into the summary text below yet.

Thank you to Jim Schaad, Mike Jones, John Bradley, Nat Sakimura, Martin Thomas, Eric Rescorla, Matt Miller, and Richard Barnes for your efforts (and my apologies if I missed someone).

Regards,
Karen

1:  Change the language “Additional members MAY be present in the JWK.  If present, they MUST be understood by implementations using them.” to “Additional members MAY be present in the JWK.  If not understood by implementations encountering them, they MUST be ignored.”  (And make the same change for JWK Set as well.)

2:  Characterize all existing JWS and JWE header fields as either must be understood or may be ignored.  “alg”, “enc”, and “zip” must be understood.  “kid”, “x5u”, “x5c”, “x5t”, “jwk”, “jku”, “typ”, and “cty” can be ignored because while not using them may result in the inability to process some signatures or encrypted content, this will not result in a security violation – just degraded functionality.  Other fields such as “epk”, “apu”, “apv”, “epu”, and “epv” must be understood and used when “alg” or “enc” values requiring them are used, and otherwise they may be ignored.

3.  Define a new header field that lists which additional fields not defined in the base specifications must be understood and acted upon when present.  For instance, an expiration-time extension field could be marked as must-be-understood-and-acted-upon.  One possible name for this would be “crit” (critical).  An example use, along with a hypothetical “exp” (expiration-time) field is:

  {"alg":"ES256",
   "crit":["exp"],
   "exp”:1363284000
  }

4.  All additional header fields not defined in the base specifications and not contained in the “crit” list MUST be ignored if not understood.

5.  Define a new header field “asd” (application-specific data) whose value is a JSON structure whose contents are opaque to and ignored by JWS and JWE implementations but for which its contents MUST be provided to applications using JWS or JWE, provided that the signature/MAC validation or decryption operation succeeds.  The intended use of this field is to have a standard place to provide application-specific metadata about the payload or plaintext.

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

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

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

---

From: Mike Jones <[email-masked]>
Date: Tue, 12 Mar 2013 14:00:27 +0000

+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

John B.

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

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

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