Subject: [openpgp] Combining signature with signer's public key

From: Kai Engert <[email-masked]>
Date: Thu, 10 Dec 2020 22:38:22 +0100

Is it possible to include the sender's own public key as part of a 
detached OpenPGP signature?

When Thunderbird sends a signed email, it wants to include the sender's 
public key by default, to ensure that the recipient has it available.

Thunderbird sends the key as an attachment.

We received a surprisingly high number of complaints from users. who are 
unhappy about having attached the key by default. Apparently having the 
extra public key attachment causes confusion on the recipient side, with 
users not understanding what the attachment is about.

However, I haven't heard complaints about the signature attachment - 
which is shown by MUA that don't support OpenPGP. The signature 
attachment appears to be less of a problem or confusion.

If it were possible to include the sender's public key inside the 
signature, Thunderbird could use a single attachment for both.

Thanks,
Kai

---

From: [email-masked]
Date: Thu, 10 Dec 2020 16:53:54 -0500

On 12/10/2020 at 4:38 PM, "Kai Engert"  wrote:Is it possible to
include the sender's own public key as part of a 
detached OpenPGP signature?

=====
Possible, but slightly tedious:

[1] Export the public key as an asc file
[2] Add a line after the last line, saying that the key as well as
whatever is to be signed in the message is now being signed by the
signer's key (list name and long fingerprint
[3] Armor sign the entire thing  (asc key file and extra line)
[4] Send the Armored signed message as the attachment instead of the
signature
vedaal

---

From: "brian m. carlson" <[email-masked]>
Date: Fri, 11 Dec 2020 01:01:18 +0000

On 2020-12-10 at 21:38:22, Kai Engert wrote:
> Is it possible to include the sender's own public key as part of a detached
> OpenPGP signature?
> 

Yes, adding an attachment that the sender did not explicitly request is
not a good idea.  I would find this undesirable, too.

> However, I haven't heard complaints about the signature attachment - which
> is shown by MUA that don't support OpenPGP. The signature attachment appears
> to be less of a problem or confusion.

That's because (a) it's been around a long time and (b) that this is a
multipart/signed message, not an attachment.  An MUA that handles S/MIME
already knows how to handle this type because the same MIME type is used
for both (although the MIME type of the signature is different).  And
generally the signature doesn't have an attachment Content-Disposition.

Some MUAs do show it as an attachment and that does cause confusion.
I've had people ask me about it.

> If it were possible to include the sender's public key inside the signature,
> Thunderbird could use a single attachment for both.

I don't think RFC 4880 specifically permits this as part of an OpenPGP
message, but then again they don't specifically permit a detached
signature as an OpenPGP message (although it is described elsewhere).  I
suspect many implementations would in fact understand and parse a key
that was included in the same OpenPGP message as the signature, but
might or might not permit it to be imported.  RFC 3156 states that the
second body "MUST contain the OpenPGP digital signature," but doesn't
restrict it to that or specify things that it should not contain.

You could prototype it and try to see how other implementations (e.g.,
mutt) handle it.  I don't know how you'd get GnuPG to emit a combined
block, though.

There is also a specification called Autocrypt[0] (which I have not
looked at more than cursorily), which may be useful for your needs.

Finally, you could just assume that the user has access to a suitable
keyserver, like many people do, and skip sending the key altogether.
This is what mutt does.

[0] https://autocrypt.org/level1.html
-- 
brian m. carlson (he/him or they/them)
Houston, Texas, US

---

From: Wiktor Kwapisiewicz <[email-masked]>
Date: Fri, 11 Dec 2020 08:21:26 +0100

Hi Kai,

> detached OpenPGP signature?

You may be interested in the Key Block signature subpacket as detailed 
in here:

https://tools.ietf.org/html/draft-ietf-openpgp-rfc4880bis-10#section-5.2.3.31

Do note that as to my knowledge nothing supports it yet (happy to be 
corrected).

Kind regards,
Wiktor

-- 
https://metacode.biz/@wiktor

---

From: Werner Koch <[email-masked]>
Date: Fri, 11 Dec 2020 09:29:52 +0100

> You may be interested in the Key Block signature subpacket as detailed

