Re: [dane] Use OPENPGPKEY or SMIMEA if both are available?

[Patrick Ben Koetter <[e-mail]>]

* Paul Wouters <[e-mail]>:
> On Mon, 9 Mar 2015, Patrick Ben Koetter wrote:
> 
> >while thinking about OPENPGPKEY and SMIMEA I came across this question:
> >
> >What if a recipient publishes both, an OPENPGPKEY and a SMIMEA RR in DNS and
> >what if a sender (MUA/MTA Filter) is capable to encrypt messages for both
> >standars S/MIME and PGP.
> >
> >Which should the sender prefer? Could the receiver indicate a preference?
> >
> >Has there been any discussion on this? Should there be? Did it take place and
> >I missed it?
> 
> It has not been discussed.
> 
> I would think this is a local policy decision. Likely, if respondering
> to an encrypted message using X, one would encrypt back using X if the
> local policy allows this. If sending a message from scratch, I would
> think local policy applies?
> 
> An email client could prompt the user. An MTA would have to make a
> decision on its own, based on its policy.
> 
> I wouldn't go so far as to allow the recipient to show a preference. The
> recipient shows its accepted methods by publishing the related record in
> DNS. This works similar to crypto suite/algo negotiations. The initiator
> can pick its favourite from the intersection of what both parties
> support.

I think there are several options to handle OPENPGPKEY and SMIMEA conflicts.
My intention is to find the one that requires the least or no sender
interaction.

Why? End to end encryption is known to be complicated. That's one of the main
reasons why average users refuse to use it. They consider themselves unable
to make the right decisions. They avoid these conflicts refusing to use
end-to-end encryption at all.

Both, OPENPGPKEY and SMIMEA, carry the potential to increase wider usage of
encryption. They offer a safe way for automated key distribution. All a sender
will have to do is 'send' the message. Given appropriate software, MUA or MTA,
will handle safe key retrieval and encrypt the message for any OPENPGPKEY and
SMIMEA enabled recipient.

Letting the sender decide in case of conflicts - OPENPGPKEY and SMIMEA are
present at the time of sending - puts the burden back on the sender. I'd like
to avoid that because I expect this to be counterproductive for wider
adoption.

One way to handle this without user interaction is to handle it at MTA level.
The operator could specify a preference.

Another way would be to let the recipient specify a preference. Preferring one
over the other would only take place if the sending MUA/MTA was able to deal
with either standard.

The sender would not have to interact with the software to make a decision.
The recipient could indicate preference for standard A e.g. simply because
messages encrypted by A can be read on more devices (desktop/tablet/mobile).
Standard B would only serve as fallback.

This would still leave the option to override on the sender's side. But then
it would be intentionally. Most of the time recipient preference would just
"do the right thing".

p@rick

-- 
[*] sys4 AG
 
https://sys4.de, [phone]
Franziskanerstraße 15, 81669 München
 
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein