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

Re: comments on client auth

Peter Williams <peter@VeriSign.com>:
  [lots of confident assertion that X.509v3 could do all that SPKI wants]

I'd like to believe that an existing standard that has accrued a fair amount
of market acceptance would in fact do everything that we need.  I will need
a lot of help from smarter people than me to figure out whether that's true,
however, and that by itself doesn't bode well, though it doesn't bother me a
great deal - it took smarter people than me to build the systems I routinely
use in my work with great confidence.  I look forward to a robust discussion
of that issue, in particular the questions of how multiple key-centric
certificates, with identical naming attributes, can be served by an X.500
service.

My issue, however, is one that I have not heard discussed at all so far on
this list:  that of implicit trust.  There is implicit trust involved in any
certification path that has a root that is someone else.  When I chase a
chain of certificates to a trusted root, the thing that bothers me is *why*
I trust that root.  Put another way, *how* can I be sure that the trust that
I as programmer had in the root that *I* intended to install in that place of
trust is appropriate, given the possibility of compromise along the path from
my statement of trust to the execution of the program?  The best thing that
we could come up with in our implementation was that the programs all had the
root name and key compiled into their execution code.  If we were able to be
absolutely(well, all right, reasonably) certain that no one could substitute
that key, either in the linking process, or during or after the delivery of
the compiled executable, it would be all right, but a program doesn't know,
does it, whether its code was appropriately protected from tampering?

Bear in mind that the issue is not whether the operating environment *can*
be secured in such a way, but whether I can know at runtime that it *is* so
secured.  If our friend A. Clueless User, for whom we are building all this,
is fooled into running the wrong program, everything we worked for can be
out the window (Obviously, this has always been true, and I want my level
of paranoia to be reasonable %>, still...).

On the other hand, if a certificate were to be made from any statement that
could be uttered by any human in any appropriately understandable way (such
as X.509 certificates and PGP certificates do about names, which humans who
send or read mail messages can authorize appropriately), then chains of
authority, not identity, would be possible, and (this is the point, finally)
the final arbiter, the trusted root, is the relying party {him|her|it}self.
That's what we have been trying to do, but implicitly, via corruptible
mechanisms.  All trust and authorization is therefore explicit, and the
semantics of the authorization can be whatever the relying party wants it to
be, since nobody else cares about it.  Obviously, standards could be evolved
for those, but they could be specific to the applications, and not hold up
generic standards efforts while they try to make absolutely sure they've
figured out every nuance of every possible use of the generic standard.
I think that's revolutionary in its simplicity and security.

In case it matters, I am the anonymous "person" to whom Carl refers, the one
who has implemented chains of authority, including ACLs and group memberships,
and the authorization to sign those authority instruments, without the benefit
of simple certificates, and has therefore been working on replacing it with
an SPKI-type structure.  I think the benefits are enormous, and primarily involve
throwing away a lot of custom code.  I'm trying to write a paper that will
describe the effort, but of course, I'm also trying to convince my fellow
designers to adopt the idea(theirs is some of the code I'd like to toss).  Feel
free to mail me with questions, comments, etc.



Brian Thomas                             <bt0008@entropy.sbc.com>
Southwestern Bell
One Bell Center, Room 23Q1               Tel: 314 235 3141
St. Louis, MO 63101                      Fax: 314 331 2755
Follow-Ups: