Scute until version 1.7.0 only supports a single device, and the code assumes it's only one.
Now, gpg23 offers better handling of multiple devices, we can update the implementation to support multiple devices.
Scute until version 1.7.0 only supports a single device, and the code assumes it's only one.
Now, gpg23 offers better handling of multiple devices, we can update the implementation to support multiple devices.
rG GnuPG | |||
rGdd600bbc84dd scd: Support specifying keygrip for learn command. | |||
rG273b8ec1931d scd,openpgp: Support READCERT by keygrip. |
Status | Assigned | Task | ||
---|---|---|---|---|
Testing | • gniibe | T6002 scute w/ gpg23: Support multiple cards/tokens, major update with KEYGRIP | ||
Resolved | • gniibe | T6003 card: READCERT with KEYGRIP |
For testing, I can use these sites for client certificate authentication:
https://stackoverflow.com/questions/38095559/https-test-server-that-checks-client-certificates
For Chromium, we can use Mozilla's modutil to enable scute:
https://linuxkamarada.com/en/2019/09/26/setting-up-smart-card-authentication-on-google-chrome-chromium/
In my case, I did:
modutil -dbdir sql:.pki/nssdb/ -add "scute" -libfile /usr/local/lib/x86_64-linux-gnu/scute.so
I realized that we need to invent a way to represent KEYGRIP (40-byte string) in the scheme of PKCS#11; PKCS#11 uses fixed-size string (space padded) for it's label (32) and serialno (16). Basically, it identifies the device by slot number.
Newer specification is here: https://docs.oasis-open.org/pkcs11/pkcs11-base/v3.0/cs01/pkcs11-base-v3.0-cs01.html
In the branch https://dev.gnupg.org/source/Scute/history/t6002/ , by the commit rS123d617ebefe: Less administration of devices by scute., things has been changed.
It's experimental, only supports OPENPGP.3 keys.
I think that PKCS#11 specification has some (irrelevant/wrong/unclear or not useful) assumptions for user<->application<->system interactions, how devices are controlled by a system and by a user.
Wise use of the specification would be that we don't try to clarify those interactions (which leads to complicate implementations), but to pick up things what we can do in meaningful and clear semantics for users.
In the branch, now, multiple devices are supported, but Scute does not watch or care about the device insertion/removal at all. This change allows gpg-agent to prompt the insertion of the device when not yet inserted. Devices are under control of scdaemon, but not under Scute. This may greatly simplify things.
This change is not perfect. It cannot support a use case where an application wants to know/detect device removal to close its session.
Other than that, it works pretty well.
I found this page:
https://firefox-source-docs.mozilla.org/security/nss/legacy/nss_tech_notes/nss_tech_note2/index.html
And I do:
NSS_DEBUG_PKCS11_MODULE=scute NSPR_LOG_MODULES=nss_mod_log:4 NSPR_LOG_FILE=/tmp/scute.log chromium
to test.
The change requires "KEYINFO --list" command. This is not available through remote access of gpg-agent (extra socket).
We could change how device keys are listed. Currently, Scute does KEYINFO --list, then asking gpgsm for each certificate.
Currently, there are two ways for Scute to get certificates;
But the latter is also restricted (not available through remote).
Kleopatra uses SCD READCERT for reading certificates from the PIV app. This is used to import the certificates stored by the PIV app. I'm not sure whether this is really needed. Maybe we could/should use "learn card" for this instead.
Firefox nicely shows the 3 NIST certificates from my Telesec card but not the important Brainpool certificate for eIDAS. It turns out that Firefox does not support Brainpool, despite that a patch has been provided 8 years ago. See https://bugzilla.mozilla.org/show_bug.cgi?id=943639 . Thus there is currently no way to use LibreOffice or Okular to signe PDFs because they rely on NSS.
I can successfully sign with LibreOffice Writer (using Brainpool with Yubikey). I need to do:
Did you test with a self-signed cert? I ran into the problem that the selection only showed the root certificate, the signing works using the leaf cert, but the root cert was put into the signature. Changing Scute to only return the leaf certificate made it work but verification failed.
Further the cert chain is not shown by firefox - I need to test with a newer version, I guess.
I tested with a self-signed one.
Firefox doesn't work (it seems that we need another fix in Firefox itself). Chromium and LibreOffice work.
Merged the changes in t6002 branch into master.
I realized that Chromium shows S/N of the certificate (as well as Subject and Issuer) in the dialog (selecting a key).
(Firefox shows label and serialno of the card, in the device manager of its "Settings".)