Proposal of OpenPGP Email Validation

[nico at enigmail.net]

Hi,
thanks again for the great feedback.

Am 28.07.2015 um 19:26 schrieb MFPA:
> 
> Hi
> 
> On Monday 27 July 2015 at 6:55:24 PM, in
> <mid:55B6708C.9090007 at enigmail.net>, nico at enigmail.net wrote:
> 
>> If the
>> goal is to keep validations in sync,   key owners might
>> have to confirm emails added over the year   earlier,
>> which shouldn't be too bad. - - If the goal is to
>> reduce validation requests, I see no   problem to have
>> different expiration dates. I think, because each email
>> should be validated from time to time anyway (and this
>> is an isolated process), each validation should give
>> the 12 month period for the specific email when it is
>> validated. Or do you see any problems?
> 
> I just think if I was to receive revalidation requests all at the same
> time I would be less likely to overlook those for little-used email
> addresses I do not often check. It also keeps it neat.
> 
OK, I will add this as an argument.
Does anybody disagree?

>> It only says that the email did
>> one day work for a validation of any kind, which is
>> more than what we have now.
> 
> We have the Web of Trust to demonstrate that. But those are generally
> one-off signatures on a key, and may be quite a few years old. Some
> email providers recycle addresses, so an address Bob used a few months
> or years ago could now be under Alice's, or even Mallory's, control.
> 
> As far as I see it, your scheme adds two things: periodic
> revalidation, and an easy way to get a signature on your key without
> having to meet anybody.
> 
Yep, sounds good to me.
May be an additional value is the goal to establish some
"common" validation signatures, which would allow to
use/trust these signatures by default.
Thus, we also introduce an easy way to benefit from a
validation (signature).

>> That is, such a validation
>> does not give full trust, it would only give slightly
>> more trust over emails that do not have the validation.
> 
> Indeed. I think an annual revalidation period strikes a reasonable
> balance, although maybe there are email services that recycle
> addresses more quickly than that.
> 
Finding the right balance is probably something we have to find out over
time. I would start very very conservatively, just not to annoy people.

>> But that might be enough to solve the faked key issue.
> 
> Are there really many "faked" keys, rather than keys that are no
> longer used, forgotten passphrase, lost private key, etc.?
> 
AFAIK, there are not THAT many faked keys, but the problem exists
especially for key parties of our internet world
(a famous German magazine, at least one GPG tool, ...).
The problem is that the German magazine takes this as a show stopper
(both personally and publicly).
I really want to have them back on our road for more encryption
with OpenPGP.
And the "publicity" we get from not validating email addresses
is really a big problem (especially as fixing that problems sounds so
easy and obvious).
Thus, without fixing this, IMO the whole OpenPGP movement
has a reputation problem.

>> this solution does NOT solve the
>> problem of interception of emails. But it helps to
>> detect them
> 
> How does this help to detect interception of emails?
> 
Today, people with faked keys simply get unreadable emails,
but don't know whether there were trolls or spies at work.
After validating their own key, only one of two things can happen:
a) The faked key problem is solved, because people
   now know, which of the available keys to prefer
   (provided people trust the validation signature)
b) The faked key problem still exists, because a
   validation signature to the faked key was
   also added.
   In this case we know that something more severe happened:
   - either the confirmation email was intercepted
   - or the validation server was corrupted
That is, either the problem is solved or
we know that the problem is more severe than just a work
of trolls only uploading a faked key for fun.

>> It depends on whether and how far you trust the
>> provider. Reality looks different (see startmail,
>> posteo, riseup, and many company email servers). I
>> don't claim to solve any problem in that area.
>> User/clients might have to decide whether to trust a
>> validation notation given by posteo, riseup, google,
>> ...
> 
> Company email servers, I would expect companies as a matter of course
> to have a means to decrypt their employees' emails.
> 
> I'm shocked to read [0] that Riseup once had a webmail option that
> stored the user's public and private keys. Riseup now tells [1] users
> who want to use encrypted email to utilize an email client to send and
> receive email, while keeping their private key stored safely on their
> local machine.
> 
> [0] <https://help.riseup.net/en/email/webmail/where-is-imp>
> [1] <https://help.riseup.net/en/security/message-security/openpgp#can-i-send-and-receive-encrypted-email-using-riseups-webmail>
> 
> Startmail sounds like a similar concept to Hushmail, which was
> compromised by a court order obtained through a mutual assistance
> treaty. It is not clear to me why Startmail would not be expected to
> suffer the same fate.
> 
> Posteo looks interesting. But their overview says end-to-end
> encryption is done by the user in addition to Posteo's own security
> measures, so the user would have to generate and store their own keys.
> 
> And Google make a living out of exploiting data mined from users'
> emails and search activities. Why would anybody trust them?
> 
Interesting, but this is a different issue.
The question you raise is: (How far) Can we trust the email
provider/server regarding the handling of private keys.

Here in this proposal, IMO, we have a slightly different problem,
which makes corruption less likely.
The reason is:
If an email provider/server "G" gives the private key to the NSA
we don't know about it, because that's a private deal between G and NSA.
Thus, this breakage of privacy is hard to detect and therefore
not a big risk for G to do.

But if G claims that an email address was validated
although it was not, they express this as a public signature
visible to the whole world.
If they do that, people can/will find out and blame G.
But that's something G clearly wants to avoid
(they need trust by their customers).
Thus, they have much more interest not to signal validation
of a faked key because any violation here is easy to detect.

Best
  Nico

-- 
Nicolai M. Josuttis
www.josuttis.de
mailto:nico at enigmail.net
PGP fingerprint: CFEA 3B9F 9D8E B52D BD3F 7AF6 1C16 A70A F92D 28F5