[147244] in cryptography@c2.net mail archive
[Cryptography] Cryptographic mailto: URI
daemon@ATHENA.MIT.EDU (Phillip Hallam-Baker)
Thu Sep 19 14:12:04 2013
X-Original-To: cryptography@metzdowd.com
Date: Thu, 19 Sep 2013 13:15:50 -0400
From: Phillip Hallam-Baker <hallam@gmail.com>
To: "cryptography@metzdowd.com" <cryptography@metzdowd.com>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
--===============2876158421737231379==
Content-Type: multipart/alternative; boundary=001a11c32e88a8eab304e6bfb4ea
--001a11c32e88a8eab304e6bfb4ea
Content-Type: text/plain; charset=ISO-8859-1
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@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@example.com:example.net:
Syd6BMXje5DLqHhYSpQswhPcvDXj+8rK9LaonAfcNWM
Where
alice@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/
--001a11c32e88a8eab304e6bfb4ea
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>I am in mid design here but I think I might have some=
thing of interest.</div><div><br></div><div>Let us say I want to send an em=
ail to <a href=3D"mailto:alice@example.com">alice@example.com</a> securely.=
=A0</div>
<div><br></div><div>Now obviously (to me anyway) we can't teach more th=
an a small fraction of the net to use any identifier other than the traditi=
onal email address.</div><div><br></div><div>So we need some sort of direct=
ory 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@exam=
ple.com:example.net:Syd6BMXje5DLqHhYSpQswhPcvDXj+8rK9LaonAfcNWM</div>
<div><br></div><div>Where=A0</div><div><br></div><div><a href=3D"mailto:ali=
ce@example.com">alice@example.com</a> is Alice's email address for secu=
re communications</div><div><br></div><div><a href=3D"http://example.net">e=
xample.net</a> is a server which will resolve the reference by means of a s=
imple 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 documen=
t (probably JSON) that specifies:<br></div><div><br></div><div>* X</div>
<div>* Alice's certificate(s)</div><div>* Alice's email receipt pol=
icy whether to always encrypt, what message formats are supported</div><div=
>* links to whatever additional advice information might help convince a re=
lying 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 UR=
I 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.=A0</div><div><br></div><div>It wou=
ld slurp down the data once a day (say) and keep it in a cache for use by t=
hat user alone unless it is marked public when any user of the PKI discover=
y agent can make use of it.<br>
</div><div><br></div><div>It would attempt to validate the information obta=
ined, possibly resulting in a report if it detected a change in a previousl=
y 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 ou=
tbound 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 disco=
very, not validation.=A0</div>
<div><br></div><div>2) Better to send email encrypted under a key that is n=
ot validated than in the clear.</div><div><br></div><div>3) A MUA should of=
fer the option 'force encryption' however. And in that case it woul=
d barf if the key provided didn't meet the validation criteria.</div>
<div><br></div><div><br></div>-- <br>Website: <a href=3D"http://hallambaker=
.com/">http://hallambaker.com/</a><br>
</div>
--001a11c32e88a8eab304e6bfb4ea--
--===============2876158421737231379==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
--===============2876158421737231379==--
