![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
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.ibm.com) http://www.research.ibm.com/people/l/leiba http://www.research.ibm.com/spam
_______________________________________________ Ietf mailing list Ietf at ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.