ietf-mailsig
[Top] [All Lists]

RE: QUERY: Key Server Choices

2005-07-25 16:55:22


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?



<Prev in Thread] Current Thread [Next in Thread>