[jose] "crit" strings don't have to be field names

["Manger, James H" <[e-mail]>]

As we define the "crit" field we don't need to use field names as the critical strings.

Implementations will have a list of critical strings they understand (based on the specs that define those critical strings) and will confirm that all the "crit" values are in their list. This will be a distinct step from the other code that uses specific fields.

For instance, if we defined a simple KDF initially then later specified support for the NIST 800-56A Concat KDF it would be better to define 1 critical string "nist800-56A", instead of listing "PartyUInfo", "PartyVInfo", "SuppPubInfo", and "SuppPriveInfo" fields names in the "crit" field -- any of which might be absent from a particular JOSE message if they had some default value.

Another example: if a group insists on a strong signature verification policy (eg MUST use OCSP, MUST hard-fail if OCSP is unavailable, MUST check Certificate Transparency, and MUST log results for 7 years) there is no new header field to add to a JWS, but it could define the critical string "StrongSig1".
 

--
James Manger

 -------- Original Message --------
> Subject: [jose] Proposed resolution of header criticality issue
> From: Karen O'Donoghue <[e-mail]>
> Date: Tue, March 12, 2013 12:31 am
> To: [e-mail]

>  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
>    }