Address->Mail signing, multiple signatures

[David Woodhouse]

On Tue, 2004-02-24 at 11:30 +0000, David Woodhouse wrote:
> The proposal as it stands; as a straw man to be argued against...

I'll expand on it a bit.

First, we can note that we should allow _multiple_ signatures. If a mail
has From:, Sender:, and Resent-From: headers, then any or all of those
may have signed the message. Any or all may be publishing records in the
DNS saying that you should disregard mail claiming to be from them which
is not signed.

So if we add a new header to contain some form of signed hash of the
contents, we can include the pubkey which was used to generate it. 

Given a mail, and no access to the outside world, we can know which keys
signed which parts of the mail.

The person listed in the From: header may have signed the body.
The person listed in the Sender: header may have signed the body, and
 also the Message-Id: and Date: headers too.
The person listed in the Resent-From: header may have signed body,
 and the headers Message-Id:, Date:, Resent-Date: and Resent-Message-Id:

All we need to provide is a way for people to sign those things (and
possibly some other things) and include the signatures transparently in
the headers of the mail.

And then a way for them to publish in DNS a promise that "All mail I
send will have _these_ parts signed by _this_ key".

In fact, I think we should standardise the '_these_' parts list,
possibly to those I listed above, to avoid unnecessary complexity in the
DNS records.

So you start off with a mail which looks like this:

--------------

Resent-From: Joe <engineer at company.com>
Resent-To: Sleuth <reporter at news.org>
Resent-Message-Id: <102 at server.company.com>
Resent-Date: Tue, 24 Feb 2004 11:30:02 +0000
From: Fred <boss at company.com>
Sender: Jane <secretary at company.com>
Message-ID: <101 at server.company.com>
To: Staff <all at company.com>
Date: Mon, 23 Feb 2004 14:20:34 +0000

You're all going to be fired new week. Sucks to be you.

--
Fred.

This mail was checked for viruses by some company's free advert.

--------------

If it were signed by Fred, as the author, he'd not have known the
Message-Id or Date. Only the content can he authorised. But he'd have
added these headers (don't argue about names):

X-Auth-1-Pubkey: aaaabbbbccccdddd
X-Auth-2-hash-content: 3,3d58b23a,hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh

That content-hash says that you're looking for three lines in the body,
with a cheap-to-calculate rolling checksum of 3d58b23a. Find three lines
matching that checksum and then take a strong hash of those, along with
the numbers 3 and 3d58b23a. It'll come out to hhhhhhhhhhhhhhhhhhhhhh.

Then Jane might have signed it too. She will have added:

X-Auth-2-Pubkey: bbbbccccddddeeee
X-Auth-2-hash-content: 3,3d58b23a,iiiiiiiiiiiiiiiiiiiiiiiiiiiiiii

As the actual sender, she will _also_ have added:

X-Auth-2-hash-Date: jjjjjjjjjjjj
X-Auth-2-hash-Message-Id: kkkkkkkkkkkkkkk

which are just trivial signatures of the contents of those headers.

Now when Joe resends it, he adds his own headers...

X-Auth-3-Pubkey: ccccddddeeeeffff
X-Auth-3-hash-content: 5,5c2d7823,mmmmmmmmmmmmmmmmmmmmmmmm

Note that the content hash now signs _five_ lines, because it's grown a
stupid virus checker advert. The original hashes _also_ work, because
you can find the original three lines and check them, and it's
reasonable to accept the mail with only _two_ extra lines added.

Joe will also add headers with hashes of the Date:, Message-Id:,
Resent-Date: Resent-Message-Id: headers.

That's about it.

--

The only vaguely interesting bit is how we make the hash resilient --
and I think the rolling checksum to find N lines within the body does
that OK. 

You take each MIME part separately if it's a MIME mail. Do the fuzzy
hash thing only on text parts -- after un-base64-encoding if appropriate
and converting to UTF-8. Other parts you just do a straight signature
without screwing about.

S/MIME doesn't look sufficiently flexible to do this, but maybe we could
use it for the signatures of binary parts? 

-- 
dwmw2