On Fri, Mar 9, 2012 at 8:03 PM, Robert Ransom rransom.8774@gmail.com wrote:
Users need to specify a full certificate chain, not just the end-entity certificate.
Agreed that this is desirable, but if we take that route, we need to amend the current rule for deciding whether to use the v3/v2 vs the v1 handshake. Currently, according to tor-spec, a client that sees a certificate chain should assume that it's getting a v1 handshake.
Fortunately, every version of Tor that only allows the v1 handshake is now deprecated.
Have you considered whether to allow the user to store the TLS certificate's private key in a hardware device?
Sounds desirable. I have no idea how to do this from OpenSSL, but there is surely a way.
[...]
The simplest way to get a plausible commonName here would be to do a reverse lookup on our IP and try to find a good hostname. It's not clear whether this would actually work out in practice, or whether we'd just get dynamic-IP-pool hostnames everywhere blocked when they appear in certificates.
What if a bridge's IP address and reverse-DNS hostname change?
I believe in that case we would have to generate a new cert. I have no idea if this reverse-DNS idea is any good. Any better ones?
How does this interact with the v3 link protocol signaling mechanism?
The v3 link protocol signalling mechanism checks for any of the following not being true """ * The certificate is self-signed * Some component other than "commonName" is set in the subject or issuer DN of the certificate. * The commonName of the subject or issuer of the certificate ends with a suffix other than ".net". * The certificate's public key modulus is longer than 1024 bits. """ So I guess we should amend the proposal to say that nobody is allowed to self-generate a self-signed cert for a 1024-bit RSA key whose DN has only only a commonName ending with .net.
How will a bridge's client be told what hostname to specify in its server name indication field?
I was thinking through a torrc configuration values. Any better ideas?