From: solar <solar@heliacal•net>
To: "Luke-Jr" <luke@dashjr•org>
Cc: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] [BIP 15] Aliases
Date: Mon, 19 Dec 2011 17:13:14 +0000 [thread overview]
Message-ID: <64F593B6-CF1C-4FF1-87B9-5C1E7A667A4B@heliacal.net> (raw)
In-Reply-To: <201112191135.34080.luke@dashjr.org>
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.
>
> Accepted CAs is/should be a property of your *operating system*, not any
> particular software. Anyhow, restricting this further just makes it even more
> unusable. Already there is only 1 or 2 CAs that will provide a gratis
> certificate for personal/small users. If you only allow high-class CAs, I
> imagine that will restrict "no key in the URI" aliases to those who will fork
> over a lot of money.
>
> ------------------------------------------------------------------------------
> Learn Windows Azure Live! Tuesday, Dec 13, 2011
> Microsoft is holding a special Learn Windows Azure training event for
> developers. It will provide a great way to learn Windows Azure and what it
> provides. You can attend the event by watching it streamed LIVE online.
> 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
next prev parent reply other threads:[~2011-12-19 17:13 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-12 22:21 Amir Taaki
2011-12-12 22:25 ` Amir Taaki
2011-12-12 22:32 ` Luke-Jr
2011-12-13 4:38 ` theymos
2011-12-13 7:41 ` Jorge Timón
2011-12-15 19:59 ` theymos
2011-12-15 23:56 ` Amir Taaki
2011-12-16 2:37 ` Kyle Henderson
2011-12-16 4:32 ` Walter Stanish
2011-12-16 2:48 ` Matt Corallo
2011-12-16 17:23 ` Khalahan
2011-12-16 19:54 ` slush
2011-12-16 20:10 ` Amir Taaki
2011-12-16 20:14 ` Harald Schilly
2011-12-16 21:52 ` Khalahan
2011-12-16 22:05 ` Rick Wesson
2011-12-18 21:05 ` Jorge Timón
2011-12-18 21:18 ` Jordan Mack
2011-12-18 21:44 ` Luke-Jr
2011-12-18 23:58 ` slush
2011-12-19 1:13 ` Luke-Jr
2011-12-19 1:14 ` Pieter Wuille
2011-12-19 1:43 ` Luke-Jr
2011-12-19 1:44 ` slush
2011-12-19 7:56 ` Jorge Timón
2011-12-19 11:44 ` Andy Parkins
2011-12-19 14:46 ` solar
2011-12-19 15:35 ` Rick Wesson
2011-12-19 16:35 ` Luke-Jr
2011-12-19 17:13 ` solar [this message]
2011-12-19 16:30 ` Luke-Jr
2011-12-19 17:04 ` Jordan Mack
2011-12-19 17:09 ` slush
2011-12-19 18:13 ` Jordan Mack
2011-12-19 18:17 ` slush
2011-12-19 18:50 ` Jorge Timón
2011-12-19 20:03 ` Jordan Mack
2011-12-19 19:22 ` Jordan Mack
2011-12-19 18:15 ` Luke-Jr
2011-12-19 18:52 ` Jordan Mack
2011-12-19 19:16 ` Luke-Jr
2011-12-19 20:03 ` Jordan Mack
2011-12-16 8:35 ` Pieter Wuille
2011-12-16 16:03 ` Rick Wesson
2011-12-16 16:17 ` Pieter Wuille
2011-12-16 16:21 ` Rick Wesson
2011-12-16 17:21 ` Andy Parkins
2011-12-12 23:16 Zell Faze
2011-12-12 23:37 ` Jorge Timón
2011-12-12 23:41 ` Luke-Jr
2011-12-13 2:39 ` Stefan Thomas
2011-12-12 23:52 ` Matt Corallo
2011-12-12 23:37 ` Will
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=64F593B6-CF1C-4FF1-87B9-5C1E7A667A4B@heliacal.net \
--to=solar@heliacal$(echo .)net \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=luke@dashjr$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox