Have KeyBase publish itself as a public KeyServer

[EliW]

It would be an important step in KeyBase adoption IMO, for it to publish itself as a valid keyserver using the standard protocols for such.

As it stands, since keybase doesn't, it means that all the tooling (such as EnigMail for Thunderbird) that has existed for a decade+ ... is unusable against keybase published keys.

[mtougeron]

+1

[zQueal]

This would be a pretty advanced feature that wouldn't get too much traction IMO. It's entirely possible, I believe, but it requires you to have the complete version of gpg installed as it requires the gpgsm command line application. Also, this will not work with the method notated on the keybase website as they do not contain keys.

This would be very difficult, however, as the certificate request .pem would need to be signed by a recognized certificate authority (not free) to be valid. Then you could simply use the gpgsm command line application after you have imported your signed .key to export your .p12 certificate-key pair: gpgsm -o secret-key.p12 --export-secret-key-p12 0x000000

After that, you simply re-import the .p12 certificate into your system, and restart Thunderbird and you should have a fully functioning key. All that's left for you to do is to re-extract the certificate from the .p12 file and upload it to keybase.

Very convoluted if you ask me.

[EliW]

Xanza - I believe that we've "crossed mental paths here" on this. As what I am suggesting is the antithisis of an 'advanced feature', and instead something designed to make things much simpler.

And in fact, doesn't involve any command-line setup.

There are numerous tools, such as EnigMail for Thunderbird (just one example), that simply 'work' to encrypt/decrypt messages for you, and validate keys against valid public keyservers that are existing.

For example my configuration field from my own EnigMail:

If keybase.io would publish itself as a public keyserver, using the protocols designed for that. It would mean that people could just add something like: pgp.keybase.io into their list of servers. And magically EnigMail would start looking at keybase keys for validation/encryption purposes.

Without the need to go and manually do any command line, or copy/paste encryption from the website.

[asgrim]

What @EliW is suggesting sounds like something that should be possible - I'm not an expert in any of this by any means, but surely providing a directory of GPG keys aligns with Keybase.io's goals?

tl;dr: +1

[zQueal]

@EliW Oh, wow. I had no idea keyservers had that ability -- or that EnigMail worked like that.

I'm using the same public key for keybase that I am for my public key server http://pgp.mit.edu/pks/lookup?op=get&search=0x7715BB392D0019C4 and was able to set this up pretty easily.

Definitely a cool feature!

[ramsey]

+1

[calevans]

+1

[winks]

As much as I like this idea, as someone who has already implemented a key server and tried to host sks, onak and at least one more - don't underestimate this, running a keyserver is even more horrible than using gpgme or whatever bindings you use. Don't underestimate the effort. ;)

[EliW]

I am certainly not underestimating the effort. However it's an important step for Keybase to take for acceptance, and to work with the long existing community of cryptography that already exists.

[jcarouth]

+1

[adamculp]

+1

Without being able to "find" keys on Keybase.io using tools such as EnigMail, it is really useless at this point. However, this doesn't mean that Keybase needs to become a keyserver, if they push keys to already existing keyservers.

[jakerella]

+1

On a side note... why does github not have a "voting" mechanism for issues yet?!?

[damonjones]

+1

[leedavis81]

+1

[EricHogue]

+1

[moeffju]

:+1: This could actually even be done by a third party using the keybase API, couldn’t it?

[ramsey]

Yep. You can even sync your local GPG keyring with the servers, and it will transfer keys you "tracked" with Keybase, though I think this would be a valuable and important feature for Keybase to implement to promote the web of trust.

[EliW]

Moeffju : Actually from reading the API docs Moeffju, you can't. Because the API only allows you to lookup users by username. You can't query against an email address which is how keyservers work.

More importantly, I think this is something that would need to be done by Keybase.io itself. Because there are some limitations of how keybase itself is designed to work. That will make keybase publishing itself a little tricky. For example if you make a key on keybase, it only allows you to associate one email address with it. While keys traditionally/by-standard are built to allow you to associate any number of addresses, each address to have it's own trust level, and to even associate things like a photo, to help with identification.

