Eric
In other words, Eric, the logic that goes from DKIM to a CA is rather
circuitous. It contains some twists and choices.
Uh, sure, if you say so. The fact is that the document explicitly
suggests that it be secured via DNSSEC, so the path is nowhere
near as indirect as you suggest.
Actually, that text demonstrates the kind of mis-directed requirements placed on
the DKIM effort.
What should have been an exercise in writing a specific protocol has, instead,
been forced to make comments about other work. So, now, you are using a bit of
frankly pedagogical commentary as some sort of proof of normative inclusion.
(To say that something is "used", as you did about CAs, you are counting it as
part of the specification.)
This seems to be a particular pattern with anything that touches security and
perhaps accounts for the area's stellar record of creating successful
IETF work.
In any event, the fact that there is text that makes reference to DNSsec does
not change the logic problems I cited. By way of a legalistic demonstration of
this fact, I'll repeat that the language is not normative.
Again, for your assertion to be correct, you must count DKIM's scope of what it
"uses" as being everything that is in everything that DKIM touches, and maybe
even requiring that this inclusion recurse down, ad infinitum.
In fact if you are looking for the characteristic of craftiness that
is implied by the word disingenuous, then I'd be inclined to suggest
that it applies more to claiming that DKIM *does* use CAs than to
the claim that it does not.
Of course you would.
Not too happy about having the word disingenuous applied to the analysis you
posted?
Indeed, it is never pleasant to be the recipient of such labels about one's
intent, particularly when that use is both unfounded and inaccurate.
d/
--
Dave Crocker
Brandenburg InternetWorking
<http://bbiw.net>
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html