Dave Crocker wrote:
As with the rest of DKIM, internal procedures are internal procedures, even when
"internal" happens to occur between ADMDs.
I don't think that exchanging public (or even private, yuk) keys between
ADMDs is internal. Nor do I think that encouraging such would be likely
to sit well when our specs are reviewed later on. (E.g. by secdir, where
I would raise the issue if I drew the document - must check if that can
happen:-)
Where the delagatee supplies a public key to the delegator then its
quite likely that that public key will never get updated. That's a bad
thing.
I'm *not* saying that we have to invent any kind of key management, but
if keys are to be sent between domains (even in a minority of cases),
then we do need to have analysed those cases and shown that there's an
easy way to handle them. IMO, the SSP DSD mechanism is potentially
better from this angle since its ok to exchange signer names once and
never have to change them for other than business reasons. And I find
the argument that SSP DSD means there's little or no need for cross
domain key transport (other than in key records, as per base) to be
fairly convincing, though I don't feel comfortable that I understand
who'll be delegating, when, and to whom.
SSP DSD may of course be worse from other points-of-view, and the
WG may well decide not to do it, or to do it later, or whatever, but
I think a consequence of not including it as a requirement, is that
we increase the amount of work we have to do on key management.
And of course, if there are ways to avoid the key delegation (for
everyone, or almost everyone) using DNS mechanisms, then that's great,
and we're off the hook again. (I haven't totally understood some of
what's been said along those lines to be honest, maybe its a side
effect of the thread being so long.)
Stephen.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html