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.
R's,
John
On Mon, 18 Aug 2025, Phillip Tao wrote:
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]
Regards,
John Levine, [email protected], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
