4

I don't get what header parameters like jku, kid, x5u are for in JSON Web Signature (JWS).

Since We have to verify the integrity of the content against secret key/public key, is it safe to leave jku, kid, x5u in the JWS header? Someone may replace these sections by their own and sign a new signature with his key against the tampered content. So how do we deal with such case?

3

These fields are here to allow the component verifying the ticket to identify the key used for the signature.

  • jku is an URI that reference the public key used for generating the signature. It must follow RFC7517 format. The entity verifying the token is responsible for checking whether that signing key can be trusted or not.
  • kid is the key identification and it's only valid in the context of a given audience: the context of your application must define how to use that parameter to identify the key. It can be the fingerpring of the x509 cert user for signing, it can be the certificat serial number, it can be a reference to a row in a table, it can be the ID of a HMAC secret stored into a JSON file, or the XPath inside a XML document, whatever is defined by the signing party.
  • x5u must contain an URL to the x509 certificate that was used for signing the token. That certificate must be in PEM format.

Typically, you will only have one of these parameters in any given token (there can only be one signing key, after all) although it isn't impossible to have the same key accessible through different methods (this mostly means that it's not impossible to have both a jku and a x5u header that point to the same key but you should try to avoid that kind of ambiguity).

By definition, if someone changes the headers and signs the ticket again, the result is not the same token so you don't need to worry about that: you can safely reject any token that you can't properly validate.

| improve this answer | |
  • In this case: X signs a signature for content Z with private key, Y receives the content and verify it with public key. If the signature and the public key clue inside JWS header both get changed, how could Y validate it and reject? – whuala Mar 22 '18 at 9:17
  • Y doesn't care where the headers comes from: it must read the headers and see if it can use them for validating the signature. if it cannot (because it doesn't understand the parameters), it must reject the token. if it can but the signature doesn't match (because a different key was used for signing) it must reject the token. Otherwise, it must accept it. – Stephane Mar 22 '18 at 9:58
  • I think you're misunderstanding something fundamental: a token is immutable. You can't slice it into parts and rebuild it. If you do, it is a different token and you must sign it again. – Stephane Mar 22 '18 at 10:01
  • Are you, by any chance, trying to use the JWT headers to carry information that isn't actually related to the token itself? Know that you're not allowed to do that: anything that isn't directly related to the token itself must be in the body. – Stephane Mar 22 '18 at 10:02
  • 2
    @whuala I think you missed when Stephane said in his answer: The entity verifying the token is responsible for checking whether that signing key can be trusted or not. See also tools.ietf.org/html/rfc7515#section-10.3 – AndrolGenhald Mar 22 '18 at 14:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.