Show that an encrypted message was signed, without decrypting it

Daniel Kahn Gillmor dkg at fifthhorseman.net
Tue Oct 13 19:02:24 CEST 2020


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] https://tools.ietf.org/html/rfc6376#section-3.1
    https://www.giovannimascellani.eu/dkim-for-debian-developers.html

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,

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


More information about the Gnupg-users mailing list