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

[Mike Jones <[e-mail]>]

Fair enough, but I am also very confident that every implementation trying to use a compressed payload where it was expecting an uncompressed one would quickly notice the difference and then do what it takes to get their implementation fixed/updated. ☺

                                                            -- Mike

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

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

I am very confident that every (reasonable) JOSE implementation will notice the “alg” value, ie fail-safe on an unrecognized “alg” value.

> (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.

I have far far less confidence that every (reasonable) JOSE implementation will notice an unexpected field, particularly a known field in an unexpected context.

--
James Manger
                                                                Cheers,
                                                                -- Mike

From: Manger, James H [mailto:[e-mail]]
Sent: Wednesday, December 19, 2012 5:39 PM
To: Mike Jones; [e-mail]<mailto:[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