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). > or you can't guess the certificate thumbprint if you need it. Guessing seldom works. :) FF's certificate manager displays cert fingerprints. > 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.) 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. _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
