==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
On 2013-10-26 14:26, Gregory Maxwell wrote:
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 non-repudiation will provide cryptographic evidence to the participants which can be used to resolve disputes: e.g.
[...]
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.
CAs do not work very well, because no one knows or trusts the CA, the CA does not know anyone, and it is a lot jumping through hoops to persuade the CA to trust anyone. As a result, any procedure that has the step "First the end user gets a certificate from the CA and installs that certificate" never flies. It is just too much of a pain in the ass. This is not matter of people fearing vast powerful quasi governmental conspiracies. (Though in view of recent leaks, you should fear vast powerful quasi governmental conspiracies) The problem is that the CA model itself does not work. The problem is not that they are in bed with your enemies, though they probably are. The problem is that they are not in bed with you.
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
x.509 is evil. x.509 is designed for universe ruled by a single state, that state the fount of all trust, all nyms, and all relationships. Reality, however, is that relationships and trust are predominantly peer to peer, thus anything touched by x.509 somehow always develops an absolutely horrid user interface. When we apply x.509 to a universe far more anarchic than it was designed for, bad things happen to the UI. What your proposed system intends to provide is reputational information. You need some entity, a server, likely a tor hidden service, to curate reputational information, and charge a fee for doing so: You are competing with ebay, whose main asset is their large collection of other people's reputational information. Let us call such entities, entities that collect and curate reputational information, reputational servers, ebay being the big example of a reputational server. You would like to be able to transport reputational information, so that it is public domain, not the private property of a given reputation server. So you don't want reputational information to be information about joe@ebay.com, though of course you should present it that way, rather than displaying public key information directly in the UI (employ Zooko's triangle, and never throw 256 bit random numbers in the end user's face) So, has to be the reputation of the owner of a bitcoin wallet, not the reputation of the owner of x.509 certificate.
On Sun, Oct 27, 2013 at 7:59 PM, James A. Donald <jamesd@echeque.com> wrote:
Let us call such entities, entities that collect and curate reputational information, reputational servers, ebay being the big example of a reputational server.
So long as you don't label scores as 1=bad up through 5=good. Sites that do that are false... it causes artificial inflation because anything less than 5 is viewed as an affront or subpar, and there is no higher than a 5. It should be labeled 1=shitty 3=truly_avg 5=amazing.
x.509 is intended to associate a non human readable public key with a human readable globally unique user name. You hope to associate a reputation with that globally unique user name. x.509 does not actually work, as the phishers routinely demonstrate. People are used to logging into their bank, and getting slung from one certificate to the next, none of the certificates having much resemblance to the name of their bank. Further, the process of getting and installing an x.509 public key is too horrid for the ordinary end user to deal with. Use zooko's triangle. Associate reputation with a public key, and present to the user not the public key, but the account of the owner of that public key on the reputation server that curates the reputational information.
participants (3)
-
grarpamp -
Gregory Maxwell -
James A. Donald