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.
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. > 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. > (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 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. > (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? > (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. -- @MartinPaljak.net +3725156495 _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
