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?

Improve this question

1 Answer 1

Reset to default
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
13
  • 1
    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
    Commented Mar 22, 2018 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
    Commented Mar 22, 2018 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
    Commented Mar 22, 2018 at 10:01
  • 1
    From what I know, JWS is composed of <header>.<payload>.<signature> . <signature> is private_key(<header>.<payload>) . I could change the header and use my own private key to generate signature, then send <modified header>.<modified payload>.<modified signature> to X. Then if X use the public key listed in <modified header> to verify, he'll take it as valid. Am I missing something here?
    – whuala
    Commented Mar 22, 2018 at 10:31
  • 3
    @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
    Commented Mar 22, 2018 at 14:52

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .