On 9/29/2010 3:05 PM, Andre Zepezauer wrote:
> On Wed, 2010-09-29 at 13:35 -0500, Douglas E. Engert wrote:
>>
>> On 9/29/2010 9:51 AM, Andre Zepezauer wrote:
>>> Hello Douglas,
>>>
>>> in my opinion the usage of OpenSSL in libopensc.so should be removed
>>> altogether. If cryptography is needed by some cards (i.e. for
>>> ), then this should be done by dedicated
>>> tools. CardOS is a good example. It requires encrypted APDU:s for the
>>> delete_MF and create_MF commands. This is done by cardos-tool, which has
>>> to be executed only before personalisation. Looking at the code of
>>> entersafe, gpk and oberthur I came to the conclusion, that a similar
>>> approach could work for these drivers too.
>>
>> I agree. The PIV card only needs 3DES for initialization/personalization
>> today. The piv-tool was designed to allow for initializing test cards, with
>> the intent that production cards would be issued by card management stations
>> run by others as the NIST standards only cover a few of the commands needed
>> for initialization, leaving the rest up to the card vendors. (i.e. one can
>> generate a key ipair on the card, but you can not load a private key on the
>> card.) Thus the ordinary user would not require OpenSSL.
>>
>>>
>>> If parsing of certificates is the reason for using OpenSSL, then the
>>> missing functionality of pkcs15-cert.c should be determined and
>>> corresponding tickets should be created.
>>
>> What has happened as some card driver authors have found it easier to
>> just use OpenSSL, and have added routines like: sc_pkcs15_pubkey_from_cert
>> into pkcs11-pubkey.c Because the parse_x509_cert only works with RSA.
>>
>> But to get this code replaced, will take the will of the community
>> to get this done.
>
> I don't think so, because the function sc_pkcs15_pubkey_from_cert is
> called only at pkcs15init/pkcs15-lib.c#L2030
>
> The same holds for sc_pkcs15_pubkey_from_prvkey, which is called at
> pkcs15init/pkcs15-lib.c#L2036 and nowhere else.
>
> That shows (at least to me), that these two functions belonging to the
> tools section of OpenSC and should be placed there.
But parse_x509_cert also get the pubkey from a cert. So why are there two
routines? Because parse_x509_cert only works with RSA? Where as
sc_pkcs15_pubkey_from_cert could easily work with more the RSA.
So we have duplicate code, using different methods. We could do a better
and implement sc_pkcs15_pubkey_from_cert without OpenSSL, and use it from
parse_x509_cert.
I am interested in expanding OpenSC to work with EC keys, with at least
named-curves. (The OID of the curve is the parameter.) parse_x509_cert does
not obtain the algorithm parameters, which for RSA are null, and the
pkcs15-piv.c needs to get the public key from the cert in normal use. This
will require a modified parse_x509_cert or sc_pkcs15_pubkey_from_cert.
(Since the PIV specs for EC only require the use of prime256v1 or secp384r1
so I could take a shortcut, and use the size of the point to get the curve,
but in the future, other cards may support EC for other curves or even explicit
parameters.) All the code for EC is in OpenSSL, making it very tempting
to just use OpenSSL.
The gostr3410 [1][2] algorithm is also based on EC, but has its own OID
{iso(1) member-body(2) ru(643) rans(2) cryptopro(2)} and requires parameters,
and it looks like the way it is used does not require parsing the cert to get
a public key so has not been added to parse_x509_cert.
Much of gost is in OpenSSL too, as a separate engine, and the pkcs11/openssl.c
introduces the use of many of the hash and verify functions from OpenSSL.
So getting OpenSSL out of OpenSC is looking like a big project.
[1] http://tools.ietf.org/html/draft-dolmatov-cryptocom-gost34102001-00
[2] http://www.faqs.org/rfcs/rfc4357.html
--
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
