Re: [jose] Proposed resolution of header criticality issue

[Tim Bray <[e-mail]>]

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 <[e-mail]>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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/jose
>
>