From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 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> <201112191145.02427.andyparkins@gmail.com> <201112191135.34080.luke@dashjr.org> To: "Luke-Jr" 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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