I believe I took an action on Thursday's Jabber session to state more
clearly my concerns about x= semantics.
Stephen's proposed text used both the terms "expiration" and "best
before" to describe the x= value. These are very different concepts.
An expiration on a signature would mean that the signature is no longer
valid after that date/time. It does not necessarily mean that the
responsibility that led to the signature has also expired. The
expiration of a signature doesn't affect anything other than that
particular signature; other signatures may exist with different
expirations, and regardless the message itself isn't expiring.
A "best before" date on a signature means that the signature may or may
not not be valid after a certain date, but don't be surprised if you
can't verify it any more. There is nothing wrong with using the
signature after its "best before" date, just like the carton of yogurt
with a "best before" date of April 8 that I ate yesterday, which tasted
fine.
In the Jabber chat, Barry thought we had accepted the "best before"
semantic.
The primary value in the "best before" date is that it helps explain
some signature verification failures. If you get a message that doesn't
verify, and it's past the "best before" date, then it helps explain the
failure. Do you really know that this is the reason for the failure?
No; in fact, if you were able to retrieve the public key and they abide
by the suggested practice of never changing the key under a selector
other than to revoke it, it's fairly certain that this wasn't the reason
for the failure. Furthermore, an attacker could send a message with a
signature showing a best-before date in the past, and a selector that
doesn't exist, and there would be no way to know if the signature had
been valid, or was a complete fabrication. For this reason, you can't
treat signatures past their best-before date any more favorably than any
other breakage.
This causes me to ask, what good is a best-before date on a signature?
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?
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.
-Jim
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html