Re: [jose] Field Matrix

[Mike Jones <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On Behalf Of Richard Barnes
Sent: Thursday, June 20, 2013 1:52 PM
To: Jim Schaad
Cc: [e-mail]
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 <[e-mail]<mailto:[e-mail]>> 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