keybase-issues

keybase-issues copied to clipboard

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.

+1

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.

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.

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

@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!

+1

+1

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. ;)

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.

+1

+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.

+1

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

+1

+1

+1

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

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.

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)

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?

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

:+1:

+1

:+1:

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.

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

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

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.

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.

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.

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. :-)