river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sim IJskes - QCG <...@qcg.nl>
Subject Re: Application Code Auditing & Signing Area
Date Mon, 18 Jan 2010 10:22:15 GMT
Peter Firmstone wrote:
> When all is said & done, there is enough compute power, heck, River is a 
> distributed system, it all comes down to trusting code.  We have the 
> tools to sign, we have the tools to check integrity.  If we can clarify 
> proxy verification from the server side, we've got it made.  How do we 
> make sure the client side isn't compromised?

We verify trust on both sides by having the public part of the root of 
the chain in the certificate, in our keystore. (right?).

During first time deployment the public root cert is deployed together 
with the program code we trust implicitly.

Then we download code from an unknown (or potential rogue) source, and 
verify trust with the cert chain.

I would not trust code that is signed in the 3rd degree. I'm not sure if 
this is enforcable (currently?). And i don't like to depend on cert 
providers (for cost reasons for instance).

So in practice i foresee the following. There is a central deployment 
source for code & rootcerts. 1 rootcert identifies the deployment 
cloud/cluster/environment. Every node identifies itself by a indiviual 
cert signed by this rootcert. There is a cert generation facility 
running on the central deployment source, that allows for generation of 
new certs based on a cert request, signed with a external 
identification. The cert generation facility accepts this request either 
implicitly or by some other external verification.

By having all certs that i trust directly signed by a rootcert that i 
trust, i make sure everybody plays for the same team.

Anyhow, i believe we need to detach ourselfs from the notion the 
trustable certs are only generated by companies that charge a lot of money.

Also, would i trust all code signed by an apache cert? Or just the code 
signed by a delegate of an apache cert?

The problem with executing signed code is that one becomes an actor. We 
become responsible for the actions of that code. And the defence that 
one was an unwilling agent for malignent code becomes very thin when the 
people find out it was based on a trust relationship established some 
time ago. (a judge in a court would say: you should be a better judge of 
character, but your still responsible).

I can see parallels between downloading a program from a website and 
executing it, but we are talking here about pre-vetted code, and i would 
like to judge that personally on a case to case basis, instead of an 
automated process that can happen even when i sleep.

Gr. Sim

-- 
QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
Quality Consultancy Group b.v., Leiderdorp, Kvk Leiden: 28088397

Mime
View raw message