Re: [jose] Whether implementations must understand all JOSE header fields

[Mike Jones <[e-mail]>]

The prefix for “alg” values would have exactly the same property as adding a new header parameter.  If the new alg value was not understood, the JWS would be useless to the receiver.  (Just as it would be useless if a new header value was used, if not understood.)  I’m not sure why the former is any more usable than the latter.

                                                                Cheers,
                                                                -- Mike

From: Manger, James H [mailto:[e-mail]]
Sent: Wednesday, December 19, 2012 5:39 PM
To: Mike Jones; [e-mail]
Subject: RE: [jose] Whether implementations must understand all JOSE header fields

> “zip” is a perfect example of indicating a change of semantics with the presence of a new field.  The processing of a JWE without a “zip” field is different than the processing of it with one.  An implementation must understand the field to use the resulting JWE.  The same would be true of any JWS that used a “zip” extension.
>
> It would never be safe to ignore this field, whether defined as part of the base spec, or defined as an extension later.

I agree.
When I looked at a handful of publicly available JOSE implementations quite a while ago none enforced the “MUST understand everything” rule — so a zip-for-JWS extension would be dangerous for them. One implementation later added code to enforce the rule using one fixed list of all header fields defined in JW* — so a zip-for-JWS extension would be dangerous for that too.

We know the “MUST understand everything” rule makes it hard to deploy non-critical extensions.
It seems to me that the rule also makes it dangerous to deploy critical extensions.
About the only safe way to define a critical extension will be to define a prefix for “alg” values (eg "alg": "zip;RSA1_5"). I hope that isn’t the most practical option we leave for anyone wanting to extend JOSE.

--
James Manger