12 Srp
2021
12 Srp
'21
10:06
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.