Hi @aheinecke, thanks for thinking about this, and thanks for tagging me here too. I'm definitely interested.

I agree with you that attaching the OpenPGP certificate as an application/pgp-keys subpart of a multipart/mixed message would be a UI/UX regression.

I'm not sure specifically where the you would put the pubkey in the signature. can you provide an example?

Since we're talking about e-mail here, i assume we're talking about PGP/MIME. Are you suggesting that it would live in the same MIME part as the signature? If so, i don't see how to read RFC 3156 §5 in that way, but i admit the document is surprisingly vague about what is actually in it.

RFC 3156 says:

The second body MUST contain the OpenPGP digital signature.

and RFC 4880 §11.4 says:

detached signatures are simply a Signature packet stored separately from the data for which they are a signature.

But i guess nothing says that the second MIME body part must be *only* the OpenPGP digital signature. Is that where you're expecting to place the OpenPGP certificate? or somewhere else? Do you expect the signature cover the certificate as well as the message itself? (i'm not sure that it needs to, but i'm just trying to clarify the cryptographic semantics you're looking for)

Have you tested inclusion of an OpenPGP certificate wherever you're intending to put it and seen what happens with different PGP/MIME-compatible MUAs?

I think the question about whether to include an Autocrypt header is probably orthogonal to this "pubkey in the signature" approach. Given that multiple e-mail programs out there today already look for certificates in the Autocrypt header, is there some reason not to emit it?

I agree with you that it'd be nice to know that all e-mails would be signed, but given the state of the network today, but that doesn't seem realistic for most users because of the multiple-MUA situation many people are in. On that front, I'd be curious to hear your thoughts about the expect-signed-mail proposal -- it's half-baked right now, but some thoughts about how to do it right from another active developer would be super useful.

Werner said that it's possible in OpenPGP to also put the pubkey into the signature. (...) The nice advantage is that this will also work for files.

Are you suggesting that it would live in the same MIME part as the signature?

I interpreted this as putting the pubkey in the signature itself, e.g. as unhashed subpacket. This is an attractive solution, because the signature is typically handed to the openpgp implementation as-is, so this would just work in mail clients that use gnupg under the hood. We had actually considered this as a mechanism for key exchange in the (very) early stages of Autocrypt. I vaguely recall Neal also wanted to do something with this idea more recently (perhaps pep-related? don't remember).

The disadvantage is that this mechanism tightly couples the key exchange with signed-only emails. We all agree that weirdo attachments have a big impact on user experience. And the email ecosystem hasn't moved even a bit soften this, e.g. on Google Groups signatures result in attachment squares so large they disrupt the flow of reading: https://groups.google.com/forum/#!topic/qubes-users/EYp4QcS_FL0.

I would be more enthusiastic about this mechanism for key exchange if there was no way that didn't have this unfortunate side effect. But headers exist, and they offer a tradeoff that isn't intrusive to "email userspace", albeit at the cost of requiring explicit client support. But we've almost paid that cost at this point, and I never regretted this choice we made in Autocrypt. Because imo, the single most important thing email crypto needs to do is to get as far out of the user's way as possible.

Ah, thanks for pointing out the subpacket option (i guess it could be hashed or unhashed). i don't think any of the subpackets currently defined in RFC4880 supports this use case -- but i guess you could mint a new one, or use a notation.

I don't think it tightly couples the key distribution (it's not a key exchange) with signed-only mails, though. As i said above, i think distributing the users's minimized OpenPGP certificate in the header is pretty much orthogonal to this approach -- there's no reason you couldn't distribute an Autocrypt header as well (though i agree that once you have an Autocrypt header, stuffing the certificate in the signature itself seems like it might not be particularly useful, unless you're looking to distribute a larger certificate that can fit in the header for those people who might actually have PGP/MIME-capable MUAs).

It would be a real shame if there was no way to distribute the key invisibly with a cleartext e-mail from GpgOL though. Being able to "broadcast" a signal that the capable MUAs will read and interpret but other MUAs will ignore is pretty important for wider adoption. I know i avoid signing cleartext e-mail if i don't know my recipient's capabilities, precisely because of the UX burden it imposes.

This is a nice idea and although it overlaps with Autocrypt it has other uses too: for example verification of signed files that can be vastly simplified (just get the file and the signature, no key fetching needed, downside: the key attached to the signature could be stale).

As for implementation why not just concatenate key packet with the signature packet and extend the spec to note that detached sigs could also be followed by optional key packets? This makes the change as little as possible.

@wiktor-k, "just extend the spec" doesn't necessarily work with existing clients, which might be surprised to find unexpected packets in the signature section of an e-mail. It seems more likely to me that they'd be able to handle (meaning: ignore) an unknown subpacket (as long as it's well-formed) than to handle additional packets. But all of these surmises require testing with existing clients, of course. Has anyone done any of that testing?

ftr, here is the thread I had in mind but couldn't recall above. @aheinecke is that your thinking, or a more pgp/mime bound mechanism as @dkg assumed?

You can test it now out using GnuPG master: Just add --include-key-block and you can then verify using an empty keyring. Currently --auto-key-retrieve is not needed but we need to think on how we can enable or disable this during verification.

I think that this chnage is useful enough to be backported to 2.2. Done that.