If you had a key registry of some kind, then just like DNS gives you an IP number for a name, you could get a key for a user, and you would have a mechanism for sharing the encryption as it changes. Since you articulated earlier that my keys are likely going to be changing over time. So then I need to put a form of key evolution into this system.
And since we are worried about security in this, we have to find ways to make the DNS-for-encryption-keys be secure and immutable, otherwise, it just becomes a different vector for descryting by the wrong people. On Fri, Jan 10, 2020 at 12:08 PM Paul Heinlein <heinl...@madboa.com> wrote: > On Fri, 10 Jan 2020, John Sechrest wrote: > > > I have the feeling that the PGP process is not more widely adopted > because > > of the user experience. You have to go out of your way to get things up > and > > going. And then you have to be attentive. > > > > It would be interesting to take this "idea toolchain" and come at it > from a > > perspective of the user experience in the process. > > > > I would submit that if I need to be intentional about keys, privacy and > > trust in each transaction that the adoption rate will be very low (As I > > think we see with pgp) > > > > Are there ways to fold the "User Actions" into a process, so that the > task > > of engaging in messaging is secure and yet does not take substantial > > intention to keep things going. > > Longer ago than I care to admit, Simson Garfinkel and I exchanged some > ideas on this theme. His idea, which I thought promising, was to treat > secure e-mail exhanges like SSH logins. > > The first time I log into a remote host using SSH, I'm asked to accept > the key. It's certainly possible to request that key from a trusted > third party (even DNS), but usually I just accept the key on first > login. I only worry about it when it changes and SSH issues its > impossible-to-ignore WARNING WARNING message. > > His thought was that the first time you exchange an e-mail message > with someone, you accept that user's key (automatically offered up by > a process or protocol that doesn't yet exist). The remote user does > likewise. Thereafter, all communications with that person are > encrypted by that key. Should the key change, the mail client would > turn red or otherwise indicate WARNING WARNING. It would be up the > local user to decide if the key change is valid or not. > > There are obvious potential problems with this idea: there's no > obvious way to publish keys beforehand; it's unclear how to deal with > people who use multiple mail clients (phone, tablet, home workstation, > work workstation, web client) with the same e-mail address; too many > people will ignore WARNING WARNING and thoughtlessly accept the > change; and many others. > > Still, I thought it was on the right track toward just building > point-to-point crypto into the scheme of things. > > -- > Paul Heinlein > heinl...@madboa.com > 45°38' N, 122°6' W_______________________________________________ > PLUG mailing list > PLUG@pdxlinux.org > http://lists.pdxlinux.org/mailman/listinfo/plug > -- John Sechrest . Need to schedule a meeting : http://sechrest.youcanbookme.com . . . . sechr...@gmail.com . @sechrest <http://www.twitter.com/sechrest> . http://www.oomaat.com . _______________________________________________ PLUG mailing list PLUG@pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
