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
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
|
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 1WQxJ8-0002yM-IT
for bitcoin-development@lists.sourceforge.net;
Fri, 21 Mar 2014 11:08:14 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.214.182 as permitted sender)
client-ip=209.85.214.182; envelope-from=mh.in.england@gmail.com;
helo=mail-ob0-f182.google.com;
Received: from mail-ob0-f182.google.com ([209.85.214.182])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WQxJ7-0002Xh-KH
for bitcoin-development@lists.sourceforge.net;
Fri, 21 Mar 2014 11:08:14 +0000
Received: by mail-ob0-f182.google.com with SMTP id uz6so2294820obc.13
for <bitcoin-development@lists.sourceforge.net>;
Fri, 21 Mar 2014 04:08:08 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.182.241.67 with SMTP id wg3mr7636383obc.16.1395400088301;
Fri, 21 Mar 2014 04:08:08 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.71.231 with HTTP; Fri, 21 Mar 2014 04:08:08 -0700 (PDT)
In-Reply-To: <20140321105906.GA1725@netbook.cypherspace.org>
References: <lc5hmg$1jh$1@ger.gmane.org> <leuunm$tjk$1@ger.gmane.org>
<CANEZrP3nQfvDArKTRgje0Cus4G2JD_zpxSjA3fXfxM2TNAP80Q@mail.gmail.com>
<CALDj+BafD+6KTNcYDBEu5gNPzYozSkiC-JCxrY-PzXL2DYBRsw@mail.gmail.com>
<CAJHLa0N4J_Z907+D0ENSNKfNAW2N=7Jf4JzSCO=SU558GtGTzA@mail.gmail.com>
<lge7nk$3mf$2@ger.gmane.org>
<CANEZrP0J849oDvMWjf8LWi0xj44Q8DaUwDip5_smVBMNgeQ3mw@mail.gmail.com>
<20140320121221.GA25052@netbook.cypherspace.org>
<lgh438$tnn$1@ger.gmane.org>
<20140321105906.GA1725@netbook.cypherspace.org>
Date: Fri, 21 Mar 2014 12:08:08 +0100
X-Google-Sender-Auth: UvYm6KRuV8YWjEVXX9E4iYOCXcE
Message-ID: <CANEZrP2bG_r08vYDZZY4Hg6M+tZFzyQj7SVQ1syZwgv=+F=DqQ@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Adam Back <adam@cypherspace.org>
Content-Type: multipart/alternative; boundary=001a11c2efb89539ce04f51be6f5
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: 1WQxJ7-0002Xh-KH
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>,
Andreas Schildbach <andreas@schildbach.de>
Subject: Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments
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: Fri, 21 Mar 2014 11:08:14 -0000
--001a11c2efb89539ce04f51be6f5
Content-Type: text/plain; charset=UTF-8
On Fri, Mar 21, 2014 at 11:59 AM, Adam Back <adam@cypherspace.org> wrote:
> Maybe its time to explore raw ECDSA signed message based certs.
>
If you want to create and run a new CA, by all means. But I bet you don't.
So we're stuck with the current system for now.
> btw I dont think its quite 4kB. eg bitpay's looks to be about 1.5kB in der
> format. And they contain a 2048-bit RSA server key, and 2048-bit RSA
> signatures (256byte each right there = 512bytes). And even 2048 is weaker
> than 256-bit ECDSA.
But you have to chain up to the root.
The only reason more certs aren't ECC is backwards compatibility. Some old
browsers don't know how to handle them. It wasn't so long ago that Fedora
and Android were deleting ECC code from upstream libraries before shipping
them, either for patent reasons for disk space saving measures.
But it's possible to get ECC certs if you want. For example, Entrust is
starting to sell them:
http://www.entrust.net/ecc-certs/index.htm
But their intermediate cert is still RSA. My understanding is that ECC
roots for many CA's have been submitted and are now included, but of course
"give up compatibility with lots of users" vs "save a bit of cpu time and a
handful of bytes" is no real competition so it will be a long time until
most websites are using ECC certs.
Regardless, it's all irrelevant. Who knows when we might want to add
another feature that uses some bytes into PaymentRequests. Stuffing them
into a QR code will never make much sense IMO - it's far more sensible to
just use Bluetooth where the data size constraints are so much easier.
--001a11c2efb89539ce04f51be6f5
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">On F=
ri, Mar 21, 2014 at 11:59 AM, Adam Back <span dir=3D"ltr"><<a href=3D"ma=
ilto:adam@cypherspace.org" target=3D"_blank">adam@cypherspace.org</a>></=
span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">Maybe its time to explore raw ECDSA signed message based c=
erts.<br>
</blockquote><div><br></div><div>If you want to create and run a new CA, by=
all means. But I bet you don't. So we're stuck with the current sy=
stem for now.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(20=
4,204,204);border-left-style:solid;padding-left:1ex">
btw I dont think its quite 4kB. =C2=A0eg bitpay's looks to be about 1.5=
kB in der<br>
format. =C2=A0And they contain a 2048-bit RSA server key, and 2048-bit RSA<=
br>
signatures (256byte each right there =3D 512bytes). =C2=A0And even 2048 is =
weaker<br>
than 256-bit ECDSA.</blockquote><div><br></div><div>But you have to chain u=
p to the root.</div><div><br></div><div>The only reason more certs aren'=
;t ECC is backwards compatibility. Some old browsers don't know how to =
handle them. It wasn't so long ago that Fedora and Android were deletin=
g ECC code from upstream libraries before shipping them, either for patent =
reasons for disk space saving measures.</div>
<div><br></div><div>But it's possible to get ECC certs if you want. For=
example, Entrust is starting to sell them:</div><div><br></div><div><a hre=
f=3D"http://www.entrust.net/ecc-certs/index.htm">http://www.entrust.net/ecc=
-certs/index.htm</a><br>
</div><div><br></div><div>But their intermediate cert is still RSA. My unde=
rstanding is that ECC roots for many CA's have been submitted and are n=
ow included, but of course "give up compatibility with lots of users&q=
uot; vs "save a bit of cpu time and a handful of bytes" is no rea=
l competition so it will be a long time until most websites are using ECC c=
erts.</div>
<div><br></div><div>Regardless, it's all irrelevant. Who knows when we =
might want to add another feature that uses some bytes into PaymentRequests=
. Stuffing them into a QR code will never make much sense IMO - it's fa=
r more sensible to just use Bluetooth where the data size constraints are s=
o much easier.</div>
</div></div></div>
--001a11c2efb89539ce04f51be6f5--
|
