> 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:[email protected]]
Sent: Wednesday, December 19, 2012 5:39 PM
To: Mike Jones; [email protected]<mailto:[email protected]>
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
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
