Subject: [Arcing] The PrismProof Naming Games

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 6 Apr 2016 23:53:00 +0000 (UTC)

I see two types of naming scheme:
1) One that avoids ambiguity by means of a registry2) One that avoids ambiguity by means of random or cryptographic techniques   2a) Random strings (e.g. GUIDs)   2b) Cryptographic digest of the data itself - limited to static data   2c) Cryptographic digest of a public signature key - permits identification of dynamic data.
The last is the most flexible that does not require registration.
A while back, as part of my PrismProof usable end-to end email project, I looked into ways of creating email addresses that had the following properties:
1) Compatible with existing email clients, contacts directories etc. Can be entered without code changes.2) Break when existing SMTP infratrustructure attempts to process3) Contain a fingerprint of a public key that is a root of trust for an email user.
The objective here is to be able to use an existing email client (Thunderbird, Windows Live Mail, Outlook) to send and receive S/MIME and OpenPGP encrypted mail with zero user impact and without the need to make use of an application plugin. All the 'PrismProof' part was performed by an SMTP/IMAP proxy performing any necessary encryption, key discovery, etc.
[Obviously, this is not the desired endpoint, I want apps to support the infrastructure native. But I have come to loathe application plugins because they do not compose]
The fingerprint format I am using is not particularly important here except to note that it is designed to support versioning and also resist content type substitution attacks by calculating BASE32 (SHA-2-512 (<IANA-content-type> + ":" + SHA-2-512 (<content>)))
https://tools.ietf.org/html/draft-hallambaker-udf-03

So the approach the initial SMTP code took was to use the fact that a question mark is a de-facto non permitted character in an email address even though most clients accept use.
MB2GK-6DUF5-YGYYL-JNY5E-RWSHZ?[email-masked]
In the 2014 implementation, this was interpreted as 'send mail to [email-masked] but only if an email security profile for [email-masked] can be located that has a valid signature with a key authorized under a trust root with the fingerprint MB2GK-6DUF5-YGYYL-JNY5E-RWSHZ'

Which worked well enough for SMTP.  But then I got thinking of things like, how do I make use of the same approach in other applications, how do I make that General?
So I started looking at
[email-masked]
Which looked good till I realized that, 1) I am not doing TOR and 2) in my world, the root of authority is that fingerprint. It specifies the entire trust context in which all else is interpreted. It could specify a different DNSSEC root, it could specify WebPKI roots.
So really, the email address should be:
[email-masked]
Or if the profile is personal to just Alice and specifies where to send mail, it could just be
Anon@MB2GK-6DUF5-YGYYL-JNY5E-RWSHZ

Sent from Outlook Mobile