* Paul Wouters <[email protected]>: > 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, +49 (89) 30 90 46 64 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 _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
