1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
|
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 <timo.hanke@web.de>) 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
<bitcoin-development@lists.sourceforge.net>;
Thu, 25 Apr 2013 11:58:55 +0200
Date: Thu, 25 Apr 2013 11:58:55 +0200
From: Timo Hanke <timo.hanke@web.de>
To: bitcoin-development@lists.sourceforge.net
Message-ID: <20130425095855.GA30535@crunch>
References: <mailman.38128.1366844895.4905.bitcoin-development@lists.sourceforge.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <mailman.38128.1366844895.4905.bitcoin-development@lists.sourceforge.net>
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: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=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
|
