Robert, I don't want to offend anyone, but I think that now pam_pkcs11 is a big mess. Some of the features are available when nss is used and some are not. Some parameters are taken from extenal nss configuration some from pam_pkcs11 configuration. You need to manage the module in two different ways in term of trust etc.
It would have been better to just fork the project or make it properly. I think the best solution is to remove all the PKCS#11 code from pam_pkcs11 and use pkcs11-helper (NOT NSS), and use OpenSSL or NSS as crypto engines. In order to complete OCSP support, some work should be done in OpenSSL. In order to allow common configuration and behavior the NSS part should not use its internal keystore. But this kind of investment is out of my scope... Please remember I am not getting paid for this. Alon. On 6/16/07, Robert Relyea <[EMAIL PROTECTED]> wrote: > Alon Bar-Lev wrote: > >> > 2. I've look at the code. It seems like you added the whole nss into > >> > the source... I don't understand why... You can use the external > >> > library files. > >> > > >> No, I definately did not add all of NSS, it used NSS from a shared > >> library. I'm not sure what code you think is NSS. What is there is the > >> previous pam_pkcs11 api to the common directory, abstracted out to allow > >> it to be bilingual. > > > > So what are these files? > > src/common/SECerrs.h > > src/common/SSLerrs.h > > src/common/NSPRerrs.h > These are NSS error files (hardly all of NSS). > > src/common/rsaref/PKCS11_README > > src/common/rsaref/pkcs11.h > > src/common/rsaref/Makefile.am > > src/common/rsaref/pkcs11t.h > > src/common/rsaref/pkcs11f.h > These were imported from somewhere else. The NSS version does not use > them (they are from the openSSL version). > > > > > >> > 3. Regarding the pkcs11-helper... > >> > > >> > The problem is that NSS addition is somewhat strange... I expected > >> > that it will replace OpenSSL entirely... So that you can run current > >> > PKCS#11 implementation with NSS... This requires the abstraction > >> > library for certificate and digest will be implemented as standalone, > >> > and use this throughout the whole package. > >> > > >> I'm not sure if you are looking at the same code. Can you give examples > >> of where there isn't an abstraction? OpenSSL is replaces entirely. All > >> the crypto library specific calls live in src/common. I did not change > >> the openSSL names for things like certs, but provided typedef > >> definitions to NSS CERTCertificates. > > > > 1. You did not fix the pkcs11_lib in the part NSS is not used. It > > still uses OpenSSL. > Right you use NSS or openSSL/pkcs11. My patch adds NSS as an option, and > preserves the old code (pre- my patch) as is. > > 2. The fact that you did not change the OpenSSL names is also > > *_CONFUSING_*, the result is dirty unreadable code. > I'm sure a patch that changes those names would be acceptable. Doing so > seemed overly excessive to me. What is more important was to make sure > all the usage of the objects (like X509) was truly abstract outside of the > > > > True. > > But as I said, just introducing a new crypto implementation and keep > > the legacy complex just make things worse. > > If you add multi provider you need to get rid of slots... And this was > > one of the reason you said you added NSS. > The openSSL side still needed slots. You only get the abstraction if you > enable NSS. > > > >> The context handle is now completely opaque, so you are free to store > >> anything you need for pkcs11_helper there. > > > > Yes. This was done correctly, but the pkcs11_lib is not used by the > > whole package... The standalone utilities implement stuff of their > > own. > No, they use pkcs11_lib (with the exception of one tool). That was one > of my changes. I actually have a long write up on all the changes, and > include some of the issues (a few that you brought up here). I think it > was too long to make it to the mailing list, but I would be happy to > forward it to you. > > bob > > > > > > Best Regards, > > Alon Bar-Lev. > > > _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
