Hi Les,
ideally, protocol designers should use information in the header to identify a key. The obvious example is the "kid" parameter. That's what it has been designed for. (Over time more parameters have been added.) Sometimes this key identifier is elsewhere, namely * not in the JOSE structure itself (hence implicit), or * in the payload of the JOSE structure itself. 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). 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. 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. 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. Ciao Hannes Am 12.10.2023 um 20:54 schrieb Les Hazlewood:
Hello folks - I hope someone can help answer a quick question: https://datatracker.ietf.org/doc/html/rfc7515#section-5.2 does not make any indication if a Claims payload may be parsed before signature/MAC verification. I am a JOSE library author/maintainer and I've had application developers request the ability to look at information in a Claims payload to help find the key used to verify the signature/MAC. Their concerns are that an Identity Provider may use a key id (kid) in the header that is not guaranteed to be globally unique, and they may need other information in the Claims (e.g. issuer) to help them locate the appropriate key. My response was that there are many other options like jku, jwk thumprints as key ids, x5t, etc, that all mitigate this concern, and I dislike parsing payloads that haven't been cryptographically verified due to potential security issues otherwise. But they said those additional headers are only relevant if if the IdP actually uses those values, and if not, they still might need to look in the claims. What is the JOSE committee's stance on parsing the claims before signature verification? Thank you kindly, Les _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
