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>
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] [BIP 15] Aliases
Precedence: list

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