Replies inline. - Phillip
> On Aug 18, 2025, at 1:23 PM, John Levine <[email protected]> wrote: > > It appears that Phillip Tao <[email protected]> said: >> 1. Easier to implement - By sharing much of the underlying technology with a >> widely deployed (or rather, >> hopefully-soon-to-be-widely-deployed) authentication mechanism in DKIM2, it >> will be easier for both senders and receivers to adopt. >> Similarly, implementors do not have to worry about cases like the inner >> headers not matching outer headers. > > But, as I explained in the previous message, there is nothing to share. Perhaps I explained it badly. I'm saying that there may be parties which are interested in supporting both DKIM2 and these unobtrusive signatures. In which case, rather than having to support two entirely separate schemes, they could support a single scheme (or at least two very similar schemes), where the only significant difference is in how keys are distributed. There currently is nothing to share, but the proposal is to base the unobtrusive signatures off of DKIM2, so there _can_ be something to share. > The > headers for the unobtrusive signatures are inside a MIME part so they're > inside the > message body and do not get canonicalized by DKIM. What led to this design decision? Is there a reason that DKIM canonicalization should _not_ be applied to the headers for unobtrusive signatures? Or was that just an incidental result of repeating the headers inside the MIME part so that they can be signed at all? From the summary Kai linked, it _seems_ like the latter. > >> 2. Explicit compatibility with DKIM2 - Ideally, these signatures should not >> be broken by intermediate hops that conform to DKIM2's >> diff algebra. By explicitly sharing the same canonicalization and signing >> scheme as DKIM2, this would guarantee compatibility with the >> DKIM2 ecosystem. > > But the signatures are on a message mapped in a MIME part which will either > be there > or it won't. It is hard to imagine a realistic situation where there would > be a > change described by diff algebra that would affect the insides of the signed > MIME part. > >> 3. No MIME structure alteration - These signatures are meant to be >> "unobtrusive". Part of that to, IMO, is that there's absolutely no >> impact on how the message is treated by the receiving MTA and MUA, >> regardless of the MUA's support for this scheme. From the >> draft/DKG's presentation in Madrid, it seems like this draft has been fairly >> well tested already, and seems compatible. However, it's >> obviously infeasible to test all existing MUAs, not to mention future >> versions of MUAs. There's significantly less risk of errant MUA >> behavior if the actual message body does not need to have a different MIME >> structure to support this signature scheme. This also >> simplifies interaction with things like Structured Email, in which certain >> MIME structures signal certain cases. > > DKIM is, at least at the moment, oblivious to MIME. We've had some thoughts > about > signing MIME parts separately, but I still don't think that matters here > since the > DKIM2 signatures would be unrelated to the PGP signatures you're using. > >> DKIM signatures can sign other headers. For DKIM2, I believe there's a >> proposal to just always sign all headers. > > Perhaps, but since the headers you care about are inside a MIME part, it's > irrelevant. > > I am not opposed do doing things in a common way where it makes sense, but I > still do not see how these MIME > wrapped PGP signatures are like DKIM signatures other than that they use the > word "signature". 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. As I understand it, the goal is to 1: attach a signature so the message can be authenticated to a specific sender, and 2. be "unobtrusive" if it fails to validate (or the receiver cannot validate). PGP is used in the current draft, but S/MIME support could be easily added, or something else entirely. This is not significantly different from the goal of DKIM. The main difference is that DKIM authenticates to a domain, not a specific sender. However, regardless of the similarity or not of the goals, there's even more similarity in the technical requirements: * Both are intended to sign the entire body (as it existed at the time of signing), as well as most of the headers * Both are intended to not interfere with the presentation of a message * Both are intended to support multiple signers * Both are expected to be verifiable by the last "hop" (whether that be the last MTA or the MUA) On a technical level, I think there's a lot that could be shared, and it would benefit both standards if they're explicitly compatible with each other. > > R's, > John > > -- > mailmaint mailing list -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
