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 [email protected] 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:[email protected]:example.net: Syd6BMXje5DLqHhYSpQswhPcvDXj+8rK9LaonAfcNWM Where [email protected] 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/
_______________________________________________ The cryptography mailing list [email protected] http://www.metzdowd.com/mailman/listinfo/cryptography
