>> 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)? >> 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 _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
