javgh
commented
10 years ago I'm not necessarily against this, but I think it doesn't really solve many problems and has a few disadvantages.
First, can we agree that there isn't really anything special about a PGP key server? For the most part, it's just a server where you can upload a data record. A data record like: PGP keys + name + email + photo + Bitcoin address. You could upload the same record to a Hive directory server instead. Sure, it's nice that there is existing infrastructure, but some server that can store small snippets of data isn't exactly a lot work. Then you might say, that PGP key servers have the advantage of being compatible with existing PGP software. But I think that's a pretty small advantage, because - let's face it - essentially no one uses PGP. So our typical user won't be saying: Oh, sweet, this uses a PGP key server under the hood, I can just hook xzy into it.
The biggest disadvantage on the other hand is, that all the stuff on PGP key servers is publicly available. So we would be asking our users to please provide a name, photo and email address, then turn around and upload their data to the open web. This is an absolute no-go in my opinion and would need to be opt-in, which raises the question of what to do if the user does not opt-in. I think Matt & co. spoke about the ideas of Hive public pages needing to be opt-in as well, so it seems they agree on this privacy aspect.
When you want to know who to communicate with or an address to send tokens to, look up the users PGP key on the key servers (via email address or fingerprint).
Now we get to the email verification part: By default, emails listed on PGP key servers aren't verified in any way. So you can just upload a new key for any email address you want and in fact someone other than Gavin did that for gavinandresen@gmail.com for example ( http://gavintech.blogspot.de/2014/03/it-aint-me-ive-got-pgp-imposter.html ).
So even if we uploaded all our users to PGP key servers, you still couldn't simply look someone up via their email address, because you don't know whether the entry is genuine.
I suppose it would be possible for us to verify the email address, only then upload the data record and in the data record have something like "This email was verified by Hive, verify this fact by going to hivewallet.com/hasbeenverifiedbyhive/gavinandresen@gmail.com ". That makes us the authority on whether the owner of that email address asked us to create the data record. But the reason for using PGP key servers was presumably to allow other wallets to participate. So if Dark Wallet wants to support that, they do the same thing and upload data records with them as the verification authority. Now we need to decide which other verification authorities we trust to have done that properly and if any of them get compromised, you have the potential of malicious data records again.
So the main problems I see are:
- it's world-readable, can only be a opt-in option
- you can't rely on the data record being valid, unless you do verification
- if you do verification in a way that is compatible with other wallets, you quickly approach the complexity of X.509 certificate management
I proposed XMPP in the past as the underlying infrastructure for Hive and I think that plays into this aspect as well. XMPP user profiles ( http://xmpp.org/extensions/xep-0154.html ) can also contain PGP keys and other stuff. So let's say we run an XMPP server at hivewallet.com and give our user's something like alice@hivewallet.com or alice@jabber.hivewallet.com . Then you can look up users by their Hive Jabber ID, which - granted - is not their email address, but at least email-address-like.
Other wallets might eventually run their own Jabber servers and bob@jabber.coinbase.com would be fully compatible with Hive wallets and vice versa. Individually users can even run their own Jabber server and maybe, in some distant future, your email address turns into a Jabber address which is also Bitcoin-enabled, at which point you could finally lookup someone via their email address and be sure to get the right person.
The big advantage of XMPP user profiles is, that - if I'm not mistaken - you can limit them to user's that you have added to your roster (XMPP speak for "contact list"). So that takes care of the privacy aspect mentioned above. You would add another user by entering their Jabber address / Hive username into Hive and only after they accept your invitation, do you get access to their name, photo and Bitcoin addresses.
The third alternative would be Mike Hearn's network of store-and-forward HTTP servers. So instead of uploading a user record to a PGP server or providing it as a XMPP user profile, you would instead have it hosted on a web server somewhere (essentially the Hive public pages we discussed before) in such a way, that it can it be viewed with a standard browser, but also be downloaded in a machinable format (presumably structured like a payment protocol request, but with photo and other data). This also raises the privacy question again though and whether it would be necessary to access-protect that webserver in some way.
I still think that XMPP is a perfect fit for a store-and-forward network, as that's what it does exactly. But I guess there is also merit to use a HTTP-based infrastructure for that instead. We can discuss that further in the communication layer ticket.
In summary, my preference would be for either the XMPP- or the HTTP-based solution and only as a distant third option using the PGP key servers, because of the problems listed above.
Cryptoidentity
Apologies for any rambling/unclarity. As this is a braindump, please ask questions to seek clarity.
PGP keys can store arbitrary data within the pubkey. This is most commonly implemented/demonstrated as the photo which can be attached. In this way, the only "official" subpacket type ("1")is Photo/JPG. Doesn't stop additional subpacket extension. For example, cryptocurrency keys/addresses could be stored as a separate subpacket types.
This is what was working on in the Mailvelope fork (including openpgpjs dependency fork). The data can be used to store a plain Bitcoin address, stealth address, Master Extended Public Key, etc. Just depends on interpretation. Our interpretation in Mailvelope was to display whatever subpackets could be defined, starting first with interpretation of the JPG data, then prototyping a packet type "100" containing a cryptocurrency address.
Because PGP keyservers already act as a distribution mechanism for identity information, we could piggyback that implementation by simply understanding how to interpret the subpacket type containing a payment tree. And because PGP is inherent message communication, users have a natural method for encrypted communications. This puts our foot in the door to unify our "Send" interface to exist for more than just a token amount. In other words, sending cryptocurrency not much different from sending a message. Just select the identity and set the data (whether it be Bitcoin or PGP email).
When you want to know who to communicate with or an address to send tokens to, look up the users PGP key on the key servers (via email address or fingerprint). If exists and has valid subpackets for the specific data we want, we can fetch the user's photo, email, name, PGP pubkey, crypto MPEK, etc.
How could this work within the confines of a wallet, i.e. Hive? If you have no PGP identity, create one perhaps based off 12 word seedphrase. If you do have a PGP key, import and associate cryptotoken subpackets with. Hive can manage automated fetches & updates from/to the PGP keyservers. Could be taken steps further and optionally move away from PIN in favor of unlocking identity with PGP password since PGP could be used to encrypt local data. User password -> PGP secret -> decrypt local data.
Other wallets could implement similarly without any new "standard" except how the new subpacket types are defined, which Peter Todd may be happy enough to provide some guidance. All the tools necessary for this are built into common gpg toolkits & a PoC implementation was already done in JavaScript. ObjC should be trivial to implement basic encryption/decryption & signing/verifying with something as crude as GPG command line tools if nothing else.