Implement decentralized GPG login

[paulproteus]

Right now, self-hosters must choose between Google auth and GitHub auth. This is sub-optimal for people who would prefer to be entirely self-reliant.

This issue tracks work required to deliver the first version of GPG login so that this is a serious option.

[gemlog]

As a self-hoster, this is the holy grail. Well, ssh or gpg keys, I don't really care. Manually adding a few keys to a key ring is fine for self-hosting. Please just get the mechanism there first and then worry about automating it. No one has had a good idea about the latter, ever, so far as I know.

[matjolic]

Implementing such a feature would be really awesome for self-hosting apps. A cool project to take a look at that has tackled the idea is monkeysphere, though their browser plugin only supports Firefox for the time being.

[paulproteus]

That's great that monkeysphere has been looking into this! Thanks for
linking to it. I'll ping dkg and other Monkeysphere people to find out if
it would be a good fit.

[noci2012]

another options to allow personal certificates, and be able to install a CA certificate. (xca can be used to issue/revoke certificates ..)

[Finkregh]

IMHO that would be something for another issue :-)

[chreekat]

Unsure whether this should be an entirely different ticket, but for your consideration: IndieAuth! It is not a very widely used service, but I think it has great potential.

[elimisteve]

@paulproteus By GPG login do you mean via some sort of challenge/response mechanism? Like if I want to login as user@domain.com, Sandstorm grabs my GPG pubkey from Keybase, encrypts a challenge to me, I decrypt it, then I paste that into a web form (or paste in the answer encrypted with the server's pubkey) to log in?

[elimisteve]

@noci2012 Personal certs are interesting, but perhaps difficult to distribute?

@chreekat IndieAuth is pretty sweet, but having something more cryptographically secure sounds nice... Perhaps combining IndieAuth with grabbing a given user's GPG key from Keybase could work?

[noci2012]

why, you obtain them from a CA...
Create a CSR where the email address is the subject, and ask a CA (f.e. cacert.org), but can be ANY CA that you trust to sign them. downlaod them from their secured website and done.

If someone creates a a private CA and signs through that, is just mean the Public key of the Selfowned CA must be in the trusted store on the "server", or in the path the "Service" uses.

This is equivalent to Login by mail adres.... where the mail adres is signed by a Trusted CA and the trusted CA is known in the trusted CA list. The same certificate can be used to sign or encrypt mail (S/MIME).

XCA is a good tool to manage a private CA..., http://xca.sourceforge.net

[elimisteve]

Explanation of this from @kentonv in this post on sandstorm-dev:

The GPG login plan is actually even more anonymous: there is no email involved, just a key pair. The user's "identity" is their key fingerprint. They log in by proving they own the corresponding private key.

[noci2012]

And through the fingerprint & id the remainder of info & web of trust can be checked. (who trusts who, who cosigned the GPG and to what level, including mail addresses).
An email address in a CA certificate can be a fake one as well IF the CA accepts that.
With xca ( http://xca.sourceforge.net/ ) you can issue your own certificate(s) based on private CA if you like.

[zenhack]

Is there any work on this actually happening? With the fingerprint-as-identity solution, I'm envisioning part of a sign-in page that looks something like:

Please run the command:

echo 'I authorize sign-in #52 to example.sandcats.io as C0B2C432638DAEB0D70715C7F654B8C7D4CA3CB8 on So 24 Apr 2016 04:51:29 EDT' | gpg --armor --detach-sign

And paste the result below:

...

[kentonv]

@zenhack Relevant: https://sandstorm.io/news/2015-05-01-is-that-ascii-or-protobuf

Though probably the answer to that problem here is to say: "You need to use a signing key that you only use for signing natural language text."

Another thing to consider: If we used decryption rather than signing, then we could actually store a symmetric key encrypted to your public key, and encrypt all your data on the server with that symmetric key, such that there's no way for Sandstorm to access your data at rest (only when you log in). However, there is a risk that users will unwittingly turn into a decryption oracle for their Sandstorm server.

Otherwise, yes, that's more or less what I'd like to implement. But no, there is no work happening on this currently -- too much other stuff to do. If you'd like to work on it, that'd be cool!

[zenhack]

Ok, yeah, wow.

My immediate thought is "how many developers can I find in the wild who sign packages, git tags and emails with the same key?"

"You need to use a signing key that you only use for signing natural language text" sounds more much like "You should use a different password for every site" than I'm comfortable with -- my bet is many people won't. Doesn't diminish the importance of the advice (in either case).

I will need to think about this.

[zenhack]

Maybe the thing to do is just document that pitfall right on the login page itself; might actually raise some awareness of the issue.

Perhaps as a mitigating measure we should look at other popular things GPG is used to sign; distro packages, git tags, whatever monkey sphere does... and craft the string format to avoid collisions with those. This way, an attacker would at least need to make the string look different from what the user usually sees, even if it otherwise seems innocuous.