Clarify whether non human public entities can have a Keybase account

The Keybase interface is remarkably useful from a company perspective to allow companies to verify their contributions or for ease of receiving confidential information.

For example depending on the situation it may be permissible to have a partner generate some shared key and then send it to your company via a PGP encrypted message using the Keybase UI to generate this message even if they have never themselves signed up. This may sufficiently harden some other less secure communication channel such as email. Or permit a reasonable level of non-repudiation if the sender also has a PGP Key / is registered on Keybase.

Furthermore organisations can have things like Twitter accounts, Websites etc so a good chunk of the current options should work for proofs. Sadly not the gist option unless it could be exposed as a full public repo instead of specifically as a gist.

As long as the login details are held by a trusted group of individuals such as the systems administrators I see this working quite well to transfer reasonably sensitive information due to the client side nature for sending and ease of use for non-technical users. However Keybase is described as a public directory of people so it is unclear whether other public entities with a designated controlling group such as companies can have their own Keybase presence. I see no technical reason why this would not work albeit with the caveats that the necessity of sharing the login details reduces the security level possible but it is unclear from the terms whether this is permitted.

The idea of Keybase for entities has been passed around before. To my recollection the idea had positive feedback, but I don't think any decision was ever passed. Mostly the Keybase team is working on getting the Go client pushed, and then will be back to adding and perfecting features of the client and service. But I really agree. Keybase for organizations is really needed and necessary for wider adoption.

it may be permissible to have a partner generate some shared key and then send it to your company via a PGP encrypted message using the Keybase UI to generate this message even if they have never themselves signed up.

This may sound like a great idea, but it almost completely defeats the purpose and idea of Keybase as a whole. The entire concept is for people to feel relatively comfortable that those they're in contact with, or which to contact are exactly who they say they are. If Keybase were to allow any internet entity to generate a key (such services already exist) there is zero guarentee that the person contacting you actually is the person from whom your expecting communique.

This is obviously just my opinion, but it doesn't seem too sound. The only solutions around this that I can think of would involve some hefty programming and an extremely convoluted method which would have an extremely small niche use case. It might be helpful to some, but I wouldn't hold your breath on this becoming a feature at all, or at the very least any time soon.

I was actually referring to only using the key on the recipient side. The client does not need a key to generate a message only the recipient can read, merely to identify themselves as the originator. Keybase is meant to work both ways certainly, but I for example was recently stumped on how I could get a secret shared key for API authentication by a third party. It does not actually matter in that context, at least not so much, that the sender is who they say they are as, if they are not, the integration simply wont work as they will need to use the key as a salt to generate valid requests to our API, so any man in the middle attacks etc simply wont work. The adversary would likely be able to call our API for a while of course, but assuming we go via our staging environment first we would catch the mistake before they were able to access real information from production as the client would not be able to make valid calls so we would simply disable that key and try again. The concern in this instance is simply to protect the key from being read by anyone intercepting the communication or coming across it i.e. in my email client if my machine was compromised.

I considered one-time read ephemeral messaging systems where if I was not the one to read it the message would be unavailable and thus we could simply try again, but this requires a third party involvement which you then need to trust and many of them don't truly delete the message. Simply publishing our public key and instructing the partner to encrypt and send the key is more viable, but with non-technical users explaining something like PGP is a long slog and not likely to go well if my experience of even just trying to get people to install basic programs is a good indication. If I can just direct them to a website in this case https://keybase.io/encrypt#mycompany and say "type the key, press encrypt and email me the page of nonsense that appears" or "... and add the page of nonsense as a comment on the ticket" that is sufficient that relatively non-technical users can send a key or other private data to my Company with confidence they have sent it to my company and it could not be reasonably read by most potential adversaries that may intercept the email.

Of course I'd rather generate the key myself and do the inverse, but unless they either gain the expertise and confidence to use PGP/RSA or something similar themselves or sign up to Keybase this is not possible, but it is easy to work around by simply having them generate the key. Keybase in this case, is allowing identification of my company (even with its current functionality assuming it is permitted) using for example website and twitter for verification and guaranteeing that only I can read it.

If we are to charge the partner for use of our API we should do everything we can to ensure that on our side the key can't leak and thus adversaries cannot generate valid calls to our API. Of course, I could already do this using my personal Keybase account, however really I should not know the key either, only the person who can place the key in our encrypted config management system should really be able to decrypt it, but for us, that means the four people in our systems group should be able to look it up. Really it should not be bound to just me as I am a single point of failure, hence the idea for a company account. If we have a company account we can have anyone that needs to send us something private do so with confidence. That was really the krux of my question here; is it actually permitted to for example invite the systems group from my company i.e. systems@mycompany.com and setup a Keybase account for this purpose with a password known only by that group. Any liability for the failure of this approach obviously should not be applicable to Keybase looking at the current Ts & Cs but, I think it is the best option for solving this problem and of course, if I can convince the other group to also create an account then it is even better and encourages secure communication simply by making it not too much of a hassle.

There are still issues with this approach of course, the partner's machine could be compromised etc, but from our perspective we have done what we can and it is far better than what we have right now. I just didn't want to be hit with some kind of cease and desist for trying it out even just with the current Keybase functionality, just pretending my company is a "person".

Traditionally people have sent these sorts of things via plaintext email, over the phone (very prone to error) or via encryption using something symmetric like AES but then sending the key for that ciphertext is also hit by the same issues. Short of physically delivering them the key this was the best option I could come up with.

+∞

I "solved" this for my company by creating a new repository and adding a README. It doesn't integrate nicely with the rest of the Keybase experience, but it is publicly-auditable.

https://github.com/wepay/keybase

Thanks @skyzyx nice idea. I'll leave the ticket open still because I still feel this usage should have more first class support eventually. It is a really useful way of transmitting codes etc to a keybase enabled party.

keybase / keybase-issues

Clarify whether non human public entities can have a Keybase account #1757