[469] in WWW Security List Archive

home help back first fref pref prev next nref lref last post

Barring Bros Was:Re: SLL protocol implementation ?

daemon@ATHENA.MIT.EDU (Phillip M. Hallam-Baker)
Tue Feb 28 09:34:52 1995

To: www-security@ns2.rutgers.edu
cc: hallam@dxal18.cern.ch
In-reply-to: Your message of "Tue, 28 Feb 1995 00:33:53 PST."
Date: 	Tue, 28 Feb 1995 12:06:10 +0900
From: "Phillip M. Hallam-Baker" <hallam@dxal18.cern.ch>
Reply-To: www-security@ns2.rutgers.edu
Errors-To: owner-www-security@ns2.rutgers.edu

>It should be very straightforward -- either implementing purely from
>the protocol spec (http://home.netscape.com/info/SSL.html) or licensing
>sslref (a low flat-fee arrangement -- contact me for more info if you're
>interested) are both viable and low-effort approaches.

It should be but it isn't! Your government has some peculiar export
license ideas :-(

SSL and S-HTTP/Shen are trying to do rather different things. SSL is trying
to secure the Web, S-HTTP is trying to build security into HTTP. Its a very 
different character of security you get. One wouldn't look to using SSL to base 
a payments scheme on. 

Shen is a collevction of ideas of how to manage trust. Given the failure of 
Barring bros yesterday placing limits on the exercise of certificates looks to 
be very important. 

We should look to create a stock market spec ASAP. The Barrings collapse could 
have been prevented by attaching attributes to the certificate (cf PKCS certs).
The following is extrapolating the scheme I was looking at to make e-trade
work for an organisation like CERN.

Theoretical model:

The bank issues a master certificate which is signed by the board of the stock 
exchange. This has the attribute "May sign another certificate with equal
effect". The Bank also place the stock exchange master certificate in their 
personal trust hierarchy. 

The Bank mints subcertificates for each of its traders, these may have 
attributes of the type "Valid for transactions up to $10^6", "Valid provided it 
is countersigned". 

The losses of the bank with respect to any one trader are thus limited.
[Maths ommitted because it dosen't work in ascii]

Practical Model:

Real stock markets are more complex. Particularly with respect to selling 
options where the losses are open ended. The set of attributes must be 
determined to fit. The key point is that the attribute set must be given a fixed 
semantics by all the parties. There are two main options here :-

1) The stock market board sets the attribute semantics.

2) Each company may define their own semantics.

(1) is easiest to implement, (2) is easiest to administer. What is actually 
needed is a set of Meta semantics which allow the creation of a semantics which 
fits the application. 

Base Attribute types:
1) Purchase Limit.
2) Vendor Limit
3) Product restriction

Attribute Operators:
1) And
2) Or
3) Not

Meta Attributes:
1) Require countersignature.
2) Require notification after contract is struck

Algorithm Attributes
1) Allow particular signature algorithm to be used
2) Allow particular contract agreement protocol to be used.

So a certificate might be specific at the level of stating "this certificate may 
be used to sell put options in gold to the value of $1000".

A market may be made more practical by allowing notifications to be made on a 
probabalistic basis. "Inform this authority of the action at least 10% and no 
more than 20% of the time. There could also be systems built in to deal with 
fast markets when it would be advantageous to put the checking offline.

If people are interested I could put out a draft RFC PDQ. I'm interested in what 
peoples ideas on a standard attribute set might be. If anyone has stock market 
experience then it would be a big advantage.

Stock markets are the most demanding application for e-trade in many ways. They
are the simplest in one respect however. They are centralised and computerised 
making introduction administratively easier than changing everyones credit card.

	Phill Hallam-Baker

home help back first fref pref prev next nref lref last post