[ietf-dkim] "Best Before" vs. "expiration" date

[Paul Hoffman]

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.