{"type":"rich","version":"1.0","author_name":"npub1vf6uu3xanv8q5tt7vckle9s3e3z2zzkce5p5pr6x47nh32xwcj8q8a8meq","author_url":"https://nostr.ae/npub1vf6uu3xanv8q5tt7vckle9s3e3z2zzkce5p5pr6x47nh32xwcj8q8a8meq","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2011-12-19\n🗒️ Summary of this message: Using commercial CAs for trust is a site policy, but not necessary. Self-signed or CA certs can be used. DNSSEC and HTTPS can also establish trust.\n📝 Original message:Using commercial CAs to establish trust is a site local administrative policy..\n\nBitcoin 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.\n\nRick 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.\n\nI 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.\n\nIn 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.\n\nI 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 :)\n\nMaybe 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.\n\nBeing 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.\n\nLaszlo\n\n\n\nOn Dec 19, 2011, at 4:35 PM, Luke-Jr wrote:\n\n\u003e On Monday, December 19, 2011 6:44:59 AM Andy Parkins wrote:\n\u003e\u003e Perhaps we should be more strict about which CA certificates are trusted by\n\u003e\u003e the bitcoin client: say restrict it to those who have demonstrably good\n\u003e\u003e practices for verifying identity; rather than the ridiculous amount of\n\u003e\u003e trust that comes pre-installed for me in my browser.\n\u003e \n\u003e Accepted CAs is/should be a property of your *operating system*, not any \n\u003e particular software. Anyhow, restricting this further just makes it even more \n\u003e unusable. Already there is only 1 or 2 CAs that will provide a gratis \n\u003e certificate for personal/small users. If you only allow high-class CAs, I \n\u003e imagine that will restrict \"no key in the URI\" aliases to those who will fork \n\u003e over a lot of money.\n\u003e \n\u003e ------------------------------------------------------------------------------\n\u003e Learn Windows Azure Live!  Tuesday, Dec 13, 2011\n\u003e Microsoft is holding a special Learn Windows Azure training event for \n\u003e developers. It will provide a great way to learn Windows Azure and what it \n\u003e provides. You can attend the event by watching it streamed LIVE online.  \n\u003e Learn more at http://p.sf.net/sfu/ms-windowsazure\n\u003e _______________________________________________\n\u003e Bitcoin-development mailing list\n\u003e Bitcoin-development at lists.sourceforge.net\n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development"}