Comments inline. - Phillip
> On Aug 18, 2025, at 3:50 PM, John R Levine <[email protected]> wrote: > > >> 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. > > DKIM2 signs the whole message. The unobtrusive signatures are a wrapper > around PGP signatures which sign the body of the message, or in this case, a > body which is a wrapped copy of a message. I believe signing the headers is also a goal of unobtrusive signatures? The current draft says: 5.1. Always Use Header Protection A message signed with an unobtrusive signature MUST always use [I-D.ietf-lamps-header-protection], signing every header field known to the sending MUA at message composition time. 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]). > > There is no chance that DKIM2 is going to use PGP signing, so how about if > you go ask people if they'd be OK with unobtrusive signatures that are not > even sort of like PGP? I'm also not saying that DKIM2 should use PGP signing, or that unobtrusive signatures can't use PGP signing. I think the mechanism for how to normalize a message for signing, how to determine/communicate what is signed, and how to attach that signature to a message is largely independent of the cryptographic scheme. DKIM 2 can continue using its keys, unobtrusive signatures can continue using PGP keys. Unobtrusive signatures could also use S/MIME keys if there's appetite for that. The draft also seems to hold this position: It is specified initially for [OpenPGP], but can be easily extended to be used with [CMS] or other signature formats. > > R's, > John > > PS: > >> 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. 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. > > -- > 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]
