[Cryptography] Cryptographic mailto: URI

Phillip Hallam-Baker hallam at gmail.com
Thu Sep 19 13:15:50 EDT 2013

I am in mid design here but I think I might have something of interest.

Let us say I want to send an email to alice at example.com securely.

Now obviously (to me anyway) we can't teach more than a small fraction of
the net to use any identifier other than the traditional email address.

So we need some sort of directory infrastructure to allow discovery of
those email addresses and it would be good to be able to reuse existing
directories if at all possible.

But how do we insert the email addresses into a directory like LinkedIn?
Well you can add a URI into your account. So what if the URI is of the form:

ppid:alice at example.com:example.net:


alice at example.com is Alice's email address for secure communications

example.net is a server which will resolve the reference by means of a
simple HTTP query using the pattern http://<host>/.well-known/ppid/<hash>

"Syd...NWM" is the Base64 hash of OID-SHA256 + SHA256(X)

X is a public key that signs a document (probably JSON) that specifies:

* X
* Alice's certificate(s)
* Alice's email receipt policy whether to always encrypt, what message
formats are supported
* links to whatever additional advice information might help convince a
relying party the key is genuine like a CT log.
* reliance policy (is this key for public use or restricted)
* reporting policy (for future changes)

So to use this as a mechanism for ghetto key distribution receivers would
add the URI into their account. Or let their PKI discovery agent do it for

Senders would enable their PKI discovery agent to access their LinkedIn

It would slurp down the data once a day (say) and keep it in a cache for
use by that user alone unless it is marked public when any user of the PKI
discovery agent can make use of it.

It would attempt to validate the information obtained, possibly resulting
in a report if it detected a change in a previously registered key that had
not been properly countersigned by the old.

The validated info would then be used to encrypt the outbound mail
according to the specified policy.


1) This is only about key discovery, not validation.

2) Better to send email encrypted under a key that is not validated than in
the clear.

3) A MUA should offer the option 'force encryption' however. And in that
case it would barf if the key provided didn't meet the validation criteria.

Website: http://hallambaker.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20130919/39c06cf1/attachment.html>

More information about the cryptography mailing list