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.

We may add an alias for "ks-pref" to better reflect its use. Maybe "mail" or "attachment".

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

What if the header is received in a message that replies explicitly to an e-mail requesting followup from that address?

What if the same key is received both via keyservers and autocrypt headers and in a message attachment? What if it is a corroboration of information gathered via DANE?

Where is the canonical documentation about what "key origin value" means? I'd like to understand the semantics of this field better.

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?

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

For me for example I think it can help to avoid that we pick a wrong key by accident. If I have two keys with Unknown trust and one was received through Autocrypt and another has unknwon origin I would slightly prefer the autocrypt key because there is a higher chance that my intended recipient can decrypt the message.

To be sure: This is not a security attribute or security feature but it might help to create a better user experience.
So I'm for adding a value for it.
An alternative Idea from me was to use the "URL" field for something like "autocrypt:version1?prefer-encrypt=mutual" or something like 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.

I see the information that a key has been received as part of a message as useful and thus I suggested to add re-assign "ks-pref" to "mail". What the frontend does with that information is up to the frontend and depends on other properties of the mail which is out of scope for gpg or gpgsm.

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.

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

Frontends are evidently importing keys from this specific, distinguishable, and specified origin. I don't understand why not just add a value for it? Is the namespace very limited?

autocrypt is not different from attaching a file to a (signed) message as it has always been done.

There is a whole specification for automated public key management attached to Autocrypt headers, it's just as different to attaching a key to an email as "downloading a key via http" is different to 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.

And please reread my comments again: I proposed to add "mail" for this (using a yet unused value).

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.

But while I remain unclear on your reasoning, an "email" origin value would be useful to have for the time being, we can put other semantics in the URL part as Andre suggested. It would be good to also hear @patrick's thoughts on this.

Thanks

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

For example, if i mail @werner and @Valodim and i attach both of their keys to the e-mail message (so that they can mail each other), when @Valodim imports @werner's key from my message, should it also be marked as mail ? or does this proposed mail mean "from an e-mail message from the user referred to by the key" ? in the latter case it should *not* be marked as mail, right?

@werner, is there any documentation about the intended semantics of this "key origin" field that we can read to make sense of it? If not, can you point to where the documentation should be, so that someone™ can take a stab at writing it?

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

In general, I don't see the benefit of having a key origin in the keyring - I currently can't see any use-case (at least for Enigmail).

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

@werner, why is it the case that if i'm willing to look up a key via WKD on Monday, i should by definition also be willing to send a followup request to that WKD server on Thursday just because the certificate is marked with an expiration?

Is this logic intended to protect or hide:

• a) the fact of a key's existence? (if so, then querying the keyserver by primary key fingerprint is relevant)
• b) the fact that i'm interested in an e-mail address related to the key, or in the key itself? (if so, then any network access at all is relevant)
• c) the fact of the e-mail address associated with the key? (if so, then any network access based on the e-mail address is relevant)

if (b), is the logic intended to defend me as a user from a targeted attacker who ships me a specific key to see where i am on the network when i look it up again?

Is the threat model that motivates these particular lookup tactics written down somewhere, so that we can reason about it (and so that users can decide whether it fits their needs)?