From konstantin at linuxfoundation.org  Sun Sep  1 01:21:55 2024
From: konstantin at linuxfoundation.org (Konstantin Ryabitsev)
Date: Sat, 31 Aug 2024 19:21:55 -0400
Subject: Signing (and Encrypting) Mails with gpg like DKIM
In-Reply-To: <e692b965dc9f391cee92daf1c8eab40b@mail.emailn.de>
References: <e692b965dc9f391cee92daf1c8eab40b@mail.emailn.de>
Message-ID: <20240831-practical-gray-mackerel-ed137d@lemur>

On Sat, Aug 31, 2024 at 06:29:17PM GMT, T. S. wrote:

The same thought did occur to me, which is why the patch attestation process
used by many in the kernel development community uses DKIM-like signatures:

https://github.com/mricon/patatt

However, this is limited to signing -- I don't believe this mechanism can be
extended to message encryption.

-K


From mm at dorfdsl.de  Sun Sep  1 06:47:25 2024
From: mm at dorfdsl.de (Marco Moock)
Date: Sun, 1 Sep 2024 06:47:25 +0200
Subject: Signing (and Encrypting) Mails with gpg like DKIM
In-Reply-To: <e692b965dc9f391cee92daf1c8eab40b@mail.emailn.de>
References: <e692b965dc9f391cee92daf1c8eab40b@mail.emailn.de>
Message-ID: <20240901064725.4659b93c@zbook>

Am Sat, 31 Aug 2024 18:29:17 +0200
schrieb "T. S." <tfasnetamot at emailn.eu>:

> Is somethings similar available for GPG/PGP?

I don't know about such an implementation, but if you want to create
one, everybody can publish RFCs at IETF, so feel free to create such a
technology.

If you want something unofficial, use the X- headers.


From stuartl at longlandclan.id.au  Sun Sep  1 06:46:58 2024
From: stuartl at longlandclan.id.au (Stuart Longland)
Date: Sun, 1 Sep 2024 14:46:58 +1000
Subject: Signing (and Encrypting) Mails with gpg like DKIM
In-Reply-To: <e692b965dc9f391cee92daf1c8eab40b@mail.emailn.de>
References: <e692b965dc9f391cee92daf1c8eab40b@mail.emailn.de>
Message-ID: <6df9205d-045c-411e-be2d-e6532fd6cf49@longlandclan.id.au>

On 1/9/24 02:29, T. S. wrote:
> after looking into DKIM details, I started searching, why the same procedure
> cannot be used for gpg?

DKIM signs emails that are sent server-to-server.  It does not perform 
encryption of the email (that is done by the sending server sending the 
`STARTTLS` SMTP command and the pair negotiating a cipher).

Crucially, DKIM does not:

1. end-to-end digitally sign the email, the email is not signed until it 
is transmitted by your mail server, malicious code (or users) on the 
server can still manipulate it before sending.

2. perform any encryption, DKIM is about verifying sender *identity* 
(the I).  "Sender" being the server, not you the user.  Emails may be 
passed between servers via TLS, but the messages themselves will be 
stored clear-text at each hop.

For end-to-end encryption/signing, you need to apply this before your 
outgoing SMTP server receives it? that's where S/MIME and OpenPGP come in.
-- 
Stuart Longland (aka Redhatter, VK4MSL)

I haven't lost my mind...
   ...it's backed up on a tape somewhere.



From mm at dorfdsl.de  Sun Sep  1 07:42:25 2024
From: mm at dorfdsl.de (Marco Moock)
Date: Sun, 1 Sep 2024 07:42:25 +0200
Subject: Signing (and Encrypting) Mails with gpg like DKIM
In-Reply-To: <6df9205d-045c-411e-be2d-e6532fd6cf49@longlandclan.id.au>
References: <e692b965dc9f391cee92daf1c8eab40b@mail.emailn.de>
 <6df9205d-045c-411e-be2d-e6532fd6cf49@longlandclan.id.au>
Message-ID: <20240901074225.2cc2e28f@dorfdsl.de>

Am 01.09.2024 um 14:46:58 Uhr schrieb Stuart Longland via Gnupg-users:

> 1. end-to-end digitally sign the email, the email is not signed until
> it is transmitted by your mail server, malicious code (or users) on
> the server can still manipulate it before sending.

It would be possible to sign DKIM at the MUA, but this is not common.

With the selectors, each user could have its own selector and private
key.

-- 
kind regards
Marco


From stuartl at longlandclan.id.au  Sun Sep  1 07:51:57 2024
From: stuartl at longlandclan.id.au (Stuart Longland)
Date: Sun, 1 Sep 2024 15:51:57 +1000
Subject: Signing (and Encrypting) Mails with gpg like DKIM
In-Reply-To: <20240901074225.2cc2e28f@dorfdsl.de>
References: <e692b965dc9f391cee92daf1c8eab40b@mail.emailn.de>
 <6df9205d-045c-411e-be2d-e6532fd6cf49@longlandclan.id.au>
 <20240901074225.2cc2e28f@dorfdsl.de>
Message-ID: <41e19c78-20ad-47df-b607-fc63bf7b3718@longlandclan.id.au>

On 1/9/24 15:42, Marco Moock wrote:
> It would be possible to sign DKIM at the MUA, but this is not common.
> 
> With the selectors, each user could have its own selector and private
> key.

