Proposal of OpenPGP Email Validation

[nico at enigmail.net]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi MFPA,
Thanks a lot for your feedback.

Am 27.07.2015 um 15:16 schrieb MFPA:
> Hi
> 
> 
> On Monday 27 July 2015 at 6:55:03 AM, in
> <mid:55B5C7B7.4090907 at enigmail.net>, nico at enigmail.net wrote:
> 
> 
> 
>> Thus, I am happy for any feedback (details and general
>> remarks) both here and directly as email to me.
> 
> 
> Comments in no particular order, just as they occurred to me when
> looking through your paper:-
> 
> 
> 
> If a key is validated by the proxy, then subsequently uploaded again
> with a new UID, does the new UID get a validation expiry date that
> matches the rest of the key? Or does it get a standard 12-month
> validation period, but still get re-validated the next time one of the
> other UIDs needs it, so that all UIDs' validation expiry dates are
> brought back into sync? And what if the upload with an extra UID hits
> a different validation server?
> 
Hmm, I didn't think about that in detail.
But I would assume that because each validation validates a specific
email address, a validation once each year is enough.
I see no problem with both attempts:
- - 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?


> If a third party has uploaded my key, or if the validation server is
> automatically validating existing keys in response to certain events,
> the validation emails are unsolicited by me. Most people will not
> click a link in such an email.
> 
OK, I agree (unless this feature is widely accepted ;-) ).
So may be, for the beginning, validations can only be triggered
when keys are uploaded (not when they are downloaded).

> If a third party who can intercept my emails has generated a key
> containing my email address in a UID, all bets are off.
> 
This whole approach is NOT to make a perfect prove that the email
is correct.
It only says that the email did one day work for a validation
of any kind, which is more than what we have now.
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.
But that might be enough to solve the faked key issue.
This is BTW no different than for any other validation email
in common systems. They also don't give more guarantee.
Thus this solution does NOT solve the problem of
interception of emails.
But it helps to detect them (if this happens the ct guys
know that the problem is a lot worse than they thought)
and helps in case this is the result of internet trolls.

> If an email provider provides public keys for their customers,
> presumably those keys are unsuitable for mail encryption because the
> provider may have access to the private key.
> 
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, ...

> The configuration changes for email clients that you mention, things
> like which keyserver to use and which keys to trust, need to be set in
> GnuPG.conf (or maybe some form of GnuPG wrapper or plugin) so that
> they are used by an email client that simply calls GnuPG and therefore
> honours GnuPG's own settings. Same for trust models; maybe you should
> consider suggesting a modified trust model for GnuPG that includes
> options for handling validation signatures.
> 
THAT's a bigger step, but if Gnu wants to support it
(which would mean that they think that this approach is fine),
I am happy if this happens.
For the moment I try to minimize additional requirements
to be able to support this approach pretty fast
(for people who want it).
And I really try to got at least some solution for this problem,
which I consider to be one show stopper to establish email encryption.

> Blacklists should not be used *anywhere* as they are a form of
> censorship and can be used for DOS attacks.
> 
OK, don't we even have some blacklists in key servers? ;-)
But I agree, that's something we have to discuss or find out in detail.

> In your proposal for listing validation signatures in GnuPG:
> "‘!’ after sig signals successful validation" - why is this needed?
> Surely the mere presence of a validation signature signals successful
> validation.
> 
Hmm, Wener recommended to use
 --check-sigs
rather than
 --list.sigs
which then results in printing the '!'.
Isn't it necessary in your opinion?

> Why would the notation value be base64 encoded? What is the rationale
> for preventing users from reading the notation values in a key
> listing?
> 
Hmm, it was a recommendation by Kristina Fiskerstrand:
"the value should be base64 encoded to avoid some issues"
@Kristian: Can you elaborate on that?

> Notation version numbers. Rather than using different notation names
> such as validation-v2 at enigmail.net, I would think it better to keep
> the notation name standard and put the version number at the start of
> the value string.
> 
> 
Thanks
  Nico


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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)

iQIcBAEBCgAGBQJVtnCJAAoJEBwWpwr5LSj18ucQALZO/MAyIISvrJ9jpq0IoEv8
BkjSKcTdmkN3UT1mO5qTpDO/CtG0fumCMXruWLd3oMhPnxl9wItjt5ckEBUn45ow
4J0TcR5KvDEn+X6H0xa0SHGfz7p2kpjuaqLSTK8T1/12P3/ok1wk+z8gNJVcf/9o
DzYiXNSfchH8ezfQ24a0tXwotcpjMIi3ravZ4St5ppX/DnsajBiSzOOi7YbT/kT7
l9kDmTDTFlQWn/5YtaLVmsK9SSNm1hXPdEZY+Sg2dsOi7aDqrPW5IvU1daBxZQCG
w+xItKigSrLJF3cunx1k3nqwXIk0NceyW5JKR+qohZbx49eWLSXXlpbgg0A75kzx
ZDBUPC1cZ8QTdVlm/4GAV2UgkmjyqvO60uV9gSw3Gbtc6jolEsSpfX7lvK3vH6ms
oMopBCp4udsbBHEhqFeGAq4CyKQwnGSPiN7XK9O6YSVwcs2kX4WaqzG+/m//eIzy
leCX99mar34BEx63s9uhgGYyJU6GAZVB0zy56hk5H0UQPUupomNqhgGwpzZulRg4
F51LpOoo7vkfyiS+TKCSQ3DdtBHmEGMGI5AVQB5yByfx1K2ai/Qd5xNfh9ajMjnZ
+IiU05cxEy90+HvLLAwsh8E3vqvtsdYJn0pJwkEBptcGIAFVPIX1cJI1xJf1Z1dp
DooS5ZJ+JOGXWZ7EUDd0
=Xfrv
-----END PGP SIGNATURE-----