Signing Mails with OpenPGP like DKIM [was: gpg like DKIM]

[Daniel Kahn Gillmor]

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>