On Thu, Apr 14, 2016 at 05:34:45PM -0400, Ade Lee wrote:
Couple of points on 96/97.
1. First off, I'm not sure you followed my concern about being able to
distinguish between CA instances.
On an IPA system, this is not an issue because there is only one CA on
the server. In this case, I imagine there will be a well known
directory which custodia would work with.
In general though, we have to imagine that someone could end up
installing two different dogtag ca instances on the same server.
CMS.getEEHost() would result in the same value (the hostname) for both
CAs. How does your helper program (or custodia) know which key to
retrieve?
Because it is running in IPA deployment, it contacts the Custodia
instance at https://<hostname>/ipa/keys/... . Note that this is
IPACustodiaKeyRetriever which is design for this purpose (and no
other). Different setups will use a different KeyRetriever
implementation. It is conceivable that IPACustodiaKeyRetriever
could be generalised in future.
The way to distinguish Dogtag instances is host AND port.
Re multiple Dogtag instances, uh yes I overlooked this. For the IPA
use case it doesn't matter but I will update the code to write
`CMS.getEEHost() + ":" CMS.getEEPort()` into the authority entry.
Alternative KeyRetriever implementations can use this to
distinguish between instances.
(Or do you think separate attributes for host and port would be
better? Not much work either way.)
2. So, we're very careful that the signing keys are never in
memory in
the server. All accesses to the system certs are through JSS/NSS which
essentially provides us handles to the keys.
Now, I see a case where we import PKCS12 data AND the password into
memory, so that we can import it into NSS? Say it ain't so ..
With custodia, we have a secure mechanism of transferring the keys from
one server to another. It makes more sense to me to have the server
kick off the custodia transfer and then have that process also import
into the NSS db. The server would then need to await status from the
custodia/retriever process - and then initialize the signing unit from
the NSS DB. Or am I completely confused?
In the original implementation, Custodia put the key directly into
the NSSDB. Unfortunately, Dogtag could not observe the key unless
restarted (highly undesirable). I did not deeply investigate why (I
guess some sort of caching or locking) - but I did not find a
workaround. Even logging out and back into the Token did not help
(and caused other issues, like dropped or failed TLS connections in
other threads).
So I reluctantly redesigned it to what you see now, which works
- but I did not see the (obvious, in hindsight) problem.
Let's chat on IRC about it. I will probably need the help of
NSS/JSS gurus to make the former approach work.
Cheers,
Fraser