[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
this:-
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;
redelegate=2
Assert: http://www.w3.org/people/hallam/assertions; signed=KEY:RSA:phill
Phill
References: