[openpgp] Re: Certificate discovery over HKP

Andrew Gallagher <andrewg@andrewg.com> Tue, 08 April 2025 21:00 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 E9D4B1930E9B for <openpgp@mail2.ietf.org>; Tue, 8 Apr 2025 14:00:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level:
X-Spam-Status: No, score=-2.101 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, 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 pMpYLiXrfzNe for <openpgp@mail2.ietf.org>; Tue, 8 Apr 2025 14:00:54 -0700 (PDT)
Received: from fum.andrewg.com (fum.andrewg.com [IPv6:2a01:4f9:c011:23ad::1]) (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 F12E11930E91 for <openpgp@ietf.org>; Tue, 8 Apr 2025 14:00:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=andrewg.com; s=andrewg-com; t=1744146052; bh=nrHDterJoZAs7GnLwDjWJ+cwJv8grfHbMd7EnhV/G1o=; h=From:Subject:Date:References:Cc:In-Reply-To:To:From; b=VCsWvjVVNAneS/tvJl3aL3kKEqC8pb+D5g90DGhknUM7Bisr2kMyNi2vqRGrM/o9U 4o98CZPmateH1PoUx8iMhC5UEpWglMIzwiWjjLBkDP9LK3tL1+iDwlY9TGEm1s+lqc bcp7YlSHkELJ2gwSphMZpQhYIhHFPaGEvfO09wGrytgisEWDM0NEEISopI7Mpe527b ekqnbg4fpD4Pxz4ZatIdI20vXqeYtIEjaKmGZJy5/OqIcViqh024VV41tfAas6uQAc rp+DP1zXIgOWfGompgUqbsLCMjs8g+mZoK4uFygNSO6P22cphDtG8RS2DCdne2ptkg 06Qy+BWESmy+A==
Received: from smtpclient.apple (unknown [176.61.115.103]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (Client did not present a certificate) by fum.andrewg.com (Postfix) with ESMTPSA id 6BDB65EDF7; Tue, 8 Apr 2025 21:00:52 +0000 (UTC)
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
From: Andrew Gallagher <andrewg@andrewg.com>
Mime-Version: 1.0 (1.0)
Date: Tue, 08 Apr 2025 22:00:40 +0100
Message-Id: <533BAF31-3076-4E0F-A4AF-904A26049132@andrewg.com>
References: <A748070A-4774-41F9-92E8-55F724B8834C@my.amazin.horse>
In-Reply-To: <A748070A-4774-41F9-92E8-55F724B8834C@my.amazin.horse>
To: Vincent Breitmoser <look=40my.amazin.horse@dmarc.ietf.org>
X-Mailer: iPhone Mail (22D82)
Message-ID-Hash: 5Z37VGDX7JQJZN5CJU3NT7VLBGG5XDH7
X-Message-ID-Hash: 5Z37VGDX7JQJZN5CJU3NT7VLBGG5XDH7
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
CC: openpgp@ietf.org
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [openpgp] Re: Certificate discovery over HKP
List-Id: "Ongoing discussion of OpenPGP issues." <openpgp.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/mdWqrnQmSJqnU9rjbNqG20zDjOA>
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>

On 8 Apr 2025, at 20:41, Vincent Breitmoser <look=40my.amazin.horse@dmarc.ietf.org> wrote:
> 
> I read the document you linked, and the first question I have is - what exactly is the "thing to be done" here that we are trying to solve? It is unclear to me both what the exact goals are, and how HKP is the best way achieve them.
> 
> "OpenPGP certificate discovery over HKP" sounds like we are designing a technical alternative to WKD, but what are the properties we want?

The first few messages in the old thread I linked lay out the general idea. WKD has some unusual properties that make it more difficult than necessary to implement, particularly the hashing scheme, which prevents things like case or special character normalisation. For example, gmail maps john.doe(at)gmail.com and johndoe(at)gmail.com to the same account. Hashing prevents these from being easily identified by the server, hence WKD lookups are now required to send both the hashed and unhashed forms of the same address. Also, the form of the policy file causes issues with some web hosters, and the requirement for the policy file and the actual certificates to be served from the same hostname means that a shared service provider (such as KOO) has to implement a certificate infrastructure. On the other hand, a simpler indirection format allows an existing keyserver to serve certs for discovery using a single lookup protocol. And finally, we cannot safely serve v6 keys over existing WKD for fear of compatibility issues with unpatched legacy code.

> If it's to allow "recursive" lookups, we could just add a line to the wkd policy file that allows it. Or, even easier, servers could just do it without asking, since certificates available via WKD must be considered public info (modulo enumeration) anyways.

Yes, one way of implementing recursive lookups would be to just do them all the time. We would need some form of annotation though to distinguish certs that had been proxied from an authoritative source from those that had not. But the primary goal of discovery over HKP is not to enable recursive lookups, the causality is the other way around.

A