Right.  GnuPG introduced this for better user experience with mail
providers who won't deploy a Web Key Directory and, more important, to
ease handling of signed file conveyed using non-mail systems.

> Do note that as to my knowledge nothing supports it yet (happy to be

GnuPG supports this since 2.2.20 (released 2020-03-20)

  * gpg: New options --include-key-block and --auto-key-import to
    allow encrypted replies after an initial signed message.  [#4856]

--include-key-block
--no-include-key-block

    This option is used to embed the actual signing key into a data
    signature.  The embedded key is stripped down to a single user id
    and includes only the signing subkey used to create the signature
    as well as as valid encryption subkeys.  All other info is removed
    from the key to keep it and thus the signature small.  This option
    is the OpenPGP counterpart to the gpgsm option --include-certs and
    allows the recipient of a signed message to reply encrypted to the
    sender without using any online directories to lookup the key.  The
    default is --no-include-key-block.  See also the option
    --auto-key-import.

--auto-key-import
--no-auto-key-import

    This is an offline mechanism to get a missing key for signature
    verification and for later encryption to this key.  If this option
    is enabled and a signature includes an embedded key, that key is
    used to verify the signature and on verification success the key is
    imported. The default is --no-auto-key-import.

    On the sender (signing) site the option --include-key-block needs to
    be used to put the public part of the signing key as “Key Block
    subpacket” into the signature.

The include-key-block option should only be enabled if required.  MUAs
can decide whether this makes sense; GPGME supports this using
gpgme_set_ctx_flag (flags "include-key-block" and "auto-key-import").

Salam-Shalom,

   Werner

--
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

---

From: holger krekel <[email-masked]>
Date: Fri, 11 Dec 2020 09:31:14 +0100

Hi Kai, 

the reason several e-mail app implementors decided for a header 
in the discussions leading up to the Autocrypt spec in 2017
was precisely to not confuse users with weird attachments. related FAQ: 
https://autocrypt.org/faq.html#why-are-you-using-headers-rather-than-attached-keys 

What do you find problematic about it?  It's been used in several mail
apps (including Thunderbird/Enigmail up until TB78 in August 2020) and
did not cause any UX issues or complaints. I'd kindly ask you to consider
not inventing another method now without strong reason.

cheers,
holger

On Thu, Dec 10, 2020 at 22:38 +0100, Kai Engert wrote:
> _______________________________________________
> openpgp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/openpgp

---

From: "Neal H. Walfield" <[email-masked]>
Date: Fri, 11 Dec 2020 09:34:36 +0100

Hi Kai,

On Fri, 11 Dec 2020 08:21:26 +0100,
> https://tools.ietf.org/html/draft-ietf-openpgp-rfc4880bis-10#section-5.2.3.31

Storing the certificate in a subpacket area of the signature, as
Wiktor points out, is reasonable.

The subpacket that Wiktor references, however, was added to 4880bis
without any discussion on this mailing list, as far as I am aware
(please correct me if I am wrong).  As such, I would recommend that
you instead use a notation.  If, at a later point, this subpacket or a
similar one is indeed standardized, it is straightforward enough to
adapt your implementation.

You could actually store the subpacket or notation in the unhashed
subpacket area since the content is self authenticating (you can check
that the certificate is valid by checking the signature).

One thing to be aware of: the subpacket areas can only hold 64kb of
data.  So, you really should minimize the certificate.

:) Neal

---

From: "Neal H. Walfield" <[email-masked]>
Date: Fri, 11 Dec 2020 09:54:36 +0100

Hi Holger,

On Fri, 11 Dec 2020 09:31:14 +0100,
> not inventing another method now without strong reason.

Thanks for brining this up.  My response was too narrow, and your
recommendation is better.  In particular, it has the nice advantage
that it is possible to attach the sender's certificate (and some other
meta-data) even if the message is not signed.

Neal

---

From: Hanno Böck <[email-masked]>
Date: Fri, 11 Dec 2020 09:58:36 +0100

On Thu, 10 Dec 2020 22:38:22 +0100

> attachment appears to be less of a problem or confusion.

