--On Wednesday, May 12, 2021 17:45 -0700 Ned Freed
<ned(_dot_)freed(_at_)mrochek(_dot_)com> wrote:
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.
Good point, at least in theory (see below). That would also
eliminate the need for per-user entries if using the DNS.
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.
Indeed.
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.
And that is the practice that goes with the theory. We really
don't have a shortage of mechanisms for locating and retrieving
keys. Unless something changes the conditions that have
frustrated deployment and use, there is no evidence that adding
another mechanism would make enough difference to be worth the
effort (and, as John Levine pointed out, statistically probably
no difference at all). I can imagine scenarios that would
change the situation, but I don't expect any of them soon and
none of them would cause the presence or absence of one more key
location and retrieval mechanism to be an impediment.
john
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp