On Jan 13, 2011, at 2:41 AM, Charles Lindsey wrote: > On Wed, 12 Jan 2011 17:10:52 -0000, Dave CROCKER <[email protected]> wrote: > >> This raise a specific and interesting technical point. I haven't seen a >> response so far, so... > >> The core of this technology has keys that are named and accessed in >> terms of >> domain names. It really is fundamental to this technical approach. > > I don't see how that can be so. > > The fundamental core of this technology is a mechanism for contructing a > hash covering a named selection of headers and a body, coupled with some > canonicalization rules, and incorporating that into a signature header > using some well-known algorithm such as rsa (but allowing for others). > > The question of making the public key available is entirely orthogonal to > that core protocol. The DSN mechanism is fine for some applications, > especially where the lifetime of the signature is at most a few weeks. But > other means of publicising (and especially of authenticating) public keys > are also in widespread current use and there is nothing in the core > protocol that would prevent their use in other applications where they > were more suitable.
But if other ways of getting the public key are more suitable, what's left? The only thing DKIM does is allow a domain to assert responsibility for a message in a relatively cheap (if unreliable) way. If you take away the fundamental "You use this selector and this d= value in order to find the public key" then you're not left with much other than a quick-and-dirty canonicalization method that's tuned to the ways messages get corrupted in email transit. If someone wants to assert that the content of a message hasn't changed, and they're not dealing with the weird, very email-specific, constraints that DKIM is under (transparency to non-DKIM aware recipients, random body alterations en-route) then DKIM seems a fairly poor way of doing that, and there are several "real" public-key signing approaches that might better suited. > So DOSETA should provide for multiple plug-in key storage mechanisms in > just the same was as it provides for multiple plug-in canonicalizations. > By all means include the current DNS method as plug-in-key-management #1. What would be a good use case for DKIM-without-DNS? Cheers, Steve _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
