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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
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 1UVJn5-0000K8-Lg
for bitcoin-development@lists.sourceforge.net;
Thu, 25 Apr 2013 10:52:39 +0000
Received-SPF: pass (sog-mx-1.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-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1UVJn4-0003Gx-S1
for bitcoin-development@lists.sourceforge.net;
Thu, 25 Apr 2013 10:52:39 +0000
Received: by mail-oa0-f46.google.com with SMTP id k3so2654783oag.19
for <bitcoin-development@lists.sourceforge.net>;
Thu, 25 Apr 2013 03:52:33 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.60.179.42 with SMTP id dd10mr20453654oec.51.1366887153540;
Thu, 25 Apr 2013 03:52:33 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.167.169 with HTTP; Thu, 25 Apr 2013 03:52:33 -0700 (PDT)
In-Reply-To: <CANEZrP1343gX-utnbO16Z6axMDMmvYpiGXW8_Vc-yec03ip=1g@mail.gmail.com>
References: <mailman.38128.1366844895.4905.bitcoin-development@lists.sourceforge.net>
<20130425095855.GA30535@crunch>
<CANEZrP3EhS3-HnPT_exc9MjZn-ywZggSzqSHPzHU5J2EZuLQtg@mail.gmail.com>
<20130425102853.GA31573@crunch>
<CANEZrP1343gX-utnbO16Z6axMDMmvYpiGXW8_Vc-yec03ip=1g@mail.gmail.com>
Date: Thu, 25 Apr 2013 12:52:33 +0200
X-Google-Sender-Auth: WKDV6G9_GZkT3BboxQBL9To6v7g
Message-ID: <CANEZrP340hjkf8CyUnGBznRdGJWfxoAYmFOuTGbT8=pg2DNA+g@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: timo.hanke@web.de
Content-Type: multipart/alternative; boundary=089e011615883c269404db2d3771
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: 1UVJn4-0003Gx-S1
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:52:39 -0000
--089e011615883c269404db2d3771
Content-Type: text/plain; charset=UTF-8
>
> 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.
>
Re-reading what I wrote, it's not really clear.
Even if possible, the intermediate cert setup still wouldn't work for most
merchants but I didn't make that clear. It might work for EV certs. For
most sites that are just DV there's nothing you can do because CA
verification is just "do you control this domain name". So if your web
server is compromised it's game over. They can issue themselves a new cert,
and what's more, unless wallets are checking revocation lists you can't
stop them signing as you until their certificate expires.
The process for getting an EV cert is harder and there, an offline
restricted intermediate cert might make more sense because you could have a
compromised SSL key whilst not having a compromised identity, but it's
still not possible with todays CA policies.
--089e011615883c269404db2d3771
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 dir=3D"ltr"><div class=3D"gmail_extra"><div=
class=3D"gmail_quote">
<div>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 inter=
mediate certificates. Perhaps if one existed that would do the necessary th=
ings for a reasonable price you could indeed give yourself an offline inter=
mediate cert and then use that to sign one cert for SSL and another for pay=
ment request signing, but as far as anyone is aware no such CA exists.<br>
</div></div></div></div></blockquote><div style><br></div><div style>Re-rea=
ding what I wrote, it's not really clear.</div><div style><br></div><di=
v style>Even if possible, the intermediate cert setup still wouldn't wo=
rk for most merchants but I didn't make that clear. It might work for E=
V certs. For most sites that are just DV there's nothing you can do bec=
ause CA verification is just "do you control this domain name". S=
o if your web server is compromised it's game over. They can issue them=
selves a new cert, and what's more, unless wallets are checking revocat=
ion lists you can't stop them signing as you until their certificate ex=
pires.</div>
<div style><br></div><div style>The process for getting an EV cert is harde=
r and there, an offline restricted intermediate cert might make more sense =
because you could have a compromised SSL key whilst not having a compromise=
d identity, but it's still not possible with todays CA policies.</div>
</div></div></div>
--089e011615883c269404db2d3771--
|
