[Cryptography] MITM source patching [was Schneier got spooked]

[Phillip Hallam-Baker]

On Mon, Sep 16, 2013 at 2:48 PM, zooko <zooko at 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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20130916/f27881d8/attachment.html>