Section 5.2
...
,---
| A signer SHOULD NOT sign with a key that is expected to expire within
| seven days; that is, when rotating to a new key, signing should
| immediately commence with the new key and the old key SHOULD be
| retained for at least seven days before being removed from the key
| server.
'___
Change to:
: A signer SHOULD NOT sign with a key that is expected to expire within
: a transit period where protection is desired; that is, when rotating
: to a new key, signing should immediately commence with the new key
: and the old key SHOULD be retained for at least the period where
: transit protection is desired, before being removed from the key
: server.
Allow the sender to make this assessment. The sender may wish to
ensure the message verifies when first obtained by the recipient.
The transport to the recipient may suffer greater delays, than that
to an MDA. The seven day recommendation does not consider other
possible transports protected by DKIM.
Reliance upon the deployment of unsigned results headers may create
security risks, as all possible paths to the recipient must assure
such headers before there can be a safe reliance. DKIM can offer
full transport protection sooner without dependence upon provider
services being fully deployed. Few signers expect to be rolling keys
over at a rapid rate. The signature and message date provide filter
inputs with respect to typical message latencies. The verifier will
have a better understanding of what represents normal latencies, than
will the sender by way of key availability.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html