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
159
160
161
162
163
164
165
166
167
168
|
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 <melvincarvalho@gmail.com>) id 1Uhff4-0002tI-Fd
for bitcoin-development@lists.sourceforge.net;
Wed, 29 May 2013 12:39:26 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.215.48 as permitted sender)
client-ip=209.85.215.48; envelope-from=melvincarvalho@gmail.com;
helo=mail-la0-f48.google.com;
Received: from mail-la0-f48.google.com ([209.85.215.48])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Uhff3-0003Jh-8R
for bitcoin-development@lists.sourceforge.net;
Wed, 29 May 2013 12:39:26 +0000
Received: by mail-la0-f48.google.com with SMTP id fs12so8526004lab.21
for <bitcoin-development@lists.sourceforge.net>;
Wed, 29 May 2013 05:39:18 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.112.141.40 with SMTP id rl8mr1402314lbb.111.1369829660130;
Wed, 29 May 2013 05:14:20 -0700 (PDT)
Received: by 10.112.20.231 with HTTP; Wed, 29 May 2013 05:14:20 -0700 (PDT)
In-Reply-To: <CAKaEYhLH+5E0cpF1NN4VOG0Rpg7AE6aUGPG++8RO6TupndL4Dg@mail.gmail.com>
References: <CAKaEYhLH+5E0cpF1NN4VOG0Rpg7AE6aUGPG++8RO6TupndL4Dg@mail.gmail.com>
Date: Wed, 29 May 2013 14:14:20 +0200
Message-ID: <CAKaEYhKrdt61Osih+3KCdM4HLw-CRd5kN5CeT1M23Jc=y478wA@mail.gmail.com>
From: Melvin Carvalho <melvincarvalho@gmail.com>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=001a11c268a64b83f904ddda525f
X-Spam-Score: -0.6 (/)
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
(melvincarvalho[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
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: 1Uhff3-0003Jh-8R
Subject: Re: [Bitcoin-development] WebCryto standard to support secp256r1
but not secp256k1
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: Wed, 29 May 2013 12:39:26 -0000
--001a11c268a64b83f904ddda525f
Content-Type: text/plain; charset=ISO-8859-1
On 7 May 2013 12:18, Melvin Carvalho <melvincarvalho@gmail.com> wrote:
> Looking at the proposed native crypto browser support (should arrive in
> the next year)
>
> http://www.w3.org/TR/WebCryptoAPI/#EcKeyGenParams-dictionary
>
> We see:
>
> enum NamedCurve {
> // NIST recommended curve P-256, also known as secp256r1.
> "P-256",
> // NIST recommended curve P-384, also known as secp384r1.
> "P-384",
> // NIST recommended curve P-521, also known as secp521r1.
> "P-521"
> };
>
> I wonder if we might be able to get bitcoin's curve in there
>
> For more background on Koblitz curve used by bitcoin see:
>
> https://bitcointalk.org/?topic=2699.0
>
Hi All
I enuired about this and got the following reply, from the chair of the
crypto group:
[[
Just email public-webcrypto-comments@w3.org. It's a public list. Do
definitely mention your use-cases!
I think there's issues of whether NSS etc. already support it. I think the
answer here is "no" but David can clarify. The goal is not to get browser
vendors to write new crypto code, but to expose the crypto code that
already exists.
We still have an open issue about whether "experimental" registry for
identifiers for say, new curves that aren't in the core spec, will be
maintained. So, maybe if browsers don't support it today, it's always
possible they might want to support it tomorrow given Bitcoin's growth.
]]
Please let me know if anyone has a use case for ecdsa in the browser let me
know.
Or if anyone would like to write to the public list that's fine
Otherwise I'll just fire off a mail and see what they come back with ...
--001a11c268a64b83f904ddda525f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 7 May 2013 12:18, Melvin Carvalho <span dir=3D"ltr"><<a href=
=3D"mailto:melvincarvalho@gmail.com" target=3D"_blank">melvincarvalho@gmail=
.com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">Looking =
at the proposed native crypto browser support (should arrive in the next ye=
ar)<br>
<div><br><a href=3D"http://www.w3.org/TR/WebCryptoAPI/#EcKeyGenParams-dicti=
onary" target=3D"_blank">http://www.w3.org/TR/WebCryptoAPI/#EcKeyGenParams-=
dictionary</a><br>
<br></div><div>We see:<br><br>enum NamedCurve {<br>=A0 // NIST recommended =
curve P-256, also known as secp256r1.<br>=A0 "P-256",<br>=A0 // N=
IST recommended curve P-384, also known as secp384r1.<br>=A0 "P-384&qu=
ot;,<br>
=A0 // NIST recommended curve P-521, also known as secp521r1.<br>=A0 "=
P-521"<br>};<br><br></div><div>I wonder if we might be able to get bit=
coin's curve in there<br><br></div><div>For more background on Koblitz =
curve used by bitcoin see:<br>
<br><a href=3D"https://bitcointalk.org/?topic=3D2699.0" target=3D"_blank">h=
ttps://bitcointalk.org/?topic=3D2699.0</a><br></div></div></blockquote><div=
><br></div><div>Hi All<br><br>I enuired about this and got the following re=
ply, from the chair of the crypto group:<br>
<br>[[<br>Just email <a href=3D"mailto:public-webcrypto-comments@w3.org" ta=
rget=3D"_blank">public-webcrypto-comments@w3.org</a>. It's a public lis=
t. Do definitely mention your use-cases!<br><br>I
think there's issues of whether NSS etc. already support it. I think=
=20
the answer here is "no" but David can clarify. The goal is not to=
get=20
browser vendors to write new crypto code, but to expose the crypto code=20
that already exists. <br>
<br>We still have an open issue about whether "experimental" regi=
stry=20
for identifiers for say, new curves that aren't in the core spec, will=
=20
be maintained. So, maybe if browsers don't support it today, it's a=
lways
possible they might want to support it tomorrow given Bitcoin's growth=
.<br>]]<br><br></div><div>Please let me know if anyone has a use case for e=
cdsa in the browser let me know.<br><br></div><div>Or if anyone would like =
to write to the public list that's fine<br>
<br></div><div>Otherwise I'll just fire off a mail and see what they co=
me back with ...<br> </div></div><br></div></div>
--001a11c268a64b83f904ddda525f--
|
