Team Management

[mieko]

Hey Keybase Team,

I'm a big fan of what Keybase is doing, and I sort of see it at PGP's and real electronic identity's last hope. I know you've got your hands full with kbfs, the site, and the dozens of apps that every software startup has to produce these days, so I'll try to keep my non-technical pontificating as short as possible.

I started a new identity at Keybase today, but I got an invite pretty early on. I was reminded to check out Keybase again because I was tweaking the following internal document of ungodly length, yet again, to clarify the steps:

Gist: Getting a Key, and Obtaining Unlocked Access to the Repo

I don't expect you to read it, because that's the problem: that excerpt is only about the middle third of the total document, which also includes steps to install GPG for various platforms, how to fix broken symlinks in homebrew-installed gpg1 vs gpg2, how to revoke access, etc.

I like Keybase, but I've always been a crypto nerd. I'd like it anyway. I like that I have these proofs on my account, but I know there's a very real chance they'll never get used. My first PGP key, which lived from 1998-2003, and was published everywhere, and was probably only used 15 times, due to having to explain steps like the above document. That doesn't matter to me, though: I like the ideas and ideals of what Keybase is trying to do, and during the beta-meantime I'll invite and explain what it does to anyone I think may be interested.

However: Securely managing a collection of employees', contractors', and generally distributed team's keys, built on top of Keybase's ease-of-use (vs. the alternative) would get used dozens of times a month. I don't know what the solution would look like, or if it'd involve terms like "orgs" or "teams", "signed, sync'd keychains", "email domain verification", but anything that'd even cut the above document by a third would be worth a recurring monthly payment. It'd be a rage-induced impulse buy the next time I had to walk someone through the above document.

I think Keybase has thought the hardest about both the usability and security sides of situations like these. I don't know what the roadmap looks like, but I also believe Keybase has the best opportunity to provide a solution to organizations that already have these issues, and perhaps create a larger market of organizations who would have these more secure infrastructures in place if the process weren't so onerous.

Just a thought. Thanks again, and good luck.

[zQueal]

Securely managing a collection of employees', contractors', and generally distributed team's keys, built on top of Keybase's ease-of-use (vs. the alternative) would get used dozens of times a month.

Could you elaborate a bit more on what you mean here? I'm a little confused with the concept.

[mieko]

Well, here's something I started playing with shortly after the diatribe, based on functionality Keybase currently provides. Keep in mind this is just a duct-tape thought experiment:

I set up a Github repo with org-only access controls. It basically works like a keybase.txt.d. It builds a keybase.txt from all of the example.com https proofs members have committed to that repo. Through the magic of Github Pages and a reverse proxy, that file ends up published from my company's /.well-known/keybase.txt.

So here's what this buys me, so far:

1. I can control who is 'a member of my team', as far as Keybase identity is concerned, via write controls on that repo: That's cool. Re: eggs/basket, it's as good as any for defining "membership".

2. A (trusted) team member can say things like "Allow access to keybase ID jappleseed" to a system. And a script can keybase id jappleseed to confirm that he or she is:

   ✔ admin of example.com via HTTPS: https://example.com/.well-known/keybase.txt

   That's cool.

3. Even better, if a member, over a trusted/authenticated channel, tells me (or a script) "Hey! I'm jappleseed+example.com@https", software could id that directly, and it either succeed or fails.(Note: I don't know if the + syntax is documented, I just guessed that it would work. However, it'd be nice to have some special-case sugar for this e.g., jappleseed@https://example.com or https://jappleseed@example.com.)
4. I don't know how this plays with Keybase's "New Key Model", but if I (or a script:, I know I keep saying that, but the automation is what's important to me) need a PGP public key for a member, I can just pull it, currently after a dance ofjappleseed+example.com@https ->id at Keybase -> https://keybase.io/{keybase_id}/key.asc. It'd be cool if I could pull it just keybase get-key jappleseed@https://example.com
5. And because this is Keybase, and not some weird LDAP directory, I know what other social media accounts to "trust" in relation to members of my org, for example, with a hypothetical \@medium proof method, would allow me to automate who can post on the company blog, etc. Hell, in the far-future, it'd be cool for Keybase to be THE provable source of truth for membership (vs. "Welcome Aboard! What's your github?, Alright, What's your medium account? OK, here's how to get a PGP key. What's your keyid? Fine, just send me the public key. No, the public key, start over. OK.")
6. With a small wrapper, I should now be able to do things like: git-crypt --add-keybase-user jappleseed@https://example.com, knowing that the person has been authenticated as a member of "example.com", and I can get their public key without a too many crazy steps on their side. Edit: Even better, perhaps git-crypt --sync-keybase-team https://example.com/

Now here's where the hack falls apart (and would maybe need some "Team Management" features from Keybase to hold up):

1. I cannot enumerate 'admins of https://example.com', presumably for the same reason I can't enumerate all reddit proofs, which makes sense. Well, I can, but a script would have to know about my repo, or my .well-known/keybase.txt, and would get something wrong. The idea being, a script could update all sorts of third-party social media and internal access controls based on the answer to "What is the list of admins @ https://example.com" as a source of truth. I think the API supports this, though ("ambiguous Identify").
2. If I had a way to refer to such a group by name, I could do things like encrypt files via KBFS to "@example.com" to represent all organization members.
3. I have no way to "revoke" membership. Where here, "revoke" just means "clients, and keybase.io, just drop your caches for anything re: proofs obtained from https://example.com". Obeying the Expires: HTTP header would probably cover this. (This may already be true, haven't really investigated too deep.)
4. Well, it's just "admin of https://example.com/". I could extend the misery of this hack into "teams" via creating sets like "admin of devel.example.com" and "admin of qa.example.com" and building out the appropriate infrastructure, but you know.
5. Then of course political issues: Here, I see no value in hiding "admin of" lists to the public. Presumably other companies will, and presumably some employees will. I don't know how keeping everything publicly verifiable plays into this. All that would really matter for cases like this would be that other org members could verify this. In my case, I'd get value by being able to pull the list un-authenticated anyway.

Some of this stuff sounds really nerdy, but I'm imagining what could be built on Keybase primitives like this, so the end result would end up easier to use than what we have today, at least from a "development team" level of technical ability.

Please take this thought experiment as what it is: wondering, "How would this be easier if I could count on every developer having a Keybase account, and they could authenticate membership to my org, and I could test for that in any system I controlled."

[cjb]

Short answer: We're working on it and agree it's a super important feature!

CC @malgorithms for your design feedback

[billinghamj]

Also very keen.

Related: #1826