[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: specification language?

>Full R4RS Scheme would be too "dangerous".

>A subset of scheme would be very interesting -- you'd want to cut out
>the file I/O primitives at least.

Too dangerous and too damn big. there are a number of levels we could work 

1) define a data structure and use a well explored notation (e.g. 
        s-expressions) to encapsulate it.

2) use a scheme engine stripped of access to sensitive objects.

3) Do something derranged.

I would put into the 3 category any language which is designed for general 
purpose use - i.e. including file I/O operations and the like. I am not a fan of 
safe tcl, the run time is huge and hacky and the syntax is not all that good.

What we need is something that allows us to construct certificates in an 
extensible manner. Do we really need to be able to declare proceedures and 
functions? Could we manage with something much simpler?

In the latter category I would class Shen MkII which is based on a very simple 
assertion layer e.g.:-

Assert: http://www.whitehouse.gov/%*; signed=KEY:RSA:bill
Assert: http://zorch.w3.org:6001/%*; signed=KEY:RSA:server
Assert: http://zorch.w3.org:6001/; signed=KEY:RSA:server
Assert: http://zorch.w3.org:6001/secrets/%*; encrypt=KEY:RSA:server

[This could be lispified as 
        ((assert http://www.whitehouse.gov/%*; ((signed KEY:RSA:bill)))
         (assert ... ))))))))

The URis KEY:RSA:* are names for RSA encryption keys. The actual key could be 
specified instead eg RSA:9xMihEdvDt66rXDpf34NayyWWfe...kM2qArK+xqcUNbxOZw==

The URIs with the %* bits in them are wildcarded URIs.

This file may be loosely interpreted as follows:

"All resources from www.whitehouse.gov are signed by bill"
"All resources from zorch.w3.org:6001 are signed by server"
"The resource http://zorch.w3.org:6001/; is signed by server"
"Access to the resources http://zorch.w3.org:6001/secrets/%*; requires
        use of encryption under the key server"

The use of strongly typed keys simplifies the job of negotiation to a very large 
extent. Negotiating the key also means that the algorithm has been negotiated.

The question is what trust can be deduced from this system. Here I would like 
people to attempt to get out of the traditional CA concept of trying to provide 
trust. Instead let us concentrate on trying to avoid bad things happening. There 
is a subtle but important difference.

The idea I had was that we start by using unauthenticated lists of assertions. 
After all we will never get anything done if we insist that everything be proven 
beyond doubt. The assertions made are effectively a series of warnings. If I get 
the assertion list and apply it then my browser should give me a warning 
whenever an assertion fails - e.g. I download a whitehouse document and it
has no signature.

The next stage up is that we begin signing sets of assertions. Forget for a 
moment the problem of establishing a chain of trust. Just concentrate on what a 
signed list of assertions gives us. The browser can pop up a warning box stating 
that an authenticated list of assertions has been violated.

The next stage along is to add delegation. This is the tricky stage. Consider 
that we add delegation under two parameters, the first governs the domain for 
which the delegtion is valid the second specifies whether we will permit the 
delegated trust to be delegated itself. eg

Delegate: http://www.w3.org/people/hallam/assertions; domain=execute;
Assert: http://www.w3.org/people/hallam/assertions; signed=KEY:RSA:phill