> However it also opens the door to insufficient or incompatible
> signing. I sign a few fields, and you validate as if there
> is a robust protection of the headers. I sign a few headers and you
> sign a lot, with little overlap between our sets; should the validator
> treat validation of our two messages the same?
The way the spec is written I suppose the validator will have to treat
the two messages the same (at least as far as validation of the
signature goes). However, afterward, which headers were included in the
validation will have to be considered if you intend to take some action
based upon the valid state of the message.
For example, consider the case of Yahoo with DomainKeys. Currently,
they present a message in the MUA to the effect of "DomainKeys has
confirmed that this message was sent from <domain>". My own product
inserts a similar message into its web based MUA. Now, suppose such a
message were displayed based upon a DKIM verification which did not
cover the Subject header and that header had been modified for some
reason. This might tend to make the end user believe that the altered
Subject text was cryptographically verified and true to the original
when, in fact, it wasn't, and isn't. This is why Yahoo's choice of
wording in their message was very careful and particular. Some might
not be so thoughtful.
If you don't want to get into end user details, similar problems could
arise in filtering agents if some filter is based upon the accuracy of
the Subject text, or omits the filtering of the Subject text altogether,
when a valid DKIM signature is present. This issue needn't be
restricted to the Subject header.
> 1. How are folks deciding what fields to sign?
In my own case I decided to a) sign all headers (except X type headers)
and b) not give my customers a UI to decide which headers to sign and
not sign. This was largely decided because of the issue mentioned above
and because there is some uncertainty about the impact of DKIM's
flexible header signing capability.
> 2. To what extent do we care about different signers choosing
> different fields to sign, in terms of how to process a validated
> signature?
I care greatly if the Subject isn't covered for the reason mentioned above.
Arvel
_______________________________________________
dkim-dev mailing list
dkim-dev(_at_)mipassoc(_dot_)org
http://mipassoc.org/mailman/listinfo/dkim-dev