[Cryptography] Cryptographic mailto: URI

[Phillip Hallam-Baker]

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:
Syd6BMXje5DLqHhYSpQswhPcvDXj+8rK9LaonAfcNWM

Where

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
them.


Senders would enable their PKI discovery agent to access their LinkedIn
account.

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.


Notes:

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>