Re: Secure email

On 1/18/2016 3:24 PM, Alan Karp wrote:
> One way to handle key rollover is to start with two keys with different
> expiration dates, k1 and k2.  Before k1 expires, you generate k3 and
> certify it using k2.  Use k2 as your primary and k3 as secondary.  Lather
> rinse repeat.  This approach does not cover the case of a k2 being
> compromised, but its private key can be kept offline until
>
>
> --------------
> Alan Karp

Fine for when you need to bind a message to a person or organization.
My main point is that I believe by giving up a requirement for strong
binding the implementation and UI issues go away.  In fact there is
no UI as the implementation is invisible as described.

With the approach I described keys come and go with email client
installations.  They aren't bound to people but to email clients.
They can be created anew at will.

It's only in the rare case that one cares about binding an email
to a person (e.g. legal or financial) that most people even care
about such a binding.  In that case I suggested that binding through
something like a secure web site is trivial.  If the key changes,
bind again.  I don't see a need for key rollover.

Do I care that the above message really came from you Alan?
I guess in some weak sense I do.  I'd be a bit surprised and miffed
if it was sent by somebody doing a man in the middle attack.
Still, no big deal is my view.  You are one of the relatively few
people on these lists that I've met in person.  For me most of
the people on this list are identified by their email messages.
If their email client key doesn't change I can be assured they
haven't changed.  If it does, big whoop.  I probably wouldn't
even bother to try to link the two identities.  If at some point
I did care THEN I'd work on a binding which I consider to be a
small problem technically, but a big problem for a user interface
that will be used by the great unwashed.

In any case with this current message I have no assurance
that the above message came from the you I've worked with.
I have no such assurance AND the email was sent in clear text
across the network.

Hmmm.  Now that I think of it, however, I've been only considering
communication between two endpoints.  What about email
communication like that of this list that is more multicast?
I guess in that case the Mailman (or whatever) server must
serve as an end.  For that case any bindings would have to be
with the list server anyway.  If my client knows all the destinations
(cc, bcc, etc.) then the point to point implementation works.
For a list server, however, it seems to me the server has to take
the role of an endpoint.  Not a big deal IMO.  In that case it would
be "nice" if the list server would let the list members know if the
client key of a sender changed - so people on the list could do a
new binding if they wished.  Maybe just including a hash or id
along with the email address as the "from" so that anybody
concerned could notice which emails came from which Id/hash
and could do the work to bind them together if it became important.

Incidentally, David Nicol pointed out:

http://boingboing.net/2014/06/04/google-announces-end-to-end-en.html

Do others have relevant experience with that implementation?
I've been burned so many times trying to use PGP/GPG for encrypted/signed
email that I'm reluctant to try without a recommendation.

--Jed