----- Original Message -----
From: "Mark Delany" <MarkD+dkim(_at_)yahoo-inc(_dot_)com>
Hector, you've done a great job of describing the mechanics as you see
it, for x=. In short you've describe "what" x= might mean really well.
What I'm not grasping - and I apologize for this - is the "why".
Why should verifiers care about an x=? What problem do you see it
solving? Particularly, what problem does it solve that a Selector
revocation doesn't solve?
You allude to an answer above with "key management security concept"
but I don't see any elaboration in your later text.
Good morning,
I left the "reason" as out of scope because I think there are many reasons
why one might implement it, especially depending on what role you are
playing.
Lets ask it this way:
What is the purpose of DKIM?
And how does expiration help it?
From the innocent verifier standpoint, its goal in DKIM might include:
- Address the malicious transaction problem,
- Quickly disseminate the bad from the good,
- Reduce overhead,
- Protect customers/users,
- Help protect DKIM domains as a standard consistent protocol.
In short, address the global spam problem.
Does expiration contribute for this purpose?
From a verifier standpoint, it is looking to be told what is bad mail. It
wants every piece of information the domain can expose to communicate levels
of control.
From a signer standpoint, If the domain is saying the expiration is one
such control to invalidate a signed transaction, then it is not up to the
verifier to decide if its useful idea or not. The verifier will not know
the "true intent" of the domain's control here. Why should the verifier not
honor it?
This is also addresses your previous question regard the application usages
and there they serve any useful purpose. That all depends on your role.
I apologize if this short answer doesn't fully describe my overall opinion,
but I will say that DKIM is short on controls or fail detection ideas in
DKIM.
What is unique about Expiration is that it is probably the only clear item
in the DKIM protocol that helps with failure detection:
expiration ----> clear definition for invalid,
no verification required.
key change --> fail hashing,
viewed as never existed.
So is there a higher invalid "weight" with the clear expiration detection?
The specs already implies to not reject if the signature fails. So
deprecating the expiration descriptor will fall in line with the going on
philosophy.
Any who, I think it is useful. Whether how useful it is for the signer, it
open to many interpretations based on what role you are playing.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html