Show that an encrypted message was signed, without decrypting it

Stefan Claas stefanclaas at
Wed Oct 14 18:21:27 CEST 2020

On 2020-10-13 17:02, Daniel Kahn Gillmor via Gnupg-users wrote:
> On Sun 2020-10-11 09:59:12 +0200, Stefan Claas wrote:
>> Helmut Waitzmann Anti-Spam-Ticket.b.qc3c wrote:
>>> Yes, but why should she want to be able to do that?  She could
>>> decrypt the message and, if it turns out that the message is not
>>> signed, discard the message.
>> It would allow Alice (in her organization), or others, to do a
>> pre-check, with procmail etc., to set-up an auto-responder, informing
>> Bob that he did not signed his message and that his message will be
>> discarded.
> The traditional answer for supporting this kind of workflow for e-mail
> is called "triple-wrapping" -- see RFC 2634.  That is, there is an inner
> signature, then a layer of encryption, and an outer signature that is
> intended to be visible to the transport agents handling the encrypted
> message.  Those transport agents (or procmail, or autoresponders, or
> whatever) may may routing or handling decisions based on the outer
> signature without any knowledge of the inner signature.  However, i have
> not seen triple-wrapping in wide-spread, interoperable use.  Most MUAs i
> have experience with do not generate triple-wrapped messages, and i've
> found very few transport agents that interpret using them.  IIUC, the
> only triple-wrapping implementations out there use S/MIME cryptographic
> e-mail, not PGP/MIME.
> More common on today's e-mail interactions is "Domain-keyed Internet
> Mail" or DKIM -- see RFC 6376.  This is a cryptographic signature over
> the entire message that is typically added by the sender's relaying
> transport agent -- the first transport agent that handles the e-mail
> message.
> Subsequent transport agents can verify the DKIM signature using the DNS
> as a form of proof-of-origin (typically, this is managed at the domain
> level, though domain operators may carve up the "selector" space for
> outsourced transports, or may also permit users to manage their own
> selectors [0]).  This isn't exactly the same as an individual sending a
> message that is signed by the message origin, because DKIM signing tends
> to happen away from the originating endpoint.  But for spam abatement
> and reputational systems, knowing that a message is signed by the domain
> itself is often good enough in practice.
> [0]
> So there isn't really a good (or reasonable) way to do what you're
> asking for with OpenPGP directly.  Given that mail is a complicated
> interoperability space, you're probably better off conditioning your
> procmail filters or autoresponder based on DKIM signature validity
> (though i advise reading and understanding the associated DMARC
> specifications before choosing to aggressively reject mail).
> Hope this helps,

Thank you very much for your detailed reply, much appreciated!

P.S. already replied yesterday off-list and had deleted the message,
hence my short reply here.

Best regards

More information about the Gnupg-users mailing list