For GPG:
Since the keys are managed by GnuPG itself and things like Enigmail are layered on top, where do you think we could plug in the authentication best? Still for instance as patch to Enigmail with a new function "verify from namecoin"? It could work like this: I select the key if I already have it, choose "verify from namecoin" and enter the namecoin id I know this key should belong to. Then the key is signed if it matches the namecoin identity. Furthermore, one could also implement a "import from namecoin" function that also fetches a key given the URI in the namecoin identity. It would then display the GPG uid of the fetched key (so I can check it matches the name / email address I expect from the user) and allow me to sign the key if I like it. Do you think this all makes sense like that?
Further ideas: Since namecoin identities can also contain a name and/or email address, we could also check this against the GPG uid if applicable. The general problem I see with GPG verification is that the GPG key won't be imported as "id/domob" but still as "Daniel Kraft <d@domob.eu>", so even if the fingerprint is verified against the namecoin identity the user still needs to confirm he/she actually expects "id/domob" to show up as "Daniel Kraft" later on for GPG. That's not a big problem in my opinion (especially not for key exchange between people who know each other personally or at least online already), but I think it needs some thought.
For OTR:
Here similar things arise. When I verify that the OTR key of someone matches "id/domob", do I also want to verify that the XMPP address matches the one in "id/domob"? What do I do for a user with multiple OTR keys for different devices? What if there's no public XMPP record or OTR is used for a protocol different than OTR? So I think again matching an XMPP contact to a namecoin id has to be done manually. Thus I propose the following implementation:
Patch the Pidgin OTR plugin (because that's what I use
), or maybe write another plugin, so allow a fourth verification option: "Verify by namecoin". If I choose this, instead of a shared secret I can enter an arbitrary id/ name which I know by other channels to be owned by my chat partner. Then the key is verified if this name matches the other's OTR key. As mentioned, I'm still responsible to manually connect my chat contact to an identity name, but that should be fine. What do you think about this suggestion? I think it may be quite easy to implement (once I work my way into Pidgin plugins).AFAIK, there's not yet an "official" proposal for how to store OTR keys in identities. Since there's as mentioned the possibility to have multiple keys for different devices (or accounts with different protocols that are still owned by the same person), I suggest to add the field "otr" which can be either a string giving the fingerprint itself or an array of strings, where the verification succeeds if any element matches the key. Does that make sense? Do you think we should, especially in the latter case, somehow associate each key also to an account / XMPP resource? But I think that's not necessary - if I state that a list of keys is controlled by me, that I think it is safe for anyone to assume that every of those keys is acceptable to contact me. It doesn't matter to which chat account a key belongs.
UPDATE:
I've started work on integration for the Pidgin OTR plugin, with my code available from git on my server:
Code: Select all
git clone -b namecoin-verify https://git.domob.eu/pidgin-otr-nmc.git
(Or by an address designated as "allowed signer" by the domain name's value field, see discussions in other threads.)
