One of the things that dirmngr has going for it is that it tracks the current network state, and it would be nice to be able to reuse that state across sessions. If an ephemeral keyring can't use a shared dirmngr, there are fewer arguments for having dirmngr in the first place, and people might be more justified in replacing it with things like https://gitlab.com/anarcat/scripts/blob/master/openpgp-key-get

I don't anymore think this is a high priority request. BTW, A more real problem than several dirmngr instances is multi-user access to smartcards.

Yep, I'd like that, too. Sadly G-Suite Sync does not support "PGP/MIME" which is the standardized format we need to put together a message with attachments in a Mail.
So for now we only have PGP/Inline support. See: T3545

• If the original key origin is a KEYSERVER or WKD it is fine to fetch an update of the key from a keyserver/wkd without user interaction.
• if the key origin is file it can be assumed that the key has bee received hand to hand and thus the existence of that key should not be made public.

I did not yet implement the use of "key origin" in Enigmail. I don't believe that it adds much value, because I anyway need to track more details about autocrypt keys separately from the keyring (such as the peer-state).

does the proposed mail value indicate that the key was received over e-mail, or is it intended to have some more nuanced semantics?

I disagree that it's conceptionally the same, unless you also consider any key on an HTTP server to be "conceptionally the same" as WKD.

Conceptionally it is the same. You receive a key and start to use it, everything else is not a matter of gpg; in particular not the autocrypt protocol.

Certain origins do have special treatment but in general the key origin is meta data for the frontend.

I agree with you and GpgOL handles it that way so for me this would work. But I'm not actually implementing autocrypt, so I also added @patrick to the subscribers.
I've talked about using key-origin in Enigmail with him in Brussels and I would be interested what he thinks Enigmail might require and if gpg could be improved for that.

autocrypt is not different from attaching a file to a (signed) message as it has always been done. We have no special treatment for that in gpg. Certain origins do have special treatment but in general the key origin is meta data for the frontend. For example it allows us to update a key received from WKD when it has expired.

Hi,
if I don't misunderstand you, we already have that:

My interpretation of the key-origin is that it's basically up to the application what it does with the information. It is added information, like the TOFU history we can have. I don't necessarily think in terms of "trustworthyness".

I'm a bit confused. The origin of Autocrypt keys is clearly different from keyservers ("ks"), why would they use the same value? I was aware that origin values are mapped to integers, but your description seems to imply that these integers have significant ordering in terms of trust. The documentation in the man page is a bit bare bones, but my interpretation of "key-origin" was that it simply stated the method of discovery for a key, leaving any implications of trust to the client. Is this incorrect?

@werner: what if the autocrypt header is in a dkim-signed message, and the dkim signature covers the autocrypt header, and the dkim signature is verifiable using dnssec? is it still the same as from a keyserver?

Receiving a key by mail should in general be considered unknown and is not more trustworthy than receiving a key from a keyserver. I would suggest that you use "ks-pref" for this purpose. That origin value has no special meaning in gnupg but is numerical ordered between keyserver and and DANE; gpgme currently maps it to keyserver level anyway.

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

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

@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.

Great. Let me know when the newest gpg4win is released.

fwiw, a comment over on T4422 contains a bash script that tries to force GnuPG to do its certificate/signature re-ordering. this doesn't produce anything canonical yet, but it's the closest i've come so far to getting GnuPG to do something repeatable with a certificate after merging (but even that is not quite stable).