This idea was brought up by Domob here and was further discussed here.
I just ran across the Skier keyserver (Python): https://github.com/SkierPGP/Skier
It looks like it is too much for this purpose but may be helpful in creating a minimal local server. E.g. to be used in NMControl.
[edited]
Namecoin Local PGP Keyserver
Re: Namecoin Local PGP Keyserver
> It looks like it is too much for this purpose but may be helpful in creating a minimal local server
A recent commit makes it possible to "thin" the server: "Allow enabling or disabling of certain, more bloaty Skier features.":
https://github.com/SkierPGP/Skier/commi ... a3896bb1ba
Edit: Maybe the source of this Thunderbird plugin could be modified to talk to Namecoin (instead of OpenLDAP).
A recent commit makes it possible to "thin" the server: "Allow enabling or disabling of certain, more bloaty Skier features.":
https://github.com/SkierPGP/Skier/commi ... a3896bb1ba
Edit: Maybe the source of this Thunderbird plugin could be modified to talk to Namecoin (instead of OpenLDAP).
Secure Addressing 1.6
by Hiroya Matsuba
This add-on provides features to avoid sending emails to wrong addresses. Key features are a confirmation window of recipient's addresses upon sending, name and affiliation look up at mail composition and main windows, and safe auto completion.
Re: Namecoin Local PGP Keyserver
That certainly is an improvement. What I had in mind was a very simple bottle request.somename wrote:> It looks like it is too much for this purpose but may be helpful in creating a minimal local server
A recent commit makes it possible to "thin" the server: "Allow enabling or disabling of certain, more bloaty Skier features.":
https://github.com/SkierPGP/Skier/commi ... a3896bb1ba
Any objections to a bounty for an NMControl plugin?
Hmm this looks more complicated. Also the keyserver approach should work with every mail client.Edit: Maybe the source of this Thunderbird plugin could be modified to talk to Namecoin (instead of OpenLDAP).
Secure Addressing 1.6
by Hiroya Matsuba
This add-on provides features to avoid sending emails to wrong addresses. Key features are a confirmation window of recipient's addresses upon sending, name and affiliation look up at mail composition and main windows, and safe auto completion.
Re: Namecoin Local PGP Keyserver
I had completely missed we already have a bounty for this. Maybe I should take a break.
Still, how would this work? Search the keyserver for id/user and have the keyserver reply with exactly one key? This would mean the keyserver would have to dig through the whole id namespace.
Still, how would this work? Search the keyserver for id/user and have the keyserver reply with exactly one key? This would mean the keyserver would have to dig through the whole id namespace.
Re: Namecoin Local PGP Keyserver
This is no big issue, I think. Currently (~5000 id/ records) reading in into a simple cache array takes less than an hour using name_show. Probably much less with name_filter or a new purpose-built RPC. Even if we have half a million ids this doesn't take a lot more time as most CPU time is wasted separating the 600000+ d/ records.phelix wrote:This would mean the keyserver would have to dig through the whole id namespace.
After this cache setup the keyserver could permanently listen to incoming blocks, extract any id content from a new block and update the cache.
Re: Namecoin Local PGP Keyserver
Actually "name_filter id/" takes only 10 seconds or so. Maybe this is the way to go for now.cassini wrote:This is no big issue, I think. Currently (~5000 id/ records) reading in into a simple cache array takes less than an hour using name_show. Probably much less with name_filter or a new purpose-built RPC. Even if we have half a million ids this doesn't take a lot more time as most CPU time is wasted separating the 600000+ d/ records.phelix wrote:This would mean the keyserver would have to dig through the whole id namespace.
After this cache setup the keyserver could permanently listen to incoming blocks, extract any id content from a new block and update the cache.
Re: Namecoin Local PGP Keyserver
The way I assume this should work is by getting the actual key from a keyserver. Tor support could be added but it still is not very nice. Alternatively we could store the key in the blockchain (my pubkey is ~1200 bytes - 3 names/values). Opinions?
Re: Namecoin Local PGP Keyserver
I think we shouldn't put pubkeys into the blockchain. Instead, I agree with phelix that getting the key from a keyserver over Tor and verifying the fingerprint against the blockchain seems fine. Doesn't the id/ format also allow to specify a link to the pubkey if hosted somewhere? This (if present) could also be used.phelix wrote:The way I assume this should work is by getting the actual key from a keyserver. Tor support could be added but it still is not very nice. Alternatively we could store the key in the blockchain (my pubkey is ~1200 bytes - 3 names/values). Opinions?
BTC: 1domobKsPZ5cWk2kXssD8p8ES1qffGUCm | NMC: NCdomobcmcmVdxC5yxMitojQ4tvAtv99pY
BM-GtQnWM3vcdorfqpKXsmfHQ4rVYPG5pKS
Use your Namecoin identity as OpenID: https://nameid.org/
BM-GtQnWM3vcdorfqpKXsmfHQ4rVYPG5pKS
Use your Namecoin identity as OpenID: https://nameid.org/
-
- Posts: 2001
- Joined: Tue Jun 05, 2012 6:25 am
- os: linux
Re: Namecoin Local PGP Keyserver
Will ECC pubkeys fit in the blockchain acceptably? I think GPG has added support for them in beta versions. (Not certain on this.)domob wrote:I think we shouldn't put pubkeys into the blockchain. Instead, I agree with phelix that getting the key from a keyserver over Tor and verifying the fingerprint against the blockchain seems fine. Doesn't the id/ format also allow to specify a link to the pubkey if hosted somewhere? This (if present) could also be used.phelix wrote:The way I assume this should work is by getting the actual key from a keyserver. Tor support could be added but it still is not very nice. Alternatively we could store the key in the blockchain (my pubkey is ~1200 bytes - 3 names/values). Opinions?
Re: Namecoin Local PGP Keyserver
Yeah they should fit. This would be cool. But with my enigmail I can not create ECC keys so we should probably allow other methods, too, and maybe postpone this a bit.biolizard89 wrote:Will ECC pubkeys fit in the blockchain acceptably? I think GPG has added support for them in beta versions. (Not certain on this.)domob wrote:I think we shouldn't put pubkeys into the blockchain. Instead, I agree with phelix that getting the key from a keyserver over Tor and verifying the fingerprint against the blockchain seems fine. Doesn't the id/ format also allow to specify a link to the pubkey if hosted somewhere? This (if present) could also be used.phelix wrote:The way I assume this should work is by getting the actual key from a keyserver. Tor support could be added but it still is not very nice. Alternatively we could store the key in the blockchain (my pubkey is ~1200 bytes - 3 names/values). Opinions?