letspgp notes

gistfile1.txt

Is it possible: some kind of LetsEncrypt for pgp email addresses? (LetsPGP) 
- Bitcoin irc bots do this for nicks. 

Q: How does keybase verify email addresses now? Maybe can reuse their code.

LetsEncrypt actually solves two problems:
- Make it easy to obtain a TLS cert.
- Get these certs to be trusted by browsers. (By shipping the LetsEncrypt root cert in major browsers by default.)

What does this (not) verify?
YES: cryptocert = email/domain
NO: email/domain = real-world person/org

What it would be verifying: the entity in control of privkey also can read email at address.

This signing should be *only* valid for the use of that key for email, and for no other purposes. 
Maybe only specific-formatted UIDs should be signed? E.g:
[autosign] (LetsPGP) <name@mayfirst.org>

Autosigned keys should be given the lowest level of trust.

# Trust in authorities
In order for this to be secure, there must be several autosigners maintained by separate authorities. Example orgs to host such services:
- LetsEncrypt
- EFF
- Keybase

# Also
Also, each DIME server can sign the pubkey(s) of each of its users.

NOTE There is a trust issue here, the server can MITM the user. Server sigs should NOT be trusted as sole authority on email-cert pairing.

The trust issue with 3rd party autosigners is less, because they do not control the email server infrastructure.

Online autosigning is a must, but providers are welcome to implement a tiered approach with periodic signing using additional offline keys.

[LetsPGP autosigner] LetsEncrypt (online) <letspgp@letsencrypt.org>
[LetsPGP autosigner] EFF (offline) <letspgp@eff.org>

# Protocol
All communication happens via signed AND encrypted email.
- User has a keyring with an appropriate uid. (Autosign format.)
- User submits a sign request.
- Autosigner replies with a single-purpose confirmation code.
- User client decrypts message and sends confirmation code back to autosigner.
- Autosigner signs the user key and publishes it on keyservers. Also sends confirm ok message back to user.

Q: can make this simpler. Don't need the conf code as long as the request is signed?

Problem: an attacker capable of large-scale network monitoring can scoop up the messages and reply, impersonating the address holder even if they don't have control of the account on the actual email server. This is not MITM, this is straight-up impersonation.

Q: does email have *any way* of veriying sender's address?

Sender Policy Framework (SPF) - interesting but doesnt seem to be good enough.
Callback verification, also known ascallout verification or Sender Address Verification. - Also not good enough. Verifies that the address in question exists, but does not verify any correlation to control of that address.

If the user's email provider signs their key, this can obviate some of this. Then, an attacker would need to collude with the provider.

N.B. This seems to be bumping up against a fundamental problem with the email server model. (Users/clients are not their own servers.)

How does letsencrypt solve this for domains? DNS can lie.

Autosigner checks with mail provider. Does like callback verification, except provider also responds with a pubkey for that address.