Given the public key is published in DNS records, could you imagine the 
hot mess that'd create for domains with lots of users?  Either lots of 
DNS records, or lots of users sharing the same private key.

Neither is a good look.
-- 
Stuart Longland (aka Redhatter, VK4MSL)

I haven't lost my mind...
   ...it's backed up on a tape somewhere.



From mm at dorfdsl.de  Sun Sep  1 07:55:26 2024
From: mm at dorfdsl.de (Marco Moock)
Date: Sun, 1 Sep 2024 07:55:26 +0200
Subject: Signing (and Encrypting) Mails with gpg like DKIM
In-Reply-To: <41e19c78-20ad-47df-b607-fc63bf7b3718@longlandclan.id.au>
References: <e692b965dc9f391cee92daf1c8eab40b@mail.emailn.de>
 <6df9205d-045c-411e-be2d-e6532fd6cf49@longlandclan.id.au>
 <20240901074225.2cc2e28f@dorfdsl.de>
 <41e19c78-20ad-47df-b607-fc63bf7b3718@longlandclan.id.au>
Message-ID: <20240901075526.13a1add7@dorfdsl.de>

Am 01.09.2024 um 15:51:57 Uhr schrieb Stuart Longland:

> Given the public key is published in DNS records, could you imagine
> the hot mess that'd create for domains with lots of users?  Either
> lots of DNS records, or lots of users sharing the same private key.

Is there a limit for DNS records?
I don't see a problem here, especially if they are provisioned in an
automatic way.

-- 
Gru?
Marco


From stuartl at longlandclan.id.au  Sun Sep  1 08:17:59 2024
From: stuartl at longlandclan.id.au (Stuart Longland)
Date: Sun, 1 Sep 2024 16:17:59 +1000
Subject: Signing (and Encrypting) Mails with gpg like DKIM
In-Reply-To: <20240901075526.13a1add7@dorfdsl.de>
References: <e692b965dc9f391cee92daf1c8eab40b@mail.emailn.de>
 <6df9205d-045c-411e-be2d-e6532fd6cf49@longlandclan.id.au>
 <20240901074225.2cc2e28f@dorfdsl.de>
 <41e19c78-20ad-47df-b607-fc63bf7b3718@longlandclan.id.au>
 <20240901075526.13a1add7@dorfdsl.de>
Message-ID: <1da1b417-04c7-4d5b-bd12-b90b730c3573@longlandclan.id.au>

[Re-send with correct from: address? apologies to the moderators for the 
noise]

On 1/9/24 15:55, Marco Moock via Gnupg-users wrote:
> Is there a limit for DNS records?

In theory, probably not.  In practice, most definitely, especially if 
you don't "own" the DNS server.

> I don't see a problem here, especially if they are provisioned in an
> automatic way.

Again, not everyone has that luxury.  There exist many web hosting 
providers whose only means of updating DNS is a crummy web application. 
CheaperDomains for example does this, and allows just 4 TXT records.

https://community.cloudflare.com/t/dns-record-limit/169997 suggests a 
limit of 1000 records for CloudFlare for example (and its import 
instructions limit the zone file to 256KiB).
-- 
Stuart Longland (aka Redhatter, VK4MSL)

I haven't lost my mind...
   ...it's backed up on a tape somewhere.


From hfollmann at itcfollmann.com  Sun Sep  1 10:07:19 2024
From: hfollmann at itcfollmann.com (Henning Follmann)
Date: Sun, 1 Sep 2024 04:07:19 -0400
Subject: Signing (and Encrypting) Mails with gpg like DKIM
In-Reply-To: <1da1b417-04c7-4d5b-bd12-b90b730c3573@longlandclan.id.au>
References: <1da1b417-04c7-4d5b-bd12-b90b730c3573@longlandclan.id.au>
Message-ID: <271E02CF-5198-4523-A6BA-5A4639B10C3F@itcfollmann.com>



> On Sep 1, 2024, at 02:18, Stuart Longland via Gnupg-users <gnupg-users at gnupg.org> wrote:
> 
> ?[Re-send with correct from: address? apologies to the moderators for the noise]
> 
>> On 1/9/24 15:55, Marco Moock via Gnupg-users wrote:
>> Is there a limit for DNS records?
> 
> In theory, probably not.  In practice, most definitely, especially if you don't "own" the DNS server.
> 
>> I don't see a problem here, especially if they are provisioned in an
>> automatic way.
> 
> Again, not everyone has that luxury.  There exist many web hosting providers whose only means of updating DNS is a crummy web application. CheaperDomains for example does this, and allows just 4 TXT records.
> 
> https://community.cloudflare.com/t/dns-record-limit/169997 suggests a limit of 1000 records for CloudFlare for example (and its import instructions limit the zone file to 256KiB).
> --
> 

And on top of that you need the unprotected private key for each user. 
That is probably a bad idea.

-H

From andrewg at andrewg.com  Sun Sep  1 12:24:40 2024
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Sun, 1 Sep 2024 11:24:40 +0100
Subject: Signing (and Encrypting) Mails with gpg like DKIM
In-Reply-To: <e692b965dc9f391cee92daf1c8eab40b@mail.emailn.de>
References: <e692b965dc9f391cee92daf1c8eab40b@mail.emailn.de>
Message-ID: <ABE99A3F-63E6-4302-879D-5F41A1A646D3@andrewg.com>

