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.

should be useful to create such completion stuff. No context specific completion but this is imho anyway a misfeature.

I've changed the text of this report from "filter" to "screener" to match the preferred terminology. thanks for the clarification.

I still consider the import screener (the term filter is used in a different way now) a big mess. Using the import feature to maintain the idea of a curated keyring is a bad idea because gpg has not been designed with this in mind. We spent so much time on this screener already and problems pop up again and again.

I think this is now resolved, as of rG926d07c5fa05

I am not proposing changing the order of the *hashed* subpackets in a signature. I'm proposing removing/changing/canonicalizing the *unhashed* subpackets in a signature. Sorry if i didn't make that clear enough in the initial message.

But wait. Does my idea really help with comparing? I doubt it because a signature also includes a date and other variable stuff and thus they are already binary identical or it is a different signature.

Right we can't change the order of signature subpackets after they have been created. Given that we create subpackets by directly appending them to a memory buffer instead of keeping a list of subpackets to create, the least invasive method would be a function to shuffle that memory buffer right before the signature is computed.

I thoroughly agree that this is not required by the specs.

Do you mean this?

That is not required by the specs. Another way is to provide a tool to compare keys. That seems to be easier to me. Also consider the cases that there are new new packets or signature subpackets with unknown properties to the current implementations. What about different encodings in signed key material?

The comment from aa above appears to be misdirected/spam.

@werner , I understand your poiont.

So, this is VERIFY reset allows the host to implement the "force" flag we always had in the card for the first key. At least kind of, because malware can still suppress the VERIFY reset ;-). The integrated "force" flag requires the admin PIN, which is malware should have more problems to snoop.

For the record, the authentication status reset by VERIFY command was introduced in OpenPGPcard specification V2.2.
I think V3 card supports that.
Gnuk 1.2 supports this reset feature.

Yes. For the use case of GnuPG, it is better to support disabling (unauthorize) use of keys.
On the other hand, IIUC, the original OpenPGPcard implementation is designed/implemented under the influence of other smartcard usages.

The idea with the smartcard is that you can limit the time of exposure
of the key. Leaving the card accessible to the host is thus not a good
idea. Malware can simply snoop the PIN from the last operation and
then, at its own discretion, use the keys of the card. This can only be
avoided by using a smartcard reader equipped with a pinpad and able to
filter commands so that it is not possible to bypass the pinpad (which
is easy for the host).

Unfortunately, not all OpenPGPcard implementations support command to unauthorize use of keys.

Using a smartcard it should be possible to set a cache-ttl value so that not only on-disk keys but also the PIN used for unlocking the key on the smartcard is not cached longer than the given period in cache-ttl. Until now you have to plug out and in the card by yourself to get this working. Alternatively you theoretically could set a config in scdaemon to power off the card after some time ("card-timeout). It could be a solution to set this config automatically if cache-ttl option is used.

Go ahead and type your message ...

Is this even something that we can control?

Smartcards and on-disk keys are very different things and handled by different processes.

I would also like this feature. I currently use a pair of subkeys (one for work one for personal projects) and it would be much easier if I could configure gpg-agent to append comments to the keys rather than displaying (none). Perhaps a flag could be added to sshcontrol which allows you to specify and arbitrary comment?