On 19 Aug 2025, at 00:25, Phillip Tao <[email protected]> wrote: > > The discussion at > https://www.openpgp.org/community/email-summit/2025/minutes/#cleartext-non-disturbing-signatures-in-headers-dkg > also implies that headers are expected to always be signed (with DKG > pointing out that DKIM style signing would also cover outer headers [or IMO, > there would be no need for "inner" headers]).
DKIM signing covers the outer headers, and e2e signing covers the inner headers. The first priority of any e2e signature scheme is to ensure that all the information signed over survives long enough to be verifiable in principle at the receiving end. Message-level outer headers do not necessarily survive remailers or noncompliant MTAs, but inner headers should be more robust. >>> First of all, I do not think these signatures need to be limited to PGP. >>> That's the specific technology that this idea came out of, but I think the >>> goal is more generalizable. >> >> It would be really helpful if you could get the authors of the current draft >> to write a strawman suggesting how that would work. It is my impression that >> they feel rather strongly about PGP. > > I believe Andrew and Kai have both been commenting on this thread. Please > jump in if I've misunderstood the motivation of the draft. You are correct, the goal is to robustly and transparently attach e2e signatures, of any kind, to a MIME structure. How these signatures are created and represented at the cryptographic level is secondary. We use OpenPGP as a concrete example because we are most familiar with it, and it is the one we intend to implement. The specification is intentionally open for any signature scheme to be used, we suggest CMS as a suitable alternative in the text but in principle you could use openssh or minisign signatures, if you were courageous enough. The “Sig” header is merely a vector for a signature; you can have as many “Sig” headers as you want, and there is no requirement that they all have to contain the same kind of signature. > The one thing I am saying that I think deviates from the current draft, is > that I think ensuring that this plays well with DKIM2 should be an explicit > goal. Very possibly the existing draft already accomplishes that (not totally > sure, since I find it a little harder to reason about two separate signing > mechanisms that have some interplay), but I think sharing some mechanical > pieces with DKIM2 guarantees that, and also provides some other benefits. DKIM2 alignment is not (yet?) explicitly mentioned in the draft, however we do wish to avoid any incompatibility with DKIM2, and if it were possible to align with, or even reuse portions of, the DKIM2 specification I think it would be a good idea. Full alignment is probably neither possible or desirable however, as the goals of the specifications differ. Thanks, A
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
