Interesting issues; see below.
At 4:54 PM -0800 3/30/06, Jim Fenton wrote:
> The hash is computed using the hash algorithm
> that is used in the signing algorithm (taken from the "a=" tag),
using "simple" header canonicalization on the DKIM-Signature header.
I believe that some signer and verifier APIs have trouble handling
"simple" canonicalization because they don't present the whole header
field. It may be problematic to mandate "simple" here; why not use the
same header canonicalization specified for the signature?
I'm open to that change; I thought "simple" was the easiest, but
maybe not. How do others feel about this?
> sig-p-tag-result = "verified-ok" / "verified-failed"
/ "not-verified" / x-sig-p-tag-result
I'm concerned that including verification results is going to introduce
a whole bunch of new semantics (and possibly transitive trust) to the
multiple-signature case.
It only introduces semantics if the receiver wants it to. There is
nothing in the spec that says whether or not a receiver would want to
trust these results. However, not including them, and believing that
some signers might break signatures by munging headers or the body,
prevents the receiver from having any idea where a message might have
changed. That's OK, but I thought I heard folks wanting to pass the
information forward in the signing chain.
If a later signer says they didn't verify the
previous signature, or that verification failed, are they taking
responsibility for the message or not?
Of course they are. They are taking responsibility for the message
that they passed. There is nothing in the above semantics that says
anything about responsibility.
If they are in either case, how
is their verification result relevant to the recipient's verifier?
I'm not sure, but I thought that others wanted this. If no one wants
it, it is easy to remove.
Aside from wording nits ("header" -> "header field") I don't see
anything else wrong with this proposal, other than its complexity.
Aw, c'mon. One set of options isn't complex! :-)
As
far as the bid-down attacks are concerned, I think this is an
overreaction; signers wouldn't have a good reason to use any algorithm
that's that thoroughly broken.
True, but we need a way to allow signers to use more than one type of
signature until they are reasonably sure that all recipients are able
to verify with the "better" algorithm. This is the crux of the
Rescorla-Bellovin paper. We are sanguine on bid-down attacks because
we don't have any real-world cases yet for them; that could change in
the future.
I'm also concerned about the prospect of
DKIM verification yielding other than a binary result, if valid
signatures cite others that they say they couldn't verify.
The verification is still binary, but I see your concern about the
interpretation being fuzzy.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html