I note that the key label is not set when Knot generates new keys via PKCS#11.
Invoking `p11tool --list-all' shows a key as
Object 449:
URL: pkcs11:model=;manufacturer=nCipher%20Corp.%20Ltd;serial=xxx;\
token=YYY;\
id=%04%66%D0%9C%0D%9E%24%D9%79%0A%17%D3%5D%A0%CC%5A%3F%E2%A3%26;\
type=public
Type: Public key (RSA-2048)
Label:
ID: 04:66:d0:9c:0d:9e:24:d9:79:0a:17:d3:5d:a0:cc:5a:3f:e2:a3:26
The ID is that which `keymgr list' displays (with colons in it), but the label
is empty.
Is this by design? Would it be possible for Knot to actually set the label
(e.g. zone name - key type: example.com-ksk)?
Best regards,
-JP
Good morning,
In Knot 3.2.0 the rrsig-refresh default changed, excerpt changlog:
knotd: default value for 'policy.rrsig-refresh' is propagation delay +
zone maximum TTL
I'd like to understand the rationale behind this change and whether or
not we should tune this parameter in our deployment.
We currently have monitoring in place to ensure that we always serve
valid signatures. In my understanding with the old defaults < 3.2.0 of
rrsig-refresh of 7d and rrsig-lifetime of 14d, we always ended up with
signatures that were at least valid for 7 days. As I understand, with
the new defaults, signatures might be refreshed way closer to their
expiry date. This makes me a bit uneasy, as if there are issues with
signing this gives us hardly any time to react and fix potential issues
before the current signatures expire.
I assume setting rrsig-refresh explicitly to 7d would restore the old
behavior, but I'm wondering if this is somehow bad practice and if we
are overly paranoid with our monitoring.
How do other people handle this? Are there any downsides of setting a
higher value of rrsig-refresh that we are not aware of?
Regards
André
