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:[email protected]]
Sent: Wednesday, December 19, 2012 5:39 PM
To: Mike Jones; [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
