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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <solar@heliacal.net>) id 1RcgmF-00042E-TR
for bitcoin-development@lists.sourceforge.net;
Mon, 19 Dec 2011 17:13:27 +0000
X-ACL-Warn:
Received: from pelican.heliacal.net ([173.246.103.92] helo=pelican)
by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1RcgmA-0007XX-Bk for bitcoin-development@lists.sourceforge.net;
Mon, 19 Dec 2011 17:13:27 +0000
Received: from laszlo.jax.imobile3.com (laszlo.jax.imobile3.com
[199.189.207.150])
(using TLSv1 with cipher AES128-SHA (128/128 bits))
(No client certificate requested)
by pelican (Postfix) with ESMTPSA id 28B4A19122;
Mon, 19 Dec 2011 17:13:15 +0000 (UTC)
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset=us-ascii
From: solar <solar@heliacal.net>
In-Reply-To: <201112191135.34080.luke@dashjr.org>
Date: Mon, 19 Dec 2011 17:13:14 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <64F593B6-CF1C-4FF1-87B9-5C1E7A667A4B@heliacal.net>
References: <1323728469.78044.YahooMailNeo@web121012.mail.ne1.yahoo.com>
<CAGQP0AEEzOjc2ayOJYgs_oh4RG91Dp4JSHUjyPX=qdp+ri6oSg@mail.gmail.com>
<201112191145.02427.andyparkins@gmail.com>
<201112191135.34080.luke@dashjr.org>
To: "Luke-Jr" <luke@dashjr.org>
X-Mailer: Apple Mail (2.1251.1)
X-Helo-Check: bad, Not FQDN (pelican)
X-Spam-Score: -2.1 (--)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
0.0 FSL_HELO_NON_FQDN_1 FSL_HELO_NON_FQDN_1
0.5 VA_HELO_CHECK Host Used Invalid or Forged HELO/EHLO
-2.6 RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
0.0 HELO_NO_DOMAIN Relay reports its domain incorrectly
X-Headers-End: 1RcgmA-0007XX-Bk
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] [BIP 15] Aliases
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: Mon, 19 Dec 2011 17:13:28 -0000
Using commercial CAs to establish trust is a site local administrative =
policy..
Bitcoin and operating systems have no technical need to concern =
themselves with this. It is a shame that the system has been abused by =
CAs paying off operating system and web browser vendors but this is not =
the only way to use it.. my policy may be (as an example) to require =
each party I deal with to generate their own self signed cert or their =
own CA cert (same thing really) and then I can trust that and only that. =
Obviously, commercial CAs will sell a certificate to anyone which means =
you trust anyone that is their customer. This is a valid site policy =
but not for everyone.
Rick Wesson's suggestion about DNSSEC and such is interesting since it =
would provide a system for that 'first contact' exchange where you can =
more reliably retrieve the certificate, if the site supports it. Some =
policies may not require this however - you can always get the trust =
established another way like downloading a cert file from a website or =
whatever else you consider adequately secure for your organization.
I think 3rd party CA lists and the DNSSEC/DANE idea are both useful ways =
to automatically establish trust out of band, but this is independent of =
the actual implementation of alias resolution, which happens after a =
trusted connection is made. Automatically establishing trust with the =
alias resolver is perhaps a useful feature, but not a requirement for =
either side to support alias resolution.
In any case, it sounds like using HTTPS and x.509 certs would allow many =
of these automatic trust establishment systems to be implemented on top, =
allowing flexible policy configuration, which seems to be important to =
several people in this thread of discussion.
I think using JSON would be ok but like it's been said, you either have =
to serialize your binary data into some text format like base64/UUencode =
or represent it as an integer array, both of which are inefficient.. =
probably cancelling out any benefit of using JSON in the first place :)
Maybe there is no need for binary data for alias resolution though.. I =
imagine it would be as simple as submitting a name to resolve, and =
giving back a base58 address string, perhaps along with a textual =
comment or other extra, information data.
Being strict or lax or anything else is not really a concern for alias =
resolution - establishing trust is an administrative issue with a lot of =
different solutions and not every site or application requires trust. =
HTTPS and mutual authentication may be desirable for general cases, =
however HTTP should work just as well if trust is established another =
way and thus SSL/TLS is not a requirement for the HTTP exchange to work. =
As an example use case, I may be using IPsec or any number of other =
systems external to bitcoin and alias resolution itself.
Laszlo
On Dec 19, 2011, at 4:35 PM, Luke-Jr wrote:
> On Monday, December 19, 2011 6:44:59 AM Andy Parkins wrote:
>> Perhaps we should be more strict about which CA certificates are =
trusted by
>> the bitcoin client: say restrict it to those who have demonstrably =
good
>> practices for verifying identity; rather than the ridiculous amount =
of
>> trust that comes pre-installed for me in my browser.
>=20
> Accepted CAs is/should be a property of your *operating system*, not =
any=20
> particular software. Anyhow, restricting this further just makes it =
even more=20
> unusable. Already there is only 1 or 2 CAs that will provide a gratis=20=
> certificate for personal/small users. If you only allow high-class =
CAs, I=20
> imagine that will restrict "no key in the URI" aliases to those who =
will fork=20
> over a lot of money.
>=20
> =
--------------------------------------------------------------------------=
----
> Learn Windows Azure Live! Tuesday, Dec 13, 2011
> Microsoft is holding a special Learn Windows Azure training event for=20=
> developers. It will provide a great way to learn Windows Azure and =
what it=20
> provides. You can attend the event by watching it streamed LIVE =
online. =20
> Learn more at http://p.sf.net/sfu/ms-windowsazure
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
|
