On Sat, 2006-04-15 at 15:54 -0400, Hector Santos wrote:
From: <Bill(_dot_)Oxley(_at_)cox(_dot_)com>
I suspect in the real sysadmin world changing keys every week
probably isn't going to happen :-)
You probably mean "isn't going to happen too often" :-)
The issue is the "period" when there is concurrency of keys, the rollover
time.
So even if you have a key for over a year, the day you do decide to switch,
how long do you keep the old one? The current minimum recommendation is
seven (7) days. I have no problem changing that two weeks.
In my book, this is not a big deal because there isn't going to be any
solution to the idea of some time-shifted, belated, delayed verifier, with
the extreme case of a vacation user not picking up his mail on a regular
basis. This is especially the case, when it has no help from the backend.
The MUA can pick up DKIM signed messages from different places, each with
their own rollover retention periods. So in my book, its just the nature of
the beast for the MUA.
Also consider this, the USER who installs a MUA DKIM-ready system or DKIM
plug-in, will probably now get vendor instructions that says:
"Installing this PLUG-IN requires your MUA to do mail pickups on
a regular basis. Delaying mail pickups over extended periods
(Weeks), can cause false positives with DKIM signed messages."
By not blanking the public portion of the key, a key status indication
could overcome problems related to prematurely causing messages not to
verify at the MUA.
Special actions desired by the sender will likely want to occur at the
MDA and not the MUA with respect to the key changing status. Add a key
parameter that indicates a key has been retired. This would allow
continued processing of received messages prior to MUA verification.
This would permit a differentiation between handling related to messages
with revoked keys, versus those with retired keys. Perhaps in the
revoked key case, the message would be silently discarded, rather than
rejected.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html