On Sat, 2006-04-15 at 15:54 -0400, Hector Santos wrote: > From: <[EMAIL PROTECTED]> > > > > 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