On 31 Aug 2024, at 23:35, T. S. <tfasnetamot at emailn.eu> wrote:
> 
> Hello,
> 
> after looking into DKIM details, I started searching, why the same procedure cannot be used for gpg?
> With gpg a lot of people from get confused, when they receive signed mails either because of the -----BEGIN PGP SIGNED MESSAGE----- strings, or because the unknown attachments in MIME message.
> 
> When now looking to DKIM, this looks much more advanced. There is a Header in the mail, containing the signature all details to the signature and information about header items included in the signature:
<snip>
> Is somethings similar available for GPG/PGP?
> 
> Currently I found nothing, but I expect that this could help for much better acceptance for signed mails.  Receivers, who don't know anything about gpg getting not confused, as the Header is totally invisible.
> With such an implementation I would start again sending all my mails automatically signed, as I have not longer to answer questions about my weird looking mails.

You?re essentially talking about defining a new cleartext signing mechanism, so that people using PGP-unaware mail clients can remain blissfully unaware, while also allowing for a graceful upgrade to signed mail for those who can.

Unfortunately, history has taught us that any cleartext sent over email *will* be mangled, and this will break the signature. MTAs are in general really bad at preserving the content of email messages. The only reliable way we know of to protect your signed plaintext is to encode it in something more robust, such as base64. Even then, if it is encoded as a base64 MIME part, MTAs have been known to mangle the MIME headers, which breaks the signature. And if you don?t sign over the MIME headers, your email is dangerously malleable (see efail). 

So for the foreseeable future at least, it seems you can have trustworthy signed emails or you can have backwards-compatible cleartext signing, but not both. 

A
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20240901/73643277/attachment.html>

From mm at dorfdsl.de  Mon Sep  2 06:49:37 2024
From: mm at dorfdsl.de (Marco Moock)
Date: Mon, 2 Sep 2024 06:49:37 +0200
Subject: Signing (and Encrypting) Mails with gpg like DKIM
In-Reply-To: <e692b965dc9f391cee92daf1c8eab40b@mail.emailn.de>
References: <e692b965dc9f391cee92daf1c8eab40b@mail.emailn.de>
Message-ID: <20240902064937.43bfc02b@zbook>

Am Sat, 31 Aug 2024 18:29:17 +0200
schrieb "T. S." <tfasnetamot at emailn.eu>:

> If someone could provide me with information, if such header
> implementations are already somewhere discussed, I would be glad.

I've now seen an implementation for signing control messages for Usenet:

ftp://ftp.isc.org/usenet/control/hispagatos/hispagatos.hacking.exploits.gz


MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="signcontrol"
Content-Transfer-Encoding: 8bit
X-PGP-Sig: GnuPG_v2 Subject,Control,Message-ID,Date,Injection-Date,From
        iQHIBAABCAAyFiEE/G5Aphyycx8BqrxkqP6aHcFxsyAFAmbRFmYUHG5ld3NAaGlz
        cGFnYXRvcy5vcmcACgkQqP6aHcFxsyDlYAwAuEZAjR7V/k9e73rkONzMAS24HWeQ
        6l5hraveKcUQKpvWu3BxQ5iVn2rxEixbHqsUi7CTXHThYGc85s0veqCTROE8AVC2
        11fSd0sQVz/1Gq2/Us/Dk3E6yttGEnJhBGsftQ/+BnTyhZ7Nr2iPUtBgZ8/B21B6
        Se9e0DJUozyFO/dLjSrd73aoMNW0p3Ay+jqvA0zO01lhrSkVRoqRggyIbZYRSiWX
        UkajMq5LglfVbWDhnT59p6D4tJBtVCYfDxBVMNN21ERFPy19pVhxgjjBgqf5OKZi
        Xu0dfruQcLDGhVuVH71gDc0TWC5gYzNKM46hZndPWrpx+IyAWJ/RwK2fsBNzNOpF
        Fc7RGKbKx7xdMX8ICHcSKxJzjBAYWw032ybWejodTl6C2ytqnDBbvrCMueZpoN1I
        NtWdPDflgapCtSL66I6JEV/HeaPVE8ZX5W2TRLPP67uTzfrmU03y2AW0VKQC77gb
        0F5Uxka7ThKOv64WgQcukidfaWBmeA3nGw49
        =tU9d


From wk at gnupg.org  Mon Sep  2 09:00:53 2024
From: wk at gnupg.org (Werner Koch)
Date: Mon, 02 Sep 2024 09:00:53 +0200
Subject: Signing (and Encrypting) Mails with gpg like DKIM
In-Reply-To: <e692b965dc9f391cee92daf1c8eab40b@mail.emailn.de> (T. S.'s
 message of "Sat, 31 Aug 2024 18:29:17 +0200")
References: <e692b965dc9f391cee92daf1c8eab40b@mail.emailn.de>
Message-ID: <87wmju7d5m.fsf@jacob.g10code.de>

On Sat, 31 Aug 2024 18:29, T. S. said:

> either because of the -----BEGIN PGP SIGNED MESSAGE----- strings, or because
> the unknown attachments in MIME message.

