Paul Hoffman wrote: > At 5:28 PM -0400 4/18/06, <[EMAIL PROTECTED]> wrote: >> Proposed >> x= Expiration date (plain-text; RECOMMENDED, default is no >> expiration). The format is the same as in the "t=" tag, >> represented as an absolute date, not as a time delta from the >> signing timestamp. Signatures MUST NOT be considered valid if >> the current time at the verifier is past the expiration date. >> The value is expressed as an unsigned integer in decimal ASCII, >> with the same constraints on the value in the "t=" tag. The >> value >> of the "x=" tag MUST be greater than the value of the "t=" tag if >> both are present. >> >> INFORMATIVE NOTE: The x= tag is not intended as an anti- >> replay defense. Its proposed use is to indicate Key/Signature >> expiration. When message is considered expired It becomes the >> policy of the verifier on how to further process the message. > > There is a *huge* difference between key and signature expiration. > Given that x= appears in a signature, the informative note should say > "...indicate signature expiration". But, if we do that, we need to say > what it means for a signature to expire. We can reuse semantics on > signature expiration from other IETF specs, if we can find one that > has expiring signatures. > > The last sentence in the informative note directly contradicts the > MUST NOT in the body of the definition. I understand some people want > it one way and others want it the other way, but we can't have a spec > that says both. +1
There is also a huge difference between key or signature expiration, and message expiration. The text "When message is considered expired" implies that the message itself expires, which it does not do. -Jim _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
