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

Re: comments on client auth

Brian's comments have got me thinking.

First I think that the Verisign position while understandable is a bit off base. 
Of course anyone who wants to make a business out of this area should base it on 
X.509v3, at least for the next couple of years.

What SDSI is trying to achieve is somewhat different, it is motivated by the 
work Matt Blaze and others have been doing with policymaker and on Butler 
Lampson's experience with TAOS. What SDSI is trying to provide is an operating 
system level security scheme and be a step towards a network operating system 
security scheme.

The starting point for the network operating system is that there is no 
"operator", nobody has SYSTEM priv for the net as a whole. This means that a lot 
of problems with authentication that have been swept under the carpet 
traditionaly have to be solved. Chief amongst these being that anyone should be 
able to configure systems.

I think that we should be clear to distinguish between two different 
interpretations of chained namespaces. IN SDSI I can create a name using a path 
- "RSA.com's Verisign.com" I think that this is impractical since it fragments 
the namespace preventing any equality tests is RSA.com's verisign.com the same 
as openmarket's ?

The basis of the Web is to finesse the naming scheme issue by overloading DNS. 
So the statement becomes "The entity which rsa.com believe to have IANA DNS 
registration verisign.com" as opposed to "The entity which rsa.com calls 
verisign.com". I recomend that SPKI follow the Web epistemology.

It is very useful to be able to construct a label which differentiates between 
two roots to the same principle. Consider the improvement in news reading now 
that Netscape have introduced news://foobar.com/ type access to mailing lists. 
The original Web design was attempting to collapse all news services to a single 
point of access - something that I never found too credible. This was because 
some people had got wedged on naming issues thinking that they could create 
names which were ubiquitous locators.

I suggest that SPKI construct a URI for identifying a party or object which 
captures the authority chain, something like:-

WEB:iip@ai.mit.edu		The party iip@ai.mit.edu
WEB:/rsa.com/iip@ai.mit.edu	The party rsa.com considers to be iip@ai.mit.edu
WEB:/x.org/iip@ai.mit.edu	The party x.org considers to be iip@ai.mit.edu
				The party x.org considers to be the party 	
				rsa.com considers to be iip@ai.mit.edu

This structure allows complex assertions to be expressed :-

"Allow access to WEB:/x.org/iip@ai.mit.edu or WEB:/rsa.com/iip@ai.mit.edu"

By logging operations under the chain of authority information we can back out 
if a certificate is revoked.

Perhaps we don't need to bind the chain into a single URI but it would be nice 
to keep the identity names compact. It does permit some nice WAN type work :-

Permit entry to WEB:/etna.ai.mit.edu/hallam@ai.mit.edu
	- i.e. allow access to me provided I have a credential from my

The way to intepret such identifiers is to start from the left hand side, the 
first token has to be one that exists in the base vocabulary of the party making 
the authorisation decision.

We can enter an identifier into the base vocabulary with an assertion:-

"authorise holder of key RSA:236123649213498162 as etna.ai.mit.edu"
"authorise holder of key DSS:21387461246982364,123461236 as rsa.com"
"authorise WEB:/rsa.com/* as WEB:/*"
	- ie subordinate our decision making to rsa.com

I think that the SDSI step of providing an authorisation chain is a critical one 
for configuring the authorisation mechanism itself. It is probably not very 
usefull once that configuration is complete.

Note that the WEB: scheme I propose may not be ideal, it may be sufficient to 
simply define a uri which is somewhat better than the mailto: scheme which is 
pretty broken and gives the wrong connotation.

I would like to have the ability for a party to arbitrarily subdivide their 
portion of the namespace. So by owning hallam@ai.mit.edu I automatically "own"
micropay.hallam@ai.mit.edu. This is similar to the mailbox schemes 
hallam=micropay@ai.mit.edu that some systems provide.


Phillip M. Hallam-Baker					hallam@ai.mit.edu

Is the NSA spying on your machine? To find out visit