As of now, I am not aware of any specifications for doing
DKIM using any other
mechanism, for obtaining keys. Defining such a mechanism
will take unknown
resources and time. The output of that effort is not certain.
q=xkms
That's it, done.
The XKMS specification is fully specified and has been extensively
reviewed by the leading cryptographic security vendors. It is a W3C
standard. It has been mentioned several times.
The time required for adding in the XKMS option is the time it takes to
add the tag option q=xkms.
XKMS already has an SRV record defined.
To use XKMS as a key mechanism for DKIM we need a unique URI that stands
for DKIM. The best way to do this would be to get an IANA registration.
However if no registration is made the URI will automatically be
generated once the RFC issues.
So I think the questions are:
1. Key Server:
1a. Do you agree that storing public keys in the DNS is
the way to go? or
DNS should be the mandatory to implement mechanism.
1b Would using some form of HTTP retrieval or HTTP key
server be better?
There are constraints to using the DNS that cannot be overcome without
doing considerable abuse to both DKIM and DNS. In particular if you are
attempting to use DKIM in combination with an existing PKI with
previously deployed keys, if you want to use long key sizes, if you want
deeper signature semantics, if you want to do encryption.
These are all out of scope, but XKMS already solves all of them.
If you wanted to support long time archival signatures one way you could
do it would be to set up an XKMS server to provide the necessary
information.
Any alternative protocol is going to end up being SOAP-ified and
XML-ified. The basic semantics of the XKMS Locate request are:
"What public key should I use to [X] data using protocol [Y] when
talking to [Z]"
E.g.
"What public key should I use to Encrypt data using protocol S/MIME
or PGP when talking to alice(_at_)example(_dot_)com"
2. Working group project management
2a. Should the working group focus on the current, DNS-based
mechanism now, and pursue additional mechanisms later? or
2b. Should the working group include development of a
non-DNS-based mechanism as part of its initial delivery?
2c the working group focus on the current, DNS-based
mechanism, specify q= tag specifiers for existing key
location mechanisms and decide on the development of
additional mechanisms if the need arises?