Don't use those legacy inline PGP encryption.  Use PGP/MIME, a 28 year
old standard (RFC-2015).  You should give that unnamed attachment a
name, for example

  Content-Type: application/pgp-signature;
           name="openpgp-digital-signature.asc"

which clearly shows what kind of attachment this is.

> When now looking to DKIM, this looks much more advanced. There is a Header in
> the mail, containing the signature all details to the signature and

<the_usual_rant> You may want to go back to the year ~2000 when DKIM was
first presented at the IETF in Paris.  It was then a quick hack from the
sendmail authors and it took only a few hours until an attack on this
was found.  DKIM also broke with the long standing rule of being able to
work in a pipeline (iirc, this is called an online algo these days).
Instead of doing all that DKIM stuff it would have been easier to
directly use S/MIME or PGP/MIME and include copies of important headers
in a signed attachment.  But well, attachments are ugly for some people.
</>



Salam-Shalom,

   Werner

-- 
The pioneers of a warless world are the youth that
refuse military service.             - A. Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openpgp-digital-signature.asc
Type: application/pgp-signature
Size: 247 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20240902/2f04bcc9/attachment.sig>

From jb-gnumlists at wisemo.com  Wed Sep  4 14:33:28 2024
From: jb-gnumlists at wisemo.com (Jakob Bohm)
Date: Wed, 4 Sep 2024 14:33:28 +0200
Subject: Signing (and Encrypting) Mails with gpg like DKIM
In-Reply-To: <271E02CF-5198-4523-A6BA-5A4639B10C3F@itcfollmann.com>
References: <1da1b417-04c7-4d5b-bd12-b90b730c3573@longlandclan.id.au>
 <271E02CF-5198-4523-A6BA-5A4639B10C3F@itcfollmann.com>
Message-ID: <8601fff5-27bb-8e3f-d1ef-0f249d1de5db@wisemo.com>

On 2024-09-01 10:07, Henning Follmann wrote:
>
>> On Sep 1, 2024, at 02:18, Stuart Longland via Gnupg-users <gnupg-users at gnupg.org> wrote:
>>
>> ?[Re-send with correct from: address? apologies to the moderators for the noise]
>>
>>> On 1/9/24 15:55, Marco Moock via Gnupg-users wrote:
>>> Is there a limit for DNS records?
>> In theory, probably not.  In practice, most definitely, especially if you don't "own" the DNS server.
>>
>>> I don't see a problem here, especially if they are provisioned in an
>>> automatic way.
>> Again, not everyone has that luxury.  There exist many web hosting providers whose only means of updating DNS is a crummy web application. CheaperDomains for example does this, and allows just 4 TXT records.
>>
>> https://community.cloudflare.com/t/dns-record-limit/169997 suggests a limit of 1000 records for CloudFlare for example (and its import instructions limit the zone file to 256KiB).
>> --
>>
> And on top of that you need the unprotected private key for each user.
> That is probably a bad idea.
Not anymore than for any other signing.? In particular, only automated
server-side signing would need (somewhat) unprotected key access.
Signing in the MUA asdiscussed above could protect the key in a GPG
card, but is entirely hypotheticaland antithetical to the idea of DKIM.

Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded



From jb-gnumlists at wisemo.com  Wed Sep  4 14:41:38 2024
From: jb-gnumlists at wisemo.com (Jakob Bohm)
Date: Wed, 4 Sep 2024 14:41:38 +0200
Subject: Signing (and Encrypting) Mails with gpg like DKIM
In-Reply-To: <87wmju7d5m.fsf@jacob.g10code.de>
References: <e692b965dc9f391cee92daf1c8eab40b@mail.emailn.de>
 <87wmju7d5m.fsf@jacob.g10code.de>
Message-ID: <a2febef6-623f-f03a-d4fd-10e5d1e0f19f@wisemo.com>

On 2024-09-02 09:00, Werner Koch via Gnupg-users wrote:
> On Sat, 31 Aug 2024 18:29, T. S. said:
>
>> either because of the -----BEGIN PGP SIGNED MESSAGE----- strings, or because
>> the unknown attachments in MIME message.
> Don't use those legacy inline PGP encryption.  Use PGP/MIME, a 28 year
> old standard (RFC-2015).  You should give that unnamed attachment a
> name, for example
>
>    Content-Type: application/pgp-signature;
>             name="openpgp-digital-signature.asc"
>
> which clearly shows what kind of attachment this is.
>
>> When now looking to DKIM, this looks much more advanced. There is a Header in
>> the mail, containing the signature all details to the signature and
> <the_usual_rant> You may want to go back to the year ~2000 when DKIM was
> first presented at the IETF in Paris.  It was then a quick hack from the
> sendmail authors and it took only a few hours until an attack on this
> was found.  DKIM also broke with the long standing rule of being able to
> work in a pipeline (iirc, this is called an online algo these days).
> Instead of doing all that DKIM stuff it would have been easier to
> directly use S/MIME or PGP/MIME and include copies of important headers
> in a signed attachment.  But well, attachments are ugly for some people.
> </>
Using S/MIME for server to server protection would involve heavy mangling
of mail bodies, unlike the header-only placement of DKIM signatures.? It
is true that DKIM generation and validation needs the entire mail in some
kind of storage, such as the mail spool of a resend-capable MTA, which is
a key reliability requirement for non-spam mail servers anyway.

