On Wed, Jul 25, 2012 at 7:11 PM, Manger, James H < [email protected]> wrote:
> >> I’ll add another argument for removing the “MUST understand everything” > requirement. > > > The requirement of understanding everything is only about the layer that > performs signature validation, clearly. > > > > The header is supposed to be metadata for validation only. Putting > non-validation metadata in the header is a bad idea. They payload is > arbitrary -- apps can customize it at will to specify app-level metadata > semantics there. > > > So are you suggesting we disallow metadata about the content (category 4 > in my list) from the header? For instance, we should drop the "typ" > parameter (just keeping an indication of whether there is another layer of > JOSE processing inside, or perhaps not even that)? > I am suggesting that any metadata without security implications should not be in the header, and if it is in the header, then the validator must fail because it has implications for security that it doesn't understand. And yes, metadata about the contents does not belong in the JWT header. > > > >> JOSE currently uses one bucket (the header JSON object) for different > categories of info: > >> 1. Structure of the JOSE message (eg indicate whether the 2nd > dot-separated segment is plain text, an encrypted key, etc) > >> 2. Algorithm details (eg name, IV, etc) > >> 3. Hints about keys (eg URI to get key if you don’t have it; > revocation status, etc) > >> 4. Metadata about the content (eg content-type, last modified > date, etc) > >> > >> Even if it is important for security that, say, some structural info is > not ignored that doesn’t mean the same importance applies to the other > categories of info. > >> > >> Different categories of info will be handled by quite different code. > For instance, a JOSE library is unlikely to care at all about the content > metadata; only the decryption code cares about the IV; etc. To enforce a > “MUST understand everything” requirement all these different pieces of code > from different layers in a software stack (eg app vs library) will need to > cooperate. That cooperation will require more complex APIs between layers > (eg library returns “content”, “headers”, and “list of headers the app MUST > understand because the library ignored them (assuming they are content > metadata)”). > > -- > James Manger > -- --Breno
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
