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

--===============4477495805140050501==
Content-Type: multipart/alternative;
	boundary="=_72491be55a93a6bfce347818b77a9a44"

--=_72491be55a93a6bfce347818b77a9a44
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"



On 7/14/2026 at 2:49 PM, "Ashith Raghunath"  wrote:

	I'd like to explore a different model for discussion.

	The basic idea is that users continue to generate and own their
OpenPGP key pairs locally. Their email provider authenticates them
using existing account authentication mechanisms and registers the
user-provided public keys with a trusted key registry. The provider
never generates or possesses private keys.

	The registry would issue a signed binding between an email address
and the submitted public key, maintain an append-only transparency log
of registrations, rotations, and revocations, and expose a discovery
API for mail clients.

	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. A sending client would discover the registry
via DNS, retrieve the recipient's certificate, verify the registry's
signature and transparency proof, and then encrypt the message if a
valid certificate exists. If no certificate is available, email
delivery would continue exactly as it does today.

	-----

	Several points:

	1.   Pgp users may sometimes switch from one email address to
another, while keeping their public keys the same.=20

	2.   Some users prefer to encrypt and/or sign, on their own without
any email client intermediary.

	3.   The main identifying key characteristics are

	          -  the key type (v3, v4, v5, RSA, DH, Elliptic Curve, etc)

	           - the key size 4096, 8192, custom size e.g. 7706

	           - the key fingerprint

	The issue would be to keep a record of these 3, together with the key
name and/or email with which this triad was generated.

	Instantly problematic is that this is open to malicious attack, but
mainly to discredit someone.=20

	If, for example, such a triad is created with the name=20
Rumplestilsken.=20

	Anyone who wants to cast doubt on Rumplestilsken's *real* key, can
just make several keys with different fingerprints, but with the same
size, type, and name, and email, (and can even predate the creation
time of the *real* key).

	So, it still depends on a *trusted* signature on the *real* key, but
not the others.

	A possible approach, might be to have a recognized authority, (i. e.
the GnuPG signing key that signs the major Linux releases or
libraries, to sign the First key it receives made with the above triad
and key name, stating only that this was the first key that the GnuPG
registry received that was generated with the above triad.

	This assumes that malicious fakes would be sent later, after this key
becomes public.=20

	Also, of course, it assumes that there would be sufficient funding
for all the extensive work and people power that this would require.=20

	I, for one, would be happy to contribute to such an approach.=20

	If there are  enough people that would like to see this happen enough
that they would contribute, then maybe this approach could be further
explored.
	-- vedaal
--=_72491be55a93a6bfce347818b77a9a44
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset="UTF-8"

<span style=3D"font-family: Arial; font-size: 14px; line-height: 150%;"><sp=
an style=3D"font-family:Arial;font-size:14px;line-height:150%;"><br><br><di=
v class=3D"hush-quoting-section">On 7/14/2026 at 2:49 PM, "Ashith Raghunath=
" &lt;[email protected]&gt; wrote:<blockquote class=3D"hush-quote" sty=
le=3D"border-left:solid 1px #ccc;margin-left:10px;padding-left:10px;"><div =
dir=3D"ltr"><p>I'd like to explore a different model for discussion.</p><p>=
The basic idea is that users continue to generate and own their OpenPGP key=
 pairs locally. Their email provider authenticates them using existing acco=
unt authentication mechanisms and registers the user-provided public keys w=
ith a trusted key registry. The provider never generates or possesses priva=
te keys.</p><p>The registry would issue a signed binding between an email a=
ddress and the submitted public key, maintain an append-only transparency l=
og of registrations, rotations, and revocations, and expose a discovery API=
 for mail clients.</p><p>Rather than requiring each domain to host public k=
eys (as with WKD), domains would simply advertise their authoritative regis=
try through a well-known DNS record. A sending client would discover the re=
gistry via DNS, retrieve the recipient's certificate, verify the registry's=
 signature and transparency proof, and then encrypt the message if a valid =
certificate exists. If no certificate is available, email delivery would co=
ntinue exactly as it does today.</p><p>-----</p><p>Several points:</p><p>1.=
&nbsp; &nbsp;Pgp users may sometimes switch from one email address to anoth=
er, while keeping their public keys the same.&nbsp;</p><p>2.&nbsp; &nbsp;So=
me users prefer to encrypt and/or sign, on their own without any email clie=
nt intermediary.</p><p>3.&nbsp; &nbsp;The main identifying key characterist=
ics are</p><p>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; -&nbsp; the key type (v3, =
v4, v5, RSA, DH, Elliptic Curve, etc)</p><p>&nbsp; &nbsp; &nbsp; &nbsp; &nb=
sp; &nbsp;- the key size 4096, 8192, custom size e.g. 7706</p><p>&nbsp; &nb=
sp; &nbsp; &nbsp; &nbsp; &nbsp;- the key fingerprint</p><p>The issue would =
be to keep a record of these 3, together with the key name and/or email wit=
h which this triad was generated.</p><p>Instantly problematic is that this =
is open to malicious attack, but mainly to discredit someone.&nbsp;</p><p>I=
f, for example, such a triad is created with the name&nbsp; Rumplestilsken.=
&nbsp;</p><p>Anyone who wants to cast doubt on Rumplestilsken's *real* key,=
 can just make several keys with different fingerprints, but with the same =
size, type, and name, and email, (and can even predate the creation time of=
 the *real* key).</p><p>So, it still depends on a *trusted* signature on th=
e *real* key, but not the others.</p><p>A possible approach, might be to ha=
ve a recognized authority, (i. e. the GnuPG signing key that signs the majo=
r Linux releases or libraries, to sign the First key it receives made with =
the above triad and key name, stating only that this was the first key that=
 the GnuPG registry received that was generated with the above triad.</p><p=
>This assumes that malicious fakes would be sent later, after this key beco=
mes public.&nbsp;</p><p>Also, of course, it assumes that there would be suf=
ficient funding for all the extensive work and people power that this would=
 require.&nbsp;</p><p>I, for one, would be happy to contribute to such an a=
pproach.&nbsp;</p><p>If there are&nbsp; enough people that would like to se=
e this happen enough that they would contribute, then maybe this approach c=
ould be further explored.</p><p><br></p><p>-- vedaal</p></div></blockquote>=
</div></span></span>
--=_72491be55a93a6bfce347818b77a9a44--


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

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18Kb3BlbnBncCBt
YWlsaW5nIGxpc3QgLS0gb3BlbnBncEBpZXRmLm9yZwpUbyB1bnN1YnNjcmliZSBzZW5kIGFuIGVt
YWlsIHRvIG9wZW5wZ3AtbGVhdmVAaWV0Zi5vcmcK

--===============4477495805140050501==--