This is not a problem with gnupg-pkcs11-scd itself, but a warning for anyone attempting to use PKCS#11 keys with GnuPG on a Fedora or RHEL compatible system. If you attempt this DO NOT USE the pkcs11-helper or pkcs11-helper-devel RPMs provided by Fedora or Fedora EPEL to build gnupg-pkcs11-scd. At present it appears there are no RPM packages for gnupg-pkcs11-scd for Fedora or RHEL so you must build that package regardless. But if you depend on pkcs11-helper RPMs it will change the URIs exposed in a way that will break integration with GNU Privacy Guard. Compiling pkcs11-helper and gnupg-pkcs11-scd from upstream solves the problem, as does using a non-RedHat distribution like Debian.
I've filed a bug against pkcs11-helper with RedHat explaining this issue:
Here's what happens after configuring a PKCS#11 provider and attempting to import a PGP key:
$ gpg --expert --full-generate-key
[...]
Your selection? 14
Serial number of the card: D2760001240111503131AD4306431111
Available keys:
(1) 258DAF945486847792A1AC4F9E69487B7F6EF2A2 pkcs11:model=;token=loadshared%20accelerator;manufacturer=nCipher%20Corp.%20Ltd;serial=;id=%25%8d%af%94T%86%84w%92%a1%acO%9eiH%7b%7fn%f2%a2 (null)
[...]
gpg: [internal]:0: invalid algorithm
Note the (null) at the end of the key line.
Here's the exact same configuration after rpm -e pkcs11-helper pkcs11-helper-devel followed by compiling pkcs11-helper and recompiling gnupg-pkcs11-scd:
$ gpg --expert --full-generate-key
[...]
Your selection? 14
Serial number of the card: D2760001240111503131AD4306431111
Available keys:
(1) 258DAF945486847792A1AC4F9E69487B7F6EF2A2 nCipher\x20Corp\x2E\x20Ltd///loadshared\x20accelerator/258DAF945486847792A1AC4F9E69487B7F6EF2A2 rsa2048
Now the end of the line has rsa2048 instead of (null) for the last field.
After answering questions about validity, user name and email address this leads to a successful import. I'm able to sign and verify files using the corresponding key pair. No changes were made either to the configuration or to gnupg-pkcs11-scd sources to get this result.
If you're trying to use GnuPG with PKCS#11 keys DO NOT USE the pkcs11-helper or pkcs11-helper-devel RPMs provided by Fedora or Fedora EPEL. Compile the source code from here instead:
This is not a problem with
gnupg-pkcs11-scditself, but a warning for anyone attempting to use PKCS#11 keys with GnuPG on a Fedora or RHEL compatible system. If you attempt this DO NOT USE thepkcs11-helperorpkcs11-helper-develRPMs provided by Fedora or Fedora EPEL to buildgnupg-pkcs11-scd. At present it appears there are no RPM packages forgnupg-pkcs11-scdfor Fedora or RHEL so you must build that package regardless. But if you depend onpkcs11-helperRPMs it will change the URIs exposed in a way that will break integration with GNU Privacy Guard. Compilingpkcs11-helperandgnupg-pkcs11-scdfrom upstream solves the problem, as does using a non-RedHat distribution like Debian.I've filed a bug against
pkcs11-helperwith RedHat explaining this issue:[https://bugzilla.redhat.com/show_bug.cgi?id=2298882]()
Here's what happens after configuring a PKCS#11 provider and attempting to import a PGP key:
Note the
(null)at the end of the key line.Here's the exact same configuration after
rpm -e pkcs11-helper pkcs11-helper-develfollowed by compilingpkcs11-helperand recompilinggnupg-pkcs11-scd:Now the end of the line has
rsa2048instead of(null)for the last field.After answering questions about validity, user name and email address this leads to a successful import. I'm able to sign and verify files using the corresponding key pair. No changes were made either to the configuration or to
gnupg-pkcs11-scdsources to get this result.If you're trying to use GnuPG with PKCS#11 keys DO NOT USE the
pkcs11-helperorpkcs11-helper-develRPMs provided by Fedora or Fedora EPEL. Compile the source code from here instead:[https://github.com/OpenSC/pkcs11-helper]()