FWIW I have heard lots of complains about the signature attachment,
which is why I stopped sending signed emails by default a long time ago.

-- 
Hanno Böck
https://hboeck.de/

---

From: Wiktor Kwapisiewicz <[email-masked]>
Date: Fri, 11 Dec 2020 10:01:49 +0100

Hi Neal,

> data.  So, you really should minimize the certificate.

Minimizing the certificate is actually a good idea regardless of the 
certificate transport method (Autocrypt header, signature subpacket, 
notation etc.).

It would be good to specify what actually would that minimized cert 
contain. I think the primary key + valid encryption subkey + signing key 
that signed the e-mail + User ID of the sender which contains their 
e-mail address (or the primary one if there is no better match) would 
constitute the minimal set. Of course clients on the receiving side 
should properly merge the cert with what they already have (*not* 
replace it).

Kind regards,
Wiktor

---

From: Kai Engert <[email-masked]>
Date: Fri, 11 Dec 2020 10:02:53 +0100

On 10.12.20 22:53, [email-masked] wrote:
> On 12/10/2020 at 4:38 PM, "Kai Engert" <[email-masked]> wrote:

Thanks for your suggestion.

This approach probably doesn't work for us. I should have clarified that 
it's about PGP/MIME. I guess receiving agents aren't prepared to receive 
a signed message in the place where they expect a signature. Also, IIUC, 
the signature calculation would have to be different, it would have to 
feed both the primary message and the secondary message (with the key) 
into the signature calculation. It seems this won't be comaptible with 
existing clients.

Thanks
Kai

---

From: Wiktor Kwapisiewicz <[email-masked]>
Date: Fri, 11 Dec 2020 10:03:44 +0100

Hi Hanno,

> which is why I stopped sending signed emails by default a long time ago.

Too bad signatures cannot be put into headers (just like DKIM 
signatures). That would not confuse people (because they generally don't 
inspect headers) while providing necessary info for clients that 
understand them.

Kind regards,
Wiktor

---

From: "Neal H. Walfield" <[email-masked]>
Date: Fri, 11 Dec 2020 10:27:52 +0100

On Fri, 11 Dec 2020 10:01:49 +0100,
> certificate transport method (Autocrypt header, signature subpacket,

I agree that when we need to optimize for space, data whose utility in
the particular context is zero or less should be stripped.

> contain. I think the primary key + valid encryption subkey + signing
> key that signed the e-mail + User ID of the sender which contains
> their e-mail address (or the primary one if there is no better match)
> would constitute the minimal set. Of course clients on the receiving
> side should properly merge the cert with what they already have (*not*
> replace it).

I think over specifying is bad, because what is useful is context
dependent.  Should I be forbidden from including third-party
certificates?  What if I suspect that one of them would allow you to
authenticate my certificate?  What if I have per-device encryption
subkeys and I know that your implementation will encrypt to them all,
like Open Keychain?  Do I have to choose one?

:) Neal

---

From: Kai Engert <[email-masked]>
Date: Fri, 11 Dec 2020 10:43:11 +0100

> not inventing another method now without strong reason.

The amount of data that can be transported in an email header is limited.

For the simple keys that can be generated inside Thunderbird (primary 
key, single subkey for encryption, single used ID), using the Autocrypt 
header could work.

However:

- we also allow users to use their complex keys with Thunderbird,
   which may contain multiple user IDs, and contain many certifications,
   causing the key to be very big
   The Autocrypt header seems like an incomplete key distribution
   mechanism for complex keys.

- what Thunderbird sends in PGP/MIME's application/gpg-keys
   attachment isn't limited to the sender's public key.
   It will also include revocation statements,
   for revoked keys matching the sender's email address.

Kai

---

From: "Neal H. Walfield" <[email-masked]>
Date: Fri, 11 Dec 2020 10:53:32 +0100

On Fri, 11 Dec 2020 10:43:11 +0100,
Kai Engert wrote:
> key, single subkey for encryption, single used ID), using the
> Autocrypt header could work.
> 
> However:
> 
>   which may contain multiple user IDs,

You only need the User ID corresponding to the email address in the
from field, and the current self signature.

>   and contain many certifications,

The last I checked gmail doesn't accept mails larger than 25MB.  So,
you'll need a filter if you intend to include everything...  Also, you
have to remember that the email also has content, so you probably
don't want to reserve more than a few MB for the signer's certificate.
In that case, you pretty much have to filter some certificates...

>   mechanism for complex keys.

Indeed.  I'd argue that that is a feature, not a bug.

---

From: "Neal H. Walfield" <[email-masked]>
Date: Fri, 11 Dec 2020 11:14:33 +0100

On Fri, 11 Dec 2020 10:03:44 +0100,
Wiktor Kwapisiewicz wrote:
> signatures). That would not confuse people (because they generally
> don't inspect headers) while providing necessary info for clients that
> understand them.

When you say cannot, I think you mean there is no standard to so.
Technically, I think, it is possible, and it is a neat idea.

---

From: Kai Engert <[email-masked]>
Date: Fri, 11 Dec 2020 11:22:06 +0100

> Technically, I think, it is possible, and it is a neat idea.

It's a nice idea, but it's also new, so it's not practical as the single 
mechanism to use in the immediate future.

Preserving compatiblity with a majority of existing implementations is a 
high priority for me, and using the gpg-keys attachment mechanism seems 
best to achieve that.

Kai

---

From: Kai Engert <[email-masked]>
Date: Fri, 11 Dec 2020 12:21:55 +0100

Thanks to everyone for your comments and suggestions, it was very helpful.

I wonder if the following could be reasonable.

(1) Similarly to the Autocrypt keydata header
let's define a new header that can be used to transport revocation 
information for a key.

With Thunderbird's current approach to include revocations as part of an 
gpg-keys attachment, we probably cannot expect most other MUAs to 
automatically process it.

Thunderbird would implement the new revocation information header, and 
both send and consume it. With this, Thunderbird would no longer need to 
distribute this information in an attachment.

(2) If the sender's key is simple, don't use an attachment.

Strip certificates, include it as an Autocrypt keydata header.

(3) Develop a reasonable strategy for treating complex keys,
which contain multiple user IDs, or multiple sub keys, or both.

I'm worried that sending a key with only a single user ID can be 
confusing, for example in the following scenario.

Alice's key has two user IDs, @project1.org and @project2.org.

Alice sends a signed email from @project1 to Bob, Bob verifies/accepts 
the key for this email address. Later Alice sends a signed email from 
@project2. Bob will be confused why Alice's key is shown as unverified, 
despite her using the same key. This will require UI to distinguish the 
key verification status individually per user ID.

To minimize this confusion, I think it would be preferable to always 
keep all user IDs, then Bob can be immediately aware that the keys is 
used for multiple addresses.

Does the current Autocrypt specification allow the distribution of a key 
with multiple user IDs and sub keys?

If we strip certificates, but keep user IDs and sub keys, can we expect 
keys to still have a reasonable size for transport in the Autocrypt header?

If yes, then Thunderbird could always include an Autocrypt keydata 
header for complex keys, too.

Kai

---

From: Andrew Gallagher <[email-masked]>
Date: Fri, 11 Dec 2020 11:26:48 +0000

On 11/12/2020 11:21, Kai Engert wrote:
> This will require UI to distinguish the key verification status 
> individually per user ID.

This is an eventuality that any reasonable UI *must* already handle. 
Just because my key is valid for [email-masked], does not mean that 
it is therefore valid for [email-masked].

-- 
Andrew Gallagher

---

From: Kai Engert <[email-masked]>
Date: Fri, 11 Dec 2020 12:32:07 +0100

> it is therefore valid for [email-masked].

Yes, fully agree.

My questions remain nevertheless.

Kai

---

From: Bart Butler <[email-masked]>
Date: Fri, 11 Dec 2020 12:19:23 +0000

Hi Wiktor,

Does signature.asc even show up as an attachment if you set the disposition to inline for PGP/MIME? That would be the obvious solution for suppressing unwanted signature.asc attachments for non-aware recipients.

Bart

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

---

From: Heiko Schaefer <[email-masked]>
Date: Fri, 11 Dec 2020 13:22:12 +0100

Hello Kai

On 12/11/20 12:21 PM, Kai Engert wrote:
[..]
> which contain multiple user IDs, or multiple sub keys, or both.
[..]

I would like to add a strong vote for not casually inventing yet another
mechanism for distributing OpenPGP key material.

The autocrypt standard is established, and quiet a few projects support
it (https://autocrypt.org/dev-status.html).

One of the stated objectives of autocrypt is "Use decentralized, in-band
key discovery" (https://autocrypt.org/background.html). This seems to be
exactly what this discussion is about.

For example, the point you raise above is specifically covered in the
standard here: https://autocrypt.org/level1.html#openpgp-based-key-data

If the autocrypt standard does not satisfy requirements that thunderbird
has, relating to key discovery, it would seem best to me that the wider
OpenPGP community work on enhancing the standard.

Thank you, regards,
Heiko

---

From: Werner Koch <[email-masked]>
Date: Fri, 11 Dec 2020 21:01:20 +0100

> it (https://autocrypt.org/dev-status.html).

Autocrypt is bound to mail use cases and can't be used in other
environments.  Remember that mail is only one use-case; there are many
other important use cases.

Key discovery has never been in the scope of OpenPGP.  The standard
provided means to implement systems but does not enforce the use of one.
That limited scope worked very well over the last 23 years.

Noet that I do not say that such topics ares out of scope for this
mailing list; merely for the OpenPGP standard.  In fact, over all the
years this list has also been used as an implementers forum.

Salam-Shalom,

   Werner

---

From: Steffen Nurpmeso <[email-masked]>
Date: Fri, 11 Dec 2020 21:28:18 +0100

Werner Koch wrote in
 <[email-masked]>:
 |On Fri, 11 Dec 2020 13:22, Heiko Schaefer said:
 |
 |> The autocrypt standard is established, and quiet a few projects support
 |> it (https://autocrypt.org/dev-status.html).
 |
 |Autocrypt is bound to mail use cases and can't be used in other
 |environments.  Remember that mail is only one use-case; there are many
 |other important use cases.

Also it is a tremendous waste to include kilobytes of data (for
usual key types) in each and every mail for nothing, even if the
mail as such is not even signed!
And if it is signed, then everything you want is included anyway
.. no?

 |Key discovery has never been in the scope of OpenPGP.  The standard
 |provided means to implement systems but does not enforce the use of one.
 |That limited scope worked very well over the last 23 years.
 |
 |Noet that I do not say that such topics ares out of scope for this
 |mailing list; merely for the OpenPGP standard.  In fact, over all the
 |years this list has also been used as an implementers forum.

I personally (not yet supporting OpenPGP for at least one more
year, but S/MIME) am also of the opinion that _if_ you discover to
have an immediate, real need to start a secure, encrypted
communication with someone that you have not yet exchanged keys
with, then you can very well send a small message in advance and
ask for a public key, or how and where to get it.  I admit,
i never understood autocrypt.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

---

From: Vincent Breitmoser <[email-masked]>
Date: Fri, 11 Dec 2020 21:52:47 +0100

> then you can very well send a small message in advance and ask for a public
> key, or how and where to get it.  I admit, i never understood autocrypt.

Autocrypt was designed with folks in mind who don't think that way.
We wildly speculated there'd be a lot of those.

 - V

---

From: Steffen Nurpmeso <[email-masked]>
Date: Sat, 12 Dec 2020 23:08:25 +0100

Vincent Breitmoser wrote in
 <[email-masked]>:
 |> then you can very well send a small message in advance and ask for \
 |> a public
 |> key, or how and where to get it.  I admit, i never understood autocrypt.
 |
 |Autocrypt was designed with folks in mind who don't think that way.
 |We wildly speculated there'd be a lot of those.

Well yes, sure.  It is just, i guess i "never gonna fall for
Modern Love".  I find it wasteful, superfluous, and
over-engineered.  And in my opinion it is not bad advice to users
to say just that.
In S/MIME that is much better, but of course you need a CA.
I have a CACert S/MIME certificate, i had to verify its email
address, and if i send a S/MIME signed mail anyone can savely save
the public certificate that ships with it, when they verify it
against the ... well you know how it works of course.
I'd rather have the same for OpenPGP, a signed message with the
public thing extractable embedded, then i at least know that the
signer had the private key for that public thing at hand.

--steffen
|

---

From: John Scott <[email-masked]>
Date: Sun, 13 Dec 2020 15:12:47 -0500

> signer had the private key for that public thing at hand.
I don't think it's standard but GnuPG enables this with the --include-key-
block and --auto-key-import pair of options:

--include-key-block
> This  option  is  used to embed the actual signing key into a
> data signature.  The embedded key is stripped down to a
> single user id and includes only the signing subkey used to
> create the signature as well as as valid encryption subkeys. 
> All other info  is  removed from the key to keep it and thus
> the signature small.  This option is the OpenPGP counterpart
> to the gpgsm option --include-certs.

--auto-key-import
> This  is an offline mechanism to get a missing key for
> signature verification and for later encryption to this key. 
> If this option is enabled and a signature includes an
> embedded key, that key is used to verify the  signature  and 
> on  verification success that key is imported. The default is
> --no-auto-key-import.
>               
> On  the  sender  (signing) site the option --include-key-block
> needs to be used to put the public part of the signing key as
> “Key Block subpacket” into the signature.

---

From: Steffen Nurpmeso <[email-masked]>
Date: Mon, 14 Dec 2020 22:20:26 +0100

Hello.

John Scott wrote in
 <23083923.ouqheUzb2q@t450>:
 |On Saturday, December 12, 2020 5:08:25 PM EST Steffen Nurpmeso wrote:
 |> I'd rather have the same for OpenPGP, a signed message with the
 |> public thing extractable embedded, then i at least know that the
 |> signer had the private key for that public thing at hand.
 |I don't think it's standard but GnuPG enables this with the --include-key-
 |block and --auto-key-import pair of options:
 |
 |--include-key-block
 |> This  option  is  used to embed the actual signing key into a
 |> data signature.  The embedded key is stripped down to a
 |> single user id and includes only the signing subkey used to
 |> create the signature as well as as valid encryption subkeys. 
 |> All other info  is  removed from the key to keep it and thus
 |> the signature small.  This option is the OpenPGP counterpart
 |> to the gpgsm option --include-certs.
 |
 |--auto-key-import
 |> This  is an offline mechanism to get a missing key for
 |> signature verification and for later encryption to this key. 
 |> If this option is enabled and a signature includes an
 |> embedded key, that key is used to verify the  signature  and 
 |> on  verification success that key is imported. The default is
 |> --no-auto-key-import.
 |>               
 |> On  the  sender  (signing) site the option --include-key-block
 |> needs to be used to put the public part of the signing key as
 |> “Key Block subpacket” into the signature.

Very interesting!  I did not know that indeed, i am still with gpg
1.4 ;-), but gnupg 2.25 is standard in CRUX-Linux, too, so.
Yes, that is a very, very good thing then, in my opinion!
Begs the question, if i will implement OpenPGP support next year
(after the MIME rewrite that thing needs first), can i somehow
integrate this with email when using standard OpenPGP MIME format.

--steffen
|

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 18 Dec 2020 18:53:19 -0500

On Fri 2020-12-11 12:19:23 +0000, Bart Butler wrote:

> Does signature.asc even show up as an attachment if you set the
> disposition to inline for PGP/MIME? That would be the obvious solution
> for suppressing unwanted signature.asc attachments for non-aware
> recipients.

Setting a MIME part as Content-Disposition: inline (RFC 2183) is
intended to encourage the recieving MUA to display the part inline to
the reader.

if the receiving MUA has no way of rendering the signature part
(Content-Type: application/pgp-signature), then there's no way that it
can actually render it "inline", so most MUAs will simply ignore the
Content-Disposition: inline header, rather than hiding the message part
entirely.

        --dkg

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 31 Dec 2020 14:22:23 -0800

> Technically, I think, it is possible, and it is a neat idea.

You may want to keep an eye on draft-ietf-httpbis-message-signatures that
is defining an HTTP header field for conveying a signature over (a subset
of) the message.  It seems like at least some of the topics covered would
be relevant for the email case as well.

-Ben