[openpgp] Certificate discovery over HKP

Andrew Gallagher <andrewg@andrewg.com> Tue, 08 April 2025 09:52 UTC

Return-Path: <andrewg@andrewg.com>
X-Original-To: openpgp@mail2.ietf.org
Delivered-To: openpgp@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 72AB718DCE82 for <openpgp@mail2.ietf.org>; Tue, 8 Apr 2025 02:52:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=andrewg.com
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D1W9_EK0IyAE for <openpgp@mail2.ietf.org>; Tue, 8 Apr 2025 02:52:34 -0700 (PDT)
Received: from fum.andrewg.com (fum.andrewg.com [135.181.198.78]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 7DE4D18DCE7A for <openpgp@ietf.org>; Tue, 8 Apr 2025 02:52:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=andrewg.com; s=andrewg-com; t=1744105953; bh=lE07NsZDNXbNSUifPGLrrZYT8zN+DeTOerrKybsw/pY=; h=From:Subject:Date:To:From; b=lIM57DxukzrMj/QejDjpxFxuwOtDrAoRIrlx5msGN0aRU7Dic0PlCuGNi1jb40DJc 6a9mR+tMIW2RpbdCpRf6hbGCip5GXmFtEPP7NdEBlcNFi/RiPVWiTB7XDCp2E/DJEi cjebr2Hy57GgedfJFgZgZ3YfcaXgQWz+Y6bCYJQdDEFQxbPBzVj4sMusdcNkrjVKkS RGK4OP9tLcV5kCKeDjivva0tSgvFYkLctETB8Amlf51HgciPS1FNbtKEA1hf5vSoCx jqWN7DvCg4GN6tlj5EA8i9maeBqtAbxgbnuXNXxstbgQluLYoVbLKF/FGuhbQKvoqr 0j5oExR1GtTcA==
Received: from smtpclient.apple (serenity [IPv6:fc93:5820:7349:eda2:99a7::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by fum.andrewg.com (Postfix) with ESMTPSA id 199C75EDF7 for <openpgp@ietf.org>; Tue, 8 Apr 2025 09:52:33 +0000 (UTC)
From: Andrew Gallagher <andrewg@andrewg.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_B07B32BE-8A38-4584-A3E9-F52CDA5A7A63"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6.1.9\))
Message-Id: <F51333E5-1AC3-4216-B720-4EBEFA3B6AAB@andrewg.com>
Date: Tue, 08 Apr 2025 10:52:15 +0100
To: "openpgp\\@ietf.org" <openpgp@ietf.org>
X-Mailer: Apple Mail (2.3731.700.6.1.9)
Message-ID-Hash: GO4AE2ETVMR22MIKJFNAJHTC2EU3MU3U
X-Message-ID-Hash: GO4AE2ETVMR22MIKJFNAJHTC2EU3MU3U
X-MailFrom: andrewg@andrewg.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-openpgp.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [openpgp] Certificate discovery over HKP
List-Id: "Ongoing discussion of OpenPGP issues." <openpgp.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/zSVyA-GYLmwV7GChbzU1sGBcOac>
List-Archive: <https://mailarchive.ietf.org/arch/browse/openpgp>
List-Help: <mailto:openpgp-request@ietf.org?subject=help>
List-Owner: <mailto:openpgp-owner@ietf.org>
List-Post: <mailto:openpgp@ietf.org>
List-Subscribe: <mailto:openpgp-join@ietf.org>
List-Unsubscribe: <mailto:openpgp-leave@ietf.org>

Hi, all.

At the OpenPGP Email Summit last week, we discussed OpenpPGP certificate discovery over HKP, and it was again suggested that we use SRV records instead of a .well-known policy file. I could not immediately recall all of the arguments leading to the previous decision to use a policy file, so I want to follow up now with a summary of the various considerations.

The main concern with policy files remains the barrier to entry for small domain owners, who would have to maintain an `openpgpkey.$DOMAIN` web service to serve as little as a single file. While this would not be difficult for the technically experienced, TLS certificate management is still a significant amount of work compared to setting a SRV record. Setting a CNAME to redirect to a shared service provider would shift the burden of TLS management to the provider, who would have to maintain a certificate management infrastructure for an arbitrary number of domains (although it should be pointed out that KOO already does this).

The main concern with SRV records remains the difficulty of looking up arbitrary DNS records from constrained environments such as browser engines and mobile phone sandboxes. If we moved to this method, we would probably want to specify a method of configuring a known keyserver to proxy discovery lookups, by analogy with recursive DNS resolvers. In addition: a) not all domain registrars support setting SRV records (although it is a one-off cost to change registrars), and b) we can require that policy file lookups are covered by a TLS certificate, but cannot yet require that SRV records be covered by DNSSEC - so a MITM could more easily redirect a client to a malicious discovery service (but consider that a similar argument applies to non-DNSSEC MX records).

Some technical details can be found in the "key discovery" document in the HKP draft repository:

https://gitlab.com/andrewgdotcom/draft-gallagher-openpgp-hkp/-/blob/main/openpgp-key-discovery.md

And the head of the original discovery discussion (from 2023!) is here:

https://mailarchive.ietf.org/arch/msg/openpgp/9Y3y3S4RgJGcv6-QofGA57Kh1f8/

My gut feeling is that the SRV method is technically more “correct” and easier to implement on the server side, but the policy file method is easier to implement on many clients. If we agreed to also specify a proxy discovery method, the balance may shift towards SRV.

Any thoughts?

A