[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
WEB:/x.org/rsa.com/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
workstation.
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.
Phill
----
Phillip M. Hallam-Baker hallam@ai.mit.edu
Is the NSA spying on your machine? To find out visit http://127.0.0.1/
References: