rich1.0npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgydhttps://nostr.ae/npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgydnjumphttps://nostr.ae📅 Original date posted:2012-11-27 📝 Original message:Luke-Jr - common subset of what operating systems ship is fine for me as long as people do due diligence around mobile OS' here. It seems easier to me to just grab a list from a popular browser, on the grounds that SSL is mostly used by them so nobody is going to buy an SSL cert rejected by IE/Firefox/Chrome/etc. But intersecting OS lists is effectively the same. For my own clients I'd just ship my own copy of the canonical CA certs regardless, because integrating with each operating systems proprietary crypto APIs is a lot of work vs just loading a pem file into OpenSSL. If there are a lot of people who want to use the OS cert management UIs then I guess that can be a point wallet clients compete on. > Removing that and adding a opaque string called domain name, or > identityName would be sufficient to move the conversation forward > without the x.509 baggage. But it would result in implementations that do not meet the requirements. Yes, X.509 has problems. It's in the proposal because we can get the effect we want (verifiable domain names in the UI) in about 50 lines of code, today, with the id-verified keys people actually have already bought. As Gavin says, we can add optional fields later to extend the protocol in a backwards compatible way.