Topic: Bitcoin Invoice Signatures (Read 893 times)

CA are central, PGP isn't central. I can give you my public key and you can verify my messages. So how do you trust a CA who says this is the key you need? You are trusting the CA, which can and most have been hacked. PGP public keys can't be hacked, they can be falsified  but there is ways around that.

Please read about PKI's which is the infrastructure that CA's use and how that is broken. Currently PGP is the best and only trustless system.

LOL, no doubt.  And while there have been instances of CAs behaving badly, SSL is still used and generally trusted for transactions and communications of low to moderate importance.

For example: you're using it right now.

Hrm. I would have answered, "how do I know a man in the middle didn't give me their public key instead?" But the same weakness exists with CAs. How do I know a man in the middle didn't add their key as a CA when I downloaded my browser?

It's tricky.

...I wonder if people still use Namecoin.

If you're going to make a user-friendliness argument, the real issue isn't interface, or what signature scheme you're using or whatever. The real issue is: how do you know that Wells Fargo's key is Wells Fargo's key? Or that a particular key identifies George (of George's Baklava), for that matter?

The cert-signed-by-CA approach makes that easy: some CAs are considered to be trustworthy, so if they tell you the key is good, it's good. Of course, if you can't trust the CAs, the system doesn't work.

But PGP doesn't provide an answer here at all. On the contrary, it says "go find someone you trust and see if they believe it". How on Earth do you propose to make that process "user friendly"?

The people on this forum are all of the people you know?  Stop strawmanning and think of all the people you know, your parents, your dentist, the grocery checkout clerk.  How many of them have heard of PGP or can describe its proper use?  But they know the "little lock thing" on the browser means things are at least trying to be secure, and commerce may proceed.  Would I use this for transactions valued in the BTC equivalent of millions of dollars?  Probably not-- that sort of thing requires a stronger trust model than SSL achieves.

PGP might be a more "correct" way to approach this, but I'm looking for something that will work right now in the real world, and have real benefits even if it ain't perfect.  If implemented, this will improve the trust and security of almost every Bitcoin merchant transaction.  And for bonus points, it's trivially easy to implement.

I was a huge fan of PGP ten or so years ago, to the point where I gave a presentation on the subject to a local ColdFusion (the programming language) user group meeting.  I sill do conference sessions from time to time about how public key encryption, SSL, and PGP work.  People are always startled to discover that the top of the SSL trust layer isn't at the CA layer, it's the browser manufacturers, who choose which CAs to include.

Unfortunately, my attempts to get my circle of nerd friends to embrace PGP fizzled every time.  Today I see it used pretty much daily for encryption during B2B document exchange, but key signing is nonexistent and the public key exchange is done in a depressingly insecure way.

That being said, it'd be fairly easy to optionally replace "sigdomain" with "sigkey" (or perhaps "sigpgp") and attach a key ID (or perhaps fingerprint, but I'm trying to keep it short) and PGP sig hash instead.  But I'm trying to get an idea off the ground that could work with the whole world today.

For all of the complaints about SSL, and I'll be the first to agree that many are valid, it's still way better than nothing.  And it's time to do better than nothing.

Yeah, use GPG for now.  The payment protocol will eventually take this function over for people that don't use GPG.

> PGP is a better solution, and can be made sure that a company/person generated the address.

I like PGP as well as the next person, but the SSL trust network is far better established than PGP's, and either of them can verify that a company/person generated the address.

PGP might be a better solution *in theory*, but in practice SSL is actually used by ~100% of people on the Internet.  What percentage of all of the people you know have actually signed or encrypted a message using PGP?

One problem I see with Bitcoin URIs is that it's impossible, as a customer, to prove ex-post-facto that you made a payment (a) to a specific entity or (b) for a specific purpose.  While you may trust that a Bitcoin address/URI belongs to a vendor based on the fact it was presented via SSL on that vendor's page, once you've made payment you have no mechanism to prove that (a) you saw that URI on the vendor's page, (b) you made payment for any specific purpose, or (c) you paid the amount in full.  In short, there's nothing to enforce non-repudiation of a vendor's Bitcoin URI invoice once payment is made.  In other words, it's easy to create an invoice, but how can a customer show a receipt that's provably from the invoice?

It occurs to me that we already have infrastructure in place to address this-- SSL.  (SSL ain't perfect, but it's way better than nothing.)

Since the URI for a Bitcoin payment (BIP 0021) is intended to be extended, I propose this:

The vendor MAY append two (or three*) fields to the end of a URI: "sigdomain", and "sig".  "sigdomain" indicates the DNS name where the SSL public key can be retrieved that verifies the signature of the transaction, and "sig" is the Base-64 encoded SHA1RSA signature of the URI up to and including the "=" sign after "sig".  ("sig" MUST be the last field of the URI.)  If "sig" is used, then "sigdomain" MUST also be included.

Example:

bitcoin:1NYTSZeZ6axJhnR41AfxxB4ks5fEgkjDQ8?sigdomain=darylb.net&sig=b9FUOZOmvlIYAMD6FH4mTw9fipCLi8WSnN9laSg%2BlRagU5EwHe9VFN0NlX1B%2FKKNtcKlbqBel1C4WOh9bH2uibg5eNKBwDXUWenLk%2BT3i5G5iUn0uG5SNtz69zOYAloFRn5E8CAFXElqoBFj24XcU6tgRJuFv7EwFMGiNhenaauHaohB8sYr8HNKqoeLC5zMbG9sB%2FCy%2F8N3Vj7QSFYh4bQt4W%2FJI%2Fai8Fq4E7U%2FEUHR%2BHINb%2FX%2FSwUxXMva6LuDRQq%2FzhhNUFmbtd1ahne%2FF%2FADm8UQMM1LPj%2FZMtbpE6EUEW5%2BVkFYiaK2tOIBauQb%2FbrstOcIkxZgS7VdC3%2BQgw%3D%3D

Or:

This address has been signed using the private key corresponding to the public key that's available by connecting to "https://darylb.net".  The client SHOULD store the public key cert along with the invoice, so that signature verification is replayable even if the server's key is replaced.

Granted, this makes for a rather dense QR code, but with a 4.2k hard limit for alphanumeric QR codes, it's not approaching the maximum.

Clients unaware of Bitcoin Invoice Signatures (BIS) will simply ignore the added data; but clients that are aware of BIS can present (a) all of the fields included, and (b) the value of sigdomain (or optionally the Distinguished Name that the cert was issued to) and (c) the fact that the vendor has signed the transaction AND that the client has validated that signature.

In the case of a payment dispute, the customer can present the original Bitcoin Invoice URI, and prove that their payment was made through the public blockchain.  The URI in this case becomes both the invoice /and/ the receipt.

*Expiration: to limit the valid time for invoice's payment, a vendor MAY add a field labelled "sigexpiration" can be added before the "sig" field, which will be yyyymmddHHmmss encoded, and in the UTC time zone.  (HH is using a 24-hour clock.)  Clients SHOULD translate that time to the time zone of the user, and MUST NOT allow payment to be submitted after that cutoff.  (Payments confirmed after the cutoff become a dispute outside the scope of this proposal.)

I'm aware of BIP 0070, but this is far more lightweight, is usable offline, can be implemented in a relatively short period of time, and won't break existing Bitcoin clients.

Java source code for this:  https://github.com/dbanttari/bitcoin-invoice