On 8/20/2025 11:34 AM, John R. Levine wrote:
On Wed, 20 Aug 2025, Murray S. Kucherawy wrote:
I have to find the specific sections, but I recall RFC 6376 talking
about
why client verification of signatures is not a great idea. Keys rotate,
for example, so long-term signature validation is not guaranteed to be
reliable. People who were around in the RFC 4871 days may remember
other
reasons why the general position was that this wasn't something worth
pursuing.
Client signing was clearly out of the question since there's no
reasonable way to manage the signing keys, so if they're not going to
sign it makes sense for them not to verify either.
I do not understand what the key management problem is that you are
referring to. I am guessing the issue has to do with multiple users
being able to access the same private key.
But, of course, there is nothing to prevent each user from having a
different private key, tied to different public key, tied to a different
selector. That sort of administrative freedom was one of the reasons
for have selectors.
Also, issues with signing are largely irrelevant to possible issues with
validation, given that the former is dealing with private/protected keys
and the later is dealing with very public keys.
Also, by that point we had realized that spam filtering works a lot
better in the MTA than in the MUA. It can look at lots of mail at
once, not just mail to one user, and have shared dynamically updated
criteria. You can still have per-user criteria, but they're applied
in the MTA so, among other things, all of the user's MUAs see the same
results.
Except there is nothing preventing having UAs share assessment data with
a common analysis engine.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
bluesky: @dcrocker.bsky.social
mast: @[email protected]
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
