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