Also at the moment, all of the keybase keys that you get from keybase, are sent to you as untrusted/unsigned keys in my keychain. There's no web-of-trust information from the others who have signed that key. Also, since once you are running a keyserver, someone can push keys to you that are fully fledged keys with multiple signatures and complicated web-of-trust information on it... which keybase doesn't currently support. With only the idea of 'user tracking user'. Not 'key owner signing key of key owner'.

So even if keybase changes it's API to allow for email-based lookups. I'd be wary using a 3rd parties implementation of a keyserver based upon this. Since I'd be concerned that it wouldn't be truly trying to 'play nice', as it were. If keybase themselves were to implement this. Then I expect that it would do the best job possible, making a 'match' between the keybase notation and the keyserver protocol's concepts. And that they would manage this into the future. (IE, if they start allowing web-of-trust levels of trust to be specified, they could retroactively adjust everyone's previous 1-level of trust that exists now)

[zQueal]

Moeffju : Actually from reading the API docs Moeffju, you can't. Because the API only allows you to lookup users by username. You can't query against an email address which is how keyservers work.

There is currently a feature request in right now that tests positive with the community. I'd say, although I have absolutely no bearing on whether or not it becomes a feature, that there's a very high probability that it'll be included in a future release as a feature.

So maybe it's not something you should count out just yet?

[boegh]

Just to chirp in: +1 from here as well.

[notpushkin]

:+1:

[olea]

+1

[neersighted]

:+1:

[konklone]

Big :+1: here. Though it sure sounds like work, a keybase keyserver could make a great connector between keybase's current community and the existing community of people who have been using PGP in practice for some time.

And ccing @thisisparker, a friend who actually uses Thunderbird+PGP a good deal.

[WayneBooth]

+1. Keybase is a no go until is aligns itself with the standard workflow of key management. They means keyservers.

[cartel0x27]

+1. Not a lot of work at all if the api is extended to allow lookup by email address.

[zQueal]

Keybase is a no go until is aligns itself with the standard workflow of key management.

This really struck me as odd. You're saying you refuse to use a tool until it functions the same way as the other hundred thousand CLI PGP tools out there? It might have just blown over my head, but it seems rather counter productive to create new software and make it the exact same as old software; hell, even to compare it to old software is a bit moot.

[timbray]

I’d argue that the current “standard workflow” of key management has significantly failed, judging by the proportion of non-hardcore-geeks who use it. That proportion, last time I checked, rounds to 0.00000%. Something new is urgently called for if we want any chance of getting private communication into the mainstream.

[cartel0x27]

This isnt about working with old tools, its about working with current tools. Thunderbird+Enigmail, PGP Desktop and straight up GPG all have builtin support for keyservers. By requiring someone to download and install another application you've already raised the barrier to entry. It is better to just add keyserver support and bring the existing install base into the fold.

[ramsey]

I also think the standard workflow for PGP has failed, but we can take two paths here: we can make the standard workflow better by introducing better tools, or we can create new standards with different workflows.

PGP is still a good standard. The Web of Trust is still a great concept. They're just difficult to use. I like the idea of making better tooling around them, making it easier for even non-techies to use.

This is why I'm asking for Keybase to support key server integration, but it's far from an ultimatum for me. I like the Keybase tech and ideas and will continue to follow it with great interest. :-)

[konklone]

PGP is still a good standard. The Web of Trust is still a great concept. They're just difficult to use. I like the idea of making better tooling around them, making it easier for even non-techies to use.

This is why I'm asking for Keybase to support key server integration, but it's far from an ultimatum for me. I like the Keybase tech and ideas and will continue to follow it with great interest. :-)

Yes, this is exactly it. Keybase is doing great work and is getting better. Keyserver support, while potentially tricky, is a great way to unify the growing Keybase audience with the traditional PGP audience. Those audiences are going to have to meet somehow if this is going to work out.

[gburd]

+1

[johanmeiring]

+1 :-)

[timbray]

Having had a close look both at the Keybase API and the public-keyserver API, it should be said that the latter is a kludgey semi-structured mess. I suspect that implementing it would be highly nontrivial.

[konklone]

Semi-relatedly, Keybase just released their own brand new PGP JS/Node implementation today: https://keybase.io/kbpgp

