Stephen Farrell wrote: > Current: > > x= Signature Expiration (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. > > Proposed: > > x= Signature Expiration/Best-Before (plain-text, OPTIONAL, default is > no expiration/best-before). The format is the same as the "t=" tag, >
I'm not sure I want to start another discussion about the "t=" tag like we had about the "x=" tag, but I'm even less sure what to do with t=. Do we want to base the format on that of t=? > represented as an absolute date, not as a time delta from the > signing timestamp. Verifiers who support x= MUST conside a > signatuure invalid if the current time at the verifier is past > the expiration date. If a signature is invalid for this reason, > then the normal rules apply, so the signature SHOULD be treated > the same as if cryptographic checking had failed or as if the > public key could not be retrieved. The latter isn't a very good example, since section 6.2 refers to deferring acceptance of messages if the public key can't be retrieved, and that would not be desirable in the case of an expired signature. > Verifiers MUST NOT asssume > that there is any particular relationship between the x= value > and the life cycle of a public key. > I'm not clear on what the above statement means. What would be an action that results from an assumption of this sort? -Jim _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
