Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Move _ec_curve_info from pkcs11-tool.c to pkcs11.h #3079

Closed
msetina opened this issue Mar 20, 2024 · 3 comments
Closed

Move _ec_curve_info from pkcs11-tool.c to pkcs11.h #3079

msetina opened this issue Mar 20, 2024 · 3 comments

Comments

@msetina
Copy link
Contributor

msetina commented Mar 20, 2024

It is notoriously hard to get key info for EC key on the card. I found that pkcs11-tool can present those numbers. If we use CKA_EC_PARAMS, we get OID encoded, but then it is still another step to get key_length and curve name (if someone need it)
The mentioned variable is perfect for translating the bytes gotten from CKA_EC_PARAMS and then enrich the data with more info about the key.
Moving it would help other languages to make the translation and put single point of knowledge to update information.

@frankmorgner
Copy link
Member

pkcs11.h was meant to be compatible with the original file without the copyright limitations. I don't see a reason to include conveniance functionality into this.

For example, openssl/obj_mac.h has a more complete description of names and OIDs and OpenSSL also comes with functions to get the public and private key size.

@Jakuje
Copy link
Member

Jakuje commented Mar 21, 2024

I think this is certainly out of the scope of the opensc pkcs11 module. This might be provided as part of the opensc.h, but that won't guarantee any API/ABI stability.

As mentioned in #3078, I think if you need a universal solution, using some higher-level wrappers around the pkcs11 modules, such as pkcs11 provider for openssl. With OpenSSL in place, you will get a lot of functions around the "provided" keys to get all the information you need.

@msetina
Copy link
Contributor Author

msetina commented Mar 21, 2024

Thank you. I still think it would help to have utility data on the crossroads of all these, but I understand your position. I realised that pkcs11.h is not the optimal place as opensc is not the only one tat implements it. That was wrong in my proposition.

@msetina msetina closed this as completed Mar 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants