On 2020/07/29 05:15, Matthew Finkel wrote:
[ ... snip ... ]
A signature must include "v0" and the values used in "YYYY-MM-DD" and INT_8(validity_period), such that the client can derive the correct blinded public key for verification when starting from the long-term identity key. The signature should be over a certification of an independently generated ed25519 key pair. This new key pair (along with the certification) can be used for providing message integrity within the application's protocol. If, instead, the derived key is used directly for signing, and the application needs the keys online for signing messages, then this risks the security of the long-term key, as well. The blinding scheme allows for (partially) recovering the long-term secret key from the derived secret key.
This is super useful, Matt! Thanks for writing all of this down.
Another example use case comes from Jeremy Rand where the onion service key is used in a root CA certificate, and a leaf certificate (signed by the CA cert) is used by the application.
This idea stemmed from a conversation between David, George, and me a little while after the Stockholm meeting last summer. The implementation of the tool for generating the various x509 files (the x509 CA and the signed x509 certificates) is available from
https://gitlab.torproject.org/ahf/onion-x509
For people who are unaware of what this tool is doing, I can flesh it out here:
Tor uses an ed25519 secret key format that is incompatible with the ed25519 secret key encoding found in x509, and we cannot just convert the .onion identity ed25519 key to a PEM file and make, for example, a web server use it directly. This also seems to be what Matt is recommending against. As seen in Matt's [0], the signatures and public keys are all using the same encoding, however.
In ordinary TLS, where the server sends the certificate chain, we don't keep ANY of our CA's secret keys online (since we hopefully don't have access to them under normal circumstances). Thus, we only need the secret and public key of our leaf certificate to be available for our TLS service to do signatures as part of the TLS protocol. We can therefore generate an "Onion CA" from Tor's .onion identity secret key, but never have to move any secret key with it into our TLS service deployments.
Once we have generated this "Onion CA", which is identified by the onion identity public key, we use the onion-x509 tool to issue leaf certificates that are signed by the "Onion CA." By configuring our TLS service to use the Onion CA and our ed25519 leaf key pair, and its x509 certificate (signed by the Onion CA), the client will be able to verify if the certificate is "valid" just based on the Onion address itself.
I think the stateless nature of this system is pretty cool. I don't believe that moving to blinded keys blocks anything for it to work, which means I think Jeremy and I should probably coordinate to do that instead of the direct use of the onion identity key pair as the tool does today.
Of course, the modifications to the browser are the terrifying part of all of this as such changes touch some scary code paths in how TLS certificates are validated. Still, if this can work, it would make x509 certificates very easily accessible for Onion service operators.
If Jeremy gets the demo to work in Tor Browser and it all looks promising, we should also spend a bit of time rewriting the Go tool to C and bundle it with the Tor codebase.
Following from the previous example, (most likely) the CA certificate should not be signed directly using the onion service's long-term secret key. However, a derived key could be used in the CA certificate and the leaf cert could contain an ephemeral key (in exactly the same way that tor certifies ephemeral keys using the derived blinded signing key). This idea appears to be a concrete design of how the above (abstract) key certification could be implemented, and it could be a format that tor natively supports.
From what I can tell, it should be possible for us to update the
onion-x509 tool to use the blinded key instead.
Exciting stuff!
All the best, Alex.