<div dir="ltr"><div>I am in mid design here but I think I might have something of interest.</div><div><br></div><div>Let us say I want to send an email to <a href="mailto:alice@example.com">alice@example.com</a> securely. </div>
<div><br></div><div>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.</div><div><br></div><div>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.</div>
<div><br></div><div><br></div><div>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:</div><div><br></div><div>ppid:alice@example.com:example.net:Syd6BMXje5DLqHhYSpQswhPcvDXj+8rK9LaonAfcNWM</div>
<div><br></div><div>Where </div><div><br></div><div><a href="mailto:alice@example.com">alice@example.com</a> is Alice's email address for secure communications</div><div><br></div><div><a href="http://example.net">example.net</a> is a server which will resolve the reference by means of a simple HTTP query using the pattern http://<host>/.well-known/ppid/<hash></div>
<div><br></div><div>"Syd...NWM" is the Base64 hash of OID-SHA256 + SHA256(X)</div><div><br></div><div>X is a public key that signs a document (probably JSON) that specifies:<br></div><div><br></div><div>* X</div>
<div>* Alice's certificate(s)</div><div>* Alice's email receipt policy whether to always encrypt, what message formats are supported</div><div>* links to whatever additional advice information might help convince a relying party the key is genuine like a CT log.</div>
<div>* reliance policy (is this key for public use or restricted)</div><div>* reporting policy (for future changes)</div><div><br></div><div>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.</div>
<div><br></div><div><br></div><div>Senders would enable their PKI discovery agent to access their LinkedIn account. </div><div><br></div><div>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.<br>
</div><div><br></div><div>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.</div>
<div><br></div><div>The validated info would then be used to encrypt the outbound mail according to the specified policy.</div><div><br></div><div><br></div><div>Notes:</div><div><br></div><div>1) This is only about key discovery, not validation. </div>
<div><br></div><div>2) Better to send email encrypted under a key that is not validated than in the clear.</div><div><br></div><div>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.</div>
<div><br></div><div><br></div>-- <br>Website: <a href="http://hallambaker.com/">http://hallambaker.com/</a><br>
</div>