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 ------------------------------------------------------------------------------ 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
