Sounds like you should have two version, an OpenSSL based version, and an NSS based version at least until the issues are addressed.
Not only will the pam_pkcs11 be calling NSS or OpenSSL, other pam modules in the pam stack or even the application may be using OpenSSL. For example, one may want to use GDM or OpenSSH calling PAM. The Pam stack may uses ldap, with SASL and TLS and Kerberos with PKINIT calling OpenSC with OpenSLL. Right now OpenSSL is the defacto shared library. Introducing NSS as well into the pam stack may have unexpected some side effects. So keeping an pam_pkcs11_openssl version might be prudent. And pam_pkcs11 is just one pam module that can use a smart card. Russ Allbery's pam-krb5 can call the Heimdal or MIT Kerberos which can call PKCS#11 for use with smart cards. http://www.eyrie.org/~eagle/software/pam-krb5/ (RedHat has one too.) This pam_krb5 can authenticate to a Kerberos KDC or Windows AD, thus allowing one to use the same smart cards with Windows login on Windows, and on Unix. So even if you do use NSS, to solve some issues, it will only solve them for user of pam_pkcs11, not all the uses of PAM with smart cards. If you want to use NSS to handle the smart card slot issues, then you need to address the other pam modules so PAM can have a consistent user interface. Alon Bar-Lev wrote: > 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 > > -- Douglas E. Engert <[EMAIL PROTECTED]> Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