As a mail admin I see a lot of buggy 3rd party mail servers built by rather
large companies, but the traditional line mangling so common before MIME
seems a thing of the past, while Base64 encoding mail bodies has become
the realm of buggy software and/or spam (I happen to use such a buggy big
name SMTP library for mailing webshop receipts etc.)

Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded



From andrewg at andrewg.com  Wed Sep  4 15:05:28 2024
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Wed, 4 Sep 2024 14:05:28 +0100
Subject: Signing (and Encrypting) Mails with gpg like DKIM
In-Reply-To: <a2febef6-623f-f03a-d4fd-10e5d1e0f19f@wisemo.com>
References: <e692b965dc9f391cee92daf1c8eab40b@mail.emailn.de>
 <87wmju7d5m.fsf@jacob.g10code.de>
 <a2febef6-623f-f03a-d4fd-10e5d1e0f19f@wisemo.com>
Message-ID: <FD3723E3-3979-4D67-8F50-91C3B8AD8AB7@andrewg.com>

On 4 Sep 2024, at 13:41, Jakob Bohm via Gnupg-users <gnupg-users at gnupg.org> wrote:
> 
> As a mail admin I see a lot of buggy 3rd party mail servers built by rather
> large companies, but the traditional line mangling so common before MIME
> seems a thing of the past,

As I mentioned already in an (accidental) off-list message to the OP, I have one regular correspondent who sees my signatures as broken if I send email from my laptop, because some as yet unknown MTA on the path between us is normalising a double newline into a single newline between the MIME headers of the inner multipart and the inner MIME plaintext part. I?m sure I?m not the only person to experience this.

A

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20240904/6e8bf717/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20240904/6e8bf717/attachment.sig>

From dkg at fifthhorseman.net  Thu Sep  5 17:04:23 2024
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Thu, 05 Sep 2024 11:04:23 -0400
Subject: Signing Mails with OpenPGP like DKIM [was: gpg like DKIM]
In-Reply-To: <FD3723E3-3979-4D67-8F50-91C3B8AD8AB7@andrewg.com>
References: <e692b965dc9f391cee92daf1c8eab40b@mail.emailn.de>
 <87wmju7d5m.fsf@jacob.g10code.de>
 <a2febef6-623f-f03a-d4fd-10e5d1e0f19f@wisemo.com>
 <FD3723E3-3979-4D67-8F50-91C3B8AD8AB7@andrewg.com>
Message-ID: <87jzfqw39k.fsf@fifthhorseman.net>

On Wed 2024-09-04 14:05:28 +0100, Andrew Gallagher via Gnupg-users wrote:

> As I mentioned already in an (accidental) off-list message to the OP,
> I have one regular correspondent who sees my signatures as broken if I
> send email from my laptop, because some as yet unknown MTA on the path
> between us is normalising a double newline into a single newline
> between the MIME headers of the inner multipart and the inner MIME
> plaintext part. I?m sure I?m not the only person to experience this.

I think that's me!  We should really try to debug that further at some
point, Andrew, but not at the risk of distracting from or delaying any
of the many other projects we're collaborating on at the moment ?

Back to the topic at hand: it seems like there are several orthogonal
questions that are being discussed in this thread, and it would be best
to tease them apart if anyone wants to make progress.  I *do* think
progress is achievable here and might be worthwhile on at least some
of these ideas, but it would happen on a matter of years, not months.

Let's break out the distinct things that people might want from "using
OpenPGP like DKIM"

? Who is doing the DKIM signing?  DKIM signatures are typically done by
  the server (the MTA), but this thread includes some discussion about
  them being done by the user (the MUA).  The *recipient* of course,
  can't tell whether the DKIM signing key is held by the MUA or the MTA,
  so this doesn't really give the recipient any clear end-to-end
  assurances.  I'm personally not that interested in the idea of giving
  DKIM signing keys to end users, but this is one possible project.

? Doing something DKIM-like, but for encryption: i don't think this is a
  coherent goal.  DKIM is signatures-only, and trying to repurpose it
  for encryption doesn't make sense.

