On Mon, Aug 10, 2020 at 09:00:32AM -0400, Nick Mathewson wrote:
On Wed, Jul 29, 2020 at 1:15 AM Matthew Finkel sysrqb@torproject.org wrote:
Hello everyone,
Hi, Matt!
There's a part of this that I'm still trying to figure out:
The safest usage of the long-term keys for alternative purposes I see appears to be by deriving a (fixed/deterministic) blinded key pair using the same scheme that Tor uses, and signing/verification simply follow the same process as Tor, except the derived keys need not rotate periodically (is this true?). The derived key should be used for certifying a freshly generated ed25519 key, which is used in the application protocol. For example, if I want to use a key for code signing such that it is bound to my onion service key, then I could derive a certifying key by following Tor's derivation scheme, by substituting:
BLIND_STRING = "Derive temporary signing key" | INT_1(0) N = "key-blind" | INT_8(period-number) | INT_8(period_length)
with
BLIND_STRING = "Derive code signing key" | INT_1(0) N = "code-sigining-key-blind" | "v0" | "YYYY-MM-DD" | INT_8(validity_period)
In the case of v3 onion services, 'period-number' comes from the current time, and 'period-length' comes from the consensus, so it's easy for the client to know what parameters to use when deriving the key.
But how is the party that relies on the derived key supposed to know what values were used for "YYYY-MM-DD" and "validity period" in this case? It seems like those two values would need to be shipped along with the key, which could make for logistical issues.
I was imagining "just serialize it in the public key". The public key would grow by a few more characters, but not too much. In this case, we'd probably want a defined (extensible) structure for the public key rather than each application defining their own arbitrary format, but I didn't get that far in thinking about it.