Dave Crocker wrote:
>> 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.
> 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.
I think that if "CA" meant "central authority" rather than
"certificate authority", it would probably be appropriate.
But it doesn't, and CA brings in all kinds of baggage mostly
from the "certificate" side. If I understand things correctly,
DNSSEC doesn't require use of "certificates".
It's probably the wording here that's really the problem. Instead
of antognizing the X.509 crowd (as it currently reads), it should
be phrased in a positive way "the only trust root required for
DKIM is the existing DNS trust root", or somesuch.
>> 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.
This is, IMHO, probably not a battle worth fighting. I'm comfortable
with the language that Russ/Arvel suggested.
Mike
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html