Eliot Lear <[EMAIL PROTECTED]> writes: > Hi Eric, > > I would generally agree with you about the enthusiasm of the document. > This is probably a good place for it, so long as it's accurate. I would > quibble with you on one point: >> >> o there is no dependency on the deployment of any new Internet >> protocols or services for public key distribution or revocation, >> >> I think this is a bit misleading. DKIM depends partly on DNSSEC >> for security, and that is not yet widely deployed. >> > > I believe the point Dave is trying to make is that you don't need to > deploy a huge infrastructure to deploy DKIM.
Well, in that case you could argue the same thing about S/MIME, which can work in opportunistic (only partly secure modes). > DKIM does NOT require > DNSSEC. And S/MIME doesn't require PKI. > Deploying DNSSEC improves the security of DKIM in the face of > DNS attacks. In the face of attacks which we know happen.... >> S 1.2.2 >> the basis for evaluating whether to trust the message for delivery. >> >> I'm not sure "trust" is a useful word here. >> > > The intent is to state that if you know who you're dealing with you can > decide how best to dispose of the message. That's fine, but trust is a word with a complicated history. >> The owner of the domain name being used for a DKIM signature is >> declaring that they are accountable for the message. This means that >> their reputation is at stake. >> >> I'm not sure I understand what reputation means in this context. >> > > I believe it would be pedantic to define a commonly used English word. I disagree. 1. It's a technical term in the security community, and since there's no reputation service being proposed.. 2. As I've pointed out before, manual forensics about who actually sent a message aren't really *that* difficult. Transmitting a message at all puts your reputation on the line--to the extent that sending spam damages your reputation. >> This claim strikes me as rather strange.... Remember that X.509 *was* >> intended to work with a directory, indeed The Directory (X.500). So, >> while it's certainly true that it's hard to get keys, it's not that >> the guys who designed it were somehow too stupid to know about >> directory systems. >> > > I read Dave's claim is to the contrary. They presumed a directory > infrastructure that in fact has proven difficult to widely deploy to the > level of the individual. Hmm... I don't read it that way. The beginning of 5.4 says: Unlike all four previous IETF email security initiatives, DKIM employs a key centric, directory based PKI as opposed to a certificate based PKI in the style of Kohnfelder (X.509) or Zimmerman (web of trust). Which seems to suggest that X.509 isn't directory-based. But as I noted, the original design certainly was.... -Ekr _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
