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

Daniel Kahn Gillmor <[email protected]> Wed, 22 Jul 2026 10:44:09 -0400
Newsgroups gmane.ietf.openpgp
Message-ID <[email protected]>
--===============7234367074058876778==
Content-Type: multipart/signed; boundary="=-=-=";
	micalg=pgp-sha512; protocol="application/pgp-signature"

--=-=-=
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Mon 2026-07-20 17:49:28 -0400, Simo Sorce wrote:
> But assuming people here is willing to trust DKIM as a part of the
> proof of authentication, then the "registration" of the public key
> could be a couple of signed emails[1] sent to the registry and the
> registry authenticating the sender's email via DKIM signatures (to make
> spoofing hard).

This is an interesting approach.  It's limited because of DKIM's
inherent ephemerality (e.g. selectors can be removed from the DNS, and
in some cases the secret keys for any given selector are published
regularly.

So this might be a useful way to register a key with a particular
service (while using the big player's existing signing infrastructure),
but it might not result in a long-lasting credential.  (that
ephemerality isn't necessarily problematic, it's just a bit different
from how we have traditionally thought about endorsements by default in
OpenPGP).

I recommend looking at (and weighing in on)
https://gitlab.com/andrewgdotcom/openpgp-hkp/-/merge_requests/11 which
contemplates using DKIM in this way for purposes of publishing to an HKP
server.

      --dkg

--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

wr0EARYKAG8Fgmpg1zkJEHgLhU7ZwrSWRxQAAAAAAB4AIHNhbHRAbm90YXRpb25z
LnNlcXVvaWEtcGdwLm9yZ/CZgxuyIgJ2Uo80yfUO39MGE8+AFG6j7JIKf7gI+aff
FiEEY6wRjlsuXWbIioWneAuFTtnCtJYAAJUOAQCLWiVuDnu3gtWTrjGIlt4I0MxR
dBEE6HW5rZom69x3RwEAiw8/BzLlHeZNwtNWwFjUewHYTCWRN8t+CjQv1bglXQI=
=2Sng
-----END PGP SIGNATURE-----
--=-=-=--


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

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18Kb3BlbnBncCBt
YWlsaW5nIGxpc3QgLS0gb3BlbnBncEBpZXRmLm9yZwpUbyB1bnN1YnNjcmliZSBzZW5kIGFuIGVt
YWlsIHRvIG9wZW5wZ3AtbGVhdmVAaWV0Zi5vcmcK

--===============7234367074058876778==--