[openpgp] Re: Proposal: Provider-assisted OpenPGP key disc overy

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--===============3168218269525887210==
Content-Type: multipart/signed; protocol="application/pgp-signature";
 micalg=pgp-sha512;
 boundary="------678391fefa8e1d529bfd3471ab8ee808ffe79e180aee274e265fd5cb5bf11a88";
 charset=utf-8

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------678391fefa8e1d529bfd3471ab8ee808ffe79e180aee274e265fd5cb5bf11a88
Content-Type: multipart/mixed;boundary=---------------------a1976ce1d6b0e83314bbed27b19c0a66

-----------------------a1976ce1d6b0e83314bbed27b19c0a66
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;charset=utf-8

Hi Ashith,

It seems we've all found the same moment to respond to you. In addition to=
 their comments, I will point out that getting the major ESPs to use such =
a registry will absolutely never happen. There's no upside for them, and t=
he downside (users generating keys, losing them, and receiving unreadable =
mail) is very large. So while WKD-style pointers to an authoritative HKP s=
erver are very useful for those domains and ESPs that do support them, and=
 we should have that capability, relying on ESP to register keys as the pr=
imary key discovery mechanism for most OpenPGP users is not feasible.

-Bart


On Wednesday, July 15th, 2026 at 11:58 AM, Andrew Gallagher <andrewg=3D40a=
[email protected]> wrote:

> Hi, Ashith.
> =


> You've arrived at an opportune moment, as we are currently working on
> this problem area. Welcome!
> =


> On 14/07/2026 19:47, Ashith Raghunath wrote:
> > Rather than requiring each domain to host public keys (as with WKD),
> > domains would simply advertise their authoritative registry through a
> > well-known DNS record.
> =


> Yes, this is in the pipeline already - see Section 11 of draft-hkp [1].
> The use of SRV records rather than TXT is more standard for service
> discovery, but the idea is essentially the same as yours.
> =


> Once a client has the location of an authoritative HKP server, the
> correspondent's canonical bundle can be downloaded via the HKPv2 API.
> The question of how to enhance the result with a transparency proof is
> on our todo list, but we are waiting for the KEYTRANS working group to
> finalise their protocol first, to see if we can copy their homework... ;=
-)
> =


> Thanks!
> A
> =


> [1]
> https://datatracker.ietf.org/doc/html/draft-ietf-openpgp-hkp-01#name-cer=
tificate-discovery-using
> =


> _______________________________________________
> openpgp mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
> =


-----------------------a1976ce1d6b0e83314bbed27b19c0a66--

--------678391fefa8e1d529bfd3471ab8ee808ffe79e180aee274e265fd5cb5bf11a88
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: ProtonMail

wrsEARYKAG0FgmpXX14JEJkFRGXvMx5ERRQAAAAAABwAIHNhbHRAbm90YXRp
b25zLm9wZW5wZ3Bqcy5vcmdiHJkLwH1HTFq5glOSJtPO/c4CC7zYjYhmGECU
6YOQABYhBDwVkTeBh+6myif6rJkFRGXvMx5EAAAjkgD9Eh2+En9kCIB/OWKL
DM9J86xOhiRinwCL5m9GudsWZ3UA/3y/mv4/3yEOiLmDC+UlPMebCwybAnum
5fVeGVY3YO4K
=bvE+
-----END PGP SIGNATURE-----


--------678391fefa8e1d529bfd3471ab8ee808ffe79e180aee274e265fd5cb5bf11a88--


--===============3168218269525887210==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18Kb3BlbnBncCBt
YWlsaW5nIGxpc3QgLS0gb3BlbnBncEBpZXRmLm9yZwpUbyB1bnN1YnNjcmliZSBzZW5kIGFuIGVt
YWlsIHRvIG9wZW5wZ3AtbGVhdmVAaWV0Zi5vcmcK

--===============3168218269525887210==--