? Putting end-user OpenPGP certificates in the DNS: this one is already
  done!  See RFC 7929 (https://datatracker.ietf.org/doc/html/rfc7929)

? Creating a new structure for signed-only mail that would be capable of
  improving on (and at some point supplanting) PGP/MIME
  multipart/signed: This is where i think it gets interesting.  If you
  want to pursue this, i'd recommend identifying the specific flaws of
  PGP/MIME multipart/signed that you want to ameleiorate, and the
  tradeoffs that you're willing to accept to fix them.  You probably
  want to find a proper venue for discussion (e.g. The IETF OpenPGP or
  LAMPS or perhaps MAILMAINT lists).

  I would avoid trying to mix this mechanism into encrypted+signed mail,
  as we already have standards for doing that safely that don't have the
  drawbacks that multipart/signed has.

  I think you could specify such a mechanism relatively quickly if you
  make use of existing DKIM message canonicalization rules and header
  structure (but without calling it "DKIM") and replacing the DKIM
  signature blob with a base64-encoded binary OpenPGP signature object.

  You'd want to make sure that all of the headers applied by the sending
  MUA are included in the signature, so that you don't cause a
  regression from draft-ietf-lamps-header-protection mechanisms.

  And you'd need to recruit a few MUA developers who would be willing to
  verify signatures structured in this way, and to be capable of
  producing them.

  And finally, you'd need to think about the UX concerns: should the end
  user be responsible for selecting which kind of signed-only message to
  produce?  I don't think that's a reasonable question to ask of end
  users, who just want to send mail.  Do you need a
  signalling/negotiation mechanism so that MUAs can automatically choose
  the "best" signing format for any given outbound message?  Or can you
  frame the tradeoffs such that a MUA can at some point just
  unilaterally choose to emit the new format and be confident that their
  signed-only messages will be acceptable?

  Such a deployment would probably be helped along by leaning into
  recommendation (common to both DKIM and to
  draft-ietf-lamps-e2e-mail-guidance) that a message with a broken
  signature be presented in no more scary a form than a message with no
  signature whatsoever.


If you're interested in doing this kind of work but have never done
interoperable standardization before, i'd be happy to give you some
pointers and help nudge this along where i can.  This has been on my
list of things to clean up in the ecosystem for a while, and it just
needs someone to drive it forward.

      --dkg

PS for the record, i think there is one major concern about PGP/MIME
   multipart/signed: for users of MUAs that don't understand PGP/MIME,
   the signature shows up as a mystery attachment.  I can't tell you the
   number of times that i get a response from a colleague that says "i
   can't open your attachment, please re-send".  That happens often
   enough that i deliberately do not sign mail unless i know the
   recipient won't do that.  That means i don't sign most of my mail,
   which means i can't expect anyone to expect that all my mail will be
   signed.  If a mechanism like this was available, and especially if it
   didn't automatically cause warnings on the receiving end when the
   signature failed to validate, i'd use it to sign *all* of my
   cleartext mail.  Once i am comfortable signing all of my cleartext
   mail, i would be happy to start opting into something like
   https://datatracker.ietf.org/doc/draft-dkg-lamps-expect-signed-mail/

   This is a multi-stage process to get to the point where at least some
   people can have robust e2e cryptographic authenticity protections for
   their mail, but i think the work described above would be a great
   start.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 324 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20240905/ea1a7f40/attachment.sig>

From wk at gnupg.org  Fri Sep  6 11:26:30 2024
From: wk at gnupg.org (Werner Koch)
Date: Fri, 06 Sep 2024 11:26:30 +0200
Subject: [Feature request] Please make it easier to check
 success/failure from scripts
In-Reply-To: <4a38f4e8-783e-4bf0-8e2d-20558291bb84@wisemo.com> (Jakob Bohm via
 Gnupg-users's message of "Tue, 27 Aug 2024 17:37:03 +0200")
References: <4a38f4e8-783e-4bf0-8e2d-20558291bb84@wisemo.com>
Message-ID: <87wmjpb0ah.fsf@jacob.g10code.de>

Hi!

On Tue, 27 Aug 2024 17:37, Jakob Bohm said:

> status-fd output for a multitude of situation specific strings.?
> Sometimes it is even necessary to check if the expected signing key is
> mentioned in specific ways.

Right.  That is because there are a lot of use cases for signatures
which required different handling depending on the signature (e.g. time
created) and meta data from the key.

For OpenPGP we wrote gpgv to handle one common task; which was
originally Debian package signing.

Only recently we added --assert-signer to gpg which actually can replace
gpgv.  The plan is to add a few other --assert options for example to
check the time the signature was made.

> I know this because I have a script that uses gpgsm to do pipelined
> check of a large CMS signed system log, which is signed by the server
> to prevent later malicious changes.? gpgsm is used because of its
> specific support for streamed processing.

Cool.  I didn't expected that someone really has this use case.  But it
makes sense.  See T7286: Add --assert-signer also to gpgsm.

> Another, related, feature would be the ability to run the gnupg tools
> in a mode that doesn't talk to any part of the environment, neither
> the gnupg config dir, nor the various helper programs (directory,
> password prompt etc.), but instead acts predicatably based only on the
> command line options.

That is too hard to implement.  We have keys, trust models, ownertrust,
and compliance modes which is quite some data.  For this it is better to
use a separate GNUPGHOME.  The --assert-signer requires a fingerprint or
the list of fingerprints and thus the import of the to-be-tested keys
prior to running a verification.  It might be possible to combine the
import and the verification and even make the imported keys ephemeral
so that they don't clutter the keyring.  However, some file system write
access will be required unless we can find a way to keep the keys in a
memory only database.  A RAM based file system and ephemeral storage of
keys would be an easier solution.


Shalom-Salam,

   Werner


-- 
The pioneers of a warless world are the youth that
refuse military service.             - A. Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openpgp-digital-signature.asc
Type: application/pgp-signature
Size: 247 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20240906/aa268f49/attachment.sig>

From wk at gnupg.org  Fri Sep  6 14:00:53 2024
From: wk at gnupg.org (Werner Koch)
Date: Fri, 06 Sep 2024 14:00:53 +0200
Subject: Signing Mails with OpenPGP like DKIM
In-Reply-To: <87jzfqw39k.fsf@fifthhorseman.net> (Daniel Kahn Gillmor via
 Gnupg-users's message of "Thu, 05 Sep 2024 11:04:23 -0400")
References: <e692b965dc9f391cee92daf1c8eab40b@mail.emailn.de>
 <87wmju7d5m.fsf@jacob.g10code.de>
 <a2febef6-623f-f03a-d4fd-10e5d1e0f19f@wisemo.com>
 <FD3723E3-3979-4D67-8F50-91C3B8AD8AB7@andrewg.com>
 <87jzfqw39k.fsf@fifthhorseman.net>
Message-ID: <87seudat56.fsf_-_@jacob.g10code.de>

On Thu,  5 Sep 2024 11:04, Daniel Kahn Gillmor said:

> PS for the record, i think there is one major concern about PGP/MIME
>    multipart/signed: for users of MUAs that don't understand PGP/MIME,
>    the signature shows up as a mystery attachment.  I can't tell you the

See 
GpgOL: Add filenames for PGP/MIME parts
https://dev.gnupg.org/T4258

on how to solve that.  Complaints about strange attachments dropped to
nearly zero after we deployed that change 5 years ago.


Salam-Shalom,

   Werner

-- 
The pioneers of a warless world are the youth that
refuse military service.             - A. Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openpgp-digital-signature.asc
Type: application/pgp-signature
Size: 247 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20240906/7983ecd2/attachment.sig>

From dkg at fifthhorseman.net  Fri Sep  6 16:00:09 2024
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Fri, 06 Sep 2024 10:00:09 -0400
Subject: Signing Mails with OpenPGP like DKIM
In-Reply-To: <87seudat56.fsf_-_@jacob.g10code.de>
References: <e692b965dc9f391cee92daf1c8eab40b@mail.emailn.de>
 <87wmju7d5m.fsf@jacob.g10code.de>
 <a2febef6-623f-f03a-d4fd-10e5d1e0f19f@wisemo.com>
 <FD3723E3-3979-4D67-8F50-91C3B8AD8AB7@andrewg.com>
 <87jzfqw39k.fsf@fifthhorseman.net> <87seudat56.fsf_-_@jacob.g10code.de>
Message-ID: <877cbox4pi.fsf@fifthhorseman.net>

On Fri 2024-09-06 14:00:53 +0200, Werner Koch wrote:
> See 
> GpgOL: Add filenames for PGP/MIME parts
> https://dev.gnupg.org/T4258
>
> on how to solve that.  Complaints about strange attachments dropped to
> nearly zero after we deployed that change 5 years ago.

This is a great idea, and certainly an improvement over an unnamed MIME
part.  That said, i suspect you have a more technical userbase than the
pool of people i correspond with.

Receiving an uninterpretable attachment named
"openpgp-digital-signature.asc" or "smime.p7s" would get me responses
like "what's an .asc file?" or "I don't know how to open a .p7s file!"
or "what does openpgp-digital-signature have to do with [subject of
message]?"

The less visible the signature is for people who can't use it, the
better.

           --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 324 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20240906/3bf0979e/attachment-0001.sig>

From wk at gnupg.org  Fri Sep  6 18:10:54 2024
From: wk at gnupg.org (Werner Koch)
Date: Fri, 06 Sep 2024 18:10:54 +0200
Subject: Signing Mails with OpenPGP like DKIM
In-Reply-To: <877cbox4pi.fsf@fifthhorseman.net> (Daniel Kahn Gillmor via
 Gnupg-users's message of "Fri, 06 Sep 2024 10:00:09 -0400")
References: <e692b965dc9f391cee92daf1c8eab40b@mail.emailn.de>
 <87wmju7d5m.fsf@jacob.g10code.de>
 <a2febef6-623f-f03a-d4fd-10e5d1e0f19f@wisemo.com>
 <FD3723E3-3979-4D67-8F50-91C3B8AD8AB7@andrewg.com>
 <87jzfqw39k.fsf@fifthhorseman.net>
 <87seudat56.fsf_-_@jacob.g10code.de>
 <877cbox4pi.fsf@fifthhorseman.net>
Message-ID: <87o750bw4x.fsf@jacob.g10code.de>

On Fri,  6 Sep 2024 10:00, Daniel Kahn Gillmor said:

> part.  That said, i suspect you have a more technical userbase than the
> pool of people i correspond with.

ROFL

-- 
The pioneers of a warless world are the youth that
refuse military service.             - A. Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openpgp-digital-signature.asc
Type: application/pgp-signature
Size: 247 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20240906/64acf376/attachment.sig>

From steffen at sdaoden.eu  Fri Sep  6 21:17:36 2024
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Fri, 06 Sep 2024 21:17:36 +0200
Subject: Signing Mails with OpenPGP like DKIM
In-Reply-To: <87o750bw4x.fsf@jacob.g10code.de>
References: <e692b965dc9f391cee92daf1c8eab40b@mail.emailn.de>
 <87wmju7d5m.fsf@jacob.g10code.de>
 <a2febef6-623f-f03a-d4fd-10e5d1e0f19f@wisemo.com>
 <FD3723E3-3979-4D67-8F50-91C3B8AD8AB7@andrewg.com>
 <87jzfqw39k.fsf@fifthhorseman.net> <87seudat56.fsf_-_@jacob.g10code.de>
 <877cbox4pi.fsf@fifthhorseman.net> <87o750bw4x.fsf@jacob.g10code.de>
Message-ID: <20240906191736.7MrPzlzy@steffen%sdaoden.eu>

Werner Koch via Gnupg-users wrote in
 <87o750bw4x.fsf at jacob.g10code.de>:
 |On Fri,  6 Sep 2024 10:00, Daniel Kahn Gillmor said:
 |
 |> part.  That said, i suspect you have a more technical userbase than the
 |> pool of people i correspond with.
 |
 |ROFL

There is btw also Content-Description:.  (Depends on the mailer if
it is used it seems (superficial knowledge), but especially so if
filename is set as is in the patch.)
(I think of all this rather as a more political issue, anyway.)

--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 harish.chandrasekar16 at gmail.com  Sat Sep  7 19:52:34 2024
From: harish.chandrasekar16 at gmail.com (Harish Chandrasekar)
Date: Sat, 7 Sep 2024 23:22:34 +0530
Subject: PGP Linux OS Upgrade Issue
Message-ID: <CAMvz1jrOFsEAPNLHELwYsrP-GuOTBkY5YoyixtvPmdP8hVW4zQ@mail.gmail.com>

Hi,

Recently our servers were migrated from Linux REHL 7 to 9. We have PGP
encryption/decryption done as part of our apps using java which runs the
gpg command . The issue is after upgradation we have installed gnupg 2 2.3
v and pinentry 1.1 but 1st time when the script runs popup of passphrase is
displayed .(manually checked by running command in terminal since we were
reciving timout when run through application). How to stop this pop up
since passphrase is already part of the command.

gpg --homedir ~/.gnupg/ --batch --yes --no--tty --receipient <value>
--passphrase <value> --output <value> --decrypt --value

Googled and found couple of suggestions to add loopback entry in pgp.conf
and pgp-agent.conf. So have created files  under .gngpg and made entries as
well.Restarted the deamon. Nothing worked.


I would highly appreciate if anyone can help on this issue?


Regards,
C.Harish
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20240907/c531f529/attachment.html>

From dkg at fifthhorseman.net  Mon Sep  9 05:47:38 2024
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Sun, 08 Sep 2024 23:47:38 -0400
Subject: [Feature request] Please make it easier to check
 success/failure from scripts
In-Reply-To: <4a38f4e8-783e-4bf0-8e2d-20558291bb84@wisemo.com>
References: <4a38f4e8-783e-4bf0-8e2d-20558291bb84@wisemo.com>
Message-ID: <87wmjlv679.fsf@fifthhorseman.net>

On Tue 2024-08-27 17:37:03 +0200, Jakob Bohm via Gnupg-users wrote:
> Another, related, feature would be the ability to run the gnupg tools in 
> a mode that doesn't talk to any part of the environment, neither the 
> gnupg config dir, nor the various helper programs (directory, password 
> prompt etc.), but instead acts predicatably based only on the command 
> line options.

Given this request for statelessness, You might be interested in the
"stateless openpgp command line interface", or "sop", which is designed
in many ways for the types of operations you're talking about:

    https://datatracker.ietf.org/doc/draft-dkg-openpgp-stateless-cli/

(disclaimer: I've been shepherding the specification, but there are a
half-dozen high quality implementations in the wild and several more in
incubation)

For signature verification specifically, the "sopv" verification-only
subset is intended specifically to integrate well with other POSIX
commands.  A sopv implementation that wraps gpgv and handles all the
status-fd checking as documented is also available at:

    https://gitlab.com/dkg/sopv-gpgv

I see that you're using S/MIME and/or CMS (i.e. gpgsm) instead of the
OpenPGP equivalents, and i don't know that anyone has produced something
comparable for S/MIME or CMS, unfortunately.  But the rough shape of the
problem space is the same.  I'd be very surprised if you couldn't move
your administrative tooling over to using OpenPGP and making it work
successfully with any of the available sop implementations.

Regards,

        --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 324 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20240908/26718de8/attachment.sig>

From wk at gnupg.org  Mon Sep  9 15:13:07 2024
From: wk at gnupg.org (Werner Koch)
Date: Mon, 09 Sep 2024 15:13:07 +0200
Subject: [admin] This is a GnuPG related ML
In-Reply-To: <87wmjlv679.fsf@fifthhorseman.net> (Daniel Kahn Gillmor via
 Gnupg-users's message of "Sun, 08 Sep 2024 23:47:38 -0400")
References: <4a38f4e8-783e-4bf0-8e2d-20558291bb84@wisemo.com>
 <87wmjlv679.fsf@fifthhorseman.net>
Message-ID: <877cblas2k.fsf_-_@jacob.g10code.de>

Hi!

Just a short reminder that this mailing list's topic is GnuPG.

Advertisement for other applications, like a Python wrapper around a
long standing command line API (going all the way back to pgp 2), is
thus off-topic.  It feels more like a SEO strategy than as helpful
information.  Please don't confuse users; search engines already deliver
too much misinformation on best gpg practices.


Salam-Shalom,

   Werner

-- 
The pioneers of a warless world are the youth that
refuse military service.             - A. Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openpgp-digital-signature.asc
Type: application/pgp-signature
Size: 247 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20240909/59e2fcaf/attachment.sig>