0

I want to sign webhooks from my web service with a JSON Web Signature (part of JWT standard), ideally using asymmetric keys (so, using RSA or elliptic curve cryptography).

What is the recommended or standard way to publish my public key? Is there a standard place to host a public key? Should it rely on a CA? Ultimately, I'm trying to find the most "standard" way of signing webhooks with asymmetric keys.

1

Just post it on your website.

For most web services, your website is your identity. If you publish your public key on your website, anyone who visits it with a secure HTTPS connection can be reasonably sure that it belongs to you. If you publish it by any other means, you would need some way to connect it to your website to assure users that it is legitimate.

  • And you can offer JWK and/or X509. This also allows to have a endpoint where you can get a new key if reissued/needed (if cached Version does not match any longer or expires) – eckes Mar 28 at 2:38
-1

What is the recommended or standard way to publish my public key? Is there a standard place to host a public key?

The best way to distribute a public key is via a (PGP) keyserver. Here are a two well known ones: Ubuntu, MIT. You can also publish it to multiple servers to make it easier for your clients to find it.

Note that this only takes care of the distribution. You will still need to deal with how users will trust this key. Most likely, you will need to publish the fingerprint of the PGP key on your website. At which point it might be preferable to publish your public key directly.

Should it rely on a CA?

This is not a requirement. Although you can get a certificate and distribute it to the parties, who will be called with your webhook, this will still require your users to implement custom validation logic as this is not a standard. This will take care of the trust issue, assuming the CA is trusted by your users.

Ultimately, I'm trying to find the most "standard" way of signing webhooks with asymmetric keys.

I am not aware of any standard. I think the closest that gets to this is the following flow.

  1. Someone registers to your services and sets up a webhook
  2. You give them a public key somehow (keyserver, direct publishing) which they can use to validate calls coming from you
  3. When you trigger the webhook, you sign it with the corresponding private key
  4. The receiving ends verify your webhook with the pre-shared public key

Without a standard, you can't work around the fact that your clients will need to implement custom logic. You could give them a library which does the key lookup and the validation.

  • How does using a keyserver help? Why would you even want to, given that it's not a PGP key? – AndrolGenhald Mar 26 at 16:37
  • I agree keyservers are only an option if it is a PGP key. I was thinking about creating such a key, publishing it and using its private part during JWT signing. Then, anyone who would like to verify the integrity of the JWT could fetch the corresponding PGP public key from a keyserver. I know of no better way to publish a public key for easy retrieval. Is there a flaw in my thinking? – Daniel Szpisjak Mar 27 at 20:38
  • PGP keyservers rely on the web of trust, if the users don't trust anyone who has signed the key there is no reason for them to trust that it's legitimate. I could upload my own key using OP's email, and you'd have no easy way to tell which one is legitimate. – AndrolGenhald Mar 27 at 21:20
  • Yes, that's true, I wasn't considering the trust part of the question, only the distribution. I guess it becomes a personal preference at this point. Either publish it on your site directly or distribute it via keyservers and state the fingerprint on your website. I'll edit my answer to highlight this point. – Daniel Szpisjak Mar 27 at 21:37

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.