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.