I move this to -users now, hoping to attract more responses. Please keep
followups there.
On Saturday 20 January 2007 16:29, Magnus Holmgren wrote:
> I've come to the conclusion that it's not possible to simply adapt the
> existing dk.c to use libdkim instead of libdomainkeys - the interfaces are
> too different, especially for verification.
>
> First, libdomainkeys gives a single result (was the signature OK, who
> signed, etc), while libdkim gives a list of all signatures and their
> respective status. There is a good reason for this: DomainKeys required the
> signing identity to be the address in the Sender: field if it exists,
> otherwise the address in the From: field. That has the advantage that it is
> the identity shown by the MUAs that will be authenticated. It has the
> drawback that mailing list managers that add footers (like this one) will
> have to re-sign all mail and change the Sender field.
>
> In DKIM, however, the signing identity is found only in the signature
> field. This means that there can be any number of valid (and invalid)
> signatures.
However, SSP (Sender Signing Policy), which I didn't look very closely at
until now (it's a separate standard that isn't done yet), addresses this and
lets domains declare that they sign all their mail. Unlike DomainKeys, it's
always the (first) address in the From field that is the Originator Address,
but relays (MLMs etc.) that re-sign messages don't have to add or alter the
Sender field (but is recommended to do so anyway).
Considering this, as well as practical use cases, perhaps we can make DKIM
functionality rather similar to the existing DK functionality.
In a message header there can be one Originator Signature and any number of
Third-party Signatures (but in practice never more than one or maybe two).
third-party signatures are good for two things (*if you trust the signer*, of
course): 1) They can certify that the originator signature (or the previous
signature, or both; I'm not sure) was valid when it got to them: "A
DKIM-aware Mailing List Manager MUST NOT re-sign an improperly signed message
in such a way that would imply that the existing signature is acceptable."
and 2) they can certify that the message was indeed sent by the purported
originator, even if there is no originator signature, e.g. if the identity
has been established through some other means (it doesn't say this in the SSP
I-D, but you can see that it's a workable use case; an example would be the
Exim Bugzilla, which sends out notices on behalf of the person who adds
comments or changes bug fields (the mail-in interface lacks authentication
though, so we should be careful there).
This means that there *can* be DKIM features that work similarly to the
existing DK features: Exim would need a list of trusted third-party signers;
dkim_sender_domains, dkim_sender_local_parts, and dkim_senders would then
succeed if there is a matching, valid originator signature *or* there is an
originator signature that is signed by a trusted third-party signer.
dkim_status and dkim_policy could also refer to the originator signature.
But users could still want to do things with messages that are simply signed
by certain signers, even if there is no originator signature, so there are
still many things to take into account.
--
Magnus Holmgren holmgren@???
(No Cc of list mail needed, thanks)
"Exim is better at being younger, whereas sendmail is better for
Scrabble (50 point bonus for clearing your rack)" -- Dave Evans
