MIME-Version: 1.0
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
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Proposal: extend bip70 with OpenAlias
Precedence: list

--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--