[dane] Storing public keys in DNS… or LDAP

["Rick van Rein (OpenFortress)" <[e-mail]>]

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
[e-mail]   (SMTP, XMPP, SIP)