Josh Good wrote: > On 2017 Feb 12, 16:17, Michael Ströder wrote: >> Josh Good wrote: >>> On 2017 Feb 11, 19:18, [email protected] wrote: >>>> So technically integrity is assured from server to server, but not between >>>> clients >>>> and server. >>> >>> That is correct. DKIM is for MTA-to-MTA integrity. >> >> There are no widely used MUA implementations making use of DKIM but it is >> definitely not >> technically or standard-wise limited to MTA-to-MTA: >> >> https://tools.ietf.org/html/rfc6376#section-2.1 >> (same text in predecessor RFC 4871) > > Yes, theoretically a sending MUA could DKIM sign, but the user cannot > from his MUA insert a new, personal DKIM selector into his domain DNS > TXT record. So DKIM is not real end-to-end as the sending in-the-flesh > user cannot choose his own keys to sign with DKIM, but can only use > those keys his domain administrator has vetted for him to use. Would you > trust such a scheme if you lived in North Korea?
There's always the issue with 3rd-party trust relationship patterns whether you trust the 3rd-party or not. >> Compared to S/MIME and PGP it provides integrity protection of message >> headers and body while S/MIME and PGP only sign the message body. > > Very true. But then, S/MIME and PGP also provide encryption of the body, > whereas DKIM can only digitally sign emails. I never said one should drop S/MIME and/or PGP in favour of DKIM. Personally I'm a big fan of using more than one layer if feasible. All I wanted to correct is the claim in your postings that DKIM itself is constrained to MTA-to-MTA communication. Ciao, Michael.
smime.p7s
Description: S/MIME Cryptographic Signature
