[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [DotGNU]Signing Webservices ?
From: |
Chris Smith |
Subject: |
Re: [DotGNU]Signing Webservices ? |
Date: |
Fri, 25 Apr 2003 12:34:08 +0100 |
User-agent: |
KMail/1.4.3 |
On Friday 25 Apr 2003 09:53, Norbert Bollow wrote:
> > 2. As to the validity of a function for execution, is is possible to
> > make function calls that are checked by the dotgnu runtime?
>
> Do you mean IL verification, or do you mean checking digital
> signatures on chunks of bytecode?
We can't do it via IL verification as the webservice may be python....
However I think I've got a solution.
Every webervice requires a dgmx file to describe its contents (this is because
introspection is not available in things like python and perl etc).
The DGMX file contains the md5/sha1 sum of the webservice.
The DGMX file is also signed by the author/vendor/distributer.
For special 'priveliged' webservices that are officially part of the DGEE or
Abdabi etc they can be signed by the 'DotGNU Group'. The DGEE can verify
this signature and open up the DGEE priveliges for it.
Distribution becomes an issue here though.
For people interested in installing and running the DGEE they will need to
obtain these webservices/dgmx pairs in a pre-signed form from the DotGNU
site. They can come as part of the distribution, but the user should verify
that they are signed by the DotGNU Group and thus are trusted. The DotGNU
Group's public key should be made available for this purpose.
People who what to install the DGEE and develop for it (like ourselves) can
register themselves as 'privelidged signees' with their local DGEE and sign
webservices themselves. If anyone else wants to use these webservices that
require particular permissions (because they are perhaps extending the DGEE
or Abdabi etc) then they will either have to be signed by the DotGNU Group or
signed by the owner of the DGEE that they are to be run on - in this case the
DGEE owner has to trust the code that is being run, and the risk is on them.
How does this sound?
It does mean that the DGEE is able to verify that the dgmx file belongs to a
particular webservice because of the sum, and that the dgmx file was signed
by a particular user or organisation and has not been tampered with.
Knowing the organisation/user also allows extended priveliges to be turned on
automatically.
> > 3. The penalty for loading must be on the startup, when a webservice is
> > registered to run, the validity must be established. The signing idea
> > is good.
The reasons for the existence of the dgmx file are endless :o)
> > Basically the person running the server must trust the person writing
> > the webservice.
>
> Or someone who is recommending it (this could even be indirect, via a
> web of trust).
Fits in with my argument above.
Unless anyone has any objections, I'm going to finish building the above into
the dgmx support. It feels quite an open solution to me.
For signing and all that I'll use gpg (or rather try and use libgcrypt as I've
got to embed signature checking within the DGEE core).
Cheers
--
Chris Smith
Technical Architect - netFluid Technology Ltd.
"Internet Technologies, Distributed Systems and Tuxedo Consultancy"
E: address@hidden W: http://www.nfluid.co.uk