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 _______________________________________________ Pki-devel mailing list Pki-devel@redhat.com https://www.redhat.com/mailman/listinfo/pki-devel
