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 <ve7jtb@ve7jtb.com> wrote:

>
> On 2013-03-11, at 10:48 PM, "Manger, James H" <
> James.H.Manger@team.telstra.com> 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:* jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] *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 <odonoghue@isoc.org>
> 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
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose****
> ** **
> _______________________________________________
> 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
>
>