As outlined below, in a note from 10/6, changes were committed (r4805)
today, with slight modifications.
o sc_pkcs15_pubkey_from_cert was moved from pkcs15-pubkey.c to pkcs15-cert.c,
and now calls parse_x509_cert. It no longer depends on OpenSSL, I can
now easily work with more then RSA keys. The OpenSSL version was only
written to work with RSA.
o sc_pkcs15_cert now has a pointer to a sc_pkcs15_pubkey, rather then
having the structure contained with in it. This allows the sc_pkcs15_pubkey
to be easily extracted from the sc_pkcs15_cert and used on its own.
o sc_pkcs15_pubkey now has a pointer to an sc_algorthim_id. This then allows
for any algorithm parameters to bew passed along.
o parse_x509_cert will now save the algorithm and any parameters in the
sc_algorithm_id, and save this in the sc_pkcs15_pubkey.
o sc_pkcs15_pubkey_from_cert and one location in pkcs15-framework.c can
now extract the sc_pkcs15_pubkey from a certificate by coping the pointer
and setting the pointer in the sc_pkcs15_cert to NULL.
o Various free routines for the sc_algorithm_id, sc_pkcs15_pubkey and
sc_pkcs15_cert now take care of the cleanup of these structures.
On 10/6/2010 11:10 AM, Douglas E. Engert wrote:
> One of the operations I need for the PIV card is to get the public
> key from the certificate, as pubkey needs to be emulated for thes cards.
> OpenSC has more then one way to do this, but only RSA keys are currently
> supported.
>
> ./pkcs15-pubkey.c has sc_pkcs15_pubkey_from_cert, but this relies on
> OpenSSL, and even then only supports RSA.
>
> pkcs15-cert.c has the parse_x509_cert which does not need OpenSSL,
> but only works with RSA, and embeds the pubkey in the cert structure.
>
> (There is also the sc_pkcs15_pubkey_from_prvkey that supports RSA
> and DSA and looks incomplete for GOSTR3410.)
>
> I need RSA, ECDSA and ECDH for PIV.
>
> The main problem with the pubkey from cert routines is that
> they skip any algorithm parameters. RFC 3279 and RFC 5787 define
> what these should look like for RSA, DSA, DH, KEA, ECDSA and ECDH.
>
> RSA has no parameters and is an ASN.1 NULL
>
> ECDSA and ECDH have a choice of ecParameters (a sequence of
> a lot of stuff) or namedCurve object identifier or an ANS.1 NULL.
>
> DSA has either no parameter or a sequence of three integers p, q, and g.
>
> You can read about the others in the RFCs. (I am not sure what gostr3410
> is doing, but it looks like it is a sequence of stuff.)
>
> The sc_asn1_decode_algorithm_id does know how to get the algorithm ID,
> and to call selected routines to decode any aditional parameters, and
> to save the information in the sc_algorithm_id params pointer and to free
> the params.
>
> PKCS#11 has for public keys:
>
> RSA: CKA_MODULUS, CKA_MODULUS_BITS, CKA_PUBLIC_EXPONENT.
> DSA: CKA_PRIME, CKA_SUBPRIME, CKA_VASE AND CKA_VALUE.
> ECDSA: CKA_ECDSA_PARAMS (DER encoded), CKA_EC_POINT(DER encoded).
>
> (PKCS#11 2.30 has definitions for GOSTR)
>
> PROPOSAL:
>
> I would like to do the following to cleanup some of the duplication:
>
> Replace with non OpenSSL code, that would
> use the sc_asn1_decode_algorithm_id, and other code from parse_x509_cert
> to get the algorithm, its parameter, and the pubkey.
>
> parse_x509_cert would call sc_pkcs15_pubkey_from_cert.
>
> The sc_pubkey would contain an sc_algorithm_id (or a pointer to one.)
>
> The sc_pkcs15_pubkey_rsa would not change, but the
> sc_pkcs15_pubkey_dsa would change, as the DSA parameters are now
> in the sc_algorithm_id parameters.
>
> The processing of the goostr3410 looks like it not completed,
> as the algorithm parameters where never copied to the
> sc_pkcs15_pubkey_gostr3410. So very little would need to change.
> as the parameters would be in the sc_algrithm_id that is part
> of the sc_pubkey.
>
> The sc_pkcs15_cert rather then having a sc_pkcs15_pubkey, would
> have a pointer to one.
>
>
> Using pointers rather then embedding the algorithm and pubkey in
> other structure would allow one to parts a certificate, and copy
> the pubkey pointer then free the certificate.
>
> IMPLEMENTATION:
>
> These changes could be made in stages, with the structure/pointer
> changes made first and continue to work with RSA. Then the EC, DSA,
> and additional GOSTR changes could be made later.
>
> SIDE NOTES:
> The NIST 800-78 specs say the PIV only has to support two named curves,
> one at 256, and one at 384, so I could just look at the size of the key,
> and skip much of this stuff, but in the long run other cards might start
> to support EC using other curves, so eventually this will be needed.
>
> Thoughts?
>
--
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
