On 19 Aug 2025, at 20:57, John R Levine <[email protected]> wrote: > > On Tue, 19 Aug 2025, Andrew Gallagher wrote: >>> I see how you could use it to wrap S/MIME (that's CMS) but I still don't >>> see how you would wrap DKIM in any way that makes sense. >> >> To be clear, neither do we. This proposal does not operate at the same level >> of the stack as DKIM, >> and it does not target the same problem space as DKIM. It does however sign >> over (a subset of) the data that DKIM signs over, which is where the >> suggestion for (partial) alignment arises. > > But it seems to me you could say the same thing about PGP and S/MIME and I > don't know anyone trying to combine them even though they're semantically a > lot closer.
Our draft specifically permits combining PGP and S/MIME signatures over the same message, by adding multiple Sig headers. This would be useful for people whose correspondents are a mixture of PGP and S/MIME users, as it would allow a message to be generated once and be universally verifiable. It is something that we have considered as follow-up work, but it is not our current priority. > As I have said several times, the kinds of header changes that DKIM tries to > deal with are unlikely to happen to wrapped headers since no MTA I know looks > inside a MIME part for extra headers, so canonicalization isn't relevant. That is correct, however if a receiving MUA wishes to compare the inner and outer headers, such changes would need to be taken into account. > If that's the goal, it'd be a good idea to be clearer about what problem > you're trying to solve, keeping in mind that there is no promise that the > mutated message bears any relation to the original and one of our open > questions is whether there's a straightforward way to say how much change is > too much. Keeping the original headers inside the cryptographic part should allow them to be validated and rendered as the original sender intended, but there is a secondary problem where mailbox indexes might not be processed by the same code as the full message view - for example the index view might not validate the signature. If the subject line were to differ radically between the outer and inner parts, a user could be tricked into thinking that the subject displayed in the index was genuine, and not notice that the subject displayed in the full message was different. We would like to permit MUAs to detect this discrepancy and downgrade the security level of an otherwise successfully validated message, but without introducing excessive fragility. > So I still don't see any useful combination, which is why I keep saying if > you think this is useful, write a draft so other people can see what you are > proposing. It was suggested that we bring the current draft to the DKIM group to explore possibilities for alignment before redrafting. We will let you know when this process is complete. A
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
