Extending DKIM through an identity tag

From: SM <sm_at_resistor.net>
Date: Fri, 16 Oct 2009 09:25:04 -0700

Hello,

The DKIM specifications allows for additional tags. According to RFC
4871, unrecognized tags must be ignored. I would like to add a FFR
which extends DKIM by adding an identity tag. The purpose is to tie
in identities as an experiment.

There are several "identities" (used loosely) in email. Most people
view the email address in the "From:" header as important. When the
messages goes through a mailing list where changes are performed on
the message, the DKIM signature verification fails. A few mailing
lists sign the message. It is not possible for a receiver to tell to
what that DKIM signature is tied to. If we can specify a "link" to
one of "identities" in the message headers, e.g. the List-ID: or
Sender:, it can help receivers validate mailing list traffic and
other third-party signatures.

As an example, my message current has as DKIM signature with:

         h=Message-Id:Date:To:From:Subject:In-Reply-To:References:
         Mime-Version:Content-Type:Sender:List-Help:List-Unsubscribe:
         List-Id:List-Subscribe:List-Owner:List-Post:Cc;

It is proposed to add a hi=header-field-name tag. The DKIM signature
would now be:

         h=Message-Id:Date:To:From:Subject:In-Reply-To:References:
         Mime-Version:Content-Type:Sender:List-Help:List-Unsubscribe:
         List-Id:List-Subscribe:List-Owner:List-Post:Cc;hi=List-Id;

Once the DKIM verification is done or as a last stage in a DKIM
verification, we see whether the domain name part in the List-ID
matches the DKIM User/Agent Identifier. That identifier should also
match or be a subdomain of the Signing Domain Identifier to prevent abuse.

With the above, receivers would be able to whitelist or score mailing
list traffic. The above extension could also be used to identify
forwarders, resent messages, etc. I am not suggesting having a
constraint on the "hi=" tag as the aim is to be able to express the
identity through the semantics of the header fields chosen by the
signer. Note that final decision rests with the receivers and as
such, this should be viewed more as a way for signers to signal what
they are doing instead of forcing a policy onto the receivers.

ADSP could be extended through a dkim=identity tag to signify that
the domain is DKIM signing and there should be a tie to an
identity. There are two paths here:

  1. The Author Domain advertises that so that messages going through
any path (mailing list, forwarders, etc) should be DKIM signed.

  2. It applies to the Signing Domain only.

OpenDKIM already supports an Identity header (FR #SF2839110). We
only have to modify the code to support an optional tag.

I would like to stress that this is an experiment and not a
reinterpretation of the DKIM specifications. OpenDKIM should remain
compliant with all the RFCs.

What do you think?

Regards,
-sm
Received on Fri Oct 16 2009 - 16:25:30 PST