[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]
>
> They were not assertions; they were propositons, based on compare
> and constrast between the requirements and models. The propositions can
> perhaps be shown to be false to demonstrating where the similarity
> was wrong, else a requriements has not been addressed
> in the comparison.
I think I understood your meaning; in my haste I failed to characterize
it effectively. Sorry...
> The SPKI notion of a SIMPLE infastructure is already estalished
> in the "v1" model of X.509, where there is just a key
> and a name, plus some minimal management data to
> faciliate lifecycle management where keys go into a
> systems, and get pulled out again, under the users or
> issing organizations control (dates, version#).
> If you dont want a name, dont put one in. See, its easy!
This is the most important issue to me as an implementor, of course: can
the tool I'm evaluating do the job that I want? I am not particularly
enamored of one encoding or another, I just want what I choose to do what
I need done. I welcome more discussion of that, but in the sense that the
requirements are ostensibly the same, I'd like to hear it in the context
of the PKIX discussion, to which I also subscribe.
The problem is that the discussions I'm hearing there are so minutely
concerned with the finest details of usage of different fields that I am
completely lost. It's clear that I am well out of my depth here; but
so would many potential implementors be, many of whom are smarter than
I, and that bothers me a lot, because it means that the group will
not reach the IETF goal of making a clear, implementable standard of
interoperability.
I hate quoting at length, so I'll summarize: my earlier post mentioned my
problem with implicit trust. Your reply, with which I agree, said that
some level of trust is necessary, but that it can be based upon judgement
of acceptable levels of risk. My point is this: as a human, I am capable
of that kind of judgement, and I authorize myself to take those risks, but
my programming skills are not such as could give a program I write that
much wisdom. I, or the user of my program, must be able to express that
judgement to my program in a way that it can understand and execute it
appropriately.
An example should be illustrative: I trust VeriSign's level 3 CA
service, knowing their level of notarial assurance of the identity of a
keyholder. Therefore when I get mail from someone with a certificate
signed by their commercial CA, I feel confident of the identity of that
person, and if something in that identity maps to something that I can
get a legal hold on, such as a SSN or, in my business, a phone number,
I can feel safe offering that person access to information concerning
their phone service that I keep in my systems.
The question is: how do I express that confidence to my application server?
If I merely install your CA's name and key as a trusted root, or (more
appropriately) have my internal CA certify it, I tell my application only
that I am willing to agree that the signer of a request has a particular
name. I have not told it that I trust that person to access anything in
that application. The traditional answer to that problem is an application-
specific access control list, because we have authenticated but not authorized
the request. My reaction to the email I got above would be to install that
user's name in my application's ACL.
Well, all that's nice, but the ACL has just the same need for authentication
as the request, and not just authentication, either; I need to know that
the author of the ACL was someone that I authorized to update my ACL. Hence
the ACL that authorizes ACL authors. Of course, all these authorizations are
given to names, and so along with every signature there's the name of the
signer, and the relying application (or its database daemon that builds pre-
authenticated ACLs from authorization records for speed) has to chase a chain
of certificates for each name to verify the signature.
What a strong faction at least of the SPKI group is pushing is to *do away*
with names in these contexts. Ultimately, an application doesn't care what
the client's name is; it's just a layer of indirection that gets in the way.
The application's job is to determine whether a request is authorized. If
the client can present a credential, signed by someone trusted, that the key
he uses is authorized, then there is only one certificate to trust, and if
the key signing the certificate is its own, there can be no key it trusts
more, and the trust does not have to be implicit.
If you, Peter, missed Carl's page on the generalized certificate stuff, let
me point you to it again, it's at http://www.clark.net/pub/cme/html/cert.html.
Yes, he bashes X.509; yes, he bashes ASN.1, but the point is that for relying
parties that are represented by autonomous daemons without human sensibilities,
names are only an annoyance; it's the keys that are being authorized. It is
so in our distributed applications toolkit, even though we use the names to
stand for the keys, and have to chase chains every time we want to authorize
a request.
I have no problem with the rest of your comments in general. I specifically
agree strongly with the points about making judgements and accepting risks.
The point is, how do I express these judgements to my cyber-agents, the
software that I use? The mechanisms currently popular seem to me to be too
coarse, with their all-or-nothing authorization semantics, and too specific
to certain applications, with certain bits defined by the standard to mean
something not generally applicable to all certificate users, and too complex
for human understandability.
What I at least am arguing for is a simple way to implement a relying-party-
as-issuer model, what you call the 'final assertion of id'. For at least
one broad class of uses, one I think was not envisioned by the original X.509
design which clearly and perhaps artificially separated authentication from
authorization, this model is the most straightforward, efficient, and secure.
For other uses, such as email, the model includes both models currently in
vogue(well, only one, PGP, is in wide use), since a name is effectively a
privilege, one which a human can recognize and therefore authorize. For yet
another, such as non-repudiation, it may not serve well, because of the need
for some external authority, but then it may; I have not explored that use.
If my comments have stirred up some real interest, I am glad. I am sorry if
my historical and theoretical knowledge is lacking. In defense, however, both
of Professor Rivest's work (boy, have I got cheek!) and Blaze's work to which
you referred, if they have done nothing better, they have brought the light of
past thought down to the current generation of users and implementors
(including me) in terms we can understand, and that's worthwhile.
Brian Thomas - Distributed Systems Architect bt0008@entropy.sbc.com
Southwestern Bell bthomas@cdmnet.com(or primary.net)
One Bell Center, Room 23Q1 Tel: 314 235 3141
St. Louis, MO 63101 Fax: 314 331 2755
Follow-Ups: