[mailto:owner-ietf-mailsig(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of Dave
Crocker
Is it really clear that *storing* keys in the DNS is the right
approach? To me, that sounds like pre-judging a little bit
too much
of the working group's end result.
Thomas,
The current language of the charter does not specify an
open-ended design
process. Rather, it specifies an effort to refine an existing
specification.
These are different approaches that working groups can take.
In the case of
DKIM, the basis for the working group is an existing
specification that derives
from running code and deployed use. The charter seeks to
protect that investment
rather than call for an open-ended process.
Hence, yes, the current charter language "pre-judges" quite a
bit. That's
considered a feature, not a bug.
There is a major issue in the language that you keep refusing to
discuss. Specifically the question of interfaces to other means of
storing keys that are either defined already (PKIX, XKMS) or might be
defined in a separate working group.
For reasons I have already advanced I think that XKMS should be
addressed in a separate draft. It is a simple matter to state how to
link from DKIM to XKMS. The q=xkms key query mechanism is essentially
fully constrained by the existing specifications. But it would be very
advantageous to explain how to use a DKIM stored DNS key to bootstrap
the communication to the XKMS service.
X509 certificates are a different matter. We need a means of advertising
the location of an x509 certificate in a key record. There are two
potential ways to do this, an X509 certificate and an x509 certificate
path. Both of these mechanisms are FULLY CONSTRAINED by existing
deployments.
Therefore people who are going to link their key records to certificates
will use the x509cert=<uri> and x509path=<uri> attributes. The only
degree of freedom here is the choice of the attribute tags themselves.
Attempting to keep this work out of scope is futile. The language as
specified is not acceptable and unless it is changed I will submit an
alternative charter proposal to the IESG.