S 1.1.
o there is no dependency on public and private key pairs being
issued by well-known, trusted certificate authorities,
This claims seems somewhat disingenuous.
It shouldn't. The statement is simply and directly accurate, as given.
The problem with the analysis you provided is that it conflates a dependency
that DKIM *does* have on the DNS, with the means that DNS might/will use to
provide acceptable service.
To pursue the line of concern you have raised, here are some simple questions:
1. Does DKIM specify anything that looks like a cert authority?
Answer: No.
2. Does DKIM require validity of the data produced by the DNS?
Answer: Yes.
3. Does the DNS provide reasonably good data validity today?
Answer: Yes
4. Is the current DNS vulnerable?
Answer: Yes
5. Are CA's required to fix this?
Answer: Maybe, but maybe not. Certainly that is the path being explored,
planned on, and maybe even slightly deployed. Other schemes might have been
feasible, but they aren't what has been defined.
In other words, Eric, the logic that goes from DKIM to a CA is rather
circuitous. It contains some twists and choices.
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.
Otherwise we have to use the same logic to say things like: You "use" Turkish
because you bought a product that was imported from Turkey.
S 3.3.
As noted previously by Russ, I think 512 keys are unwise.
Is there an immediate danger to using them, for the purpose for which DKIM is
intended to be used?
Has the use of 512 keys been banned from the current Internet?
Is that danger worse than the many other imperfect mechanisms being used on the
net?
Perhaps greater wisdom rests in providing alternatives, including the ability to
use existing packages today, with an eye towards agility on key size.
S 3.6.
DKIM keys do not require third party signatures by Certificate
Authorities in order to be trusted, since the public key is retrieved
directly from the signer.
Well, no, it's retrieved from the DNS server for the signer's
domain, which may or may not be the same thing.
It probably is worth making that distinction, if only to help remind people of
such things as delegating signing, by outsourced services and the like.
One could have a semantic debate that they are all part of the same authority
structure, but it can't hurt to underscore the operational distinction.
d/
--
Dave Crocker
Brandenburg InternetWorking
<http://bbiw.net>
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html