[147254] in cryptography@c2.net mail archive
Re: [Cryptography] Cryptographic mailto: URI
daemon@ATHENA.MIT.EDU (Phillip Hallam-Baker)
Sat Sep 21 18:20:34 2013
X-Original-To: cryptography@metzdowd.com
In-Reply-To: <17AC7CAF-21B0-49E4-8815-1896736B37B5@webweaving.org>
Date: Fri, 20 Sep 2013 08:55:48 -0400
From: Phillip Hallam-Baker <hallam@gmail.com>
To: Dirk-Willem van Gulik <dirkx@webweaving.org>
Cc: "cryptography@metzdowd.com" <cryptography@metzdowd.com>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
--===============1829871773753357674==
Content-Type: multipart/alternative; boundary=089e01160098820c5b04e6d030d4
--089e01160098820c5b04e6d030d4
Content-Type: text/plain; charset=ISO-8859-1
On Fri, Sep 20, 2013 at 4:36 AM, Dirk-Willem van Gulik <dirkx@webweaving.org
> wrote:
>
> Op 19 sep. 2013, om 19:15 heeft Phillip Hallam-Baker <hallam@gmail.com>
> het volgende geschreven:
>
> > Let us say I want to send an email to alice@example.com securely.
> ...
> > ppid:alice@example.com:example.net:
> Syd6BMXje5DLqHhYSpQswhPcvDXj+8rK9LaonAfcNWM
> ...
> > 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)
> ..
> > 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.
>
> We've been experimenting with much the same. With two twists. Basic
> principle is the same.
>
> We use:
>
> - <namespace>:<id>
>
> as to keep it short. ID is currently a <sha1>; namespace is a 2-3 char
> identifier. We then construct with this a 'hardcoded' zone name:
>
> <namespace>.fqdn-in-some-tld.
>
> which is to have a (signed) entry for in DNS:
>
> <id>.<ns>.<namespace>.fqdn-in-some-tld.
>
> which is in fact a first-come, first-served secure dynamic dns updatable
> zone containing the public key.
>
> Which once created allows only updating to those (still) having the
> private key of the public key that signed the initial claim of that <id>.
>
Interesting, though I suspect this is attempting to meet different trust
requirements than I am.
A couple of days ago I spoke with someone well known here who has seen the
Snowden files. His take was that when the NSA has a choice of doing A or B
it always does both.
I think we need to adopt the same approach but in a way that lets all the
various approaches work together. It should not be necessary for me to
install five plug ins into Thunderbird to support five different flavors of
researchy trust infrastructure.
A better approach is to have one plug-in, or better native support for a
connector to a Web Service that can then perform all the researchy trust
infrastructure navigation on my behalf. The Web service can be shared
between users and when there is a new researchy trust infrastructure
proposed, all that is necessary to add it into the mix is to extend the Web
Service and everyone using it can try out the new scheme and see if it is
practical.
This approach does introduce the risk that the web service might be
compromised. Particularly if the client is unable to perform at least some
degree of local validation on the keys. But the long term expectation would
be that support for trust infrastructures that prove to be stable, widely
used, and effective will eventually migrate into the client.
At this point the experimental research question should be 'is this trust
infrastructure practical'. We can get a very good idea of the security
properties of the system by looking at how people use it and doing math.
--
Website: http://hallambaker.com/
--089e01160098820c5b04e6d030d4
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Fri, Sep 20, 2013 at 4:36 AM, Dirk-Willem van Gulik <sp=
an dir=3D"ltr"><<a href=3D"mailto:dirkx@webweaving.org" target=3D"_blank=
">dirkx@webweaving.org</a>></span> wrote:<br><div class=3D"gmail_extra">=
<div class=3D"gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><br>
Op 19 sep. 2013, om 19:15 heeft Phillip Hallam-Baker <<a href=3D"mailto:=
hallam@gmail.com">hallam@gmail.com</a>> het volgende geschreven:<br>
<div class=3D"im"><br>
> Let us say I want to send an email to <a href=3D"mailto:alice@example.=
com">alice@example.com</a> securely.<br>
</div>...<br>
> ppid:alice@example.com:example.net:Syd6BMXje5DLqHhYSpQswhPcvDXj+8rK9La=
onAfcNWM<br>
...<br>
<div class=3D"im">> <a href=3D"http://example.net" target=3D"_blank">exa=
mple.net</a> is a server which will resolve the reference by means of a sim=
ple HTTP query using the pattern http://<host>/.well-known/ppid/<h=
ash><br>
> "Syd...NWM" is the Base64 hash of OID-SHA256 + SHA256(X)<br>
</div>..<br>
<div class=3D"im">> So to use this as a mechanism for ghetto key distrib=
ution receivers would add the URI into their account. Or let their PKI disc=
overy agent do it for them.<br>
<br>
</div>We've been experimenting with much the same. With two twists. Bas=
ic principle is the same.<br>
<br>
We use:<br>
<br>
- =A0 =A0 =A0 <namespace>:<id><br>
<br>
as to keep it short. ID is currently a <sha1>; namespace is a 2-3 cha=
r identifier. We then construct with this a 'hardcoded' zone name:<=
br>
<br>
=A0 =A0 =A0 =A0 <namespace>.fqdn-in-some-tld.<br>
<br>
which is to have a (signed) entry for in DNS:<br>
<br>
=A0 =A0 =A0 =A0 <id>.<ns>.<namespace>.fqdn-in-some-tld.<b=
r>
<br>
which is in fact a first-come, first-served secure dynamic dns updatable zo=
ne containing the public key.<br>
<br>
Which once created allows only updating to those (still) having the private=
key of the public key that signed the initial claim of that <id>.<br=
></blockquote><div><br></div><div>Interesting, though I suspect this is att=
empting to meet different trust requirements than I am.</div>
<div><br></div><div>A couple of days ago I spoke with someone well known he=
re who has seen the Snowden files. His take was that when the NSA has a cho=
ice of doing A or B it always does both.</div><div><br></div><div>I think w=
e need to adopt the same approach but in a way that lets all the various ap=
proaches work together. It should not be necessary for me to install five p=
lug ins into Thunderbird to support five different flavors of researchy tru=
st infrastructure.=A0</div>
<div><br></div><div>A better approach is to have one plug-in, or better nat=
ive support for a connector to a Web Service that can then perform all the =
researchy trust infrastructure navigation on my behalf. The Web service can=
be shared between users and when there is a new researchy trust infrastruc=
ture proposed, all that is necessary to add it into the mix is to extend th=
e Web Service and everyone using it can try out the new scheme and see if i=
t is practical.=A0</div>
<div><br></div><div><br></div><div>This approach does introduce the risk th=
at the web service might be compromised. Particularly if the client is unab=
le to perform at least some degree of local validation on the keys. But the=
long term expectation would be that support for trust infrastructures that=
prove to be stable, widely used, and effective will eventually migrate int=
o the client.</div>
<div><br></div><div><br></div><div>At this point the experimental research =
question should be 'is this trust infrastructure practical'. We can=
get a very good idea of the security properties of the system by looking a=
t how people use it and doing math.</div>
</div><br clear=3D"all"><div><br></div>-- <br>Website: <a href=3D"http://ha=
llambaker.com/">http://hallambaker.com/</a><br>
</div></div>
--089e01160098820c5b04e6d030d4--
--===============1829871773753357674==
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
--===============1829871773753357674==--
