At 3:32 PM -0700 4/24/06, Jim Fenton wrote:
This causes me to ask, what good is a best-before date on a signature?
Good question. I don't agree with the people who want it to mean
"don't check for the signing key after this date". That's silly: it's
a simple DNS query, it takes less effort to reject than it does to
start a TCP connection.
The same thing holds true, with minor changes, under the expiration-date
paradigm. The only differences are that (1) expiration makes it
possible to optimize-out the checking of expired signatures, and that
(2) expired signatures are definitely invalid. This leads me to wonder
that the value of deliberately invalidating a signature on expiration
is: about the only use I can think of for (2) is to limit the scope of
replay attacks, but no, the informative text says we shouldn't do that.
So what should we do with it then?
More good questions. "I, the sender, want this to not be able to be
validated after this date" is all well and good, but the sender's
wishes go directly against the recipient's wishes, which are to have
as many validated messages as possible.
The logic gets even more tortured when you spell out the whole
equation, which is "I, the sender, want this to not be able to be
validated after this date, but if you have already validated it, oh
well."
I'm neutral on the received vs. verification time issue because I'm not
sure what to do with the x= value in the first place.
Some folks wanted to tell the receiver what time reference to compare
to for "best before" or "expiration". If there is an indication that
users want to listen to the sender about validation, they may want to
know this detail.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html