Well, I gues it's complex enough to warrant strategic discussion, which can be done in this ticket :)

In the autocrypt spec, this is called a "setup code", not a "backup code" :)

This dialog actually belongs to Kleopatra. I added the respective tag.

How about adding support with private in keyparam?

• (genkey(rsa(nbit 2048)(d xxxx)(p xxxx)(q xxxx)(u xxxx))) ; Only p and q, is OK
• (genkey(ecc(curve cv25519)(flags djb-tweak comp)(d xxx)))

I would consider this feature request. Right now you can do this by providing an empty keyring.

Thanks for the information.
Closing, as I pushed rC94b84360ca55: Add OID information for SM3..

CESI also publishes a complete white pager documenting OID assignment in details. See http://www.cesi.cn/201612/1688.html and download the pdf. Search "10197" and I see the following info:

OK, I found: http://www.oidchina.cn/oid/release/1.2.156.10197.
站点： 国家OID注册中心
数字OID： 10197
中文OID：
英文OID： sca10197
应用范围： 密码标准化技术委员会

I use: 1.2.156.10197.1.401

I am now examining OID allocation.
I'll add the OID of SM3 into sm3.c.

GnuPG does not mess with suffixes but Kleopatra has some rules of it own which might be common to KDE. I thus flag your report as a feature request.

gpgme shall provide an interface for commonly required tasks but it shall not expose everything from gpg.

I guess it depends on whether you want gpgme to be an interface to OpenPGP certificates more generally (in which case, exposing the primary flag would be useful), or just a gpg frontend (in which case, the current behavior might be ok)

Okay, will be fixed in 2.2.2.. I actually found a bug while working on the patch.

It is likely that gpa will be changed to always use the default algorithm. Users who have special requirements will need to use gpg on the command line.

Right, but gpg has a strategy to figure out what it considers the primary (ie. the user id commonly printed). If we would merely convey the primary key flag to gpgme, gpgme or the gpgme calling application still needs to figure out what it considers the primary key - that might be different from what gpg shows.

In T3457#104401, @werner wrote:

gpg --print-mds  FILES
gpg --print-md ALGO FILES

But there can be several user IDs that are marked primary, right? I know that gpg tries to not let that happen, but there are other OpenPGP toolkits out there, and composite/hybridized keys, etc where this could happen.

In T3454#104310, @gniibe wrote:

This is my note.
If it is intended to be used to OpenPGP, GCRY_MD_SM3 should be assigned in OpenPGP standard.

In T3454#104309, @gniibe wrote:

Thank you. The diff doesn't include sm3.c. Could you please update?

This is my note.
If it is intended to be used to OpenPGP, GCRY_MD_SM3 should be assigned in OpenPGP standard.

Thank you. The diff doesn't include sm3.c. Could you please update?

This is the review request link: https://dev.gnupg.org/D449

Well, it is already there:

gpg always returns the primary user id first. (see gnupg/g10.keylist.org:reorder_keyblock). gpgme keeps this order and thus the first user +id in the linked list is the primary user id. If the primary user id flag is not set the first is the same what gpg considers the primary user id. I can add this to the documentation.

Thanks. I added you to the wiki page.

I think with the SRV entry, I can configure the server in the way I want to....

In T3437#104021, @werner wrote:

dirmngr has its own stub resolver to do DNS resolution via TCP so that it can be routed via Tor (to 8.8.8.8 which is a heavy traffic resolver and thus it will be hard to single out requests to other often used addresses.).

thanks for the links to documents.
we've setup submisson-address and policy links.

I see that the completion script already uses --dump-options :-)

dirmngr has its own stub resolver to do DNS resolution via TCP so that it can be routed via Tor (to 8.8.8.8 which is a heavy traffic resolver and thus it will be hard to single out requests to other often used addresses.).

okay, I see. Than I havn't found the documentation for this feature. This is enough for defining a different sever.

The only requirement here is that you use a subdomain of gnupg.org (here wkd, but any will work). This was added for those providers who have outsourced the top level domain but can still add new DNS entries.

Using a different server is actually supported:

I know, that I can't handle all WKD request under one domain for multiple once. But i could make sure, that autoconfig.<domain> would result under another IP adresse so I can handle all of the WKD request at another server. Add a own VirtualHost entry etc.

FWIW, I plan to add a few features to gpg-wks-server to make the setup of a new domain and installation of keys easier.

That does not work because a property of WKD is that the key you retrieve has only the requested mail address and no other mail address. Merging them all into one file, which you need to do with your proposal, removes that property.

Because of policy requirements I have.

The import-show thing is new. What you see is different from the default action of gpg when it encounters a keyblock. In fact, that old output was never well defined and basically a debugging aid.

Is this not a regression, rather than a new feature request? Earlier versions of GnuPG report sec rather than pub for such keys. The file itself is a private key - that it contains a public part is surely secondary in this context.

I agree that it is better to keep it in two directories.
(The potential advantages outweight the drawbacks.)

I see.

With the GPG4Win 3.0 Release, the software is differently distributed to the System. In the 2.x releases it was one folder (usually C:\Programms\gpg4win), now it is distributed to two different folder (C:\Programms\gpg4win and C:\Programms\gnupg). So the complete GnuPG files have been rearranged to their complete own folder.

Sorry, I don't understand this. Can you please elaborate?

For context, here's what the wisdom of the crowd is rigging together around GPG to get this single-sign-on feature:

For workaround (master branch with rG0a7661129499), moving the private key file to *.key.bak can do that.

Good idea.

Fixed in master, applying D297: 785_sign-fix.patch.
If needed, it will be in stable 2.2 branch, in future.

What is the benefit of two subkeys?

Thanks, that is interesting info, I need to look into that.

I spoke with the author of onionbalance, and they said:

I'm not entirely sure whether it is due to low usage or little problems with the service, but it seems to work pretty OK. My primary concern is that as opposed to DNS based system, the onionbalance system requires my node to be running and available and as such constitutes a SPOF. Although I've cleaned up my scripts sufficiently, e.g network outage will make this service unavailable whereby the hkps pool will continue to function.

You need to raise this with the IETF OpenPGP WG. First we need it in the OpenPGP standard, then we can implement Something (tm).

It is on the same machine, as I mentioned manually deleting ~/.gnupg/private-keys-v1.d/* is a workaround I have to use, but it is not very user friendly.

Sorry previosly I asked for more slots for keys on token. But its not
needed one. I dont even know it is a valid request but

GnuPG by design uses latest sub keys so in your setup office and home one
of them is latest.

The use case is having 2 different hardware tokens - I have an opengpg card which supports 4096 rsa subkeys, and a yubikey which supports 2048 rsa subkeys. At work I need one, at home the other.

After reading PIV and using PIV token I understood how much simple and easy
GnuPG is by design. You guys rock.

Is it you are moving to new sub keys? if yes do we still need outdated old
subkeys? Is it safe to cleanup old subkeys?

Hi, currently to be able to use 2 different cards with 2 different sets of subkeys from the same primary key (home and work) I need to manually delete ~/.gnupg/private-keys-v1.d/* everytime I want to switch from the first card to the second.

@bluca I created a ticket for smartcard, so that this ticket can focus on the issue of available keys on host. If anything, please add comment to T3416: gpg should select available signing key on card (even with -u option).

@gniibe yes, I can reproduce the problem using -u.
But why does picking a UID force the usage of the first known subkey? Is that expected behaviour? Is there a relationship between UIDs and subkeys?

I have updated D297: 785_sign-fix.patch patch to minimize the impact only to secret key lookup.

My change only addressed the use case with smartcard. So, I removed [TESTING] tag.