[forquare]

+1

[pathawks]

:+1:

[segfault]

:+1:

[msjyoo]

+1

[victorhaggqvist]

+1

[wsargent]

+1

[ghost]

I agree with @timbray and @ramsey that PGP key management via keyservers and keysigning/web-of-trust has failed, more or less, entirely miserably. I don't even need to get into why.

That doesn't mean that the public key system is broken. Just the way in which they are disseminated and trusted. That's where Keybase can step in. Enigmail and GPGTools can also be built to hook into Keybase instead of standard keyservers.

The matter at hand is, should Keybase be built to interact with this system or should it be more or less separate? I would say that a break with the past could be provide a lot of opportunities for innovation, while interactivity/backwards compatibility is probably not worthwhile except for the small numbers of people who have been using encrypted mail until now - as opposed to the much higher number of people who have never even tried to use it.

[EliW]

Except jlb1234 -- By not having interactivity/backwards compatibility ... it means that all the staunch advocates of PKE in the past, who have continued to use it and preach it's wonders in the past ... are excluded from Keybase. Even if the backwards compat wouldn't be used but by a 'small portion'\ of users. Those users are the ones who have shown consistently that they care and are vocal. Those are absolutely the users that you want on your side.

\ Given that ~30 people above by my counts here have given this a +1, I doubt that the portion is 'all that small' in the end.

[gimsieke]

+1

[wsargent]

Given that ~30 people above by my counts here have given this a +1, I doubt that the portion is 'all that small' in the end.

As one of the people who voted +1, I'd like to say I want an end to the cruft, and I want fresh new implementations of key servers that aren't bogged down with 20 years of history. I'd like it to work with Enigmail, but I'd also like it not to suck.

[malgorithms]

Hi all - just so you know, we care about this. It's just unclear how to proceed, and we'll wait until Keybase is further along to address this.

There are 2 separate issues:

1. does keybase accept keys from other servers?
2. does it push to them?

for point 1, it's not simple. A key according to keybase requires a provable connection to an identity somewhere. We're not an email->PGP key service, like the others. At least not until there's a convenient way for someone to prove they own an email address, publicly. (This is discussed elsewhere in this repo.)

Plus, unlike the traditional key servers, we're striving for a canonical ordering of key announcements. Your keybase signature chain is a series of announcements: adding a proof, removing a proof, adding another proof, then another, adding a bitcoin address, things like that. Each of these links in the chain points at the previous. The goals of this system are important: (1) preventing the server from lying by omission, and (2) making sure the server gives the same answer to everyone in the world.

Contrast this with a traditional key server, which could withhold whatever it wants.

I'm not saying this totally prevents us from gossiping keys around, but it does show that keys we bring in need to be treated in a way that has nothing to do with keybase.

As for point 2, pushing keys to other servers, this interests us and should be simpler. Eventually.

Also, one last thing: it requires very few API calls to keybase to mirror our entire database and prove to an outsider that you've mirrored it accurately. This means that anyone could implement a layer that pulls keys from Keybase and pushes them to other servers or just acts as a lookup mirror. Just saying :-)

This latter point can be useful for people who worry about metadata leakage. If you don't want a powerful adversary to know you need foobar's public key, it might be nice to maintain/use a server that you trust that mirrors keybase and checks all the proofs for you.

The TL;DR here is we don't have anything planned in the short term. Pushing is possible in the medium term.

Also, I have found myself paraphrasing this a bunch:

As much as I like this idea, as someone who has already implemented a key server and tried to host sks, onak and at least one more - don't underestimate this, running a keyserver is even more horrible than using gpgme or whatever bindings you use. Don't underestimate the effort. ;)

[maxtaco]

(And BTW, there's a discussion on #1266 on how to go about mirroring.)

[ramsey]

I thought this was an interesting read about the problems with PGP/GPG, and I felt it was relevant to this conversation: http://www.thoughtcrime.org/blog/gpg-and-me/

[malgorithms]

I recommend this:

http://blog.cryptographyengineering.com/2014/08/whats-matter-with-pgp.html

[notpushkin]

@ramsey The problems Moxie describes in his post are exactly the problems Keybase is trying to solve, don't you think?