[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: comments on client auth
> Brian's comments have got me thinking.
I'm always glad to hear that; I consider it a major part of my job, regardless
of who I work for(Not that I take pride in it necessarily: I've found
that any idiot thing can cause me to think about completely unrelated things).
> 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.
Doubtless. That's where my money is invested for now...
> 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.
If anyone was in doubt about that, I apologise for assuming it. It may
be that they were. It may also be that they felt that the mere
possibility of securing machines against tampering with root keys
solved the problem of being sure that it was so. As an implementor I
have wrestled long with this problem.
> 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 ?
I don't think I follow here - isn't the idea to resolve the names by following
the references to their sources, thus making comparison possible?
Brian Thomas - Distributed Systems Architect email@example.com
Southwestern Bell firstname.lastname@example.org(or primary.net)
One Bell Center, Room 23Q1 Tel: 314 235 3141
St. Louis, MO 63101 Fax: 314 331 2755