[147722] in cryptography@c2.net mail archive

home help back first fref pref prev next nref lref last post

[Cryptography] PRISM-Proof Email,

daemon@ATHENA.MIT.EDU (Phillip Hallam-Baker)
Thu Oct 17 21:28:42 2013

X-Original-To: cryptography@metzdowd.com
Date: Thu, 17 Oct 2013 18:12:36 -0400
From: Phillip Hallam-Baker <hallam@gmail.com>
To: undisclosed-recipients:;
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com

--===============3519741203827667222==
Content-Type: multipart/alternative; boundary=089e01182d9e896e2a04e8f71d05

--089e01182d9e896e2a04e8f71d05
Content-Type: text/plain; charset=ISO-8859-1

I have produced a first draft of the specification for the Key Publication
service and key management tool that talks to it.

The code being documented is rough. Not least because the ASN.1 encoder I
wrote does not know about ASN.1 inanities like OPTIONAL, IMPLICIT or such
yet so the certs are not DER encoded.

http://tools.ietf.org/html/draft-hallambaker-prismproof-key-00


This specification represents one of the two interfaces to the blob in the
cloud that I call 'research'. We don't yet know the best approach to trust
management but it is going to be a lot easier to find out if we separate
that hard research problem from the 'plumbing' required to make secure
email work.

The other interface is the Omnibroker specification I wrote earlier this
year.

http://tools.ietf.org/html/draft-hallambaker-httpsession-01
http://tools.ietf.org/html/draft-hallambaker-wsconnect-04
http://tools.ietf.org/html/draft-hallambaker-omnibroker-06


I believe that between these specifications we have a fairly complete idea
of what the 'plumbing' side of 'Privacy Protected' Email should look like.

The Strong Email Addresses shown earlier provide a demonstration that we
can solve this problem for at least some class of email user using stock
email clients (OK plus a proxy gateway to send the mail).

If people would like to write code, we are at the point where that is now
practical. In addition it would be very useful if people could find out
information such as how various commonly used email clients store S/MIMe
keys and how might a program do the user's job of configuration for them.

-- 
Website: http://hallambaker.com/

--089e01182d9e896e2a04e8f71d05
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I have produced a first draft of the specification for the=
 Key Publication service and key management tool that talks to it.<div><br>=
</div><div>The code being documented is rough. Not least because the ASN.1 =
encoder I wrote does not know about ASN.1 inanities like OPTIONAL, IMPLICIT=
 or such yet so the certs are not DER encoded.</div>
<div><br clear=3D"all"><div><a href=3D"http://tools.ietf.org/html/draft-hal=
lambaker-prismproof-key-00">http://tools.ietf.org/html/draft-hallambaker-pr=
ismproof-key-00</a><br></div><div><br></div><div><br></div><div>This specif=
ication represents one of the two interfaces to the blob in the cloud that =
I call &#39;research&#39;. We don&#39;t yet know the best approach to trust=
 management but it is going to be a lot easier to find out if we separate t=
hat hard research problem from the &#39;plumbing&#39; required to make secu=
re email work.</div>
<div><br></div><div>The other interface is the Omnibroker specification I w=
rote earlier this year.</div><div><br></div><div><a href=3D"http://tools.ie=
tf.org/html/draft-hallambaker-httpsession-01">http://tools.ietf.org/html/dr=
aft-hallambaker-httpsession-01</a><br>
</div><div><a href=3D"http://tools.ietf.org/html/draft-hallambaker-wsconnec=
t-04">http://tools.ietf.org/html/draft-hallambaker-wsconnect-04</a><br></di=
v><div><a href=3D"http://tools.ietf.org/html/draft-hallambaker-omnibroker-0=
6">http://tools.ietf.org/html/draft-hallambaker-omnibroker-06</a><br>
</div><div><br></div><div><br></div><div>I believe that between these speci=
fications we have a fairly complete idea of what the &#39;plumbing&#39; sid=
e of &#39;Privacy Protected&#39; Email should look like.</div><div><br>
</div><div>The Strong Email Addresses shown earlier provide a demonstration=
 that we can solve this problem for at least some class of email user using=
 stock email clients (OK plus a proxy gateway to send the mail).</div><div>
<br></div><div>If people would like to write code, we are at the point wher=
e that is now practical. In addition it would be very useful if people coul=
d find out information such as how various commonly used email clients stor=
e S/MIMe keys and how might a program do the user&#39;s job of configuratio=
n for them.</div>
<div><br></div>-- <br>Website: <a href=3D"http://hallambaker.com/">http://h=
allambaker.com/</a><br>
</div></div>

--089e01182d9e896e2a04e8f71d05--

--===============3519741203827667222==
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
--===============3519741203827667222==--

home help back first fref pref prev next nref lref last post