Apologies for starting this thread and not following up on. Thanks all for the discussion. A few things I wanted to address:
> On Aug 19, 2025, at 2:13 AM, John R Levine <[email protected]> wrote: > > Once again, please send a strawman so we have some idea what it is you are > proposing. I have looked at DKG's draft and I do not see any way to shoehorn > it into any flavor of DKIM. This is where I left off because I had planned to put some text together before responding again to this thread. But further discussion addressed a lot of my questions, so I apologize, but I still have no actual text to offer. I think most folks seem to understand the gist of what I proposed. > On Aug 19, 2025, at 11:45 AM, Kai Engert <[email protected]> wrote: > > In my understanding DKIM* and unobtrusive signatures will usually > be produced by different entities: > - unobtrusive signature is produced by a fat MUA or a webmail app > - DKIM* signature is produced by the initial MTA. > > The owners of the signature keys are usually different entities, the sending > user owns the e2e unobtrusive signature key, and the email administrator > controls the DKIM* signature key. Yep, I don't anticipate that to change. Even if the signers are different entities, it's somewhat plausible they could still use a shared library. > > DKIM* signatures are usually verified by the receiving MTA, not by the MUA. > Unobtrusive signatures will probably be verified by the MUA, not by the MTA. However, on the receiving end, there are MUAs today who already verify DKIM signatures, and who would may also be interested in verifying these unobtrusive signatures. > By using the currently porposed mechanism, which adds a MIME layer around the > inner message, we get a header section inside the body. This will also give > us a good place for adding extra headers that are relevant for end-to-end > security (for example key material) and that don't need to present at the > outer header section. By placing them into the inner section in the body, > only, we avoid increasing the outer header section further. Because there is > a maximum size for the outer header block, as I understand it, and because > future key material for post quantum cryptography might be big, being able to > move those extra headers into the body seems like a useful benefit. This is a good point. > As I understand it, the MIME structure we are suggesting is a core mechanism > of MIME that every application processing MIME must support, ignoring extra > layers and processing the data that's inside the extra layer? MUAs, unfortunately, do not always handle all legal MIME structures correctly, especially if they're not currently in common use. It's very likely that this structure is well supported by most existing MUAs, but even safer would be not modifying the MIME structure at all. > Does SML ever require multipart/mixed on the outermost layer and give that > special meaning? > > Does SML require that a specific part needs to be at the top level? > > Does SML state any requirements for nesting depth? > > If the answer to all questions is "no", hopefully there's no clash here. > > It seems that SML uses multipart/related and multipart/alternative. So > hopefully the additional outer multipart/mixed layer isn't a problem. There's been discussion about having a fairly strict MIME structure for a "full representation" message. Likely with a `multipart/alternative` at the top. > On Aug 19, 2025, at 3:30 PM, Andrew Gallagher > <[email protected]> wrote: > > Unobtrusive signatures should be compatible with DKIM2, but they should not > be dependent on it. It will be some time before DKIM2 is rolled out across > the internet, but MUAs can start generating unobtrusive signatures now. This is a very good point. I think ideally, there could be much that could be shared between the two, but the practical argument of not requiring DKIM2 adoption for unobtrusive signatures is very strong. > On Aug 19, 2025, at 7:29 PM, John R Levine <[email protected]> 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, I was not arguing for any changes to any implementations of DKIM*, solely in potentially refactoring parts of the spec so it could be shared. But in any case, I think you've repeatedly made the good point that it's hard to understand exactly what that would look like without a strawman draft. > On Aug 19, 2025, at 9:57 PM, John R Levine <[email protected]> wrote: > > There's been a great deal of confusion (not by you) between the outer headers > on a message and the copy wrapped inside a MIME part that this scheme signs. > 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. I think the confusion is I don't (didn't) see the duplication of sender-attached headers (resulting in "inner" and "outer" headers) as an inherent necessity of the design. There are absolutely headers attached by the sender that MTAs may alter (like Subject). > DKIM's key distribution is deliberately kind of weak because the signatures > are only intended to sign messages in transit and be looked at within a week > or two. (I realize that few people rotate keys and it's often possible to > check signatures a lot later, but that's not the intent.) Personally I don't > think it's a good idea to try to put PGP keys in the DNS, but if you want to > do that, RFC7929 says how you can do it. Right, that's fine. I don't think that's relevant to this discussion, though. > On Sep 17, 2025, at 9:43 PM, Daniel Kahn Gillmor <[email protected]> > wrote: > > This is the crucial bit that convinced me to move forward with the MIME > structure approach outlined in unobtrusive signatures. If there are > headers that are only meaningful to the recipient of an e2e context, > there's no reason to put them in the outer header section, which is > where the MTAs have traditionally done their work. > > Finally, there is an issue of development cadence. If unobtrusive > signatures are supposed to have the advantage of relying on DKIM2 > tooling, but that tooling isn't available, or is still in flux, it could > delay the process of deploying unobtrusive signatures. Or, if > unobtrusive signatures comes up with a requirement for > canonicalization/signing/signature transmission that wasn't a goal for > DKIM2, asking to change the DKIM2 outlines so that they align could > delay DKIM2 itself. > Yep, after all the discussion above, I think these are the two big points that really make a lot of sense to me for keeping these specs completely separate. - Phillip _______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
