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

[Michael Thomas]

Paul Hoffman wrote:

> At 5:04 PM -0700 4/24/06, Michael Thomas wrote:
>
>> Paul Hoffman wrote:
>>
>>> At 3:32 PM -0700 4/24/06, Jim Fenton wrote:
>>> 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.
>>
>>
>> That's not correct. The receiver's motivation is to defend itself.
>
>
> Correct.
>
>> Validating messages
>> a priori does not do that.
>
>
> True, but does it hurt to do so? If a recipient validates a message 
> that has "expired", what is the harm to the recipient? The advatage, 
> of course, is that they are now sure where the message came from; this 
> is the same as in the normal, unexpired case.


All I'm trying to point out here is that the sender and receiver's 
motivations are
not at odds with each other. In fact, they seem quite aligned to me. And 
that's
true even if the receiver goes ahead and does the key lookup anyway; in both
cases, it has pretty reliable information from the sender that 
something's not
kosher, and that's always useful for receivers.

>> If a sender through its own policy says "don't trust/honor/blame me
>> this after this time", why should a receiver not honor that?
>
>
> If that policy makes no sense for the recipient (the sender was 
> responsible at time X but not at time X+1), then the recipient would 
> still want to know whether the message came from the putative source.


I don't see why it doesn't make sense, but if the only thing that we're 
differing
on is whether a receiver may or may not do the validation after the 
expiration
time... I don't really have much feeling one way or the other about 
that. I tend
to think they shouldn't, but I could live with it being a choice for the 
receiver
and defer this argument until we actually have some wide deployment 
experience.

       Mike