Re: [jose] Proposed resolution of header criticality issue: meta/asd

[Richard Barnes <[e-mail]>]

That's a good example of an application making a field mandatory.  It
doesn't have to be mandatory in the base spec.  Unlike with "zip", you
don't have to understand "cty" when you validate a signature or decrypt an
object.

So I would put it in the "MAY ignore" bin.


On Tue, Mar 12, 2013 at 10:06 AM, Mike Jones <[e-mail]>wrote:

>  The content type field is used as input to crypto processing rules and
> is not necessarily application-specific data.  For instance, see JWT’s
> normative use of the field to convey structural information in
> http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-06#section-7.
>
>  *From:* Manger, James H
> *Sent:* March 12, 2013 6:40 AM
> *To:* Mike Jones, [e-mail]
> *CC:* [e-mail]
> *Subject:* Re: [jose] Proposed resolution of header criticality issue:
> meta/asd
>
> I would put "cty" (content type) under "meta".
>
> Mike, do you think "cty" isn't needed, or that there is no value in
> separating such a field from the others?
>
> --
> James Manger
>
> ----- Reply message -----
> From: "Mike Jones" <[e-mail]>
> Date: Wed, Mar 13, 2013 12:07 am
> Subject: [jose] Proposed resolution of header criticality issue
> To: "John Bradley" <[e-mail]>, "Richard Barnes" <[e-mail]>
> Cc: "Tim Bray" <[e-mail]>, "Manger, James H" <
> [e-mail]>, "Karen O&apos;Donoghue" <
> [e-mail]>, "jose" <[e-mail]>
>
> 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 <[e-mail]<mailto:
> [e-mail]>> wrote:
>
> On 2013-03-11, at 10:48 PM, "Manger, James H" <
> [e-mail]<mailto:[e-mail]>>
> 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: [e-mail]<mailto:[e-mail]> [mailto:jose-
> <mailto:jose->[e-mail]<mailto:[e-mail]>] 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 <[e-mail]
> <mailto:[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]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/jose
>
> _______________________________________________
> jose mailing list
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/jose
>
>
> _______________________________________________
> jose mailing list
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/jose
>
>
>