12 Srp
2021
12 Srp
'21
11:29
Hi Luveh,
some correction.
There is also another command, keymgr import-pkcs11
It might help you.
https://www.knot-dns.cz/docs/3.1/singlehtml/index.html#document-man_keymgr
BR,
Libor
Dne 12. 08. 21 v 10:06 libor.peltan napsal(a):
Hi Luveh,
the documentation is not perfect enough not to be misinterpretable.
The formulation "path to BIND key file (private or public, but both
MUST exist)" means that both the public and private Bind key files
must exist. For example, Kexample.com.+013+65449.key and
Kexample.com.+013+65449.private
There is currently no way of importing keys that had been stored into
a HSM by Bind. Sorry.
If you really need to migrate from Bind to Knot while having all the
private keys in a HSM (or some PKCS#11 device), I guess it might work
the way that you perform manual key roll-over in sync with the
migration, so that you always need to import just public keys, and
Knot generates its new keys in the HSM itself. However, this would
require several non-trivial steps (and decent amount of coffee).
Libor
Dne 11. 08. 21 v 23:17 Luveh Keraph napsal(a):
The documentation for keymgr describes the
import-bind command as
follows:
import-bind BIND_key_file
Imports a BIND-style key into KASP database (converting it to PEM
format). Takes one argument: path to BIND key file (private or
public, but both MUST exist).
What is imported into the KASP exactly? I thought that the KASP
database consisted of public keys alone. This aside, importing a
private key will depend on whether the cryptographic provider
supports such an operation - many HSMs, in particular those with
stringent FIPS 140-compliance requirements, will in general refuse to
do so.
So, what does this command do with the private key? Is it turned over
to the cryptographic provider, returning an error if this provider
refuses to import private keys? If such is the case, is the public
key still imported into the KASP, even though there will be no
matching private key for it anywhere in the system?
One can of course use a public key without a matching private key,
but in a DNSSEC software framework like Knot, where the bulk of the
activity consists of carrying out signing operations, the presence of
a complete key pair would seem to be essential.