feat(pkcs11-tool): set CKA_PRIVATE=CK_TRUE if the --private option is…

[AlexandreGonzalo]

Hi,

I noticed that the "--private" option was not considered for private keys.
Maybe it was due to a confusion between the "CKA_PRIVATE" attribute which means that an object is only accessible when the normal user is logged in and the fact that in a key pair, we have a "private" and a "public" key.
The wording can be confusing.
So I am proposing to take into account if the --private option is set when the CKA_PRIVATE is added to the template, like it is done for secret keys or certificates.
This is changing the default behavior when a private key is created. The CKA_PRIVATE attribute used to be always set to CK_TRUE and now the value depends whether the "--private" option is set or not.
The "--private" option was ignored for private key generation.
IMO, with this PR, the behavior is now similar to other object creation or generation.
I checked the patch with the Trustonic TEE HSM.
Regards,
Alexandre.

[Jakuje]

I am ok with the write_key template change, but I am not sure about the generate key tempalte. The most common (and default) behavior of OpenSC is that upon key generation the private key has the CKA_PRIVATE and the public key does not. This is basically what the "Public Certificates Token" profile matches in the PKCS#11 3.0 [1] and which makes the use of the pkcs11 token easy for client authentication with smart cards -- the public key is visible before login and can be queried to check if it is useful for authentication and if so, the user logs in and provides signature using private key, which is not visible otherwise.

With your change, this wont be possible as the newly generated keys will be both either public or private (not that the private keys would be for much use without login even if visible though).

But I am not sure what would be the best way to solve this issue. Should we create another cli switch --private-pubkey or something to allow controlling of this? Should we make the --private tristate (unset -- previous defaults; set; set --no-private)?

[1] https://docs.oasis-open.org/pkcs11/pkcs11-profiles/v3.0/os/pkcs11-profiles-v3.0-os.html#_Toc10196664

[AlexandreGonzalo]

Thanks for your feedback.
I understand your point.
Let's keep the change for the key creation.
And for the key pair generation, I like the idea to have two options:

• "--private" for the private key
• "--private-pubkey" for the public key
  Or if we want to keep the compatibility, we can have
• "--private" for the public key like before
• "--private-privkey" for the private key

[Jakuje]

Thanks. This is a good point to keep the backward compatibility. Even though --private-privkey sounds somehow confusing, it it will have a good description, I think its the best way.