[jose] Proposed resolution of header criticality issue

[Karen O'Donoghue <[e-mail]>]

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.