Key Identification guidance

[yaronf]

Now that we're reopening the JWT BCP, should we include the guidance on key identification from Hannes' draft, https://datatracker.ietf.org/doc/draft-tschofenig-jose-cose-guidance/ ?

The target audience for the drafts may be different though, with the JWT BCP targeting library authors and the "guidance" draft aimed at application writers.

[selfissued]

It would be fine to describe how the kid header parameter should be used to perform key identification.

@hannestschofenig warns against key identification information in the payload of a JWT but doesn't give any examples of when and why this is done. I'd like to understand the nature of the problem before talking about solutions.

That said, it's normal to use claims from the payload - in particular, the iss claim - in the procedure to retrieve the keys. For instance, Obtaining OpenID Provider Configuration Information requires appending .well-known/openid-configuration to the iss claim value in an ID Token as part of the process of retrieving the signing keys. This is a feature - not a bug - as it guarantees that the keys belong to the issuer.

Our target audience should be all kinds of developers - both library and application developers.

[hannestschofenig]

The point of the draft was the following:

You need to give the recipient some means to identify the key it has to use for verification. This is information that needs to be either explit in the JWT (or in a COSE structure in general) or implicit (typically through some other layer outside).

Once you have this information you do not need other information anymore, such as algorithm identifiers, since the recipient needs to also know (in addition to the key identifier) what algorithm to use. If the recipient does not already possess this information then there is a risk that an attacker modifies information, such as the algorithm.

[selfissued]

@hannestschofenig, I'm still not sure what attack you're describing or how it should be mitigated.

For instance, when the "alg" value is a protected header parameter, the attacker can't modify it. This is true both for signed JWTs and encrypted JWTs using an AEAD algorithm. The only case where it's not true is "alg": "none", which RFC 8725 already discusses.

[yaronf]

That said, it's normal to use claims from the payload - in particular, the iss claim - in the procedure to retrieve the keys. For instance, Obtaining OpenID Provider Configuration Information requires appending .well-known/openid-configuration to the iss claim value in an ID Token as part of the process of retrieving the signing keys. This is a feature - not a bug - as it guarantees that the keys belong to the issuer.

I disagree. IMHO this is a bug: the original JOSE architecture only requires the recipient to parse the smaller/simpler header in order to validate the whole JWS.

The OIDC solution means the recipient should go through hoops instead:

• Parse an untrusted JWS (which may try to exploit JSON parsing vulnerabilities) to obtain iss.
• Use that value to access an untrusted URL to read a public key.
• Verify the JWS.
• If this fails, make sure to throw away the already parsed JWS, whose claims may already be cached somewhere.

CVE-2025-30144 is a related vulnerability.

[selfissued]

the original JOSE architecture only requires the recipient to parse the smaller/simpler header in order to validate the whole JWS.

That's not a complete description of the situation. JWS does not define a way to know the keys or validate control of them. Nor does JWT. OpenID Connect ID Tokens do, for example.

JWT does define claims used to validate control of the keys - especially "iss". That's not a bug - it's a super-useful and widely used feature.

Parse an untrusted JWS (which may try to exploit JSON parsing vulnerabilities) to obtain iss.

All JWTs are untrusted until their integrity and issuer have been validated. Nothing new.

If you can't parse bytes that purport to be JSON without exercising JSON parsing vulnerabilities in your code, you have bigger problems than those related to JWTs.

Use that value to access an untrusted URL to read a public key.

That the URL trustworthy is confirmed by validating the signature using a key obtained. If the signature doesn't validate using a key obtained by the issuer, the JWT is rejected, along with any content retrieved from the URL.

If this fails, make sure to throw away the already parsed JWS, whose claims may already be cached somewhere.

If you cache claims from a rejected JWT, that's simply a code bug.

[selfissued]

To address this issue, we need to identify the attacks we will describe in the text and how we're mitigating them. @hannestschofenig?

Unless we identify attacks and mitigations, we should close this issue with no action.