Hello, I would like to import keys for a shared policy, including the inception date, so the state on the test system is the same as on the production system.
For this I issue, e.g. for the shared KSK:
```sh
ods-enforcer key import \
--repository <myrepo> --cka_id <locator> \
--keytype KSK --keystate active \
--inception_time 2020-08-26-15:56:56 \
--algorithm '8' --bits '2048' \
--zone <zone1>
```
While this works fine, for all subsequent zones in the shared policy (e.g.
`zone2` ... `zoneN`), I receive the following error:
```sh
Already used this key with this locator: <locator>
```
If I later request the key states for zones using this policy, I see that the
first imported zone has the KSK is active, the other zones are in
`ready/waiting for ds-seen` states:
```sh
# ods-enforcer key list --verbose | grep KSK | grep '^<zone>'
<zone1> KSK active 2022-08-24 15:59:15 2048 8 <locator> <myrepo>
<keytag>
<zone2> KSK ready waiting for ds-seen 2048 8 <locator> <myrepo>
<keytag>
<zone3> KSK ready waiting for ds-seen 2048 8 <locator> <myrepo>
<keytag>
[...]
```
The fact that the inception time is only applied to the first imported zone is
confirmed while looking at the `kasp.db` SQLite DB, especially the `keyData`
and `keyState` tables:
```sh
# sqlite3 -header -csv kasp.db "SELECT p.name, z.name, d.*, s.* FROM keyData d LEFT
JOIN keyState s ON s.keyDataId = d.id LEFT JOIN zone z ON z.id = d.zoneId LEFT JOIN
policy p ON p.id = z.policyId WHERE d.role = 1 ORDER BY p.id, z.id, d.id, s.id ASC;"
name,name,id,rev,zoneId,hsmKeyId,algorithm,inception,role,introducing,shouldRevoke,standby,activeZsk,publish,activeKsk,dsAtParent,keytag,minimize,id,rev,keyDataId,type,state,lastChange,minimize,ttl
<mysharedpolicy>,<zone1>,5,7,3,5,8,1598457416,1,1,0,0,0,1,1,3,<keytag>,4,17,2,5,0,2,1642694226,1,43200
<mysharedpolicy>,<zone1>,5,7,3,5,8,1598457416,1,1,0,0,0,1,1,3,<keytag>,4,18,1,5,2,2,1598457416,0,3600
<mysharedpolicy>,<zone1>,5,7,3,5,8,1598457416,1,1,0,0,0,1,1,3,<keytag>,4,19,1,5,3,2,1598457416,0,3600
<mysharedpolicy>,<zone1>,5,7,3,5,8,1598457416,1,1,0,0,0,1,1,3,<keytag>,4,20,1,5,1,4,1598457416,0,86400
<mysharedpolicy>,<zone2>,15,10,4,5,8,1642694225,1,1,0,0,0,1,1,2,<keytag>,4,57,3,15,0,1,1643001983,1,43200
<mysharedpolicy>,<zone2>,15,10,4,5,8,1642694225,1,1,0,0,0,1,1,2,<keytag>,4,58,3,15,2,2,1642744527,0,3600
<mysharedpolicy>,<zone2>,15,10,4,5,8,1642694225,1,1,0,0,0,1,1,2,<keytag>,4,59,3,15,3,2,1642744527,0,3600
<mysharedpolicy>,<zone2>,15,10,4,5,8,1642694225,1,1,0,0,0,1,1,2,<keytag>,4,60,1,15,1,4,1642694225,0,86400
<mysharedpolicy>,<zone3>,121,9,5,5,8,1642694244,1,1,0,0,0,1,1,2,<keytag>,4,481,3,121,0,1,1643001983,1,43200
<mysharedpolicy>,<zone3>,121,9,5,5,8,1642694244,1,1,0,0,0,1,1,2,<keytag>,4,482,3,121,2,2,1642744537,0,3600
<mysharedpolicy>,<zone3>,121,9,5,5,8,1642694244,1,1,0,0,0,1,1,2,<keytag>,4,483,3,121,3,2,1642744537,0,3600
<mysharedpolicy>,<zone3>,121,9,5,5,8,1642694244,1,1,0,0,0,1,1,2,<keytag>,4,484,1,121,1,4,1642694244,0,86400
```
Considering shared policies, it seems strange to me that `ods-enforcer key
import` requires a `--zone` argument and not a `--policy` argument (as the
one-to-one matching between the two is not relevant for shared policies), or
that the command doesn't actually import the key (or at least apply the
requested states and inception time) on subsequent zones of a shared policy.
To get around this, I could manually update the `kasp.db` (this is on a test
system):
- set `keyData.inception = <inception_time>` and `dsAtParent = 3` for all KSKs
of the subsequent zones
- set `keyState.state = 2` where `keyState.state = 1` for all KSKs of the
subsequent zones
- set `keyState.lastChange = <inception_time>` where `keyState.state > 1` for
all KSKs of the subsequent zones
This is based on the the differences between first and other zones observed in
my request.
Can you confirm this is relevant (at least when no key roll-over is in
progress)?
Note: prior to this, I would copy the full `kasp.db` to test systems, but this
time I only wanted to focus on a specific policy, hence the idea of importing
keys using `ods-enforcer` command.
Thanks in advance for your replies,
--
Guillaume-Jean Herbiet, PhD
DNS-LU Technical Manager/Team Leader
Fondation Restena
2, avenue de l'Université
L-4365 Esch-sur-Alzette
T +352 42 44 09 1
F +352 42 24 73
restena.lu | dns.lu | my.lu
PGP 0x3A4C47C7
This email may contain information for limited distribution only, please treat
accordingly.
*** I am out-of-office on Wednesdays ***
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ Opendnssec-user mailing list Opendnssec-user@lists.opendnssec.org https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
