I think the expiration tag (x=) should remain as part of the specification.
But functionally defined better as a message transaction (dynamic or
delayed) key management security concept.
NOTE: This is just a suggestion, "food for thought," for the authors to
consider. I purposely added more content than probably necessary so that
all related ideas can covered. Skip, prune, fine tune as necessary
Current:
x= Signature Expiration (plain-text; RECOMMENDED, default is no
expiration). Signature expiration in seconds-since-1970 format
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 contraints on the value in the "t=" tag.
INFORMATIVE NOTE: The x= tag is not intended as an anti-
replay defense.
ABNF:
sig-x-tag = %x78 [FWS] "=" [FWS] 1*12DIGIT
Proposed change:
x= Signature Expiration (plain-text; RECOMMENDED, default is no
expiration). Signature expiration in seconds-since-1970 format
as an absolute date, not as a time delta from the signing
timestamp. The value is expressed as an unsigned integer
in decimal ASCII, with the same constraints on the value in
the "t=" tag.
The expiration is a DKIM signature descriptor exposing the
responsible domain intent to define and control the DKIM
signed message validity life span. Although this control
might be viewed as domain key management and security
concept, the domain's true intent and purpose is out of
the scope.
If present, the expiration time MUST be compared against
the message transaction reception time. Another name for
this time is the Message Post Time.
Informative Note: In theory, message post time is not
necessarily the same as the transaction reception time.
The message post time could be the time the message
as actually posted (saved) into a non-temporary message
store after it has been received and pre-processed the
by AU's AVS or Mail Filtering Agent (MFA) facility.
Extracting the transaction reception time depends on where
the DKIM verifier is operating at the AU.
- Dynamic (transport) level,
- Delayed Post Transport (storage) Level
For dynamic verification operations, the transaction reception
time is the current system time.
For delayed verifications operations, the transaction reception
time is the time extracted from the 2822.Received: header as
required to be added by the transport SMTP receiver. For
non-SMTP based transactions, use the appropriate trace header
to record and extract the transaction reception time.
If the transaction reception time at the verifier is past
the expiration date, the signature classification depends
on whether the signature was checked for validation or not:
Result when time has Expired
================= ===============================
Signature Checked Signature classification
================= ===============================
not checked SHOULD NOT be considered valid,
MAY choose to validate
----------------- -------------------------------
valid SHOULD NOT be considered valid
----------------- -------------------------------
invalid MUST NOT be considered valid
----------------- -------------------------------
Verifiers MAY choose to not perform a DKIM verification
before the expiration time is checked.
If the signature is not checked, expired signatures SHOULD
NOT be considered valid. The verifier MAY choose to perform
signature check first before making the final classification.
If the signature is valid, expired signatures SHOULD NOT be
considered valid.
If the signature is invalid, expired signatures MUST NOT be
considered valid.
INFORMATIVE NOTE: The x= tag is not intended as an anti-
replay defense.
ABNF:
sig-x-tag = %x78 [FWS] "=" [FWS] 1*12DIGIT
Reasoning:
The expiration should be compared against the transaction reception time
(MSG.RCVDTIME) or Message Post Time (MSG.POSTTIME), not the current system
time (SYSTEM.TIME).
This resolves the question on whether the expiration may be used to
invalidate an already stored message by changing its status.
In theory, for transaction level DKIM verification operations
SYSTEM.TIME = MSG.RCVDTIME <= MSG.POSTTIME
But for delayed DKIM verification operations, we have:
MSG.RCVDTIME <= MSG.POSTTIME < SYSTEM.TIME
Where
SYSTEM.TIME is the current computer time when the
verification takes place.
MSG.RCVDTIME is the current computer time the
transaction was received. (Same as trace header
Received: time)
MSG.POSTTIME is the current computer time after the
message was received and after it was pre-processed
by MFAs (Mail Filtering Agents) and actually SAVED and
RELEASED for user access.
For the most part, I think MSG.RCVDTIME should be viewed as the same as the
MSG.POSTTIME since it will typically be the same when the time resolution is
compared by the minute and the MFA overhead is low. But this all depends on
the AU incoming mail processing practice. I make the distinction because
most systems, well, I can only for ours, have a MSG.POSTTIME field So if we
have add or a 3rd party developer adds a MUA based verifier, it would be
faster to get this time rather than read the Received line. Small
distinction, probably not even worth mentioning.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html