honk/docs/security.txt

Some notes about security.

honk is not currently hardened against SSRF, server side request forgery. Be
mindful of what else may be reachable on localhost or the local network if
it's not generally accessible.

Key and signature verification is best effort, but some forgeries may sneak
past. In particular, tying together key name, key owner, actor, object, etc.
is incomplete.

How are user keys supposed to be rotated? Expired? Revoked?

The current answer is never, never, never.

If the key is only used for signing http requests, it can be be changed
basically at will. Change the key in the actor, give it a new name (to avoid
conflict with any cached keys), carry on.

Since keynames in practice don't change, honk will simply discard a key after
a signature failure and attempt to get a fresh key.

Using keys to sign json is more complicated. The current practice is to name
keys with URL fragments. example.com/user#key. If the keyname is changed to
#newkey, how does one fetch the old key to verify existing data?