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

--===============5891889560670560914==
Content-Type: multipart/alternative; boundary="0000000000006d5f600656a21db4"

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

Regarding multiple email addresses, my intention is that the registry
certifies the binding between an email identity and a public key, rather
than making the key exclusive to a single identity. A user could therefore
register the same public key for multiple email addresses, each
authenticated independently by the corresponding provider.
Regarding standalone OpenPGP clients, the proposal does not assume
provider-managed clients. The provider's role is limited to authenticating
the account holder during public key registration. After that, any
compliant OpenPGP implementation can retrieve certificates directly from
the registry.
For the issue of fake keys, I believe the proposal differs from traditional
public key servers. The registry would only accept registrations from the
authoritative email provider (or another trusted identity provider), so an
attacker would not be able to register a key for someone else's email
address simply by uploading it. In that sense, the registry is intended to
certify an authenticated identity binding rather than merely hosting
arbitrary public keys.

 The flow would be as below:

Consider a user, [email protected], who wishes to use end-to-end encrypted
email.

1. Alice generates an OpenPGP encryption key and signing key locally using
her preferred OpenPGP client. Her private keys never leave her device.

2. Alice uploads her public keys to Gmail through a security settings page.

3. Gmail authenticates Alice using its existing account authentication
mechanisms (password, passkey, MFA, etc.) and verifies that she owns
[email protected].

4. Gmail submits Alice's public keys to the registry designated for the
gmail.com domain.

5. The registry issues signed identity certificates binding [email protected]
to Alice's public keys, records the issuance in an append-only transparency
log, and returns the certificates.

6. Later, Bob sends an email to [email protected]. Before sending, Bob's mail
client performs a DNS lookup for the registry associated with gmail.com,
retrieves Alice's certificate, verifies the registry signature and
automatically encrypts the email using Alice's public encryption key. Bob's
client also signs the message using Bob's signing key.

7. Alice receives the email, decrypts it using her private encryption key,
and verifies Bob's signature using Bob's public certificate retrieved from
the registry.

If Alice later rotates her keys, Gmail authenticates the request and
registers the new public keys. The registry records the new certificates
while retaining the historical certificates for verification of previously
signed messages and decryption of archived emails. Existing OpenPGP clients
remain compatible, and if no certificate exists for a recipient, email
delivery falls back to standard SMTP behavior without requiring any changes
from users.

--
Ashith R

On Wed, Jul 15, 2026, 8:06=E2=80=AFAM <[email protected]> wrote:

>
>
> On 7/14/2026 at 2:49 PM, "Ashith Raghunath" <[email protected]>
> 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 possess=
es
> private keys.
>
> The registry would issue a signed binding between an email address and th=
e
> 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 signatur=
e
> and transparency proof, and then encrypt the message if a valid certifica=
te
> 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.
>
> 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 nam=
e
> and/or email with which this triad was generated.
>
> Instantly problematic is that this is open to malicious attack, but mainl=
y
> to discredit someone.
>
> If, for example, such a triad is created with the name  Rumplestilsken.
>
> 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 si=
gn
> 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 wa=
s
> generated with the above triad.
>
> This assumes that malicious fakes would be sent later, after this key
> becomes public.
>
> Also, of course, it assumes that there would be sufficient funding for al=
l
> the extensive work and people power that this would require.
>
> I, for one, would be happy to contribute to such an approach.
>
> If there are  enough people that would like to see this happen enough tha=
t
> they would contribute, then maybe this approach could be further explored=
.
>
>
> -- vedaal
>
>

--0000000000006d5f600656a21db4
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div>Regarding multiple email addresses, my intention is =
that the registry certifies the binding between an email identity and a pub=
lic key, rather than making the key exclusive to a single identity. A user =
could therefore register the same public key for multiple email addresses, =
each authenticated independently by the corresponding provider.</div><div d=
ir=3D"auto">Regarding standalone OpenPGP clients, the proposal does not ass=
ume provider-managed clients. The provider&#39;s role is limited to authent=
icating the account holder during public key registration. After that, any =
compliant OpenPGP implementation can retrieve certificates directly from th=
e registry.</div><div dir=3D"auto">For the issue of fake keys, I believe th=
e proposal differs from traditional public key servers. The registry would =
only accept registrations from the authoritative email provider (or another=
 trusted identity provider), so an attacker would not be able to register a=
 key for someone else&#39;s email address simply by uploading it. In that s=
ense, the registry is intended to certify an authenticated identity binding=
 rather than merely hosting arbitrary public keys.</div><div dir=3D"auto"><=
