On Wed, 2010-09-29 at 16:25 -0500, Douglas E. Engert wrote:
>
> 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
Can you point out the place where OpenSSL is called for GOST
computation. This is of interest, because host-side decryption/signing
is definitely subject for removal.
_______________________________________________
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
