@wiktor Hey, d'you know of an existing authentication protocol over HTTPS that uses PGP keys?

Thinking about tunnelling our API calls inside e.g. AES-GCM (like 1Password for teams), looking for an existing mechanism for establishing the shared secret based on the user's PGP key...

@paul When I was setting up my ssh-agent -> gpg-agent -> pcsc -> fidesmo card config I saw an article about signing a CSR with a PGP key to establish mutual TLS. It's not directly authenticating the HTTPS session connection with PGP, but could be used to initialise a machine on first use maybe?

@alex Thanks for that, using it for mutual TLS is awesome

@paul I know you can use OpenPGP directly in the TLS ( but I don't know if I'd recommend it (TLS1.3 removes support for that).

There is also HTTP Signatures I-D that Mastodon (and ActivityPub) uses: but it uses raw keys.

What is your use case that HTTPS alone does not protect against? End-to-end encryption between users and your server acts as an intermediary?

@wiktor thanks for those, the main thing is we want a fast authentication mechanism:

1. authenticate all API requests as a key, without having to unlock the key to make the request every time as it's slow (although the response, if non-empty, may be encrypted directly to the key)

Example is API request "do I have any secrets?" - usually the answer is no.

2. protect against mitm (which we've actually seen:

@wiktor We've avoided any sort of API "login" concept so far, using a custom approach on each endpoint, but next week we want to build a consistent authentication (+ maybe tunnelling) approach across all endpoints

@paul How about a simple endpoint that gives a challenge to be signed by the user? If they reply with a correctly signed message you could issue a token that is valid for some time (e.g. JWT) to be used in `Authentication: Bearer` header.

It is possible to do this all statelessly if you use signed tokens.

Check out also this thing: (not exactly what you want but interesting nonetheless).

@wiktor Yeah JWT is a great approach. Maybe we forget the tunnelling bit for now...

@paul What do you mean by tunnelling exactly? Third-party authorization? This could also be modeled with PGP.

By the way OpenID Connect is a nice spec already used by Google and Microsoft that heavily utilizes JWTs for authorization (you could authorize someone's Google/Microsoft account that way). It could be possible to write an OpenID Connect identity provider that would authorize people using PGP keys and issue JWTs like usual (that'd have broader application than just Fluidkeys)...

@wiktor Tunnelling: from the 1Password security whitepaper, page 45 "Transport Security":

@wiktor I was musing whether our login / challenge endpoint could provide more than just a signed token, but a session key that's *also* used to encrypt the whole session *inside* TLS

@paul I haven't read the whitepaper (yet) but as far as I understand SRP (and PAKE) this is for login scenarios only (that is above TLS).

I don't think this "session key" is used directly in TLS but rather to encrypt stuff that is then sent via "normal" TLS connection.

I could be wrong though as I didn't read the paper nor did I inspect their source.

SRP is mainly used to get strong security out of weak passwords, if you have OpenPGP I think you leapfrogged 1Password.

@paul Yep, sure. Alternatively you can use a Fluidkey's server OpenPGP key that the client would use to encrypt all requests to. Inside the TLS session.

@paul Yep, I set it up and forgot about it but then some blog supported OpenID (is it still alive?!) and the PGP signature authorization worked. Pretty neat, too bad it didn't see wider adoption... :)

If you're into that check out also this historic page:

@paul One relatively cheap way to get anti-MITM may be public-key pinning. That's what Chrome does for Google's properties (static HPKP) and OpenKeychain for keyservers.

(if you got this way remember to add some backup pins though...)

@wiktor Yes indeed! I'm thinking about this too.

If I'm only concerned about *read-only* mitm then we could host the pins online somewhere rather than bake them into the app

Sign in to participate in the conversation
Open social media for the UK

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!