Verify requests to the function service

[chriso]

The SDK can now verify incoming requests that have been signed with an HTTP Message Signature.

When configuring the FastAPI integration, the user can optionally provide a verification_key: Ed25519PublicKey:

import fastapi
import dispatch.fastapi
from dispatch.signature import public_key_from_pem


app = fastapi.FastAPI()

verification_key = public_key_from_pem("""
-----BEGIN PUBLIC KEY-----
MCowBQYDK2VwAyEAJrQLj5P/89iXES9+vFgrIy29clF9CC/oPPsw3c5D0bs=
-----END PUBLIC KEY-----
"""
)

dispatch.fastapi.configure(
    app, public_url="http://example.com", verification_key=verification_key
)

The orchestrator signing requests is expected to generate a SHA-512 Content-Digest header, and then generate an Ed25519 Signature header that uses a key ID of default and that covers at least the following components: ("@method" "@path" "@authority" "content-type" "content-digest").

This fixes #8.

[achille-roussel]

If we expect users to set the signing key in PEM format, we might want to make sure we have a way to encode it from the API we use to retrieve it in https://github.com/stealthrocket/dispatch/pull/100/files#diff-4f35307305b1572f81cf711ef73581ebf371a703d872d99be95499fddc78839fR43

• is there a curl | jq | ??? pipeline to get the key in PEM format?
• do we need to provide a CLI to interact with the API that outputs the key in PEM format?
• do we invest time in developing automatic key retrieval from the SDK?
• should we return the key in PEM format from the API?

That UX is important.

[achille-roussel]

To be clear @chriso, I'm not asking you to have all the answers, just kicking off the discussion :)

[chriso]

We don't require or expect that users specify keys in PEM format; the configure method accepts a Ed25519PublicKey key rather than a string (containing a PEM key); we just provide helpers to parse keys in that format.

If the user has access to the 32 byte public key then they can also do the following:

from dispatch.signature import Ed25519PublicKey

verification_key = Ed25519PublicKey.from_public_bytes(
    b"&\xb4\x0b\x8f\x93\xff\xf3\xd8\x97\x11/~\xbcX+#-\xbdrQ}\x08/\xe8<\xfb0\xdd\xceC\xd1\xbb"
)

I can add a public_key_from_bytes helper that wraps the function above if we want symmetry there? (edit: done)

[chriso]

As for whether we have APIs elsewhere return public keys as bytes or wrapped in a container (like PEM), I prefer the latter:

• ed25519 keys are small enough (32 bytes) that the base64 PEM encoding and header+footer add only a negligible amount of extra bytes
• the container carries not only the key bytes, but also the type of key (ed25519)
• the container has a human readable header (-----BEGIN PUBLIC KEY-----) that makes it clear that it's a public key that does not have to be kept secret

[achille-roussel]

I agree with having users use PEM encoded strings in their code to specify the keys, there's a lot of clarity in that model 👍

What I'm wondering is more how we get them keys in the PEM format; our current protobuf messages use bytes, there's no encoding currently.

[chriso]

Let's have the API return keys in PEM format? The user would never see keys in any other format.

[Pryz]

I'm worried that the PEM format is going to create more frustration for the users. A lot could go wrong when people start using env variables.

Why not just use base64?