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 sc_pkcs15_pubkey_from_cert 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
