From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Td7gy-0001Xo-Fl for bitcoin-development@lists.sourceforge.net; Mon, 26 Nov 2012 23:02:20 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.219.47 as permitted sender) client-ip=209.85.219.47; envelope-from=mh.in.england@gmail.com; helo=mail-oa0-f47.google.com; Received: from mail-oa0-f47.google.com ([209.85.219.47]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Td7gx-0003bu-Pl for bitcoin-development@lists.sourceforge.net; Mon, 26 Nov 2012 23:02:20 +0000 Received: by mail-oa0-f47.google.com with SMTP id h1so12436369oag.34 for ; Mon, 26 Nov 2012 15:02:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.60.171.141 with SMTP id au13mr10329065oec.124.1353970934447; Mon, 26 Nov 2012 15:02:14 -0800 (PST) Sender: mh.in.england@gmail.com Received: by 10.76.128.139 with HTTP; Mon, 26 Nov 2012 15:02:14 -0800 (PST) In-Reply-To: References: Date: Tue, 27 Nov 2012 00:02:14 +0100 X-Google-Sender-Auth: 6UdhHF2CxpBwDwmPntGUJjA1gfA Message-ID: From: Mike Hearn To: Gavin Andresen Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -1.0 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (mh.in.england[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature 0.5 AWL AWL: From: address is in the auto white-list X-Headers-End: 1Td7gx-0003bu-Pl Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2012 23:02:20 -0000 Obviously this LGTM :) Minor caveat, IMHO we should support all CAs used by the popular browsers. This ensures no merchant ever finds that their SSL cert they already own is OK for the web but not for Bitcoin. I don't see a need to be stricter here, given all it achieves is signing some data in a way linked with a domain name. X.509 is pretty baroque indeed, for our use cases it'd not be hard to do better. In particular, the inability to delegate properly rather defeats the benefits of chained certificates. For the payment processor case what you really want to do is take your keys, then issue a new cert that is specific to signing Bitcoin transactions and give that to the payment processor secure in the knowledge that they cannot MITM your secure connections. Unfortunately X.509 wasn't designed for the web and thus certificates you buy are marked such that they are not allowed to sign for other certs (due to lack of real namespace support). This leads to the idea of redefining the cert chain part of the protocol like this: repeated bytes x509_chain = 1; becomes message Certificate { enum Type { X509 = 1; } required Type type = 1; required bytes data = 2; } repeated Certificate cert_chain = 1; Then if later we want to introduce our own minimal certificate formats which include features we want, we can add new enum types to do so. Note that if an old client encounters an invoice with a cert type it doesn't recognize, it will abort parsing of the message entirely. So the request to download the invoice should probably include a protocol version number of some kind so the server knows when it's safe to use new invoice features.