Hi Arvel,
Arvel Hathcock wrote:
> In other words, given the pragmatics, how often is reasonable an
> appropriate for changing keys?
I'm just going to be honest and say that I have NEVER changed my key
since we started signing with DK over 14 months ago. I think I should
also throw out that our customers won't regularly change their keys
either (unless I can figure an automated way to do it for them). Unless
the key has been compromised, why bother with changing it at all? I'm
sure I have much to learn here and am about to learn it :)
There are cryptographic reasons why you don't want to keep using
the same key forever, but I don't believe that we need worry too
much about that here (anyone done the math to see how many
signatures before its a concern?).
More practical things that you do need to consider include:
- If using s/w crypto, then everyone who can login or run code on
that box can potentially grab the private key, so you need to
figure out how much risk that represents and probably try to
change keys so that you reduce the risk to what you consider is
an acceptable level.
- Decommissioned equipment (s/w or even h/w crypto) is a potential
source of key leakage, if you do this often, particularly with
s/w crypto you should replace and revoke, because no matter how
hard you try there may be key bits exposed on the old kit. If
you clone boxes (and keys) this all gets worse of course.
But basically DKIM is no different from secure web servers in terms
of private key handling, so there's plenty of experience out there.
One difference might be that annual certificate expiry tends to
cause key replacement in the SSL/TLS case.
Stephen.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html