Re: [openpgp] [dane] Storing public keys in DNS… or LDAP

[Phillip Hallam-Baker <[e-mail]>]

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) <
[e-mail]> 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
> [e-mail]   (SMTP, XMPP, SIP)
> _______________________________________________
> dane mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dane
>



-- 
Website: http://hallambaker.com/