Re: [opensc-devel] pam_pkcs11 0.6.0 available

[Robert Relyea]

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.

smime.p7s
Description: S/MIME Cryptographic Signature

_______________________________________________
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel