Hi Hannes, Placing the key identification information in the payload structure > itself is, as you say in your email, a bit annoying. I would call it a > flawed design (from a layering point of view). >
As would I. If you can't do it with a JWE, you shouldn't be able to do it with a JWS either IMO. Ensuring key lookup is identical between the two types affords implementation consistency, and consistent expectations on issuers and receivers. > If we are only talking about information for identifying a key then I > don't see a security problem. If we are, however, talking about making > generic decisions without prior verification of the MAC/signature then > there is obviously a huge problem. > That one can't know how it could be abused is exactly the problem. If the RFC was clear on this, even using 'SHOULD' or 'SHOULD NOT' (as opposed to 'MUST'), that would go a long way IMO. Although 'MUST' would be much better, requiring JWT issuers to be safer, whether that's using jku/x5u or xt5 or jwk thumbprints as kids, or repeating only required lookup information in the header, etc. For example: "Parameters used for key identification, lookup or retrieval MUST be contained entirely within the JWS Header. If claims are required for key retrieval, they MUST be repeated in the JWS Header. Implementations MUST NOT inspect the JWS Payload to obtain JWS signature verification keys". The problem for you as a library developer is that you do not know what > information in the payload is used to identify the key vs. used for > generic decision making. How to you design an library that ensures that > developers do not make mistakes? You don't need to be a visionary to see > how developers will introduce security bugs. > Exactly the problem. By verifying the signature first and _then_ inspecting the claims for generic decision making, you avoid an entire class of problems. I'm rather surprised the working group didn't make this mandatory in the RFC. > From the working group point of view I think we have to write a Best > Current Practice guide on what designs to avoid when designing protocols > with JOSE (and COSE) and the use of key identification information > inside the payload of a JOSE structure would be one of the items to > avoid. In OAuth we have an RFC that provides guidance for JWTs (see > https://datatracker.ietf.org/doc/rfc8725/) but this document would be > more generic. It's funny that you brought up RFC 8725. I was diving into it (again) before I noticed your reply and I was looking for anything that addressed this issue, but alas, it did not. My hope is that the working group would be willing to add it. Is there anything I can do to contribute to such an effort? I don't mind at all doing the work necessary as required by any formal working group process. Thoughts? Thank you, and kind regards, Les
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
