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
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1UVJ3F-0008BG-Fs
for bitcoin-development@lists.sourceforge.net;
Thu, 25 Apr 2013 10:05:17 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.214.50 as permitted sender)
client-ip=209.85.214.50; envelope-from=mh.in.england@gmail.com;
helo=mail-bk0-f50.google.com;
Received: from mail-bk0-f50.google.com ([209.85.214.50])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1UVJ3B-0006OV-KN
for bitcoin-development@lists.sourceforge.net;
Thu, 25 Apr 2013 10:05:17 +0000
Received: by mail-bk0-f50.google.com with SMTP id ik5so1174275bkc.37
for <bitcoin-development@lists.sourceforge.net>;
Thu, 25 Apr 2013 03:05:07 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.204.224.135 with SMTP id io7mr13803660bkb.46.1366884307186;
Thu, 25 Apr 2013 03:05:07 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.204.38.8 with HTTP; Thu, 25 Apr 2013 03:05:06 -0700 (PDT)
In-Reply-To: <20130425095855.GA30535@crunch>
References: <mailman.38128.1366844895.4905.bitcoin-development@lists.sourceforge.net>
<20130425095855.GA30535@crunch>
Date: Thu, 25 Apr 2013 12:05:06 +0200
X-Google-Sender-Auth: G1DZB751ZJIzjwS7CbGKDWGl98c
Message-ID: <CANEZrP3EhS3-HnPT_exc9MjZn-ywZggSzqSHPzHU5J2EZuLQtg@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: timo.hanke@web.de
Content-Type: multipart/alternative; boundary=485b3970d5b89476e404db2c8dde
X-Spam-Score: -0.5 (/)
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
1.0 HTML_MESSAGE BODY: HTML included in message
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
X-Headers-End: 1UVJ3B-0006OV-KN
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Cold Signing Payment Requests
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
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 10:05:17 -0000
--485b3970d5b89476e404db2c8dde
Content-Type: text/plain; charset=UTF-8
> 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.
What you wrote doesn't make any sense to me, sorry.
Yes, SSL private keys are kept online. That's irrelevant - the goal of all
this is not to protect against web server compromise. That's a pointless
goal to try and solve right now, because the SSL PKI cannot handle
compromised web servers and so neither can we (with v1 of the payments
spec).
The goal of this is to allow delegation of signing authority without giving
the delegate the SSL private key.
--485b3970d5b89476e404db2c8dde
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><div class=3D"gmail_quote">=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Chaining a custom cert onto the end doesn=
9;t work, at least not if your<br>
"end" is the SSL cert. Chaining it to the SSL cert defeats the OP=
's<br>
intention of "cold signing", as the SSL private key is usually ke=
pt<br>
online, therefore can't be used to sign a pubkey that is supposed to<br=
>
stay offline.</blockquote><div><br></div><div style>What you wrote doesn=
9;t make any sense to me, sorry.</div><div style><br></div><div style>Yes, =
SSL private keys are kept online. That's irrelevant - the goal of all t=
his is not to protect against web server compromise. That's a pointless=
goal to try and solve right now, because the SSL PKI cannot handle comprom=
ised web servers and so neither can we (with v1 of the payments spec).</div=
>
<div style><br></div><div style>The goal of this is to allow delegation of =
signing authority without giving the delegate the SSL private key.</div><di=
v><br></div></div></div></div>
--485b3970d5b89476e404db2c8dde--
|
