When generating nist or brainpool signing or authentication subkeys one must explicitly specify ecdsa or gpg will fail.
Quoting from https://lists.gnupg.org/pipermail/gnupg-users/2018-July/060755.html :
In contrast to the cv25519 and ed25519 curves this (and the NIST curves)
don't have an implict algorithm. Thus gpg tries to deduce this from the
usage parameter but that seems not to work.
The below example better demonstrates the issue. I've replaced the output of successful subkey generation with [..] since it's mostly the need more entropy message.
$ export GNUPGHOME=`mktemp -d` $ gpg -k gpg: keybox '/tmp/tmp.JkLpEC1BEX/pubring.kbx' created gpg: /tmp/tmp.JkLpEC1BEX/trustdb.gpg: trustdb created $ gpg --quick-gen-key test About to create a key for: "test" Continue? (Y/n) y [...] gpg: key 9298BA31335F947F marked as ultimately trusted gpg: directory '/tmp/tmp.JkLpEC1BEX/openpgp-revocs.d' created gpg: revocation certificate stored as '/tmp/tmp.JkLpEC1BEX/openpgp-revocs.d/AB33DE202EE3F91E944585439298BA31335F947F.rev' public and secret key created and signed. pub rsa3072 2018-07-03 [SC] [expires: 2020-07-02] AB33DE202EE3F91E944585439298BA31335F947F uid test sub rsa3072 2018-07-03 [E] $ gpg --quick-add-key AB33DE202EE3F91E944585439298BA31335F947F brainpoolP384r1 sign gpg: Key generation failed: Wrong key usage gpg: Key not changed so no update needed. $ gpg --quick-add-key AB33DE202EE3F91E944585439298BA31335F947F brainpoolP384r1/ecdsa sign [...] $ gpg --quick-add-key AB33DE202EE3F91E944585439298BA31335F947F brainpoolP384r1 encrypt [...] $ gpg --quick-add-key AB33DE202EE3F91E944585439298BA31335F947F brainpoolP384r1 auth gpg: Key generation failed: Wrong key usage gpg: Key not changed so no update needed. $ gpg --quick-add-key AB33DE202EE3F91E944585439298BA31335F947F brainpoolP384r1/ecdsa auth