Questions and suggestions wrt key-management.md
Hi @gabi-250 !
I've read over key-management.md and have a few ideas, questions, and suggestions. Please feel free to defer these or to handle them whenever you get to the corresponding parts of code; none of them is urgent.
Maybe we should rename KeyIdentity, HsClientIdentity, etc.
The Tor protocol has the notion of an "identity key"–a key that uniquely identifies a relay, an onion service, or a a directory authority. With that in mind, I think having a "key identity" could get confusing. Possible alternatives: "KeyLocator", "KeySpecifier", "KeyName", "HsClientName", "HsClientAcct", ...
Possibly we should version ArtiKeyStore.
Maybe we should have a top-level file in the arti keystore hierarchy to indicate "this is an arti keystore" and to apply a version number to it. That way, if we wanted to, we could make changes in the design in the future.
What does a C keystore look like for onion services?
In C Tor, most keys are kept in ${DATADIR}/keys. But the keys for each onion are kept in a separate directory configured for each onion service. How would we migrate these to arti, if arti expects that a c-tor keystore will be configured in a single location?
How should we store metadata?
In several cases we need to store extra data associated with a given key, and keep that data in sync. Types of data include:
- An expiration date or a time range
- A certificate
One challenge here is keeping such data in sync with the key itself, if we're allowing concurrent access.
Are paths relative to the store root?
I think that ArtiPath and CTorPath are relative paths, with respect to the root of the keystore, containing no ".." elements. If that's right, great.
Features to avoid key misuses.
The C Tor key format (or one of them, at least) encodes the usage of the key in the file itself. Thus, you can't (for example) store a new relay ed25519 identity key without knowing that it is a relay identity key (and not, say, an onion service identity key).
The goal of this design was to prevent key misuse: it makes it a little harder for somebody to accidentally use a key file in a location of the wrong type. (I do not know how often it has prevented this type of error:, but in the past, we have found that power users can sometimes create extremely confusing shufflings of their keys, under the theory that it "ought to work".)
But having keys tagged this way creates two questions:
- Are C keystores read-write, or read-only? If they are read-write, then when we're telling a C keystore to store something, we need to encode its intended usage, not only its KeyType.
Personally, I'm okay with making C keystores read-only, or even making it so that the only thing you can use a C keystore for is to copy all of its keys to arti.
- Should we try to build a similar feature for Arti?
This would be hard to do with our chosen ssh-style key format, since we want Arti to be able to consume keys generated with e.g. ssh-keygen, and since there is nowhere good to store extra information except in the "comment" field.
One possibility would be to put this information in the comment field anyway, and to warn (but not reject the key) if we see that a comment field indicates that a key has the wrong usage. For example, we could create a relay identity key with the comment "Arti: Relay Ed255519 Identity Key" and an ntor onion key with the comment "Arti: ntor onion key (Expires 2023-07-01)". If we see a relay identity key with the comment "" or the comment "key for my relay", then we allow it silently. But if we see a relay identity key with the comment "Arti: ntor onion key" we could warn the user.
I don't know whether this feature is worthwhile or not.