Keith Moore wrote:
OTOH, the assumption that _all_ public keys used to validate DKIM
signatures will be stored in DNS is a very limiting one, because it
appears to lead to either
a) a constraint that policy be specified only on a per-domain basis
(which is far too coarse for many domains) or
Actually, the DKIM base spec does provide a mechanism for replacing the
DNS keystore with something else. Look at 1.4 for a general statement,
and the description of the "q=" tag in 3.5. DKIM's intended to be able
to support user-level keys in a future version (there's some discussion
of that in appendix A), and its design is set up specifically not to
prevent that.
The proposed charter puts the details of other key management systems
and user-level keys out of scope so that we can contain the work at this
stage, and make quick progress on the first version. It'd be entirely
reasonable to recharter and attack these issues immediately after
completing the first round of chartered work, if there are enough people
who want to work on that. Or we can see how a while of deployment goes,
and form another WG in a year or so to do it.
Barry
--
Barry Leiba, Pervasive Computing Technology
(leiba(_at_)watson(_dot_)ibm(_dot_)com)
http://www.research.ibm.com/people/l/leiba
http://www.research.ibm.com/spam
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf