Jamie Nicolson wrote:

> Historically NSS has offered little support for sharing databases
> between applications. The Netscape servers worked around this by giving
> each application its own databases; they were not shared across the
> machine.


I haven't studied the current state of affairs with Netscape's 
(iPlanet's) servers, but I am pretty confident that I used to install 
one certificate and provide it for SSL to any number of servers who 
shared the same admin server.  I believe with the right amount of 
finesse I could get servers from two different server roots to share the 
same certificate db.

I seem to recall that I could have more than one certificate in the 
admin server database and choose which one I wanted to use for each 
server instance.  That part I'm less sure of.  Perhaps all I could do is 
select between different key stores.  This was back in the SuiteSpot era.

BTW, the certificate request feature of the admin console 5.0 and 
earlier seems broken.  For some reason it puts the secmod in the wrong 
place and never returns to tell me it's done generating the certificate.

You seem to think that sharing a certificate between different 
applications is a bad idea.  I can understand that it may be desierable 
if you want each application to have a distinct identity.  OTOH, There 
are situation in which I want a box or a subsystem to have an identity 
and have various 'client' applications sharing encryption services 
provided by a service provider in that subsystem.

I understand that concurrent writes to the key or cert stores would be 
problematic, but reads and/or aquiering (or even sharing) sockets should 
not be a problem.  Is there something I'm not understanding about this?

> If you look at the project plan for the next release of NSS
> (http://www.mozilla.org/projects/security/pki/nss/nss-3.4/nss-3.4-plan.html), 
> 
> you will see "Multiple client applications share the same cert and key
> databases" on the list of OUT features :(


I'm not sure what that means.  I can define and implement the interface 
to share the resources if I have a sufficiently powerful api.  From 
looking over the JSS docs, it seems to have all I need.


> You seem to envision NSS as a shared runtime facility. We've always seen
> it as a set of developer tools. There's nothing to prevent you from
> installing the libraries and JAR file in a central, shared location, but
> each application will have to have its own set of databases.


Actually, I want to build the shared runtime facility.

So far I haven't been able to get the JSS working, so all the other 
stuff is far beyond my immediate problems.  I have found mozilla's build 
system difficult to work with in general, and since I am stuck behind 
two firewalls it's hard for me to use the cvs based system at all.  At 
home I'm able to do a make -f client.mk and build the whole monster, but 
when it comes to getting individual components to build, I am not sure 
what to do.  I used to be able to do this, but either I've forgotten 
how, or I things have changed (I suspect both are ture.)

With all the various moving parts, it begins to take a very long time 
just to get to hello world.  Add to that the fact that I don't have 
Sun's compiler handy so I can't build the 64 bit version in the first 
place, and I find it more attractive to try and use the pre-built 
bundle.  Unfortunately that doesn't seem to work.  I really don't know 
where it's failing other than the fact that I get an error when I try to 
run one of the sample packages.  Perhaps everything is set up correctly, 
and just the hacked sample is bad, or perhaps I need to get the key 
databases set up correctly.  So now we start talking about the certutil 
and wham, I'm dead in the water.  Three days of my life are gone and I 
have accomplished nothing.

Please don't get me wrong.  I know you guys are some of the best in the 
industry, and you are doing the best you can with limited resources. 
That doesn't change the fact that I can't make deadlines because I can't 
  get beyond the starting point.



Thanks,

Steven


Reply via email to