STEED - Usable end-to-end encryption

[Aaron Toponce]

On Mon, Oct 17, 2011 at 08:25:04PM +0200, Jerome Baum wrote:
> How about an opportunistic approach? This email should include the
> following header:
>
> OpenPGP: id=C58C753A;
> 	url=https://jeromebaum.com/pgp
>
> The MUA could recognize a header like this one and remember that there's
> a certificate -- so the next email we send will be encrypted. The first
> email couldn't be, but is that worse than no encryption at all?
>
> Basically something like Strict-Transport-Security.
>
> What do you think?
>
> Like I said this is based on a quick skimming of the paper. Sorry about
> the long message.

For the uninitiated, http://josefsson.org/openpgp-header/ explains the
'OpenPGP' header, and it's syntax. This was something new to me. A bit of
additional research on whether or not this was something Mutt was planning
on adding led me to http://marc.info/?l=mutt-dev&m=110227240028896&w=2.

I've added it with "my_hdr OpenPGP id=${pgp_sign_as}\;url=...". The only
question remaining, for me, is whether or not it should be "X-OpenPGP" or
"OpenPGP" as the header field name. I've heard various positions on this,
but nothing definitive.

At any rate, I would love to see more client-to-client encryption in email.
I've always wondered if there could be an "OTR" approach to mail, somehow,
so people don't need to generate and manage their own sets of keys, as that
seems to be the largest hinderence to widespread adoption. The only thing
the user should do, is compose the mail, hit send, and everything is
handled with very minimal user interaction.

--
. o .   o . o   . . o   o . .   . o .
. . o   . o o   o . o   . o o   . . o
o o o   . o .   . o o   o o .   o o o
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 519 bytes
Desc: Digital signature
URL: </pipermail/attachments/20111017/413ca5c3/attachment.pgp>