ietf-openpgp
[Top] [All Lists]

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

2013-08-07 00:59:08


John Gilmore <gnu(_at_)toad(_dot_)com> wrote:
    >> 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.

    > The classic Internet protocol for providing per-user data is "finger",
    > RFC 742 from 1977.  (Note by the way the illustrious users in the
    > "examples" section.)  It has been updated a few times, most recently
    > in RFC 1288 from 1991.  It is a Draft Standard.  Many people put their
    > PGP public key in their .plan file for easy remote access via finger.

    > Finger has two drawbacks for this purpose: It is not authenticated nor
    > encrypted; and it is designed to be human-readable, not
    > machine-readable.  But a simple finger-like protocol, authenticated
    > and encrypted via keys anchored in DNSSEC, might not only fill the
    > need to obtain keys, but also offer a secured and machine-readable
    > replacement for the finger protocol.

Alas, finger ignores the MX records, and the standard client does not pass
the entire command line argument in the query (making multi-tenant hard).

This effectively means that one has to run the fingerd on the web server,
as many want "example.com" to answer the same as "www.example.com", and HTTP
doesn't do SRV lookup either.

If finger could be updated to look up a SRV RR to find the finger server,
it would be very so much easier to deploy.  Given IPv6, putting a unique IP
address per hosted domain isn't so terrible, but having
        % finger user(_at_)example(_dot_)com

send "user(_at_)example(_dot_)com" as it's query would help too.

I frankly think that having per-user data in DNS is not a horrible thing.
It is true that the DNS administrators often will not like this, but as was
pointed out in a WG session last week, many them will respond to a request
like:
        "please insert
                user.example.com IN NS ns1.user.example.com"

even when they don't understand:
     "please delegate user.example.com to ns1.user.example.com"

(yes, you can finger me for keys to check this message. John convinced me it
the utility 15 years ago.)

--
Michael Richardson <mcr+IETF(_at_)sandelman(_dot_)ca>, Sandelman Software 
Works

DNS mailbox format for users is just plain wrong.  It results in
namespace collisions between users and hosts which has all sorts
of implications on delegations.  Additionally DNS name normalisation
is nowhere near similar to the normalisation used for user names
in mail servers so even if you addressed the namespace collision
there are still major problem.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka(_at_)isc(_dot_)org
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp