Re: Public Key Look Up

Responding late to this thread... I wanted to note that
the need to store and manage lots of keys can be addressed
through the use of identity based encryption, which in effect
reduces the number of keys you need to store from one per
user to 1.

RFCs 5091 and 6508 cover specific IBE schemes, however, for
introductory material you'll need to look elsewhere.

I also note that there can still be advantages to having
a per-user lookup (either in or out of band) for the user's
public key - a lookup has the potential to tell you that
a given user is actually capable of receiving encrypted
mail. 

All that said, making server side implementation easier
does nothing to solve the real problem: All available
evidence says that there won't be sufficient uptake to
matter.

				Ned



> --On Wednesday, May 12, 2021 19:04 +0200 Alessandro Vesely
> <[email protected]> wrote:

> >...
> >> Indeed.  But if the keys include signatures, it doesn't
> >> matter where they come  from, so we're back to asking why
> >> nobody seems to use the key servers that  already exist.
> >
> > Some people has been using those key servers.  However,
> > they're vulnerable to pgp-poisoning attacks[*].
> >...
> > [*] https://github.com/skeeto/pgp-poisoner

> We are getting fairly far off-topic, but ...

> There is an extremely straightforward way to resist such
> attacks, which is to accept key updates only from the
> authenticated key owner or, _maybe_ from one of the existing
> signatories whose key is already in the repository.  There are
> issues there too, but most of them come down to something John
> Levine pointed out earlier in the thread (and that has been
> known since the 1990s), which is that PGP's web of trust concept
> does not scale very well.  I can think of another defense too,
> but, again, we are getting fairly far off-topic.

> But, Ale, it seems to me that almost everyone but you is saying
> things that ultimately lead to the same place: either that it
> would not be a good idea to try to build this into SMTP or that,
> we we did, it either wouldn't work or there would not be enough
> uptake and deployment to make it useful.  That does not
> necessarily mean that we are right and you are wrong, but it
> does suggest that this thread is nearing the end of its useful
> life.

> best,
>     john

> _______________________________________________
> ietf-smtp mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/ietf-smtp

_______________________________________________
ietf-smtp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ietf-smtp