[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: comments on client auth
> To clarify here, when you speak of "I" you are referring to yourself as
> the program? You as the software running in a sense as the user's agent
> need to trust the root?
Let me apologise. This is what gives me headaches about all this; sometimes
you(meaning I(meaning ?)) have to be excruciatingly careful about wording
and terminology in order to be understood at all. Reading my message through
your eyes (I's?) I(I, Brian) can see how confusing it could be. Permit me to
try again, and if anyone else was confused, as they likely were, it may help.
I guess I should say that I think you understood me toward the end, but the
fact that you thought I was changing my point of view is embarassing. Well,
I guess I was, but I didn't change my opinion about it. I did plainly use
the first-person singular to refer to at least three different points of view.
(No, I am not schizophrenic. Yes I am!)
> So the issue is that in writing the program, you have in mind a root
> which should be trusted, and you want to make sure that when instances
> of the program later run, they use that same root? It seems to me that
> later instances should be thought of as not your agents, but those of
> the user. It is his wishes and trust which is relevant, not yours.
> Now if he trusts you to choose the root, then your concern is valid,
> since you are worrying about it as a proxy for him.
Absolutely correct. A marvel that you understood that from my crippled prose.
> I think your second perspective here is the more useful one. There is no
> way for a program to know that it has not been altered. Only an outsider
> can check that, and that requires some other trust and verification
> mechanism.
Again, quite correct, although if the user's key is used to validate all
instruments of trust, there's one less worry. That's one key that can't
be substituted, because it won't work.
> > 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.
>
> I'm afraid I don't understand this part. Is the main point that the user
> needs to be able to specify what he trusts, rather than the program? He
> is the "final arbiter"? I think that is very reasonable but I don't
> understand the comment about "chains of authority" and certificates being
> made from any statement that could be uttered.
Right again, and no, I didn't really mean that the program, instead of the
user, should decide. The chains of authority are enabled by certificates
that explicitly authorize actions, rather than merely certifying names.
> Maybe part of my problem is that you are criticizing something which I
> do not accept. The idea that a program should choose the trusted root
> rather than the user seems a weak solution. I realize that Netscape
> has done this but hopefully it will not be widely copied. What was the
> application you discussed above where you built a root into the program?
See above. My weak prose misled you. The application was an entire messaging
infrastructure where the root was compiled into the library(statically linked)
so that all could agree on it. Problems definitely ensue if that key has to
change!
> > 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.
>
> So the idea would be that the user explicitly specifies whom he trusts to
> do what? And this is done on a per-application basis? It would seem
> that some commonality across applications would be useful. If a user
> switches from one email program to another it would be nice if his trust
> relationships could be carried over.
Yes, yes, and I agree. Though I have not specified how this is to be done,
it is definitely one of the things I hope it will support. And since, where
human end-user client code is concerned, there is less of a concept of
authorization than of authentication, the name of the peer(either an application
or a mail-type end user) is the thing authenticated, and name certificates
will do nicely. The user merely has to specify which naming authority(ies)
he trusts, and this could be done through certificates. The important thing
that I would like to note is that the specification of trust to a CA, for
example, is "I trust this CA to issue certificates that I will trust as valid
authentication of a key by a name", not "I trust any certificate chain rooted
here". If I trusted the name subordination practices of the CA, and that was
sufficient to my purposes, I could express the second kind of trust; if not,
I could use the first, or say, "I trust any *name-subordinate* chain rooted
here".
Another thing is perhaps important to point out: the applications I have
been working on are mostly those where authorization is primarily one-way,
such as in business servers responding to client requests. Since these run
on their own, they have an identity not tied to any person. The identity
represented is therefore that of the application itself, whose access controls
are expressed by the individual(s) responsible for the administration of the
code. This may be the main source of ambiguity in my language: in a way,
the code does represent the programmer, but more accurately, as you point out,
it is the application itself, expressing its wishes through the actions of
its operational administrators.
> Sorry if my comments do not seem relevant. I worked several years ago on
> the implementation of PGP and so I am coming at it from a perspective
> where as much power as possible is put in the hands of the user. You may
> be looking at a different set of issues.
>
> Hal Finney
> hfinney@shell.portal.com
>
On the contrary, your comments, though they embarassed me at my poor writing,
showed more understanding of what I was trying to get at than most so far.
Thanks for your contribution.
As for the perspective: I am certainly looking at a different set of issues
than PGP addresses, I think. I came originally from the point of view that
hierarchically rooted trust models, if difficult to implement, were better
than Pretty Good, and in some respects I still do. But if all you are doing
is sending mail, the authorization is done by the most powerful program in
existence, that has all of the appropriate rules built in, so naming is all
that you need, and either model will do. The PGP web-of-trust is more appropriate
for personal communications, and the hierarchical(if multi-rooted) model is
more appropriate for official communications, because of the controls. But
if the authorization to do something is done by less than a human intelligence,
neither model is sufficient, because of the lack of authorization. Some, such
as we, built authorization another way, and are suffering great pain. I now
believe that a model based on generic certificates ("A says B can do C - for
this time period", signed by A) offers much more flexibility, security, and
autonomy, since the user, being ultimately responsible for what his software
does, should be the ultimate authority over what it does. That's not an
anarchistic view(though I can't imagine any anarchist disagreeing with it);
it's not even, as Peter calls it, the 'final assertion of id'; it's the only
view that is ultimately responsible.
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