Subject: [ietf-dkim] Section 5.2 move recommendations for key retention to a BCP

From: Douglas Otis <[email-masked]>
Date: Thu, 20 Apr 2006 11:31:53 -0700

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