This is the first of a few issues that come in trying to rationalize at
least two of the SSP proposals, draft-hallambaker-dkimpolicy-00 and
draft-allman-dkim-ssp. I'd like to keep the issues separate, because I
think they're largely independent, so please respond in kind if at all
possible.
=====
Phill Hallam-Baker has proposed the publication of a new PTR-like RR
type, tentatively called XPTR, in order to improve the scalability of
the SSP mechanism to a large number (~1000?) of additional types of
policy in the future. To look up the signing policy of example.com, the
sequence would be:
1. Query for XPTR record for example.com. If result is an NXDOMAIN
error, the domain does not exist. If result is a NODATA error, either
the policy or the domain does not exist.
2. Query for [RRtype TBD; separate issue] record for
_dkimpolicy.{result of XPTR query}; policy record is stored at that
location.
Argument Pro: Supports a potentially very large number of policies, as
might be needed for WS-* (for example) in the future. Permits a central
point of control and modification for policies relating to different
classes of nodes in the domain.
Argument Con: Requires an additional lookup per query; other types of
policy are out of scope for the WG.
My personal opinion is along the lines of "Argument Con", that it is not
up to the DKIM Working Group to define a fully general policy
mechanism. There may be good arguments for IETF to charter some work in
this area, but that's a much larger question than this WG and
undoubtedly a much more time-consuming one as well.
-Jim
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html