There was a working group decision at the Denver meeting that "crit" must be
integrity protected. The reason for this is straightforward.
If not integrity protected, an attacker could strip the "crit" field, defeating
the semantic requirement that implementations must reject the input if a "crit"
value is used that is not understood. Thus, the spec requires that this field
be integrity protected whenever used.
-- Mike
From: [email protected] [mailto:[email protected]] On Behalf Of Richard
Barnes
Sent: Thursday, June 20, 2013 1:52 PM
To: Jim Schaad
Cc: [email protected]
Subject: Re: [jose] Field Matrix
You can eliminate the "protection required" field, because there aren't any of
those.
Or there shouldn't be: The only security case we have is algorithm dependent
("alg" must be protected if "alg" == "PS256", "PS512"). The only fields for
which the specs currently require integrity protection are "zip" and "crit".
Neither of these have the property that changing them would cause a security
violation, except in some application-dependent sense. So the choice of
integrity protection should be left to applications, not fixed in the spec.
--Richard
On Thu, Jun 20, 2013 at 2:54 PM, Jim Schaad
<[email protected]<mailto:[email protected]>> wrote:
<no hat>
Having just started looking at a design implementation, I am now more than ever
interested in seeing this matrix of fields. At the present time I think the
following columns are probably of interest:
Name, must understand, use required, common vs specific, protection required
I was just looking at the alg and enc fields for JWE and realized that one was
specific - so it should be one location - and one was common - so it should be
in a different location. And then I needed to start thinking about where it
goes in terms of compacted vs one recipient vs two recipients.
Do you have an idea of when this matrix might show up?
Jim
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
