dotgnu-general
[Top][All Lists]
Advanced

[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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]