Fix bug in keymgr_key_has_successor

The logic in `keymgr_key_has_successor(key, keyring)` is flawed, it
returns true if there is any key in the keyring that has a successor,
while what we really want here is to make sure that the given key
has a successor in the given keyring.

Rather than relying on `keymgr_key_exists_with_state`, walk the
list of keys in the keyring and check if the key is a successor of
the given predecessor key.

(cherry picked from commit 0d578097ef)
This commit is contained in:
Matthijs Mekking
2020-05-14 15:06:54 +02:00
parent f20420c3de
commit 168d362b54
4 changed files with 26 additions and 13 deletions

View File

@@ -2534,6 +2534,7 @@ set_keyalgorithm "KEY3" "13" "ECDSAP256SHA256" "256"
set_keysigning "KEY3" "no"
set_zonesigning "KEY3" "no"
# Key states.
set_keystate "KEY2" "GOAL" "hidden"
set_keystate "KEY3" "GOAL" "omnipresent"
set_keystate "KEY3" "STATE_DNSKEY" "rumoured"
set_keystate "KEY3" "STATE_ZRRSIG" "hidden"
@@ -2571,7 +2572,6 @@ set_server "ns3" "10.53.0.3"
# ZSK (KEY2) no longer is actively signing, RRSIG state in UNRETENTIVE.
# New ZSK (KEY3) is now actively signing, RRSIG state in RUMOURED.
set_zonesigning "KEY2" "no"
set_keystate "KEY2" "GOAL" "hidden"
set_keystate "KEY2" "STATE_ZRRSIG" "unretentive"
set_zonesigning "KEY3" "yes"
set_keystate "KEY3" "STATE_DNSKEY" "omnipresent"
@@ -2750,6 +2750,7 @@ set_keyalgorithm "KEY3" "13" "ECDSAP256SHA256" "256"
set_keysigning "KEY3" "yes"
set_zonesigning "KEY3" "no"
# Key states.
set_keystate "KEY1" "GOAL" "hidden"
set_keystate "KEY3" "GOAL" "omnipresent"
set_keystate "KEY3" "STATE_DNSKEY" "rumoured"
set_keystate "KEY3" "STATE_KRRSIG" "rumoured"
@@ -2793,7 +2794,6 @@ set_zone "step3.ksk-doubleksk.autosign"
set_policy "ksk-doubleksk" "3" "7200"
set_server "ns3" "10.53.0.3"
# KSK (KEY1) DS will be removed, so it is UNRETENTIVE.
set_keystate "KEY1" "GOAL" "hidden"
set_keystate "KEY1" "STATE_DS" "unretentive"
# New KSK (KEY3) has its DS submitted.
set_keystate "KEY3" "STATE_DNSKEY" "omnipresent"
@@ -2979,6 +2979,7 @@ set_keyalgorithm "KEY2" "13" "ECDSAP256SHA256" "256"
set_keysigning "KEY2" "yes"
set_zonesigning "KEY2" "no"
# Key states.
set_keystate "KEY1" "GOAL" "hidden"
set_keystate "KEY2" "GOAL" "omnipresent"
set_keystate "KEY2" "STATE_DNSKEY" "rumoured"
set_keystate "KEY2" "STATE_KRRSIG" "rumoured"
@@ -3020,7 +3021,6 @@ set_server "ns3" "10.53.0.3"
set_zonesigning "KEY1" "no"
set_zonesigning "KEY2" "yes"
# CSK (KEY1) DS and ZRRSIG will be removed, so it is UNRETENTIVE.
set_keystate "KEY1" "GOAL" "hidden"
set_keystate "KEY1" "STATE_ZRRSIG" "unretentive"
set_keystate "KEY1" "STATE_DS" "unretentive"
# New CSK (KEY2) has its DS submitted, and is signing, so the DS and ZRRSIG
@@ -3278,6 +3278,7 @@ set_keyalgorithm "KEY2" "13" "ECDSAP256SHA256" "256"
set_keysigning "KEY2" "yes"
set_zonesigning "KEY2" "no"
# Key states.
set_keystate "KEY1" "GOAL" "hidden"
set_keystate "KEY2" "GOAL" "omnipresent"
set_keystate "KEY2" "STATE_DNSKEY" "rumoured"
set_keystate "KEY2" "STATE_KRRSIG" "rumoured"
@@ -3316,7 +3317,6 @@ set_policy "csk-roll2" "2" "3600"
set_server "ns3" "10.53.0.3"
# CSK (KEY1) DS and ZRRSIG will be removed, so it is UNRETENTIVE.
set_zonesigning "KEY1" "no"
set_keystate "KEY1" "GOAL" "hidden"
set_keystate "KEY1" "STATE_ZRRSIG" "unretentive"
set_keystate "KEY1" "STATE_DS" "unretentive"
# New CSK (KEY2) has its DS submitted, and is signing, so the DS and ZRRSIG