Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1UVIxC-0004F7-G2 for bitcoin-development@lists.sourceforge.net; Thu, 25 Apr 2013 09:59:02 +0000 Received: from mout.web.de ([212.227.17.11]) by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1UVIxB-0007QN-Fk for bitcoin-development@lists.sourceforge.net; Thu, 25 Apr 2013 09:59:02 +0000 Received: from crunch ([77.180.198.197]) by smtp.web.de (mrweb003) with ESMTPA (Nemesis) id 0Lx7OL-1UXVxe2U6T-0176YX for ; Thu, 25 Apr 2013 11:58:55 +0200 Date: Thu, 25 Apr 2013 11:58:55 +0200 From: Timo Hanke To: bitcoin-development@lists.sourceforge.net Message-ID: <20130425095855.GA30535@crunch> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Provags-ID: V02:K0:vYW3UGtvObcBYhLcfPZcZSpiENj70vM348dEVrY3MsL JxGYKGQiqFA0cKjOaiVgK1AdmtwK1QqCVL05IYUcN5VLSZ1W0l a03KbwyzoUBhczgD24CpMgvZ1f1KXEjsKmjIKs/Sdc5NrkQA+k n4vOAWm3y/MHcnCMeX+L0WxvBWkTrWx4qHFhzkthusjxdj8tWD iHVgjiwm5jaJeUo+2LYeg== X-Spam-Score: 0.0 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [212.227.17.11 listed in list.dnswl.org] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (timo.hanke[at]web.de) -0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain X-Headers-End: 1UVIxB-0007QN-Fk Subject: Re: [Bitcoin-development] Cold Signing Payment Requests X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list Reply-To: timo.hanke@web.de List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2013 09:59:02 -0000 > So, I'm not a fan of weird hacks involving non-existent domain names. > There's a clean way to implement this and we decided to punt on it for > v1 in order to get something shippable, but if you're volunteering ... > :) then indeed having a custom cert type that chains onto the end is > the way to go. Chaining a custom cert onto the end doesn't work, at least not if your "end" is the SSL cert. Chaining it to the SSL cert defeats the OP's intention of "cold signing", as the SSL private key is usually kept online, therefore can't be used to sign a pubkey that is supposed to stay offline. Hence the idea of the "hack", to get two independent things signed by the CA in just one cert: 1) your SSL pubkey, 2) your custom cert (by including its cryptograhic hash). This hack seems the easiest possible solution. It also seems the only solution if you want to stick with domain-names as identifiers for the payment protocol (and I think you do). A cleaner way would be to get a cert signed by your CA that contains an extended "bitcoin" attribute in compliance with X.509, but this seems a little far off. So I am in favor of the "hack" (properly thought out where to place the hash). ps. In the long run I would of course like to see payee identities based on alt-chains rather than domain-names plus CAs. But that's rather a concern for v3 than v2. Of course, you can also chain custom certs to non-SSL identities like PGP-keys. You probably don't want to do that, but it would solve Melvin Carvalho's problem of sending to RSA keys (assuming the RSA key holder previously published his custom cert with a cert server). -- Timo Hanke PGP AB967DA8, Key fingerprint = 1EFF 69BC 6FB7 8744 14DB 631D 1BB5 D6E3 AB96 7DA8