Bug 470751

Summary:	Process of adding digital certificates could be improved
Product:	[Applications] okular	Reporter:	Nate Graham <nate>
Component:	PDF backend	Assignee:	Okular developers <okular-devel>
Status:	REPORTED ---
Severity:	wishlist	CC:	kde, tuju
Priority:	NOR	Keywords:	usability
Version First Reported In:	unspecified
Target Milestone:	---
Platform:	Other
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:

Description Nate Graham 2023-06-07 15:39:09 UTC

Right now to be able to digitally sign a document, you need to add one or more digital certificates. If your digital certificates are not found in the default location (your Firefox profile), the process of adding them is as follows:

1. Go to Settings menu > Configure backends > PDF
2. Change the value of "Certificate database" from "Default" (which shows the Firefox profile) to "Custom"
3. Click the "choose" button to select the location where your digital certificates live. If you have any certs that don't live there, move them there manually in another app
4. Notice that the "Available certificates" table hasn't gotten updated to show the certificates in that folder and become confused
5. Figure out that you need to click the Apply or Ok button to refresh it
6. After being notified that this change requires Okular to be restarted, restart Okular
7. Go to Settings menu > Configure backends > PDF again and verify that the certificate(s) you expect to be there is/are there

Needless to say, this process is quite taxing on the user and they are probably not likely to figure it out on their own without assistance or being explicitly pointed to excellent documentation.

There are various ways this could be improved, but I think a good one would be to ask the user to choose a certificate at the moment they ask Okular to digitally sign the document. Once they choose it, it would be automatically copied to a new custom certificate folder (which would be created somewhere if needed), nd then Okular would not need to be restarted, and then they would immediately be able to sign with it. In the digital signing dialog, they would be able to add a new certificate from there, to avoid having to go into the Configure Backends window at all, ideally.

Comment 1 Sune Vuorela 2023-06-08 06:21:44 UTC

Some things to also be aware of:

 - The certificate will often be hardware backed (smartcard or usb dongle), so can't really be copied around
 - If it is not hardware based, do *not* copy it around. People using it for real purposes wants to know where their keys are.

The need to restart okular when changing the nss location could probably be fixed inside poppler, and a side effect of fixing that  will probably fix all the crash-on-shutdown bugs related to nss.

I'm working on adding an alternative to using nss for digital signatures (using gpg), and most of the setup bits will kind of be delegated to kleopatra, an app kind of designed for this. 

Also when using gpg, my patches for okular will hide the path selection for nss databases.

Comment 2 Nate Graham 2023-06-08 15:07:52 UTC

Thanks for the clarification. I think it's important to distinguish between:

"technical expert who has Opinions™ on cryptography"
and
"Normal person who just wants to sign a document and isn't interested in any of the technical details required to make it happen"

Okular's signing seems like it's adequate for group 1 right now, but isn't optimal for group 2, and that's what I'm bringing up here. Obviously we don't want to make life harder for group 1, bur I'm a firm believer that good UI design can let these users co-exist using the same app. :)

Comment 3 Juha Tuomala 2025-01-09 13:15:12 UTC

(In reply to Sune Vuorela from comment #1)
> Some things to also be aware of:
> 
>  - The certificate will often be hardware backed (smartcard or usb dongle),
> so can't really be copied around
>  - If it is not hardware based, do *not* copy it around. People using it for
> real purposes wants to know where their keys are.

A certificate consists 
- a public key 
- result of CSR (certificate signing request) 

which together guarantee that given public key is part of CA's system. That can be copied from smartcard and actually Windows certificate store does that. Can be done manually with pkcs15-tool as well. When using that certificate to something else than encryption, a secret key or its compatible storage is needed - like a supported HSM smartcard. HSM provides access to that secret key but not the key itself. This is enough to use that asymmetric other half, secret key.0

Certificates can and should be copied around and it's common to store them into public ldap as part of PKI - public key infrastructure for easier distribution.

Unfortunately Kleopatra and KDE as whole implements more developer's twisted ideology than anything the users, normal people need.