[openpgp] Proposal: Provider-assisted OpenPGP key discovery

--===============6757650759887758236==
Content-Type: multipart/alternative; boundary="000000000000caf1a2065696a266"

--000000000000caf1a2065696a266
Content-Type: text/plain; charset="UTF-8"

Hello OpenPGP Working Group,

I'd like to start a discussion on a possible approach to simplifying
OpenPGP deployment by addressing key discovery and lifecycle management
while preserving user ownership of private keys.

>From my perspective, one of the primary barriers to wider OpenPGP adoption
is not the cryptography itself, but the operational aspects of discovering,
verifying, rotating, and revoking public keys. Existing mechanisms such as
WKD, DANE OPENPGPKEY, HKP keyservers, and the Web of Trust each solve part
of the problem but involve trade-offs in deployment, usability, or trust.

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.

Some of the intended goals are:

   -

   Preserve end-to-end encryption with user-generated private keys.
   -

   Make public key discovery automatic.
   -

   Simplify key rotation and revocation.
   -

   Improve detection of unauthorized key replacement through transparency
   logs.
   -

   Allow incremental deployment without breaking existing SMTP
   infrastructure.
   -

   Remain compatible with the existing OpenPGP message format.

At this stage, this is only a design proposal, and many details remain
open. Before investing further effort, I'd appreciate feedback from the
working group.

In particular:

   -

   Has similar work already been proposed or standardized?
   -

   Are there existing efforts that this proposal should build upon rather
   than duplicate?
   -

   Does provider-assisted registration introduce security or trust concerns
   that I'm overlooking?
   -

   Is DNS-based registry discovery a reasonable direction, or are there
   better alternatives?
   -

   Would this be more appropriate as an extension to OpenPGP or as a
   separate specification?

I've started documenting the proposal here:
https://github.com/dranzerashi/provider-assisted-openpgp

I'd greatly appreciate any feedback, references to prior work, or
suggestions on whether this is a worthwhile direction to pursue.

Thank you for your time.
-- 
Ashith R

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

<div dir=3D"ltr"><div><span style=3D"background-color:transparent">Hello Op=
enPGP Working Group,</span></div><div><p>I&#39;d like to start a discussion=
 on a possible approach to simplifying OpenPGP deployment by addressing key=
 discovery and lifecycle management while preserving user ownership of priv=
ate keys.</p><p>From my perspective, one of the primary barriers to wider O=
penPGP adoption is not the cryptography itself, but the operational aspects=
 of discovering, verifying, rotating, and revoking public keys. Existing me=
chanisms such as WKD, DANE OPENPGPKEY, HKP keyservers, and the Web of Trust=
 each solve part of the problem but involve trade-offs in deployment, usabi=
lity, or trust.</p><p>I&#39;d like to explore a different model for discuss=
ion.</p><p>The basic idea is that users continue to generate and own their =
OpenPGP key pairs locally. Their email provider authenticates them using ex=
isting account authentication mechanisms and registers the user-provided pu=
blic keys with a trusted key registry. The provider never generates or poss=
esses private keys.</p><p>The registry would issue a signed binding between=
 an email address and the submitted public key, maintain an append-only tra=
nsparency log of registrations, rotations, and revocations, and expose a di=
scovery API for mail clients.</p><p>Rather than requiring each domain to ho=
st public keys (as with WKD), domains would simply advertise their authorit=
ative registry through a well-known DNS record. A sending client would disc=
over the registry via DNS, retrieve the recipient&#39;s certificate, verify=
 the registry&#39;s signature and transparency proof, and then encrypt the =
message if a valid certificate exists. If no certificate is available, emai=
l delivery would continue exactly as it does today.</p><p>Some of the inten=
ded goals are:</p><ul><li><p>Preserve end-to-end encryption with user-gener=
ated private keys.</p></li><li><p>Make public key discovery automatic.</p><=
/li><li><p>Simplify key rotation and revocation.</p></li><li><p>Improve det=
ection of unauthorized key replacement through transparency logs.</p></li><=
li><p>Allow incremental deployment without breaking existing SMTP infrastru=
cture.</p></li><li><p>Remain compatible with the existing OpenPGP message f=
ormat.</p></li></ul><p>At this stage, this is only a design proposal, and m=
any details remain open. Before investing further effort, I&#39;d appreciat=
e feedback from the working group.</p><p>In particular:</p><ul><li><p>Has s=
imilar work already been proposed or standardized?</p></li><li><p>Are there=
 existing efforts that this proposal should build upon rather than duplicat=
e?</p></li><li><p>Does provider-assisted registration introduce security or=
 trust concerns that I&#39;m overlooking?</p></li><li><p>Is DNS-based regis=
try discovery a reasonable direction, or are there better alternatives?</p>=
</li><li><p>Would this be more appropriate as an extension to OpenPGP or as=
 a separate specification?</p></li></ul><p>I&#39;ve started documenting the=
 proposal here:=C2=A0<a href=3D"https://github.com/dranzerashi/provider-ass=
isted-openpgp">https://github.com/dranzerashi/provider-assisted-openpgp</a>=
</p><p>I&#39;d greatly appreciate any feedback, references to prior work, o=
r suggestions on whether this is a worthwhile direction to pursue.</p><p>Th=
ank you for your time.</p></div><span class=3D"gmail_signature_prefix">-- <=
/span><br><div dir=3D"ltr" class=3D"gmail_signature" data-smartmail=3D"gmai=
l_signature"><div dir=3D"ltr">Ashith R<br></div></div></div>

--000000000000caf1a2065696a266--


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

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18Kb3BlbnBncCBt
YWlsaW5nIGxpc3QgLS0gb3BlbnBncEBpZXRmLm9yZwpUbyB1bnN1YnNjcmliZSBzZW5kIGFuIGVt
YWlsIHRvIG9wZW5wZ3AtbGVhdmVAaWV0Zi5vcmcK

--===============6757650759887758236==--