==Background== (you can skip to the Tor section if you don't care) The Bitcoin universe is in the process of creating a specification for digital invoices called "the bitcoin payment protocol". (More info: https://bitcointalk.org/index.php?topic=300809.msg3225143#msg3225143) The payment protocol allows someone to request someone else pay Bitcoin for specific things, instructing them to pay specific amounts in specific ways, and allows the receiver to provide things like instructions for sending a refund if the transaction is for some reason aborted... all sorts of extra metadata which doesn't belong in the public Bitcoin network for scalability and privacy reasons. One of the things these invoices have is an optional signing mechanism for authentication and non-repudiation. Normally these requests would be sent over an authenticated and encrypted channel which provides confidentiality and authentication, but not non-repudiation. The non-repudiation will provide cryptographic evidence to the participants which can be used to resolve disputes: e.g. "He didn't send me my alpaca socks!" "Thats not the address I told you to pay!" "He told me he'd send my 99 red-balloons, not just one!" "No way, that was the price for 1 red-balloon!" The payment protocol is extensible and may someday commonly support many kinds of signatures, but the initial implementations only support signing with internal x.509 certificates and verifying those certificates with standard CAs. As _horrible_ as this is, it's better than nothing, and the primary users asking for this functionality have SSL websites today. We don't believe that any other PKI mechenism is actually functional enough to be usable (e.g. as evidenced by the fact that downloads of our GPG signatures, is on the order of 1% of the downloads of the Bitcoin software; and probably only a small portion of those users have actually done anything to verify the signing keys) today, so other options haven't been a priority. However, the need to use the known insecure CA infrastructure for this (optional!) feature has seriously spazzed out some people. A lot of this is pure confusion, e.g. people thinking that all payment requests would have to go via the CA (no kidding!), but its surprisingly hard to convince people who are responding emotionally of the subtle tradeoffs involved especially when they have the luxury of saying "it's your problem to go figure out, figure it out and go write a bunch extra of software for me". So having some alternative on day one would be useful in helping the more conspiracy minded understand that this isn't some effort to cram the use of CAs down their throat. ==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? -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk