On Fri, Oct 25, 2013 at 09:26:21PM -0700, Gregory Maxwell wrote: > ==Where Tor comes in== > > One of the downsides if using x.509 certs to non-repudiate here is > that sites hosted as tor hidden services can't participate. > > It occurred to me that this could be fixed with very little code: > > Take the HS pubkey, pack it into a self-signed x.509 cert with the > cn=pubkeybase32.onion. And specify that .onion certs have a special > hostname validation rule that hashes and encodes the key. > > Then the whole process would work for .onion, we'd have a non-CA > option available and working, etc. > > I'm aware that HS pubkeys have been used for application level > authentication in Tor elsewhere (e.g. I believe torchat does this) so > it's not entirely unprecedented. I'm not aware of anyone packing them > in x.509 certificates. If anyone has, I'd like to use the same > encoding style for greater compatibility. > > The biggest reason I can see not to do this is that it will not be > compatible with future editions of hidden services which aren't based > on RSA keys. (e.g. the EC point addition stuff to protect against > enumeration attacks wouldn't fit into this model). I don't think this > is a serious concern: if HS x.509s do become widely used we could add > a new authentication type for the new onion addresses when those are > introduced. > > Does anyone else see any other reasons not to do this? > > Are there other applications which would benefit from having x.509 > certs for onion names? For defense in depth on the HS side, it's best to run the HS Tor on a different machine, or at least a different VM, than the HS server, so that if the HS server software is owned, the HS private key isn't compromised. The setup you describe would prevent that configuration; consider allowing, in addition to self-signed certs, a certificate chain where the root is a CA certificate matching the HS key in the manner you describe and signing a certificate using a different key for the service to use. As for the migration to elliptic curves, I think the most serious problem you'll encounter is that the curve we end up using may not be one that has a standardized OID or is widely supported in X.509 implementations - e.g., Curve25519. -- Andrea Shepard <andrea@xxxxxxxxxxxxxx> PGP fingerprint (ECC): BDF5 F867 8A52 4E4A BECF DE79 A4FF BC34 F01D D536 PGP fingerprint (RSA): 3611 95A4 0740 ED1B 7EA5 DF7E 4191 13D9 D0CF BDA5
Attachment:
pgpMX1I1MoJMo.pgp
Description: PGP signature
-- tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk