EKR wrote: >>> >>> >> 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). >
Right. See below about weaker claims and the lack of a fully deployed PKI. It is designed primarily to scale to the level of a domain. > >> DKIM does NOT require >> DNSSEC. >> > > And S/MIME doesn't require PKI. > S/MIME has its own set of problems, which I won't rehash. > >> Deploying DNSSEC improves the security of DKIM in the face of >> DNS attacks. >> > > In the face of attacks which we know happen.... > In those places where that's important perhaps we'll see DNSSEC deployment, then. > > >>> 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. > I agree. > > >>> 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.. > The language was plainly used. You are, however, raising two separate issues: use of the term and whether reputation services are in scope. They are clearly not. However, that doesn't mean that DKIM cannot be used by such services, and it certainly doesn't mean that we must never refer to them. This having been said, I still believe the plain language reading connotes an obvious meaning. > 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. > Forensics != verification. > > >>> 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.... > While I could see how you could take this one sentence out of context and view it as poorly worded, let's agree that the author does not believe X.509 was implemented outside the notion of a directory. Let me suggest, therefore, that you propose wording to clarify. Eliot _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
