Page MenuHome GnuPG

scute w/ gpg23: Support multiple cards/tokens, major update with KEYGRIP
Testing, NormalPublic


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.

Event Timeline

gniibe triaged this task as Normal priority.May 24 2022, 4:36 AM
gniibe created this task.

For testing, I can use these sites for client certificate authentication:

For Chromium, we can use Mozilla's modutil to enable scute:

In my case, I did:
modutil -dbdir sql:.pki/nssdb/ -add "scute" -libfile /usr/local/lib/x86_64-linux-gnu/

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.

  • gpg-agent/scdaemon identifies a key by keygrip
  • scute should maintain slot number <-> keygrip table
  • in the PKCS#11 scheme, there are:
    • label
      • 32: "scdaemon"
    • manufacturer
      • 32: use string name of manufacturer
    • serial
      • use the 16 LSB of serial number
    • model
      • "OpenPGP"
    • CKA_ID
      • keygrip of 40-byte

Newer specification is here:

In the branch , 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:

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;

  • By gpgsm
  • By SCD READCERT command of gpg-agent

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 . 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:

  • Tools
    • Optoins
      • LibreOffice - Security - Certificate Path
        • Select the profile of "firefox:default-esr" for NSS certificate directory

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".)

gniibe changed the task status from Open to Testing.Oct 26 2022, 9:24 AM