I have read this thread at least up to this point. In my opinion, the Security Considerations section of a protocol RFC should, to some extent, view the larger picture including considerations not strictly encompassed by the protocol. If I were deciding, I would include an informational reference to DKIM because it is something that someone thinking about email security should consider. I see no need for this draft to say much of anything about the characteristics of DKIM or analyze how it fits into some bigger framework or the like. That should all be in DKIM documentation. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e3e3@xxxxxxxxx On Tue, Apr 1, 2025 at 11:44 PM Viktor Dukhovni <ietf-dane@xxxxxxxxxxxx> wrote: > > On Tue, Apr 01, 2025 at 02:24:04PM -0400, John Levine wrote: > > > That is of course a feature, not a bug, since DKIM wasn't intended for > > long-term verification, but I don't see why it's much different from > > anything else. If you want to verify an old S/MIME signature, you need > > a list of equally old CA certs. > > Mostly just the trust anchors, since the signature blob should include > any requisite intermediates, but the EE cert especially, and after a > while also the intermediates may well have expired (or even leaked, ...) > so one one also needs to set the clock back to ~time of receipt. But > all of that is wrong... > > What should really happen, is that MUAs should be re-encrypting S/MIME > and perhaps all mail under a per-message symmetric key on first read > That message-level key needs to be encrypted to the then current > (periodically rolled over KEK), with the KEK recoverable with a suitable > passphrase that should/can be kept offline. The encrypted on first read > message should attest to any signature validity *at time of* receipt. > > One of the harder problems is a secure encrypted search index. > > Anyway, no MUA really tackles encrypted mail adequately, so MUA-to-MUA > e2e-encrypted email that can be retained long-term, searched, validated > after the fact, ... is an unsolved problem. > > For many users, mail has moved to the web, and there is little to no > investment in MUAs. Apple removed support for S/MIME signing from > Mail.app some years ago. > > -- > Viktor. > > -- > last-call mailing list -- last-call@xxxxxxxx > To unsubscribe send an email to last-call-leave@xxxxxxxx -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
