[openpgp] Using a JSContact record in the DNS to publish OpenP GP keys and S/MIME certs

As I might have mentioned, I am heavily into the use of DNS handles and see
them as a way of combining the ease of use of systems like Signal with the
direct trust properties provided by OpenPGP.

I thought I would run this idea past folk in cryptography groups before
pushing it out into code.

The code of the Blue Sky ATprotocol identity system is that the handle @
phill.hallambaker.com is actually a DNS record binding the name to the hash
of a ECDSA signature key:

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

The plc key is just a means of retrieving the metadata associated with the
identity. That part of the spec is a bit icky because it introduces an
unnecessary control point, the PLC registry. But no problem, we can sort
that out later on.

So what if we bound the handle to a metadata record 'of some type' that
told people how to establish a secure communication with the handle owner?
Something like:

_contact.phill.hallambaker.com. IN TXT "js=earl://
example.com/mbqn-a3es-zbye-xp3o-w6et-pqug-go5v"

My original prototype involved the Mesh, this version deliberately stripped
down so that it is as easy as possible to implement in something like a
Python script. That reduces the trust properties I can achieve but is good
enough for most purposes.

The goal here is to provide Trust After First Use if the DNS zone isn't
signed and Trust Contingent On ICANN On First Use if it is. This is the
start of a conversation about trust, not necessarily the end. The idea here
is to make use of credentials that provide end-to-end trust ubiquitous.

Just as removing referential transparency (aka 'scruffy links' or 404 not
found) was the key advance that enabled the Web to take off. Delaying the
problem of validating the credentials might be the key to making Web of
Trust work.


The design I have come up with is this:

* Use JSContact [RFC9553] to represent the contact info. It is much better
to pick one format than punt and allow anything to be used. JSContact is
more expressive than the alternatives and uses JSON same as OAuth. I have
raised the topic in JMAP and folk there seem amenable to adding to the
format if we need to.

* The contact data is stored encrypted such that the string
"mbqn-a3es-zbye-xp3o-w6et-pqug-go5v" can be used to retrieve the ciphertext
from a .well-known service location on example.com and decrypt to obtain
the plaintext as described below.

* The earl is intended to be used as a bearer token that can locate and
decrypt the data which we encrypt because we don't necessarily want the
service provider to be able to read it. The contact information tied to the
DNS Handle might be used to start a conversation in which Alice provides a
more detailed contact to Bob because she likes him.

* The earl might be passed from Alice to Bob printed on a business card or
encoded in a QR code.

* Third parties might hold the encrypted contact data in a repo to provide
continuity of service if a publisher went down or was being actively
suppressed in some jurisdiction. Only the string "mbqn--" is needed to
identify the ciphertext and decrypt it.

* Yes, I am aware of RFC 6920, I am one of the authors.


Let <contact> be the UTF8 encoding of the JSContact, <service> be the
publisher and bits be the work factor for decryption. The value x is simply
a byte we add to the front of the digest value to allow for algorithm
identification.

<digest> = Base32T ( x+SHA-2-512 (<contact>), bits )

<earl> = "earl://" + <service> + "/" + "<digest>"

<key> = KDF (<digest>, "encrypted-authenticated-resource-locator")
<ciphertext> = AES-512-Encrypt (<contact>, <key>)
<location> = Base32 ( SHA-2-512 (< digest  >))

The value <ciphertext> is then published at:
https://<service>/.well-known/earl/<location>


To resolve the locator, we simply reverse the process and check at the end
to see if the digest of the recovered plaintext matches <digest>

As mentioned above, I have ignored the problem of 'is this Alice's contact
card' from consideration here, to address that we would have to answer
questions like 'is @alice.example.com' Alice's DNS handle and not just 'is
this the correct contact for the handle @alice.example.com'.

I have also bracketed the question of keeping the contact data up to date
because I see that as being like search and the Web - an essential feature
of the system which is best left out of the core platform. I do have a
design for a contact synchronization scheme involving Merkle logs and Bloom
filters, but that is another story.

_______________________________________________
openpgp mailing list -- [email protected]
To unsubscribe send an email to [email protected]