[ietf-dkim] Base issue: multiple linked signatures

[Douglas Otis]

On Dec 28, 2006, at 6:19 AM, Michael Thomas wrote:

> There's two ways to read this restriction: one is that you should  
> never do this under any conditions which ventures into silly  
> net.cop delusions of what the protocol document can mandate, and a  
> more innocent caution that the actual headers to be used for a dkim  
> verification are the outside headers, not the copied headers.
>
> The latter is the only reasonable way to read this. I agree with  
> John that this is pretty well trod ground and that it's pretty much  
> hopeless that we'll agree on any particular approach -- including  
> what started this thread. Nor do I think we ought to since it's an  
> inherently driven by heuristics which involve risk/reward tradeoffs  
> for the receiver which a standard should not be trying to second  
> guess. Leaving some raw tools around like z= and letting receivers  
> decide for themselves is about all we need for now, IMO.

Header copies might become useful as an interim fix when resolving  
issues created by "fix-ups" added by MDAs, which can be problematic  
at this time.  A hash value for the header would allow a faster  
isolation of problematic headers.   These issues should be resolved  
when the "fix-ups" are discontinued, but that might be holding one's  
breath for a while.

A more significant concern is related to the number of attempts  
needed to resolve which signature goes with which email-address,  
resulting from a missing link.  Don't assume the signing-domain and  
the email-address domain owners have exchanged private-keys or  
delegated domains in some manner.  That assumption represents a  
substantial barrier for deployment.

DKIM differentiated itself from S/MIME and OpenPGP by ensuring the  
signature remained _invisible_.  Expecting recipients to recognize a  
DKIM signing-domain assumes:

1) The signing-domain is somehow visible, which will likely confuse  
more than enlighten.

2) The signing-domain and the email-address are directly related,  
which is unrealistic in the general case.

Providing a means to link the email-address to the signature  
dramatically reduces the overhead associated with searching for a  
corresponding signature, assuming there are other means developed  
that indicates an association that does not depend upon the exchange  
of private-keys or zone delegations.

This linkage can be accomplished by making a rather minor change to  
the 'd=' and 'i=' syntax within the base draft.

3.5 The DKIM-Signature header field (i=)

---'d='

Was:

This domain MUST be the same as or a parent domain of the "i=" tag  
(the signing identity, as described below), or it MUST meet the  
requirements for parent domain signing described in Section 3.8  
(Signing by Parent Domains). When presented with a signature that  
does not meet these requirement, verifiers MUST consider the  
signature invalid.

Change to:

This domain MUST the same as or a parent domain of the "i=" tag (the  
signing identity, as described below) , or it MUST meet the  
requirements for parent domain signing described in Section 3.8  
(Signing by Parent Domains) for key record extensions ('g=' and 't=s'  
to be valid).  When presented with a signature not meeting these  
requirements, other unspecified means to associate the email-address  
domain with that of the signing domain are required, otherwise  
verifiers MUST consider the signature invalid.

---'i='

Was:

Identity of the user or agent (e.g., a mailing list manager) on  
behalf of which this message is signed (dkim-quoted-printable;  
OPTIONAL, default is an empty local-part followed by an "@" followed  
by the domain from the "d=" tag). The syntax is a standard email  
address where the local-part MAY be omitted. The domain part of the  
address MUST be the same as or a subdomain of the value of the "d=" tag.

Change to:

Identity of the user or agent (e.g., a mailing list manager) on  
behalf of which this message is signed (dkim-quoted-printable;  
OPTIONAL, default is an empty local-part followed by an "@" followed  
by the domain from the "d=" tag).  The syntax is a standard email  
address where the local-part MAY be omitted. The domain part of the  
address is not required to be same as or a subdomain of the value of  
the "d=" tag.

-Doug