Description of problem: When generating a private and public key pair using C_GenerateKeyPair() one can specify the CKA_TOKEN flag to the public key attributes to make the public key persistent. That mostly allows the public keys to be viewable, even though the private keys are hidden. However, softhsm does not honour that flag and never creates a CKO_PUBLIC_KEY object. How reproducible: 1. PKCS11SPY=/usr/lib64/pkcs11/libsofthsm2.so pkcs11-tool -k --key-type rsa:1024 --module /usr/lib64/pkcs11/pkcs11-spy.so --login 2. pkcs11-tool --module /usr/lib64/pkcs11/libsofthsm2.so -O Actual results: Nothing. Expected results: The generated public key should have been listed. Additional info: The template used in C_GenerateKeyPair is shown below: 2015-08-03 14:20:46.096 [in] hSession = 0x1 pMechanism->type=CKM_RSA_PKCS_KEY_PAIR_GEN [in] pPublicKeyTemplate[7]: CKA_CLASS CKO_PUBLIC_KEY CKA_TOKEN True CKA_MODULUS_BITS 00007ffd28e62570 / 8 00000000 00 04 00 00 00 00 00 00 ........ CKA_PUBLIC_EXPONENT 00007ffd28e62560 / 3 00000000 01 00 01 ... CKA_VERIFY True CKA_ENCRYPT True CKA_WRAP True [...] Returned: 0 CKR_OK
Issue posted upstream at: https://issues.opendnssec.org/browse/SUPPORT-170
This bug appears to have been reported against 'rawhide' during the Fedora 24 development cycle. Changing version to '24'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora24#Rawhide_Rebase
upsteam closed the bug as Won't Fix saying: CKA_PRIVATE defaults to CK_TRUE if it is not set when generating the object. One could argue that it should default to CK_FALSE for CKO_PUBLIC_KEY objects, but we want to be as restrictive as possible. You cannot see the public key because CKA_PRIVATE != CK_FALSE. Please set the attribute to false or use --login. Does that resolve it for you? if not, what would you like upstream to do?
Hi, I have addressed the issue by making gnutls always mark public keys as not private. Thus in a way this bug can be closed.