summaryrefslogtreecommitdiff
path: root/06/8813581d6653ab341e4439943419ef15cfbfb9
blob: 85583e5cb035f4b95eef95378d67969e4bf04c1a (plain)
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
Return-Path: <hearn@vinumeris.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id CAA03279
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 20 Jul 2015 15:14:04 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f180.google.com (mail-ig0-f180.google.com
	[209.85.213.180])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 43FACF1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 20 Jul 2015 15:14:04 +0000 (UTC)
Received: by igr7 with SMTP id 7so16001396igr.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 20 Jul 2015 08:14:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=vinumeris.com; s=google;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=LwAG2swWxdRSioewxPStcAGurt6g6216lFZUtyD4n08=;
	b=Q8UGq9a0/EqfhKjrcLMi1y1m4Fw2BhJ7JcxulTyBxCYPd6ICdc7dob58gHWxU49reS
	RZ3YcpVWIoLLiRG9lkHuIUPMl+21z6W5AgP7HDh3wHvc9kHHcLTAgDdjxYLgKIulKDr8
	26o+7qizVF4yDYNnWD9v593oMeUwgUi5mMlQg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=LwAG2swWxdRSioewxPStcAGurt6g6216lFZUtyD4n08=;
	b=QEFu33DW4cTk7yMljbFdjJu90VqHB/6ig600c4OHg6LeEXNFDYIXY/8ElnfwCenLbZ
	ymxvLHZo6absi2jpOpPm3/XwySeEV+ZebqOvdg2racnwYnCddInSv3FIYTfIlje8MBN0
	9jdBsLGfQMtGOHt0EozUyUuc0mFCVSojUDgIz/hZNYMQOSYIdZuJ3CcKO8GFL+l8hbG+
	qhIPzQghyAQF2GdPTLT+oieDovfyubXcuBezw2uC/GT5POPnJAyUSMrz/4yaXlXf9wcR
	QMU/CTv39enUR8cwsJlpJEwdcHLhoq7KKeVVXcM4N1rS9JvSZ/q225IdelJsa7QpjvkX
	QUPw==
X-Gm-Message-State: ALoCoQkI9aEYyOmVtpLlc+eh8KIiJn7+4uzox9PphWvAhh6+8WFgKdlHxRx/8D18pVJUMVq5T27M
MIME-Version: 1.0
X-Received: by 10.107.129.215 with SMTP id l84mr20489248ioi.78.1437405243725; 
	Mon, 20 Jul 2015 08:14:03 -0700 (PDT)
Received: by 10.50.108.111 with HTTP; Mon, 20 Jul 2015 08:14:03 -0700 (PDT)
In-Reply-To: <55AD0B43.4010207@electrum.org>
References: <CA+w+GKQbOMz5nb_SnLB6Xb0FYzNZ_rEj5nbNjm2jY0+L8JJGAA@mail.gmail.com>
	<55A4AF62.4090607@electrum.org>
	<CA+w+GKRCPEUezaTb46pzuDNxKNgi_KdTW2dOn9hsHwgD159czw@mail.gmail.com>
	<55AB8785.4080201@electrum.org>
	<CA+w+GKTtkYUst0UJa6364LqBRqWYrA+fOKed973mQCQS4ze=4Q@mail.gmail.com>
	<55AD0669.4040002@electrum.org>
	<CA+w+GKSqqD=Fwyptzd_skq3+-x2dFxjY_gOOtEuAo7ZPQ9AzoA@mail.gmail.com>
	<55AD0B43.4010207@electrum.org>
Date: Mon, 20 Jul 2015 17:14:03 +0200
Message-ID: <CA+w+GKT03z9X=hRZcOkOpBfB7iBtwbx+O0sSD5K-bki_dHWrmQ@mail.gmail.com>
From: Mike Hearn <hearn@vinumeris.com>
To: Thomas Voegtlin <thomasv@electrum.org>
Content-Type: multipart/alternative; boundary=001a113ec6acf37729051b4ffcbb
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=ham
	version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Proposal: extend bip70 with OpenAlias
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Mon, 20 Jul 2015 15:14:04 -0000

--001a113ec6acf37729051b4ffcbb
Content-Type: text/plain; charset=UTF-8

>
> The final signature is a signature of the payment request, it is not
> part of DNSSEC. So, yes, that signature can be EC.
>

Right, got it. I think we've been talking about two related but separate
issues (DNSSEC vs squeezing payment requests into URIs/qrcodes somehow).
So: DNSSEC attests via an RSA chain to some EC key stored in the wallet
which is then used to sign the payment request or URI, which also contains
a domain name.


> The payment requests I am currently playing with have the following values:
>
> pki_type = "dnssec+btc" (btc means that the signature is checked against
> a Bitcoin address stored in DNS)
> pki_data = the user's alias (DNS key)


By "alias" you mean domain name? I'm not sure what DNS key means in this
context.

I'm still not really convinced that a domain name under some new roots is
an identity people will want to use, but yes, I guess your approach would
work for those who do want it.

It still may be worth exploring the compact cert+optimized BIP70 (no
DNSSEC) in a qrcode if making a network that stores small bits of data
really is beyond us :(

--001a113ec6acf37729051b4ffcbb
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">The final signature is a signature of the paymen=
t request, it is not<br>
part of DNSSEC. So, yes, that signature can be EC.<br></blockquote><div><br=
></div><div>Right, got it. I think we&#39;ve been talking about two related=
 but separate issues (DNSSEC vs squeezing payment requests into URIs/qrcode=
s somehow). So: DNSSEC attests via an RSA chain to some EC key stored in th=
e wallet which is then used to sign the payment request or URI, which also =
contains a domain name.</div><div>=C2=A0</div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
">The payment requests I am currently playing with have the following value=
s:<br>
<br>
pki_type =3D &quot;dnssec+btc&quot; (btc means that the signature is checke=
d against<br>
a Bitcoin address stored in DNS)<br>
pki_data =3D the user&#39;s alias (DNS key)</blockquote><div><br></div><div=
>By &quot;alias&quot; you mean domain name? I&#39;m not sure what DNS key m=
eans in this context.</div><div><br></div><div>I&#39;m still not really con=
vinced that a domain name under some new roots is an identity people will w=
ant to use, but yes, I guess your approach would work for those who do want=
 it.</div><div><br></div><div>It still may be worth exploring the compact c=
ert+optimized BIP70 (no DNSSEC) in a qrcode if making a network that stores=
 small bits of data really is beyond us :(</div></div></div></div>

--001a113ec6acf37729051b4ffcbb--