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

Michael Richardson <> Wed, 07 August 2013 02:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3C80721E80B5; Tue, 6 Aug 2013 19:49:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.522
X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gyjiAPIryeDx; Tue, 6 Aug 2013 19:49:32 -0700 (PDT)
Received: from ( [IPv6:2607:f0b0:f:3::184]) by (Postfix) with ESMTP id D7B3421E80C1; Tue, 6 Aug 2013 19:49:31 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id CD79820172; Tue, 6 Aug 2013 23:55:58 -0400 (EDT)
Received: by (Postfix, from userid 179) id EC85BA904C; Tue, 6 Aug 2013 22:48:01 -0400 (EDT)
Received: from (localhost []) by (Postfix) with ESMTP id D6A49B8EA6; Tue, 6 Aug 2013 22:48:01 -0400 (EDT)
From: Michael Richardson <>
To: John Gilmore <>
In-Reply-To: <>
References: <> <> <> <>
X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature"
Date: Tue, 06 Aug 2013 22:48:01 -0400
Message-ID: <>
X-Mailman-Approved-At: Tue, 06 Aug 2013 22:58:50 -0700
Cc:, "Rick van Rein \(OpenFortress\)" <>, Phillip Hallam-Baker <>, "" <>
Subject: Re: [openpgp] [dane] Storing public keys in DNS or LDAP, or elsewhere
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 07 Aug 2013 02:49:37 -0000

John Gilmore <>; 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 "" to answer the same as "", 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

send ""; 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
        "please insert
       IN NS"

even when they don't understand:
     "please delegate to"

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

Michael Richardson <>;, Sandelman Software Works