Sounds like you are proposing this.
http://www.ietf.org/rfc/rfc4386.txt
For what it is worth, I agree that using the DNS to store per-user data is
not a good approach. The DNS administration model is that it makes
assertions about network names and not individual users. Previous attempts
to put end users in the DNS have uniformly met with failure.
But that does not mean that LDAP is a useful tool. LDAP has tons of
complexity and none of it does the slightest bit of good.
While writing my RFC tool I thought about writing a spec for an Internet
bibliography service that would convert labels [RFC4386] to XML documents
describing the reference.
Then after a fairly short amount of work I realized that I could do
everything I wanted using HTTP and some simple regular expression pattern
matching. And the regexp stuff was only necessary because I wanted to reuse
the existing libraries of references at xml.resource.org.
So if you want to do per client records my suggestion would be
1) Use HTTP as the query language transport.
2) Put some form of pointer to the service in the DNS.
3) Use DNSSEC to secure the binding
It might well be that (2) is a case where NAPTR would be a good solution.
Or it might not.
On Fri, Jul 26, 2013 at 10:19 AM, Rick van Rein (OpenFortress) <
rick(_at_)openfortress(_dot_)nl> wrote:
Hello Paul Wouters,
I came across your work on storing public key credentials of users in the
DNS:
* draft-wouters-dane-openpgp-00
* draft-wouters-dane-otrfp-00
As I am currently trying to achieve similar, secure end-to-end exchanges
of public key material for secure communication, this is very interesting.
Thanks for the work!
When I read them, I found that you made a choice that we deliberately
abandoned as unpractical, so I thought it good to share our thoughts. The
background of our work is http://networkeffectalliance.org/ with which we
aim to get more end user and technical facilities incorporated into hosting
packages. Doing this, we are rather keen on privacy and security, as you
are in your drafts.
We decided against the sort of options in DNS that you are describing
because we felt that the DNS is not meant for storing individual user
credentials. One reason for this opinion is that DNS is ultimately treated
public data, and no DNS admin will accept responsibility for "leaking"
information through DNS, whereas most users will not want that kind of
treatment with their electronically addressable contact channels. Another
reason is that DNS management is usually considered too sensitive to update
for end user changes; which is why it is often in the hands of another
(class of) operator.
We are embarking in another direction, and thought this might also be
useful for you, also because it can be used without RFC work. Instead of
using DNS for user data, we are looking at LDAP (with DANE to secure it).
It is a very suitable mechanism for retrieval of end-user descriptive
information, ranging from postalAddress to pgpKey descriptions. It also
has a well-established notion of a Global Directory that is based on
DNS-names derived from dc=,dc= trailers to distinguishedNames, and SRV
record lookups of LDAP service under such domains. Given an email address,
the username part can then be sought with (uid=…) filtering, and PGP keys
and such can be located under that node. I am not aware of any XMPP
profile for LDAP, but that is as straightforward to define as it has been
for OpenPGP, SSH and even SRP. It is probably easier to get such an LDAP
attribute spec standardised as an RFC or even just a XEP than your proposed
use of DNS.
The searchable structured data in LDAP can have privacy issues when used
as a public-facing service when published without restraint; we are
resolving that with a filtering practice (for which we are developing
software) that can filter out considered-private attributes (or objects)
unless their attribute values are explicitly mentioned in a query. So,
searching for (uid=rick) under dc=openfortress,dc=nl would deliver my
account record with email address and SIP phone number as well as being a
parent for key material, but searching for (uid=*) would not deliver this
if I configured LDAP to treat uid as too private to publish in that case.
Another reason not to publish LDAP is that it is often used for data about
local infra; this can be solved by separating in-house and public directory
services.
If you want to know more about this work, you can visit this site with the
work in progress: http://rickywiki.vanrein.org/doku.php?id=globaldir
Specifically note how, for OpenPGP, there is a solution that already works
with PGP tools -- they will perform that LDAP queries to per-domain LDAP
service. I detailed it on the subpage
http://rickywiki.vanrein.org/doku.php?id=globaldir-5-openpgp
I hope this is helpful!
Cheers,
Rick van Rein
OpenFortress
+31.53.4782239
rick(_at_)openfortress(_dot_)nl (SMTP, XMPP, SIP)
_______________________________________________
dane mailing list
dane(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/dane
--
Website: http://hallambaker.com/
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp