[ietf-dkim] Base issue: multiple linked signatures

[Douglas Otis]

On Tue, 2006-12-26 at 15:43 -0800, EKR wrote:

> > I also discussed this with Lisa, and came to a very different conclusion.
> >
> > What is being proposed above is that an additional signature be
> > generated and validated for every "important" header. That is a huge
> > waste of energy, and it will cause massive unnecessary resource usage,
> > particularly for recipients who don't care why a signature might not
> > have validated.
> 
> I don't know what's being proposed here, but as a technical matter
> it's not really the case that you can't individually insulate each
> header from breakage without doing a separate signature for each
> one. Rather, you could simply include digests for the header value in
> the header specification, i.e.,
> 
>    DKIM-Signature: a=rsa-sha256; d=example.net; s=brisbane;
>       c=simple; q=dns/txt; i=@eng.example.net;
>       t=1117574938; x=1118006938;
>       h=from=<digest-value>:to=<digest-value>:subject-<digest-value>:date=<digest-value>;
>       ...
> 
> Again, I'm not offering an opinion on what should or should not be done
> here, merely on what's possible.

Insulation is not as important as assuring an association with the
signature thereby confirming the role being played.

With the current base specification, any email-address domain not within
the signing-domain can not explicitly indicate which email-address is
associated with the signature.  When these domains differ, finding an
association must then be trial and error.  To avoid a trail and error
process, there should there be a means to assert an association that
does not demand zone delegation or the exchange of private-keys.

To retain the current freedoms of choice for email-addresses, one should
consider the situation where the identity within the From header differs
from that of the signing-domain.  The current 'i=' syntax prevents this
association being explicit when these domains differ.

-Doug