How to get EC curve name and key length over PKCS11?

[msetina]

Is there a way to get curve name and key length for EC key from the card?
I can get x,y point, but those two elude me.

[msetina]

I found CKA_EC_PARAMS which is OID. Still looking for key length.

[metsma]

OID should hint of key length. 256/384/521

[msetina]

Thank you. The how still eludes me. I think I found a coprehensive list that connects that, but I think is not accessible from where I need it.

[msetina]

Found the table in pksc11-tool.c. Maybe it would be nice to have it in pkcs11.h, so that PyKCS11 project can incorporate and maybe make a translation function (@LudovicRousseau ? )

[LudovicRousseau]

I can't find the curves names in https://docs.oasis-open.org/pkcs11/pkcs11-base/v3.0/os/include/pkcs11-v3.0/pkcs11t.h

Feel free to send a patch or PR for PyKCS11.

[msetina]

I understand. Will see how to package it for PR.

[dengert]

Cards may not have the OID, but expect calling middleware, written for the card, how to use an EC key on the card.
pkcs11-tool should be able to take an OID and pass to the pkcs11-module that should know what curves are the module can handle.

But pkcs11-tool can load other modules, that may support curves unknow to pkcs11-tool or OpenSC.

pkcs11-tool -O should list public key objects and their OID, if known, list the size and a common name for the curve.

If the card contains a certificate signed by an EC key from the card, the certificate's SubjectPublicKeyInfo should have the OID.

Last resort is to search internet for OID. For example: OID1.3.36.3.3.2.8.1.1.7
Google finds several OID registry sites and other sites that know this is brainpoolP256r1.

Complicating matters experimental OIDs may not be registered. And some OIDs have multiple curve names.

[msetina]

Thanks, @dengert. As I metioned and made a suggestion in #3079 , I found _ec_curve_info in pkcs11-tool.c which has all the info I needed. If it were in pkcs11.h, it could be used by higher level languages to make translations from value returned by CKA_EC_PARAMS attribute.
I wanted to use it with PyKCS11 and it would be a shame if it would be just copied to that project or even code I am preparing for sigxml.

[dengert]

@frankmorgner @Jakuje
There is some merit in having these defined in a header file. It could then be included in pkcs11-tool.c and pkcs15-pubkey.c or any package that wants the table.

The sc_pkcs15_fix_ec_parameters in pkcs15-pubkey.c is in effect a routing to take a partial struct sc_ec_parameters and fill in any missing info. It is used in 6 other OpenSC source files.

The confusion of PKCS11 3.0 passing Edwards and Montgomery curves by name or OID See: #2952 could also be addressed.

I have be waiting to 0.25.0 to be released to propose a PR for the #2952 which is in https://github.com/dengert/OpenSC/tree/X25519-improvements-2 branch, which also deals with openpgp use of the experimental OIDs and mapping the offical RFC OIDs for these curves.

[Jakuje]

I would reiterate back to what is the problem you are trying to solve to avoid solving X when the problem is Y. Why do you need the curve name and length?

Even though the ECC curves are group of possible infinite number of various curves with different parameters, in reality, only few of them are standardized and used in practice and even fewer of them used in smart cards and in real-world applications and protocols so most applications have some table on their own to hardcode the OID/name/size.

Other option might be going through the pkcs11 provider, if you use OpenSSL already. It will provide you a convenient functions to get the curve name and key length for the given key.

[frankmorgner]

Indeed, see also #3079

[msetina]

Yes, it is something that has to get back to the original problem. On my side, I dug over the API I need to provide this (signxml) and I hope we can come to resolution where those two are not needed or even OID. The API needs it to present EC curve information in EC public key description. At the end of day this is not something xmldsig demands as we provide it X509 certificate.
For the legacy of implementation that is in the code there there is also signature decoding where it needs key_size.
Hope we can find a good solution as it would be nice to have PKCS11 support in signxml lib.
I was considering a good place where we can get from CKA_EC_PARAMS return to information about like pkcs11-tool does, but in code.