Page MenuHome GnuPG

Wish for a new keygen API
Closed, ResolvedPublic

Description

The current GPGME keygen API basically comes down to gpg --gen-key --batch
This is not good to use for a downstream application.

I'd like at least to be able to provide a list of subkeys and a list of uids.

My ideal wish would be to have GnuPG key params in json or xml and to be able to
request supported values. As 2.1 differs from 1.4 and with 2.1 supported options
even differ depending on the gcrypt version or minor versions.

something like get_supported_key_types that would return something like:

{
"RSA": {

"lengths": [
  "1024",
  "2048",
  "4096"
],
"capabilities": [
  "sign",
  "encrypt",
  "certify",
  "auth"
]

},
"ECDSA": {

"curves": [
 "brainpoolP256r1",
 "brainpoolP384r1",
 "brainpoolP512r1",
 "NIST P-256",
 "NIST P-384",
 "NIST P-521"
],
"capabilities": [
  "sign",
  "certify",
  "auth"
]

}
}

And then for generation similarly:

{
"keys": [

{"type": "ECDSA",
 "usage": "certify sign",
 "curve": "NIST P-384"
},
{"type": "ECDH",
 "usage": "encrypt",
 "curve": "NIST P-384"
}]

"uids": [

{"name": "Andre Heinecke",
 "email": "aheinecke@intevation.de",
 "comment": "Comments are bad"
},
{"name": "Andre Heinecke",
 "email": "andre.heinecke@intevation.de"
}

]
"Expire-Date": "20200815T145012",
"Keyserver": "keys.gnupg.net"
}

And superduperideally such a json or xml representation would be available
through API and could be modified and returned again instead of using the
edit-key interface. But that's dreaming. :-)

Event Timeline

The actual plan is to restrict the wauys how gpgme can create keys. In the
future there will be only one way to create a key and no way to select an
algorithm. Those who want to use non-default algorithm should resort to the
command line and the --expert option.

Leaving the GUI vs. Commandline argument aside. I still think the batch keygen
API needs to be "modernized"

E.g. with improved authentication support in gnupg 2.1 it will become more
common to generate a key with an authentication subkey. Even the common case of
different Certify / Sign / Encrypt subkeys is not supported by the current API.

Maybe the Curves / Algos can be split up but I think gpgme needs API to query
supported Curves / Algos from GnuPG as this is more dynamic in GnuPG 2.1 then it
has been in previous versions.

I think in my previous messages the most important feature I'm missing was not
clear as I've mostly talked about subkeys and ECC curves. But what really
hinders me in making Kleopatra's key gen dialog more user friendly immediately,
even with default parameters for the key, is the API limit of only one user ID.

Adding an API to the --quick-* commands of gpg 2.1 is no my shortlist for GPGME.
This will make things much easier - including key signing.

We now have gpg --quick-addkey fpr algo usage expire
(for2.1.13)

Ok,
Let me summarize how I understand the workflow is supposed to be:

  • Generate a Key with the limited batch keygen.
  • After key creation add subkeys as wanted with --quick-addkey
  • Add additional UID's with --quick-adduid

I think I can work with that.
For full flexibility T2364 would be nice so that one could create a certify
only key this way and subkeys for everything else.

But yeah thats icing on the cake.

Still does not solve the Problem how to figure out which algrithms with which
parameters / capabilities are supportet but meh, I guess you can't have everything..

gpgme 1.7 will have gpgme_op_createkey which takes "default" and
"future-default" as algorithm parameters. There is also a bunch of user
functions to make creating a key easy with gpgme.

gpgme 1.7.0 has been released and thus I consider this bug solved.

werner claimed this task.
werner removed a project: Restricted Project.