IMO, the problem here saying that MUA's can participate in
verification is a large rathole.
Maybe, but it's also a rather important usage model and we dismiss it
at our peril. Partly that's because it'll slow down adoption, partly
it's because people will do it anyway regardless of what we say.
1) MUST receive email in a form whose transformations fall within the
acceptable set of modifications as defined in -base-nn (eg, canon, l=)
Right. Fortunately, anything that picks up mail with POP or IMAP
should be OK. And we don't have to spec that -- if the delivery
process smashes the mail, the signature will break regardless of where
in the chain the smashage happens.
2) MUST perform the verification within the "transport window",
typically 7 days.
Sorry, no, we're back to a previous argument. If someone goes away
for two weeks, and comes back and picks up his mail, his MUA is going
to check the signatures regardless of how many MUST NOTs you try to
put in the spec.
In the typical case where the user gets all his mail from a single
known-friendly POP server, it's easy enough to pick the delivery date
out of the top Received: header to see when it was delivered. Even if
it's been a while, the incremental security risk of checking a two
week old signature versus a one week old signature is pretty puny
compared to the presumably large benefit of verifying that a message
was signed.
I still don't understand the point of trying to prevent people who
don't read their mail every day from using DKIM.
3) MUST store the results of the verification process if results of the
verification process will be used for some later process
Honestly, that's none of our business. Maybe they prefer to cache the
key and rerun the verification later, or something else we haven't
thought about.
So anyway, here's two concrete suggestions:
a) The spec should say that DKIM is intended for securing messages in
transit rather than messages in an archive, and leave it at that. In
particular, I realize that a week is a practical limit for message
transit, but I haven't seen any cryptographic justification to limit
signature lifetimes to a week rather than an hour or a month.
b) It'd be a good idea to discourage people from reusing a selector
with a different key. If you change the key, change the selector, and
don't just alternate two selectors every month with a new key every time.
R's,
John
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html