Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Apple Message framework v1251.1)
From: solar <solar@heliacal.net>
In-Reply-To: <201112191145.02427.andyparkins@gmail.com>
Date: Mon, 19 Dec 2011 14:46:12 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <F5367391-7CC5-4BCB-9AC4-4E38707DAF81@heliacal.net>
References: <1323728469.78044.YahooMailNeo@web121012.mail.ne1.yahoo.com>
	<CAJna-HjyZv2y9grNdnKKG8k6tn7jdW=zL=vtrALpeW8jkuzV6Q@mail.gmail.com>
	<CAGQP0AEEzOjc2ayOJYgs_oh4RG91Dp4JSHUjyPX=qdp+ri6oSg@mail.gmail.com>
	<201112191145.02427.andyparkins@gmail.com>
To: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] [BIP 15] Aliases
Precedence: list

I think HTTPS, and more specifically x.509 PKI certs and CAs are =
generally a good idea and (historical implementation bugs aside) the =
concept is technically sound and secure.  What is a bad idea (in my =
opinion) is to trust a software vendor to decide who you should trust.. =
thus it is a bad idea for bitcoin software to promise any trust.

The part where the concept becomes flawed is trusting 3rd parties who =
have no relationship with you, to serve your interests.  Now I'm just =
generalizing here and this is not universally true.. but internet CAs =
just want to sell certificates - they generally don't care beyond that, =
and they abuse the certificate validity dates to charge more money.  All =
this is done under the guise of wanting to provide a secure experience =
to users without a prior relationship to the entity being identified.  I =
propose that trying to follow this paradigm in bitcoin alias resolution =
is a bad idea because it tries to solve 2 problems at once, one of which =
does not have any 'good' solution, and forces a specific policy.

First, we need to resolve an alias to a bitcoin address somehow.. but =
secondly we need to establish trust with the entity doing the alias =
resolution - to make sure that we can trust the response.

When resolving an alias you will have to query an untrusted server, =
possibly being proxied by an 'attacker'.  Presumably, an x.509 =
certificate will be presented, possibly self signed or chained off a =
self generated CA or whatever else.. but if it's your first contact then =
there is no possible way to know if it's correct or not.  You would have =
to retrieve the correct public key of the CA to compare to first, =
possibly out of band.  Get it from my website, compare it to my business =
card, send me an email and I'll send it to you, or get it from some =
other source using some other pre existing trust (a centralized and =
possibly private directory perhaps).  The point is, the reason there is =
so much disagreement is because there is no good way to trust the =
resolver if you don't create that trust relationship prior to resolving =
an alias from it.

I think that having to pre-trust the resolver would be an acceptable =
solution to all.. Those whose policy requires a simpler process can get =
a 3rd party CA list, much like the ones provided with web browsers and =
operating systems.  Those with strict verification policies can choose =
to pre verify every public key.. and these processes are familiar to =
many organizations using PKI for other things already.  In a client, =
presenting the usual certificate detail dialog, showing the public key, =
subject, issuer, and thumbprint would be sufficient to allow users to =
implement their own policies without forcing it one way or another.

Please consider that while some organizations or users might require =
strong anonymity and pre existing trust, there are others who may want =
to do the opposite and that is just as valid, even if you or 'everyone =
else' disagrees with that.  In the case of bitcoin, it will be used as =
part of a larger system, and whatever concerns are created by 'insecure' =
alias resolution may well be addressed in another part of the system.  =
The most successful standards and implementations are the ones which =
provide the most flexibility - primarily because that allows users to =
extend them in ways the original designers didn't necessarily plan for.

Thanks,
Laszlo



On Dec 19, 2011, at 11:44 AM, Andy Parkins wrote:

> On 2011 December 19 Monday, Jorge Tim=F3n wrote:
>> Ok, so HTTP is not an option unless it shows a huge warning. I don't
>> know the HTTPS possible attack, but maybe it needs a warning message
>> too, from what you people are saying. Although using namecoin to
>=20
> The problems with HTTPS have been social rather than technical.  =
Multiple CAs=20
> have been strong-armed by governments or tricked into issuing fake=20
> certificates by scammers.  There is no technical measure around that.  =
By=20
> using the CA certificate we are saying to the system "here is someone =
I trust=20
> to issue a certificate".  So far, with a large number of CAs, that =
trust is=20
> misplaced.
>=20
> I'm of the opinion though that this problem is outside the remit of =
bitcoin to=20
> solve.
>=20
> Perhaps we should be more strict about which CA certificates are =
trusted by=20
> the bitcoin client: say restrict it to those who have demonstrably =
good=20
> practices for verifying identity; rather than the ridiculous amount of =
trust=20
> that comes pre-installed for me in my browser.
>=20
>=20
>=20
> Andy
>=20
> --=20
> Dr Andy Parkins
> andyparkins@gmail.com
> =
--------------------------------------------------------------------------=
----
> 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