5 Čec
2018
5 Čec
'18
20:21
Hello,
We're building a replicated Signer machine, based on Knot DNS. We have
a PKCS #11 backend for keys, and replication working for it.
On one machine we run
one# keymgr orvelte.nep generate ...
and then use the key hash on the other machine in
two# keymgr orvelte.nep share ...
This, however, leads to a report that the identified key could not be
found. Clearly, there is more to the backing store than just the key
material in PKCS #11.
What is the thing I need to share across the two machines, and how can I
do this?
Thanks,
-Rick
6 Čec
6 Čec
16:25
Hello,
i think you misunderstood the "keymgr share" command completely :)
I will attempt some basic explanation first.
Knot stores all the key information, metadata and public keys in KASP
database. The private keys are saved either to pem files (PKCS #8 like
storage) or a PKCS #11 (like in your case). For the signing (and mostly
also for manipulation with keys), both KASP DB and private key storage
must contain the relevant key. Copying just the private key (or having
it accessible on more machines at a time) is not good for anything.
The "keymgr share" command is here for sharing keys between different
zones, but clearly on one computer.
If you want to migrate signing Knot from one machine to another, you
shall transfer the configuration file, KASP DB and the private key
storage. It's not needed to call any "share" command afterwards.
Hope this explanation helps :)
Libor
Dne 5.7.2018 v 20:21 Rick van Rein napsal(a):
Hello,
We're building a replicated Signer machine, based on Knot DNS. We have
a PKCS #11 backend for keys, and replication working for it.
On one machine we run
one# keymgr orvelte.nep generate ...
and then use the key hash on the other machine in
two# keymgr orvelte.nep share ...
This, however, leads to a report that the identified key could not be
found. Clearly, there is more to the backing store than just the key
material in PKCS #11.
What is the thing I need to share across the two machines, and how can I
do this?
Thanks,
-Rick
17:27
Hey Libor,
Thanks for explaining and confirming that the KASP needs local storage!
But our use case is a bit more innovative:
If you want to migrate signing Knot from one machine
to another, you
shall transfer the configuration file, KASP DB and the private key
storage. It's not needed to call any "share" command afterwards.
We are not transferring the responsibility for signing. Instead, we
have two live signers running in parallel. I'll attach the
clarification why this should work, because I am aware that it is not
what people usually do. The reason is that the signers operate
completely independently, and therefore more stably.
For this scheme, we need to copy the KASP state for each zone to which
we generate a key. That's why I was trying to (ab)use "share" on
another machine, hoping it would dig up all the data in PKCS #11.
Hope this explanation helps :)
Yes, it confirms that the KASP is not completely stored in PKCS #11.
But I am left with the question how I can transfer KASP state for
individual zones between our signer machines. Can you help with that?
Thanks,
-Rick
7 Čec
7 Čec
20:20
Hello Rick,
On 2018-07-06 17:27, Rick van Rein wrote:
Hey Libor,
Thanks for explaining and confirming that the KASP needs local storage!
But our use case is a bit more innovative:
We will probably implement something like import-pkcs11 command to
keymgr.
But I cannot say when, because we have other feature requests on the
list.
Best,
Daniel
If you want to migrate signing Knot from one
machine to another, you
shall transfer the configuration file, KASP DB and the private key
storage. It's not needed to call any "share" command afterwards.
We are not transferring the responsibility for signing. Instead, we
have two live signers running in parallel. I'll attach the
clarification why this should work, because I am aware that it is not
what people usually do. The reason is that the signers operate
completely independently, and therefore more stably.
For this scheme, we need to copy the KASP state for each zone to which
we generate a key. That's why I was trying to (ab)use "share" on
another machine, hoping it would dig up all the data in PKCS #11.
Hope this explanation helps :)
Yes, it confirms that the KASP is not completely stored in PKCS #11.
But I am left with the question how I can transfer KASP state for
individual zones between our signer machines. Can you help with that?
Thanks,
-Rick
9 Čec
9 Čec
12:20
Hi Daniel and Libor,
We will probably implement something like
import-pkcs11 command to keymgr.
But I cannot say when, because we have other feature requests on the list.
I understand. But we need it now :)
So I've checked out the source of pykeymgr at
https://gitlab.labs.nic.cz/knot/knot-dns/blob/2.6/src/utils/pykeymgr/pykeym…
It looks like all I'd need to do is look for database keys
<1,zone_name,*> to export in JSON, send that to other cluster nodes and
import it with pykeymgr's import facility.
The value stored would encompass public_key, keytag, algorithm, ksk,
created, publish, active, retire, remove. That looks pretty complete to me.
Am I oversimplifying anything?
I can fork the repo of your choice and offer a pull request, if you like.
Cheers,
-Rick
2329
days inactive
2333
days old
4 comments
3 participants
participants (3)
-
daniel.salzman＠nic.cz -
libor.peltan＠nic.cz -
Rick van Rein