[147161] in cryptography@c2.net mail archive
Re: [Cryptography] MITM source patching [was Schneier got spooked]
daemon@ATHENA.MIT.EDU (Phillip Hallam-Baker)
Mon Sep 16 17:41:29 2013
X-Original-To: cryptography@metzdowd.com
In-Reply-To: <20130916184805.GB7295@zooko.com>
Date: Mon, 16 Sep 2013 15:27:36 -0400
From: Phillip Hallam-Baker <hallam@gmail.com>
To: zooko <zooko@zooko.com>
Cc: "cryptography@metzdowd.com" <cryptography@metzdowd.com>,
Tim Newsham <tim.newsham@gmail.com>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
--===============3580741803948390567==
Content-Type: multipart/alternative; boundary=001a11c373e456454404e685325f
--001a11c373e456454404e685325f
Content-Type: text/plain; charset=ISO-8859-1
On Mon, Sep 16, 2013 at 2:48 PM, zooko <zooko@zooko.com> wrote:
> On Sun, Sep 08, 2013 at 08:28:27AM -0400, Phillip Hallam-Baker wrote:
> >
> > It think we need a different approach to source code management. Get rid
> of
> > user authentication completely, passwords and SSH are both a fragile
> > approach. Instead every code update to the repository should be signed
> and
> > recorded in an append only log and the log should be public and enable
> any
> > party to audit the set of updates at any time.
> >
> > This would be 'Code Transparency'.
>
> This is a very good idea, and eminently doable. See also Ben Laurie's blog
> post:
>
> http://www.links.org/?p=1262
>
> > Problem is we would need to modify GIT to implement.
>
> No, simply publish the git commits (hashes) in a replicated, append-only
> log.
>
Well people bandwidth is always a problem.
But what I want is not just the ability to sign, I want to have a mechanism
to support verification and checking of the log etc. etc.
> So what's the next step? We just need the replicated, append-only log.
>
Where I am headed is to first divide up the space for PRISM-PROOF email
between parts that are solved and only need good execution (message
formats, mail integration, etc) and parts that are or may be regarded as
research (key distribution, key signing, PKI).
Once that is done I am going to be building myself a very lightweight
development testbed built on a SMTP/SUBMIT + IMAP proxy.
But hopefully other people will see that there is general value to such a
scheme and work on:
[1] Enabling MUAs to make use of research built on the testbed.
[2] Enabling legacy PKI to make use of the testbed.
[3] Research schemes
Different people have different skills and different interests. My interest
is on the research side but other folk just want to write code to a clear
spec. Anyone going for [3] has to understand at the outset that whatever
they do is almost certain to end up being blended with other work before a
final standard is arrived at. We cannot afford another PGP/SMIME debacle.
On the research side, I am looking at something like Certificate
Transparency but with a two layer notary scheme. Instead of the basic
infrastructure unit being a CA, the basic infrastructure unit is a Tier 2
append only log. To get people to trust your key you get it signed by a
trust provider. Anyone can be a trust provider but not every trust provider
is trusted by everyone. A CA is merely a trust provider that issues policy
and practices statements and is subject to third party audit.
The Tier 2 notaries get their logs timestamped by at least one Tier 1
notary and the Tier 1 notaries cross notarize.
So plugging code signing projects into a Tier 2 notary would make a lot of
sense.
We could also look at getting Sourceforge and GITHub to provide support
maybe.
--
Website: http://hallambaker.com/
--001a11c373e456454404e685325f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Mon, Sep 16, 2013 at 2:48 PM, zooko <span dir=3D"ltr"><<a hre=
f=3D"mailto:zooko@zooko.com" target=3D"_blank">zooko@zooko.com</a>></spa=
n> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On Sun, Sep 08, 2013 at 08=
:28:27AM -0400, Phillip Hallam-Baker wrote:<br>
><br>
> It think we need a different approach to source code management. Get r=
id of<br>
> user authentication completely, passwords and SSH are both a fragile<b=
r>
> approach. Instead every code update to the repository should be signed=
and<br>
> recorded in an append only log and the log should be public and enable=
any<br>
> party to audit the set of updates at any time.<br>
><br>
> This would be 'Code Transparency'.<br>
<br>
</div>This is a very good idea, and eminently doable. See also Ben Laurie&#=
39;s blog<br>
post:<br>
<br>
<a href=3D"http://www.links.org/?p=3D1262" target=3D"_blank">http://www.lin=
ks.org/?p=3D1262</a><br>
<div class=3D"im"><br>
> Problem is we would need to modify GIT to implement.<br>
<br>
</div>No, simply publish the git commits (hashes) in a replicated, append-o=
nly log.<br></blockquote><div><br></div><div>Well people bandwidth is alway=
s a problem.</div><div><br></div><div>But what I want is not just the abili=
ty to sign, I want to have a mechanism to support verification and checking=
of the log etc. etc.</div>
<div><br></div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
So what's the next step? We just need the replicated, append-only log.<=
br></blockquote><div><br></div><div>Where I am headed is to first divide up=
the space for PRISM-PROOF email between parts that are solved and only nee=
d good execution (message formats, mail integration, etc) and parts that ar=
e or may be regarded as research (key distribution, key signing, PKI).</div=
>
<div><br></div><div>Once that is done I am going to be building myself a ve=
ry lightweight development testbed built on a SMTP/SUBMIT + IMAP proxy.=A0<=
/div><div><br></div><div>But hopefully other people will see that there is =
general value to such a scheme and work on:</div>
<div><br></div><div>[1] Enabling MUAs to make use of research built on the =
testbed.</div><div><br></div><div>[2] Enabling legacy PKI to make use of th=
e testbed.</div><div><br></div><div>[3] Research schemes</div><div>=A0</div=
>
</div><div><br></div><div>Different people have different skills and differ=
ent interests. My interest is on the research side but other folk just want=
to write code to a clear spec. Anyone going for [3] has to understand at t=
he outset that whatever they do is almost certain to end up being blended w=
ith other work before a final standard is arrived at. We cannot afford anot=
her PGP/SMIME debacle.</div>
<div><br></div><div>On the research side, I am looking at something like Ce=
rtificate Transparency but with a two layer notary scheme. Instead of the b=
asic infrastructure unit being a CA, the basic infrastructure unit is a Tie=
r 2 append only log. To get people to trust your key you get it signed by a=
trust provider. Anyone can be a trust provider but not every trust provide=
r is trusted by everyone. A CA is merely a trust provider that issues polic=
y and practices statements and is subject to third party audit.</div>
<div><br></div><div><br></div><div>The Tier 2 notaries get their logs times=
tamped by at least one Tier 1 notary and the Tier 1 notaries cross notarize=
.</div><div><br></div><div>So plugging code signing projects into a Tier 2 =
notary would make a lot of sense.</div>
<div><br></div><div>We could also look at getting Sourceforge and GITHub to=
provide support maybe.</div><div><br></div><div><br></div>-- <br>Website: =
<a href=3D"http://hallambaker.com/">http://hallambaker.com/</a><br>
</div></div>
--001a11c373e456454404e685325f--
--===============3580741803948390567==
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
--===============3580741803948390567==--
