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