1
 2Some notes about security.
 3
 4honk is not currently hardened against SSRF, server side request forgery. Be
 5mindful of what else may be reachable on localhost or the local network if
 6it's not generally accessible.
 7
 8Key and signature verification is best effort, but some forgeries may sneak
 9past. In particular, tying together key name, key owner, actor, object, etc.
10is incomplete.
11
12How are user keys supposed to be rotated? Expired? Revoked?
13
14The current answer is never, never, never.
15
16If the key is only used for signing http requests, it can be be changed
17basically at will. Change the key in the actor, give it a new name (to avoid
18conflict with any cached keys), carry on.
19
20Since keynames in practice don't change, honk will simply discard a key after
21a signature failure and attempt to get a fresh key.
22
23Using keys to sign json is more complicated. The current practice is to name
24keys with URL fragments. example.com/user#key. If the keyname is changed to
25#newkey, how does one fetch the old key to verify existing data?