At 12:08 PM +0200 9/29/08, Matthijs Mekking wrote:
I encourage making the 4641 document more up to date and adding better
definitions. However, one issue draw my attention: I am not sure if
doing key rollover in emergencies only is good practice, for a couple of
reasons:
* All keys have an expected lifetime. After the lifetime, you may expect
a key to be compromised. Because you cannot easily suspect this until
harm is being done, I say its better to prevent than to fix. So do key
rollover only when the keys lifetime is running out, (inclusive) or it
is suspected that the key has been compromised.
I tried hard in my proposed new text to make it clear that the above
reasoning is flawed. You cannot "expect a key to be compromised" at
any particular time in the future. That's like predicting when
someone will break into your house. If you have an idea about that,
and you care what is in your house, you will add better protections.
This is not a new idea. Look at the expiration dates on the
certificates in the trust anchor store in your browser. Many of them
are at least twenty years from now. This is not a reflection that the
CA thinks that their security is perfect for the next twenty years,
then will become so bad that the secret key will be stolen.
* If keys that act as trust anchors have a long lifetime (effective
period), key rollover is hardly operated. Doing key rollover
periodically, not only for KSKs that do not act as trust anchors, gives
us more operational practice.
* Besides, you cannot know if a resolver will pick up your KSK as a
trust anchor, so you should consider that all your KSKs can be used a
trust anchor.
* Change of zonedata size or local policies might mean that a change in
KSK is made (longer key, different algorithm...)
I thought I covered all of those in the proposed changes. If I
didn't, it was a mistake. But they are just one school of thought.
The "don't ever expire" school of thought, which is also widely held,
is essentially the opposite.
--Paul Hoffman, Director
--VPN Consortium
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