br></div><div dir=3D"auto">=C2=A0The flow would be as below:</div><div dir=
=3D"auto"><br></div><div dir=3D"auto">Consider a user, <a href=3D"mailto:al=
[email protected]">[email protected]</a>, who wishes to use end-to-end encrypted =
email.</div><div dir=3D"auto"><br></div><div dir=3D"auto">1. Alice generate=
s an OpenPGP encryption key and signing key locally using her preferred Ope=
nPGP client. Her private keys never leave her device.</div><div dir=3D"auto=
"><br></div><div dir=3D"auto">2. Alice uploads her public keys to Gmail thr=
ough a security settings page.</div><div dir=3D"auto"><br></div><div dir=3D=
"auto">3. Gmail authenticates Alice using its existing account authenticati=
on mechanisms (password, passkey, MFA, etc.) and verifies that she owns <a =
href=3D"mailto:[email protected]">[email protected]</a>.</div><div dir=3D"auto"=
><br></div><div dir=3D"auto">4. Gmail submits Alice&#39;s public keys to th=
e registry designated for the <a href=3D"http://gmail.com">gmail.com</a> do=
main.</div><div dir=3D"auto"><br></div><div dir=3D"auto">5. The registry is=
sues signed identity certificates binding <a href=3D"mailto:[email protected]=
">[email protected]</a> to Alice&#39;s public keys, records the issuance in a=
n append-only transparency log, and returns the certificates.</div><div dir=
=3D"auto"><br></div><div dir=3D"auto">6. Later, Bob sends an email to <a hr=
ef=3D"mailto:[email protected]">[email protected]</a>. Before sending, Bob&#39;=
s mail client performs a DNS lookup for the registry associated with <a hre=
f=3D"http://gmail.com">gmail.com</a>, retrieves Alice&#39;s certificate, ve=
rifies the registry signature and automatically encrypts the email using Al=
ice&#39;s public encryption key. Bob&#39;s client also signs the message us=
ing Bob&#39;s signing key.</div><div dir=3D"auto"><br></div><div dir=3D"aut=
o">7. Alice receives the email, decrypts it using her private encryption ke=
y, and verifies Bob&#39;s signature using Bob&#39;s public certificate retr=
ieved from the registry.</div><div dir=3D"auto"><br></div><div dir=3D"auto"=
>If Alice later rotates her keys, Gmail authenticates the request and regis=
ters the new public keys. The registry records the new certificates while r=
etaining the historical certificates for verification of previously signed =
messages and decryption of archived emails. Existing OpenPGP clients remain=
 compatible, and if no certificate exists for a recipient, email delivery f=
alls back to standard SMTP behavior without requiring any changes from user=
s.</div><div dir=3D"auto"><br></div><div dir=3D"auto">--</div><div data-sma=
rtmail=3D"gmail_signature"><div dir=3D"ltr">Ashith R<br></div></div></div><=
br><div class=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" class=
=3D"gmail_attr">On Wed, Jul 15, 2026, 8:06=E2=80=AFAM  &lt;<a href=3D"mailt=
o:[email protected]">[email protected]</a>&gt; wrote:<br></div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><span style=3D"font-family:Arial;font-size:14px;line=
-height:150%"><span style=3D"font-family:Arial;font-size:14px;line-height:1=
50%"><br><br><div>On 7/14/2026 at 2:49 PM, &quot;Ashith Raghunath&quot; &lt=
;<a href=3D"mailto:[email protected]" target=3D"_blank" rel=3D"norefer=
rer">[email protected]</a>&gt; wrote:<blockquote style=3D"border-left:=
solid 1px #ccc;margin-left:10px;padding-left:10px"><div dir=3D"ltr"><p>I&#3=
9;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 account authenticat=
ion mechanisms and registers the user-provided public keys with a trusted k=
ey registry. The provider never generates or possesses private keys.</p><p>=
The registry would issue a signed binding between an email address and the =
submitted public key, maintain an append-only transparency log of registrat=
ions, rotations, and revocations, and expose a discovery API for mail clien=
ts.</p><p>Rather than requiring each domain to host public keys (as with WK=
D), domains would simply advertise their authoritative registry through a w=
ell-known DNS record. A sending client would discover the registry via DNS,=
 retrieve the recipient&#39;s certificate, verify the registry&#39;s signat=
ure and transparency proof, and then encrypt the message if a valid certifi=
cate exists. If no certificate is available, email delivery would continue =
exactly as it does today.</p><p>-----</p><p>Several points:</p><p>1.=C2=A0 =
=C2=A0Pgp users may sometimes switch from one email address to another, whi=
le keeping their public keys the same.=C2=A0</p><p>2.=C2=A0 =C2=A0Some user=
s prefer to encrypt and/or sign, on their own without any email client inte=
rmediary.</p><p>3.=C2=A0 =C2=A0The main identifying key characteristics are=
</p><p>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -=C2=A0 the key type (v3, v4, v5,=
 RSA, DH, Elliptic Curve, etc)</p><p>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0- the key size 4096, 8192, custom size e.g. 7706</p><p>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0- the key fingerprint</p><p>The issue would be to k=
eep a record of these 3, together with the key name and/or email with which=
 this triad was generated.</p><p>Instantly problematic is that this is open=
 to malicious attack, but mainly to discredit someone.=C2=A0</p><p>If, for =
example, such a triad is created with the name=C2=A0 Rumplestilsken.=C2=A0<=
/p><p>Anyone who wants to cast doubt on Rumplestilsken&#39;s *real* key, ca=
n just make several keys with different fingerprints, but with the same siz=
e, type, and name, and email, (and can even predate the creation time of th=
e *real* key).</p><p>So, it still depends on a *trusted* signature on the *=
real* key, but not the others.</p><p>A possible approach, might be to have =
a recognized authority, (i. e. the GnuPG signing key that signs the major L=
inux 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 th=
e GnuPG registry received that was generated with the above triad.</p><p>Th=
is assumes that malicious fakes would be sent later, after this key becomes=
 public.=C2=A0</p><p>Also, of course, it assumes that there would be suffic=
ient funding for all the extensive work and people power that this would re=
quire.=C2=A0</p><p>I, for one, would be happy to contribute to such an appr=
oach.=C2=A0</p><p>If there are=C2=A0 enough people that would like to see t=
his happen enough that they would contribute, then maybe this approach coul=
d be further explored.</p><p><br></p><p>-- vedaal</p></div></blockquote></d=
iv></span></span></blockquote></div>

--0000000000006d5f600656a21db4--


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

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18Kb3BlbnBncCBt
YWlsaW5nIGxpc3QgLS0gb3BlbnBncEBpZXRmLm9yZwpUbyB1bnN1YnNjcmliZSBzZW5kIGFuIGVt
YWlsIHRvIG9wZW5wZ3AtbGVhdmVAaWV0Zi5vcmcK

--===============5891889560670560914==--