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:
@@ -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
|
||||
|
||||
Reference in New Issue
Block a user