[openpgp] Using DNS Handles with OpenPGP

Phillip Hallam-Baker <[email protected]>
Newsgroups gmane.ietf.openpgp
Message-ID <CAMm+LwgxtvAhqqjCayqEzUcQcezJDLBTLW=Fza149vYGK=gheQ@mail.gmail.com>
As some of you probably know, Blue Sky has been very successfully applying
two IETF technologies to create an open authentication system for the Web
and have gained over 30 million members in their first year.

I have a proposal for OpenPGP I would like to run by folks here.


My original handle was one they maintained for me @hallam.bsky.social, but
the part after the @ is just a DNS name that is bound to the Blue Sky
ATmosphere protocol gubbins by means of a prefixed TXT record. So I quickly
changed my handle to @phill.hallambaker.com:

_atproto.phill.hallambaker.com. IN TXT
"did=did:plc:k647x4n6h3jm347u3t5cm6ki"

I have wanted to do end to end secure social media for a long time. As in
'all the content on the server is encrypted Mr Starmer and the service does
not have decryption keys'. And this mechanism gives me a means of making it
possible for any of those 30 million users to comment on my personal place
on the Web:

https://phill.hallambaker.com/

So what has this got to do with OpenPGP you ask? Well they have built a
user base that is 30 million strong in a year. They have momentum, so how
can we ride that momentum to power adoption of end-to-end secure everything?


One way would be to put OpenPGP keys in the DNS alongside the handle:

_openpgp.phill.hallambaker.com. IN TXT "[email protected] fp=
E5B8-247A-F8A6-19A2-8F90--FDFC-9FF2-5980-F5BA-7E4F"

That has obvious usability problems. Putting data into the DNS as a one off
thing is practical for end users. Expecting them to maintain information in
the DNS is pretty hopeless. And I get enough spam already.

So putting OpenPGP keys into the DNS directly seems like a bad idea. Better
to use signed contacts and put the root of trust for the contact manager
into the DNS:

_mesh.phill.hallambaker.com. IN TXT "dsa=mbqn-a3es-zbye-xp3o-w6et-pqug-go5v@
@example.com"

So what this does is bind my DNS handle to my Mesh direct service address
which is a root-o-trust/service address pair. And then people can do a
fetch to get my public contact assertion signed under that root o' trust
and verify it. If my zone is DNSSEC signed, we have a fairly solid trust
path for establishing TOFU.

And that contact assertion would hold my SSH credentials OpenPGP
credentials, etc. etc. Right now I am just transferring the IANA protocol
names into my JSON serialization.


So the idea here is that we bridge from the DNS handle @
phill.hallambaker.com to a signed assertion that provides all the
credentials you might use to talk to me. I might not want to put my email
address in a public record but I could certainly put the hash of my email
address in my public contact for matching purposes and put the plaintext
address in private records I only pass out to people after I have approved
communication with them.

So the goal here is to make it possible to use @phill.hallambaker.com to
establish any sort of end-to-end secure interaction with me - mail,
messaging, data drop, voice, video.


My goal is to establish a situation where whenever someone uses the DNS
handle, they know they are getting the best available security and that
besides end-to-end encryption, we achieve end-to-end trust. The
counterparty keys will always be verified against the credentials in the
contact entries.

So if Alice is going to send a mail message to Bob, the mail client looks
at the client and sees that Bob always accepts OpenPGP over SMTP.

More importantly, if Alice is joining my development team, she publishes
her SSH public key, her OpenPGP git commit key and her code signing keys.

So how do I distinguish the OpenPGP keys for SMTP and the keys for git
commit?

Or do I just say it is a public key and git is the 'protocol'?

_______________________________________________
openpgp mailing list -- [email protected]
To unsubscribe send an email to [email protected]
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.