On 22/Jul/10 20:24, David Nicol wrote:
However, before possibly shifting to yet another list (opendkim-*), it may
be useful to discuss whether we want to limit signatures to parts that won't
be dropped, e.g. using l= or similar tag. For example, alternative HTML
text poses a difficulty, because either part can be used, or dropped. How
about adding a "part-hash" in each entity's header?
There's always PGP, a paradigm where SMTP is merely the transport
layer over which the communication rides in a secure tunnel.
Apparently, PGP suffers some of the same defects of that Charles
outlined for S/MIME in [CL3]. In addition, client support is not
widespread.
At any rate, it seems that DKIM has to sign the contents as a means to
avoid replay attacks. Therefore, even if we reused PGP or S/MIME,
we'd need to specify how to integrate them with DKIM, so that failure
to verify any signed part implies failure of the DKIM verification too.
Let me make the "part-hash" idea explicit. I'm not actually proposing
such kind of solution, but the fact that it lays somewhere between RFC
1847 and the DKIM approach, may elicit further insight. Consider this:
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/postponed;
d=example.org; s=selector; t=1279882516;
h=Message-ID:Date:From:Mime-Version:To:Subject;
b=UQbHb+18Dn8jSwgoVl1W38GUohv+Tll4Z/8eulbg0iQG0OUk7
uATrt7Zbm3ubwPlya2vMLtNYYYvLs0rTidbZijQL8qG9QxVsBk
Ol0WxWgbTJ2A/HSouU1RoVpP5LdULDkEs5HnV7PV35fcggZ7Vk
1VNC7T+yDSEkuhQw=
Received: from [192.0.2.0] (sender.example [192.0.2.0])
(AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1)
by msa.example.org with ESMTPSA; Fri, 23 Jul 2010 12:55:16 +0200
id 00000000005DC02B.000000004C4961E9.00007D16
Message-ID: <4C4961EA(_dot_)1070008(_at_)example(_dot_)org>
Date: Fri, 23 Jul 2010 12:55:16 +0200
From: User <user(_at_)example(_dot_)org>
Mime-Version: 1.0 (do we sign this comment?)
Content-Type: multipart/mixed; boundary="=boundary" (not signed)
To: Someone Else <another(_dot_)user(_at_)example(_dot_)org>
Subject: test
This is MIME-formatted message. It is useless to sign this preamble,
as email software that supports MIME-formatted messages may alter it.
--=boundary
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 8bit
DKIM-Signature: c=mellowed;
bh=f5Ntex6CQc9yQ5G0sHQSlHe2NtZLLBy1fomussAxaE0=;
b=UQbHb+18Dn8jSwgoVl1W38GUohv+Tll4Z/8eulbg0iQG0OUk7
uATrt7Zbm3ubwPlya2vMLtNYYYvLs0rTidbZijQL8qG9QxVsBk
Ol0WxWgbTJ2A/HSouU1RoVpP5LdULDkEs5HnV7PV35fcggZ7Vk
1VNC7T+yDSEkuhQw=
The body of this MIME entity is signed on its own, using 8bit.
The "master" signature supplies any parameters, such as v=, a=, d=,
s=, t=, that are not overridden by the entity-signature. The master
signature signs headers only. However, Content-* headers should not
be signed (that also avoids format=flowed to format="flowed" kind of
changes).
Entity headers are not signed, only their body is. Any encoding is
undone, recovering the original content, possibly binary. For plain
text, some punctuation is replaced by spaces --in particular the
greater-than signs ">"-- and multiple whitespace is replaced by a
single space. Recall it only has to be robust enough to deter
from replaying.
--=boundary--
Any epilogue is also not signed.
Would such signatures survive even when attachments are dropped?
Could such signatures be (partially) verified by software not
implementing the "postponed" and "mellowed" canonicalizations?
--
[CL3] http://mipassoc.org/pipermail/ietf-dkim/2006q4/006640.html
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg