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.
signature.asc
Description: PGP signature
_______________________________________________ Gnupg-users mailing list [email protected] https://lists.gnupg.org/mailman/listinfo/gnupg-users
