“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.
-- Mike
P.S. On a related topic, see the thread “Reducing the size of JWS payloads”
for a discussion on why compression won’t work for JWS payloads that are JWEs.
From: Manger, James H [mailto:[email protected]]
Sent: Tuesday, December 18, 2012 9:12 PM
To: Mike Jones; [email protected]
Subject: RE: [jose] Whether implementations must understand all JOSE header
fields
James said:
>> I would also appreciate your thoughts on whether someone can extend JWS by
>> specifying: when the “zip” field is present in a JWS the content is
>> compressed.
That looks legitimate with the current “MUST understand or reject” rule. I
think it is likely, however, that such an extension will cause security
problems. Some implementations will confirm that “zip” is on the list of known
standard fields, but will ignore it in the JWS processing code.
Mike said:
> One would define “zip” in a JWS in the normal way that extensions are made to
> IETF specs – you’d write a spec defining the meaning for it and register the
> “zip” value in the IANA JSON Web Signature and Encryption Header Parameters
> registry for JWS usage.
Lets ignore the process for now (IETF, IANA…), the issue is whether this style
of extension is sensible: an extension that indicates a change of semantics by
the presence of a new field. A style that the “MUST understand everything” rule
encourages.
My argument is that this style is too dangerous a way to indicate new
semantics. When changing semantics (as “zip” does) it would be much better to
change a field we are confident implementations will be looking at, as opposed
to relying on them to notice a new field.
--
James Manger
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
