On Tue, Jun 2, 2015 at 1:15 PM, Paul Hoffman
<paul(_dot_)hoffman(_at_)vpnc(_dot_)org> wrote:
Ignoring the "signed" part...
On Jun 2, 2015, at 6:44 AM, Joe Abley <jabley(_at_)hopcount(_dot_)ca> wrote:
If the argument that we should use HTTPS everywhere (which I do not
disagree with) is reasonable, it feels like an argument about sending
encrypted e-mail whenever possible ought to be similarly reasonable. Given
that so much of the work of the IETF happens over e-mail, a focus on HTTP
seems a bit weird.
This is a terrible idea. If the IETF mailer thinks it knows my PGP
encryption key, and I don't because I have lost it or invalidated it, then
I cannot read the mail from the IETF mailer and will thus lose valuable
information. Maybe we can develop some interface that allows a user to
specify their encryption key and remove it at will, but I've never seen
such an interface before and suspect that its design will have all sorts of
pointy edge cases.
Proposal: if you actually want this, develop an interface for telling the
server your key first. Get buy-in from others active in the IETF, if
possible. If you can pull this off, it will benefit much more than the IETF.
Well I think the original point here is 'eat the dog food' and you are now
pointing out that the dog food is inedible. Which is of course correct.
The problem I find with both S/MIME and OpenPGP is they both lack a
mechanism for receivers to tell senders
1) Whether they want encrypted mail
2) Which encryption key to use.
The first is really important for me because IETF mailing lists are all
public and I read them using the gmail webmail interface. I have absolutely
no interest in having email sent in a format that I can't read on my device
and no interest in using a different device for no other reason than to
support end-to-end encryption of public data.
I want to be able to read my IETF mail on every one of the machines I use
on a daily basis, these are three desktops, two laptops, a phone and a
tablet. Unless I can read my IETF mail on all seven platforms, it is not
going to be acceptable.
The second is important for a similar reason. OpenPGP and S/MIME are NOT
end-to-end email encryption systems. they are systems that give the OPTION
of end-to-end. That is not an option I want to make available to people
that I have not vetted previously by which I mean 'have whitelisted them'.
to do otherwise is an invitation to be spammed to death.
Now I can demonstrate ways to make whitelisting really easy and automatic.
But there is going to have to be a fallback which is either 'plaintext' or
encrypt under some non-end-to-end key.
So yes, let us make encrypting email end-to-end an eat the dog food goal,
but the point of eating the dog food is to make sure it is edible, not to
prove that we are masochists.
Like virtually every other IETF protocol there is a little bit of missing
glue which is the bit where someone can specify what their security policy
is. That is the little bit extra I would like to add in a format that makes
it usable for both S/MIME and OpenPGP.
And now I am going back to working on adding it.