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

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.