Thanks! NSS seems to be overkill for most requirements... But I understand the maintenance argument, but I don't think maintaining NSS is simpler thank OpenSSL... :)
BTW: Slotevents and multi provider is offered by pkcs11-helper as well, so solution may be much simpler :) Best Regards, Alon Bar-Lev. On 6/11/07, Robert Relyea <[EMAIL PROTECTED]> wrote: > Alon Bar-Lev wrote: > > On 6/11/07, Ludovic Rousseau <[EMAIL PROTECTED]> wrote: > > > >> This new version contains the patches from RedHat to use NSS instead > >> of OpenSSL and many other improvements they made. See the > >> ChangeLog.svn file for an exhaustive list. > >> > > > > Hi! > > Great! > > > > I am curios, why did you switch to NSS? > > > > BTW: We can shrink up the code if next version will use pkcs11-helper :) > > > The patch doesn't actually switch to NSS, but allows NSS to be used > instead of direct calls and openSSL, so you can continue to build both > ways. The default is to use direct calls and openSSL. > > The reason Red Hat switched to NSS in pam_pkcs11 is several fold: > 1) NSS already has support for multiple concurrent PKCS #11 modules. Now > you can configure more than one module for use as your login token. > 2) NSS has built-in support for things like OCSP we wanted to be able to > leverage. > 3) We are working towards being able to have a single crypto library > from a maintenance point of view. NSS was the closest to meeting all of > our requirements. > > Our plan is to enable NSS as an option in various libraries, so > packagers still have the flexibility to continue to use their existing > crypto libraries in environments that make sense for them. > > bob > > > _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
