Bug 1249621 - softhsm doesn't honour the CKA_TOKEN flag on public key
softhsm doesn't honour the CKA_TOKEN flag on public key
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: softhsm (Show other bugs)
24
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Paul Wouters
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-08-03 08:26 EDT by Nikos Mavrogiannopoulos
Modified: 2016-06-22 07:06 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-06-22 07:06:40 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Bugzilla 1339453 None None None 2016-06-22 07:06 EDT

  None (edit)
Description Nikos Mavrogiannopoulos 2015-08-03 08:26:02 EDT
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
Comment 1 Nikos Mavrogiannopoulos 2015-08-03 08:31:44 EDT
Issue posted upstream at: https://issues.opendnssec.org/browse/SUPPORT-170
Comment 2 Jan Kurik 2016-02-24 08:31:18 EST
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
Comment 3 Paul Wouters 2016-06-21 15:48:35 EDT
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?
Comment 4 Nikos Mavrogiannopoulos 2016-06-22 07:06:40 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.