I understood that there was some root zone maintenance times that meant that
changes had to happen on the 11th or something of Jan/May/July/Sept, or some
such. Otherwise, I like the concept of your schedule.
It's a bit US centric in terms of bank holidays, etc, but I'm sure that the
exact exclusion list (as you suggest) can worked out.
My mistake, I think any common day's off of work should be considered. I imagine
that there are some lists available to consider for this topic, but I am not aware
of any good ones at this point. Looking through a bunch of sites online, if all
holidays were considered, there would be no days available, but there will
probably have to be a line drawn somewhere, and I'm not the person to decide on
that.
I think that this is an important thing to consider, but I think that we need
to think more about what kinds of emergencies it deals with, and which kind
still cause a failure.
Agreed. The scenarios that I had considered were:
1) Weakness discovered in the use algorithm used to sign the KSK might
leak bits of the key. (Switching to a new key might buy a month or two to rotate
the key at a faster rate until a long term mitigation is found)
2) A vulnerability is found in the software used to sign the zone that might put
the key at risk when signing the ZSK. In this case, a fix in the vulnerability should
be implemented before resigning the zone.
3) The algorithm used to sign the KSK may found to be reversible, or not or
significantly easier to crack than originally thought. (this is the primary case for
another key algorithm to be in the set of the backup keys).
i seem to recall that there was another one, but I can't recall it at this point.
--tim