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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gmaxwell@gmail.com>) id 1VZv9M-0002Yk-OZ
for bitcoin-development@lists.sourceforge.net;
Sat, 26 Oct 2013 04:06:56 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.217.171 as permitted sender)
client-ip=209.85.217.171; envelope-from=gmaxwell@gmail.com;
helo=mail-lb0-f171.google.com;
Received: from mail-lb0-f171.google.com ([209.85.217.171])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1VZv9L-0003bI-O8
for bitcoin-development@lists.sourceforge.net;
Sat, 26 Oct 2013 04:06:56 +0000
Received: by mail-lb0-f171.google.com with SMTP id x18so1384963lbi.30
for <bitcoin-development@lists.sourceforge.net>;
Fri, 25 Oct 2013 21:06:49 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.152.3.42 with SMTP id 10mr7525160laz.22.1382760408950; Fri,
25 Oct 2013 21:06:48 -0700 (PDT)
Received: by 10.112.89.72 with HTTP; Fri, 25 Oct 2013 21:06:48 -0700 (PDT)
In-Reply-To: <201310260341.41613.luke@dashjr.org>
References: <CAAS2fgRRobkE2GdYomtJof7HCH-9ZczE9EBj7DBS-pCGscUSNQ@mail.gmail.com>
<201310260341.41613.luke@dashjr.org>
Date: Fri, 25 Oct 2013 21:06:48 -0700
Message-ID: <CAAS2fgTWjPCdAZB22GdRWkfULS-L9XaqYRZqB=dcbGV1+My3nA@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Luke-Jr <luke@dashjr.org>
Content-Type: text/plain; charset=UTF-8
X-Spam-Score: -1.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
(gmaxwell[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked.
See
http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
for more information. [URIs: dashjr.org]
-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: 1VZv9L-0003bI-O8
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Payment protocol for onion URLs.
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: Sat, 26 Oct 2013 04:06:57 -0000
On Fri, Oct 25, 2013 at 8:41 PM, Luke-Jr <luke@dashjr.org> wrote:
> Is there any point to additional encryption over tor (which afaik is already
> encrypted end-to-end)? Is there a safe way to make this work through tor entry
> nodes/gateways?
The x.509 in the payment protocol itself is for authentication and
non-repudiation, not confidentiality.
It's used to sign the payment request so that later there is
cryptographic evidence in the event of a dispute:
"He didn't send me my alpaca socks!" "Thats not the address I told you to pay!"
"He told me he'd send my 99 red-balloons, not just one!" "No way,
that was the price for 1 red-balloon!"
Just using SSL or .onion (or whatever else) gets you confidentiality
and authentication. Neither of these things get you non-repudiation.
> It'd be nice to have a way to support namecoin-provided keys too...
The payment protocol is extensible, so I hope that someday someone
will support namecoin authenticated messages (but note: this requires
namecoin to support trust-free SPV resolvers, otherwise there is no
way to extract a compact proof that can be stuck into a payment
request) and GPG authenticated messages.
But those things will require a fair amount of code (even fixing the
namecoin protocol in the nmc case), and GPG could be done just by
externally signing the actual payment request like you'd sign any
file... and considering the sorry state of their _practical_
usability, I don't think they're worth doing at this time.
By contrast, I _think_ the tor onion support would require only a
relatively few lines of code since it could just be the existing x.509
mechanism with just a simple special validation rule for .onion, plus
a little tool to repack the keys. I think it would easily be more
widely used than namecoin (though probably both would not really be
used, as gavin notes).
w/ Gavin's comments I'll go check in with the tor folks and see if
anyone has ever though of doing this before and if there is already a
canonical structure for the x.509 certs used in this way.
|
