On 9/30/2010 3:56 AM, Martin Paljak wrote: > Hello, > On Sep 27, 2010, at 11:58 PM, Douglas E. Engert wrote: > >> There has been a effort to be able to build OpenSC without the use >> of OpenSSL. Yet there is newer code that keeps creeping in to the >> trunk that requires OpenSSL. > This has been discussed several times during past few years. There was the > idea of keeping the core libopensc OpenSSL free, for various reasons. >
I believe one was size, i.e. someone wanted to use OpenSC on some phone or PDA? > As the main function of OpenSC has turned out to be PKCS#11/crypto cards and > libopensc is AFAIK not used for anything else, > I'm not sure it is any longer relevant. Yes, OpenSSL support is not required > by configure and probably OpenSC can be built without OpenSSL, but there > is no nice list about what will break if you do it. Yes it does build and the PIC card works. Having spent the last few weeks looking at OpenSSL and EC it looks like all the software crypto code is only used for initialization and thus not needed for end users. But SM could change that. The closest thing to a list is the pkcs11-tool -M, with the card of your choice. So it might be a good idea for developers to test their cards without OpenSSL, just to see if it is required or not. It may depend on the calling application, more then OpenSC, if the application depends on OpenSC supporting some hash or verify function. But any good application should implement hash and verify on its own. > > > >> The OpenSSL dependent code can be divided into 3 areas: >> >> (1) Code that tries to get some information from a certificate, such >> as the public key, or the basic constraints. For example >> sc_pkcs15_pubkey_from_cert in pkcs15-pubkey.c >> >> Much of this code appears to have been added because parse_x509_cert >> in pkcs15-cert.c does not do a good enough job in supporting more >> then RSA, and does not parse options like basic constraint that one >> card driver needs. > Except for GOST, AFAIK OpenSC really only support algorithms other than RSA. > I don't have cards with DSA but the code for DSA seems to not be complete. > Yes, that is what I am seeing. To add EC or a minimal EC with only named curves, the GOST code is a good example of what is needed. The main thing I need is to get the pub key from the cert and I think I can do that, and maybe add DSA support at the same time without using OpenSSL. (I dont have any DSA cards) > > >> (2) Code that deals with symmetric keys for example in, pkcs15-wrap.c >> It is not clear if the project wants to add native crypto to OpenSC >> code or continue to use OpenSSL, or some other package. (The gost >> code appears to introduce a dependency on the gost external engine, >> to do its crypto.) Any Secure Messaging or some card initialization >> that needs to authenticate to the card, needs this. > GOST is implemented as an engine inside OpenSSL. > > I've not used the password-protected key import feature, but I think this is > conflicting with "only hardware crypto" princile as well. Either the key has > native support from the card or it should be stored as a data object and > handled by the application as a generic "PEM file". pkcs15-wrap should be > removed in the spirit of not automagically generating private/secret keys in > software. > > Looking at the code, only pkcs15-crypt tool seems to use the pkcs15-wrap > functions to decrypt the password protected keyblob. > > >> (3) Old code that is not being used. p15card-helper.c for example >> in not used at all. It was introduced by a third party for use >> with the PIV card, but is no longer used, and in my option could >> be removed. > Unused code should be removed. I agree, as it might lead some new developer to try and use it. Should there be a separate thread to ask if there are any objections? > >> I bring this up as I am interested in adding ECC support (with named >> curves only) to OpenSC for the PIV card. No ECC crypto needs to be >> done, but support for getting the EC pubkey from a cert and saving >> a pubkey generated by the card is needed. >> >> (As an attempt to not require OpenSSL, last week I committed changes >> that allowed the PIV driver to be built without OpenSSL. OpenSSL >> is still needed for card administration, as a 3DES Decrypt is still >> needed. But the administration code and piv-tool are not >> used by the ordinary users. This type of code falls into (2)) >> >> So what is the direction? >> >> (A) Continue to use OpenSSL but only in the most limited cases? > It would be nice to be able to switch implementations but until there is no > real requirement for this, OpenSSL can be used. > It is, after all, an "industry standard" in some sense. I have noticed that Debian (any maybe others) have started to convert to using GnuTLS in some packages like OpenLDAP, for licening reasons. (I spent two much time tracking down bugs and differences in nss and ldap because of this change.) So I would not suggest it at this time, but it is an option. > > >> (B) Try and stamp it out, but this would then require adding some >> crypto for symmetric keys and maybe other hash functions? > Re-implementing is not an option, IMO. > >> (C) Embrace it, and use its crypto, key and cert structures >> and simplify OpenSC code? > You mean use OpenSC structures inside current sc_* structures? Yes, that was what I was asking, like the pubkey. But I think I could come up with a EC and DSA pubkey without using OpenSSL. > >> (D) Use some other crypto package? > > If there's anyone interested in reaping the code and hiding the common cases > behind an adapter API (sc_crypto_something) and THEN implement > the necessary hash and public key operations for a library other than > OpenSSL, it could be done. > > But changing OpenSSL to something else without a good justification is not > reasonable at the moment. Just a more careful selection of what and how is > included from OpenSSL could be done. > -- Douglas E. Engert <deeng...@anl.gov> 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
