I implemented support for ECC and DSA public keys in poldi. Tested with ECC (curve 25519) key on Gnuk smartcard (Nitrokey Start).

I think commit https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=commit;h=09c27280cc09798d15369b3a143036b7ab5ddd69 should be backported to 1.8 branch of libgcrypt.

HTTP/1.1 spec, RFC 7230, Section 5.4, paragraph 2:
https://tools.ietf.org/html/rfc7230#section-5.4

Please be so kind and point me to the specs stating that you should put the IP address into Host:

It's up to GPG to send the Host header that shows the user's intent.

Here's an ugly hack to make this work (patch based on v2.2.15).

So in short you want:

1. Allow to specify a keyserver by IP without any DNS lookups.
2. When connecting via IP use the IP address for Host:.

@werner
It is good practive to open a public ticket for many projects, because otherwise the XMPP users don't know if the fact is already known, reported or being worked on. Alternatively: Let us document the procedure in public what someone should do, if the xmpp server ist down or the certificate is expired. What is that procedure?

Right, no need to open a ticket. Jens has no account here anyway.

I gave the usual ping. Yes I'm note sure why it's not automated. Our jabber server is hosted by a volunteer so it is not in our hands.

As it ran out again before this issue got officially closed, I'll reopen it with an extended title.
Wasn't the idea to automate this somehow? >:)

@vsrinu26f No worries, looks like we are on the same page :)

Sorry i think i blabbered without understanding context.

I wish gnupg natively supports creating backup cards. To be able to import
private key material to do another keyto card. And every time it moves that
to card and removes from gnupg.

For exactly same key material on tokens. Just before writing first token
backup .gnupg folder or export all key info. Do key to card. Delete .gnupg
folder and restore from backup and keytocard second token.

Both tokens should have same material.

On the other hand if we want to track which token is used by having multiple unexpired signing subkeys and each token have its own subkey is a possible usecase where multiple admins have the tokens.

I think if we have to update one token then we have to update backup token as well if moved to new subkey.

@vsrinu26f Yes I'm using subkeys with YubiKey.

Sorry, ignore my comment if there is something with subkeys and you are
already using latest gnupg.

This is already implemented by yutaka.

Sorry for jumping in out of the blue but the idea of automatically selecting the available signing key sounds also very appealing to me.

With the downstream report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=925952 I resolve this here.

Thanks for the report. This was fixed with: https://cgit.kde.org/libkleo.git/commit/?id=8a94ac0835f0cff8908943d2a630a003a3429220 which I backported to Applications 18.12 which is the current stable release. But debian needs to add this patch. I'll report a debian bug and link it here.

Good that it works again for you.

I don't anymore think that it makes sense to fix it. Further there is no cache for PINs; that is entirely up to the card.

This was most likely a (chipcard) hardware issue. It went away after polishing the contact pads for a bit. Possibly my laptop reader applies more force...

No more reports about this in a while.

Fixed with 3.1.7

False positives happen from time to time with various Anti Virus Software. We have it as a FAQ in the wiki:
https://wiki.gnupg.org/Gpg4win/AntiVirusSoftware

Thanks so much your helps.
With new version 3.1.6, I can generate key on Kleopatra tool and use key stored in smartcard.

The same chipcard works still fine in a different (type of) reader / machine.