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
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1UVJgJ-00039I-OS
for bitcoin-development@lists.sourceforge.net;
Thu, 25 Apr 2013 10:45:39 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.219.46 as permitted sender)
client-ip=209.85.219.46; envelope-from=mh.in.england@gmail.com;
helo=mail-oa0-f46.google.com;
Received: from mail-oa0-f46.google.com ([209.85.219.46])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1UVJgI-0004Au-Q3
for bitcoin-development@lists.sourceforge.net;
Thu, 25 Apr 2013 10:45:39 +0000
Received: by mail-oa0-f46.google.com with SMTP id k3so2650760oag.19
for <bitcoin-development@lists.sourceforge.net>;
Thu, 25 Apr 2013 03:45:33 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.60.28.37 with SMTP id y5mr15859978oeg.134.1366886733435;
Thu, 25 Apr 2013 03:45:33 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.167.169 with HTTP; Thu, 25 Apr 2013 03:45:33 -0700 (PDT)
In-Reply-To: <20130425102853.GA31573@crunch>
References: <mailman.38128.1366844895.4905.bitcoin-development@lists.sourceforge.net>
<20130425095855.GA30535@crunch>
<CANEZrP3EhS3-HnPT_exc9MjZn-ywZggSzqSHPzHU5J2EZuLQtg@mail.gmail.com>
<20130425102853.GA31573@crunch>
Date: Thu, 25 Apr 2013 12:45:33 +0200
X-Google-Sender-Auth: I8LxTfnSieoOOIPZWTvdc89boZ0
Message-ID: <CANEZrP1343gX-utnbO16Z6axMDMmvYpiGXW8_Vc-yec03ip=1g@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: timo.hanke@web.de
Content-Type: multipart/alternative; boundary=e89a8fb1f7f031dd3704db2d1ec0
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: 1UVJgI-0004Au-Q3
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:45:39 -0000
--e89a8fb1f7f031dd3704db2d1ec0
Content-Type: text/plain; charset=UTF-8
>
> > 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).
>
> I don't think the OP intended to solve it "right now", i.e. in v1.
>
> He differentiated between "most trusted" and "less trusted" keys
> (certs). So he can clearly live with the SSL PKI being "less trusted"
> for his purpose.
Yes, but my point is if the SSL key lives on the web server, and there are
CAs that issue you certs based on control of a web server at the given
domain name (there are), then you can simply issue yourself a new SSL cert
with whatever data in it you want and pose as the merchant.
So I don't see how you can have a payment request signing key that's safer
than an SSL key. As Jeremy notes, CAs will not issue you intermediate
certificates. Perhaps if one existed that would do the necessary things for
a reasonable price you could indeed give yourself an offline intermediate
cert and then use that to sign one cert for SSL and another for payment
request signing, but as far as anyone is aware no such CA exists.
The interesting case is where the thing signing payment requests is less
trusted than the web server. The scenario you're trying to solve is the
inverse - the payment request signing process is more trusted than the web
server. But unless/until the CA landscape changes we don't have a way to
implement that.
--e89a8fb1f7f031dd3704db2d1ec0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div class=3D"im">> That's a pointless go=
al to try and solve right now, because the SSL<br>
> PKI cannot handle compromised web servers and so neither can we (with<=
br>
> v1 of the payments spec).<br>
<br>
</div>I don't think the OP intended to solve it "right now", =
i.e. in v1.<br>
<br>
He differentiated between "most trusted" and "less trusted&q=
uot; keys<br>
(certs). So he can clearly live with the SSL PKI being "less trusted&q=
uot;<br>
for his purpose.</blockquote><div><br></div><div style>Yes, but my point is=
if the SSL key lives on the web server, and there are CAs that issue you c=
erts based on control of a web server at the given domain name (there are),=
then you can simply issue yourself a new SSL cert with whatever data in it=
you want and pose as the merchant.</div>
<div style><br></div><div style>So I don't see how you can have a payme=
nt request signing key that's safer than an SSL key. As Jeremy notes, C=
As will not issue you intermediate certificates. Perhaps if one existed tha=
t would do the necessary things for a reasonable price you could indeed giv=
e yourself an offline intermediate cert and then use that to sign one cert =
for SSL and another for payment request signing, but as far as anyone is aw=
are no such CA exists.</div>
<div style><br></div><div style>The interesting case is where the thing sig=
ning payment requests is less trusted than the web server. The scenario you=
're trying to solve is the inverse - the payment request signing proces=
s is more trusted than the web server. But unless/until the CA landscape ch=
anges we don't have a way to implement that.</div>
</div></div></div>
--e89a8fb1f7f031dd3704db2d1ec0--
|
