Subject: [jose] Proposed resolution of header criticality issue

From: Karen O'Donoghue <[email-masked]>
Date: Mon, 11 Mar 2013 20:31:08 -0400

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.

---

From: Tim Bray <[email-masked]>
Date: Mon, 11 Mar 2013 18:42:36 -0700

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]>wrote:

> 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.
>
> "understand" text with something a bit more explicit like "must process".
> However, that text has not been rolled into the summary text below yet.
>
> 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.**
> **
> ****
> 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****
>   }****
> ****
> 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]
> https://www.ietf.org/mailman/listinfo/jose
>
>

---

From: "Manger, James H" <[email-masked]>
Date: Tue, 12 Mar 2013 13:48:07 +1100

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

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.

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

--
James Manger

From: [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

---

From: John Bradley <[email-masked]>
Date: Mon, 11 Mar 2013 23:01:07 -0400

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

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.

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

---

From: Richard Barnes <[email-masked]>
Date: Tue, 12 Mar 2013 01:01:37 -0400

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

> 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.****
>
>
>
> 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 Manger****
> *From:* [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****
> ** **
> ** **
> On Mon, Mar 11, 2013 at 5:31 PM, Karen O'Donoghue <[email-masked]>
> wrote:****
>
> Folks,****
>
>
> “enc” values requiring them are used, and otherwise they may be ignored.
>
> (expiration-time) field is:
>
>   {"alg":"ES256",
>    "crit":["exp"],
>    "exp”:1363284000
>   }
>
> and not contained in the “crit” list MUST be ignored if not understood.
>
> ** **
> ** **
> https://www.ietf.org/mailman/listinfo/jose****
> ** **

---

From: Dick Hardt <[email-masked]>
Date: Mon, 11 Mar 2013 22:26:06 -0700

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

Yeah!  Implementing MUST understand was going to be non-trivial.

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

Why must "zip" be understood? Is there a security issue here or just degraded performance? In my current implementations, "zip" does not help me enough to bother with the added complexity and I have not implemented support.

-- Dick

---

From: "Manger, James H" <[email-masked]>
Date: Tue, 12 Mar 2013 17:08:36 +1100

> Why must "zip" be understood? Is there a security issue here or just
> degraded performance? In my current implementations, "zip" does not
> help me enough to bother with the added complexity and I have not
> implemented support.
> 
> -- Dick

You don't want to try to interpret compressed data as plain text. That could be a security problem. A tricky person might be able to create, say, a valid JSON value X that compresses to Y that is also valid JSON. If you ignore "zip" you get JOSE-verified Y; if you process "zip" you get JOSE-verified X.

You might not have to implement "zip" (that is a separate MTI discussion), but your recipient code at least needs to notice when "zip" is present and throw an error (instead of misinterpreting the compressed content).

--
James Manger

---

From: Dick Hardt <[email-masked]>
Date: Mon, 11 Mar 2013 23:38:37 -0700

Thanks for the clear explanation James.

---

From: Dirkjan Ochtman <[email-masked]>
Date: Tue, 12 Mar 2013 10:48:10 +0100

On Tue, Mar 12, 2013 at 1:31 AM, Karen O'Donoghue <[email-masked]> wrote:
> 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.

This looks like a great improvement.

Cheers,

Dirkjan

---

From: Richard Barnes <[email-masked]>
Date: Mon, 25 Mar 2013 17:34:22 -0400

Trying to move this to closure...

It sounds to me like there was general agreement on points 1-4.  Can
someone file an issue for #5 and ask the editor to implement 1-4?

Thanks,
--Richard

---

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

Agreed,  I think I said that in the meeting:)  

On 2013-03-25, at 6:34 PM, Richard Barnes <[email-masked]> wrote:

> It sounds to me like there was general agreement on points 1-4.  Can someone file an issue for #5 and ask the editor to implement 1-4?
> 
> Thanks,
> --Richard
> 
> 
> 
> On Mon, Mar 11, 2013 at 8:31 PM, Karen O'Donoghue <[email-masked]> wrote:
> 
> Folks,
>