Re: [jose] Proposed resolution of header criticality issue

I really hope you're not using char[4] for field names :)


On Tue, Mar 12, 2013 at 2:44 AM, Vladimir Dzhuvinov / NimbusDS <
vladimir@nimbusds.com> wrote:

> How about "crt" instead of "crit", to fit the three-letter convention
> for naming fields?
>
> Vladimir
>
> --
> Vladimir Dzhuvinov : www.NimbusDS.com : vladimir@nimbusds.com
>
>
> -------- Original Message --------
> Subject: [jose] Proposed resolution of header criticality issue
> From: Karen O'Donoghue <odonoghue@isoc.org>
> Date: Tue, March 12, 2013 12:31 am
> To: jose@ietf.org
>
>
>  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
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose
>