On 24 sep, 20:08, Nelson B Bolyard <[EMAIL PROTECTED]> wrote: > Paco wrote, On 2008-09-24 04:17: > > > On 22 sep, 21:19, Nelson B Bolyard wrote: > > you can't also export a pkcs12 containing just CA certifcates, which I > > belive is something accepted in the pkcs12 standard, > > Mere certificates which need no encryption. There is no need to use > PKCS#12 to transfer them. Mere certs can simply be exported and imported > without any need for encryption. PKCS#12 is only needed when there is a > private key to be transferred (or backed up). >
Yeah, I know, but as a lazy programmer I wanted to use the same import method in my component to get everything :D (I'm developing a component to manage certificate exchange between Firefox and a USB cryptographic device developed at my university). Never mind it's all right now. > > or you can't guess the certificate thumbprint if you need it. > > Guessing seldom works. :) > FF's certificate manager displays cert fingerprints. > Maybe I got confused during debugging, sorry. > > I don't see the point in distributing a library which exports just the > > symbols used by firefox (except, of course, load time efficiency), > > dramatically reducing its usability by third-part developers, who would > > want to add new functionality to such an extensible architecture. > > The library does not "export just the symbols used by Firefox". > It does, however, have a tightly controlled public API. > > The reason for that is as follows. Before NSS had a tightly controlled > public API, application developers used any functions in NSS that they > wanted to use, and if the NSS developers found it necessary to change > some internal NSS function, they would hear loud complaints from application > developers about having changed some function that they used. > This effectively created a situation in which the NSS developers could not > change any internal functions at all. We solved that problem by creating > a tightly defined public API, and not exposing the internal functions to > application developers. That required putting NSS into shared libraries. > > For years, shipping a separate shared library to do encryption could get > a US application developer a long prison sentence. (The use of separate > shared libraries for encryption was OK when those libraries were part of > an OS, like Windows, which detected or prevented alteration of its > libraries, but applications could not ship their own crypto libraries.) You live in such an odd country... > During those years, NSS was made available to US application developers > as an archive (a .a or .lib file) that was linked directly into the > application program's executable file. All the internal functions were > linkable from those archives. Thus it was not possible for the NSS > developers to control the public interface, and application developers > used whatever functions they wanted. > > In the year 2000, when it became OK for applications to ship with crypto > shared libraries, NSS became shared libraries with a well defined public > API. Only the explicitly designated public functions were accessible > from outside of those shared libraries. We also became very committed to > not changing any function signatures in the public API. We can always add > new functions to the public API, but we do not change the signatures of > existing functions. > > That change happened in NSS 3.2. All NSS 3.x versions since then have > been backwards compatible in their APIs, preserving the old APIs. > > Some application developers did not like the new public APIs, and > continued to use older releases of NSS for years after NSS 3.2 was released. > But all the complaints about API stability ceased completely > when NSS 3.2 was released. > > Having explained why NSS's API is tightly controlled, I will add that > the NSS team does receive requests from time to time to export more > NSS functions through the public API, and the team has done so in > numerous releases. But the NSS team reserves the right to decide which > functions are suitable for export from the shared libs and which are not. > > Sometimes the NSS team responds to a request by creating a new function > that provides the desired functionality and exports that new function > instead of the requested one. Bug 311483 is an example of such a > decision. Nice and long story, I get your point now. Thanks for your help. _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
