Yeah, that makes sense to me. Also, even having a small set of must-understand fields (alg and zip and maybe 1 or 2 others) is very different from having a must-understand-all policy.
Cheers, Dirkjan On Thu, Dec 20, 2012 at 3:12 AM, Mike Jones <[email protected]> wrote: > 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. J > > > > -- Mike > > > > From: Manger, James H [mailto:[email protected]] > Sent: Wednesday, December 19, 2012 6:08 PM > > > To: Mike Jones; [email protected] > 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:[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 > _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
