[Opendnssec-develop] Deactivating old KSK

[Rickard Bellgrim]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

> Should we allow them to "remove" the ds record of an active key? If we
> are
> asked to retire a key and there is no ready key to take over what we do
> now
> is set the retire time to be now, but it will not actually move until
> there
> is a key in the ready state.

I did not read the last message so closely, but shouldn't the command be about notifying that you have added the new ds and not removed the old one?

Because you want to have a chain-of-trust with the new ds. It does not matter that you have an old ds that do not have the corresponding ksk in the zone, right?

> So we could make the dead time equal to the ready time of the
> replacement
> key + max(...) + safety? Or we could throw an error.
>
> If "ds remove" is called on a zone with no retired key should I take
> that
> as an instruction to roll the key?

The algorithm you proposed earlier:

"now" + max(TTL of record in parent zone + estimate of propagation delay through parent zone, TTL of record in this zone + estimate of propagation delay through this zone) + safety margin

You should also have:

If "ready time" > "now" then use "ready time" in the algo above. This will happen if you say to the system that you have added the new ds before the new key is ready.

Correct me if I am wrong...

// Rickard

-----BEGIN PGP SIGNATURE-----
Version: 9.8.3 (Build 4028)
Charset: utf-8

wsBVAwUBSvLWp+CjgaNTdVjaAQhkDggAnQhVrYRBWmmyTN8oYHPlV1Hw07q9iMYZ
hwmDKBM7ny7peVwi2F1W2CtqOC4PWPAHgQcsTZJYEZfGs3metzl91TVKaSo9ZA2b
w45F8Svzv+jSIdRfZVV1Sw05Hq41dV6IPJw7yBwJPNKeOEiD/E3vDr8aWJY785Qt
RofQpvHmmkWyQGqsSQ8oBJrRL8Edk2sjGR0L5Gz8O8GeKs7UJGd/sUD86L4H/Kyz
y4L5ur+/z8ADky9pgeAh7W8YB1kYNcB9Op7RUM1tFC9WUg3NQY81Sk2l5excv5UB
6hPPRm6Ljh9jiV0F/PSljvD5wNYPW6czUWHfhAO/PmjFRbIBit7AbA==
=4QsE
-----END PGP SIGNATURE-----


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20091105/fd81b52b/attachment.htm>