On Fri, 2007-01-12 at 00:42 -0500, Barry Leiba wrote: > Eliot Lear said... > > I'd have to go further than what you wrote. I believe the document > > should explicitly discuss interactions with DKIM, as that document is in > > front of the IESG at this time for approval as a Proposed Standard. > > Many modifications to a message will invalidate a DKIM signature. It > > may be possible for an OPES agent to resign, but there are implications > > there too that should be discussed. > > I'm with Ted here: this is a very high-level document, not one that's > actually specifying the OPES SMTP "adaptation". Perhaps (just perhaps; > I'm not convinced of that either) the final adaptation specification > should talk about DKIM. But not this one. > > In particular, I'll note that there are many places where a mail message > can be modified today, in ways that break the DKIM signature -- in an > SMTP server, in a Sendmail milter, in a Sieve script, in a mailing-list > expander, and so on. Think of OPES in SMTP as a standardized version of > Sendmail milter (which would, I hope, fix some of the unfortunate > limitations of the latter). Sure, there are things it might do that > could invalidate DKIM signatures. And there are lots of things it might > do that won't. > > Apart from a note that says, "Changing the message might invalidate DKIM > signatures, so go look at the DKIM spec and make sure you understand > what you're doing," I don't see what some future OPES SMTP adaptation > document should do about this. And I certainly don't see what this > document should do about it. DKIM has other problems. DKIM mandates the From header be signed, but also severely limits the range of identities that can be associated with the signature. As such, DKIM breaks badly when signing headers that contain "<utf8@utf-8 [ascii@ascii]>" or <utf8@utf-8>. The "downgrade" process will remain with email, which then calls into question the practicality of mandating the signing of UTF-8 based upon a premise of visual recognition sans annotation. Had the DKIM signature permitted the capturing of the identity on who's behalf it was being applied without the restrictions, then not signing headers would remain far less problematic. Protection against spoofing _must_ depend upon some form of annotation anyway and an ability to associate one domain with another. DKIM, as currently envisioned, is not robust and mandates an impractical sharing of private keys or zone delegations as the _only_ means to link headers with signatures. Even confirming DKIM identities may soon require conversion to ACE labels. -Doug _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf