Re: [jose] Proposed resolution of header criticality issue

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