[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: comments on client auth
Peter@verisign said:
> .................................. Common interfaces, modules, formats,
> etc, but radically different ideas for infrastructure security
> management, perhaps.
I am a firm believer in using other people's code if it works; more people
to look at it and find problems before and after implementation makes the
implementor's and maintainer's jobs easier. That's what I'm looking for.
If I could get you, or anyone, to demonstrate how this could work, thus
allowing me to use shared standards of this sort, I would be at least halfway
toward my goal.
> admins configures in the trust point who s/he accepts as
> serving the interests of the admin's users, on account
> of the admin verifying the issuing policy and
> the controls of the domain which reasonably ensure that
> all parties/proxies will act in the way speicified despite autonomous
> actions; some "trusted" control system (enacted in the
> CPS) will enforce the delegation assumptions with
> perhaps, but not always, the support of trusted software.
If I read this right, the very act of "configuring in the trust point", and
the mechanism, is the sticky bit for me. I see this as a use for a certificate.
Nothing else will suffice. If I(speaking as the application entity) trusted the
operating system root(and I don't see why I should have to), I could still only
trust it on the machine I was running on, and my human administrator may not be
represented on that machine - indeed may not even have access to it as a user.
Therefore some secure means of getting this administrative directive to me is
indicated. As I said, a certificate, securely and understandably representing
some humanly-decided policy, could be that instrument.
> This is human judgement, and then decision on appropriate
> "delegation of authority", represented by a choice to shove a trusted
> key into the key-domain key configuration file, or not. Practical,
> and realistic, surely. Acountability passes to the human, who
> delegates authority to decide to the proxy.
Again, the action "shove a trusted key into the key-domain key configuration
file" requires a mechanism. That mechanism is a certificate, a machine-readable,
authenticated utterance of an authorizing statement. Merely putting the key
into a list of trusted keys is insufficiently specific. The specific authorization
of what that key can do, and who (what key) so authorized it, must be communicated
as well. The term "file" is also too imprecise here; its connotation is that
of an operating-system managed storage location. But operating systems typically
do not equate key-bearing principals with their authorization entities, or if they
do, the means of doing that is not specified here. If they can do this, fine,
but again, my application cannot know certainly that they do, whereas with a
certificate supporting every assumption of fact or policy, it can. Some of my
colleagues have characterised a truly wanton implementation of this kind of
thing as little more than a secure rule base.
> You are making a decision to relyon a cert! This is
> why CAs have to be so careful, as they are therefore liable!
Correct. *I* made the decision. I must now *securely* communicate that decision
to my software agent, which is able to carry it out.
>
> This is the entrust model for X.509. It makes no difference whether you or
> your trusted CA "cerify" the public root. Obviously the more
> local the trust deicison, the easier it is for you, perhaps.
> but this is a choice. many residential users desire
> ADMD organizations of telematic services, versus
> their managing many PRMD interconnectivity graphs
> which they cannt really handle. A mix of local choice
> to configure trust in ADMDs is a nice compromise; nice to
> see PGP gone down that line; Ive stopped
> criticising PGP's inane previous-design now! I even
> stuffed a PGP key in my directory entry; not
> sure what it means though, yet.
I must confess that, having been in this discipline for less than two full years,
I am not familiar with the terminology. References to these would be appreciated.
> ACL) allow you to have free drinks; who knows. The barman
> assumes bouncer, and only checks the number, not
> the card expiry date, for example.
The barman assumes a perimeter which does not exist on an internet. Some
people have yet to understand that perimeters (operating system hosts, networks,
etc.) are no longer relevant, because even where they actually exist they
cannot be assumed. I don't think that was your problem here; I just picked
on the example because it was relevant to a continuing problem of awareness.
> I dont disagree with this underlying true condition; its however a fraction of the security
> problem; as does not facilitate accountability for those enviornments
> which demand individual accountability
> [ etc ]
I, or for tht matter Carl, or Blaze, or just about anybody, have never made
the assertion that names (and name certs) are not necessary. I will make more
of that below, but your example of accountability and auditing is one of the
major reasons that my security organization wouldn't let me get away with it.
The name certificate stands as one of the main bulwarks of human policymaking
[BF&L included], which results in the issuance of key-privilege certificates.
> > 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 find his arguments about ASN.1, & X.509 syntax purile. This is irrelevant though,
> as are all arguments about formalisms and syntax.
If we can get past this, or every time we mention it, just have some code word
to stand for all the standard assertions about how we're not arguing over syntax,
we could save some significant typing time. From now on, I won't mention it if
you won't; if you feel the need, just use the code word "gagme"... Carl and many
others will never agree, and I don't have a strong opinion on it, so let's
forget about it, okay?
> I did read his web page once; I cant remember what it said, other that
> X.509 is broken because ASN.1 is; hence all X.509 models and uses are broken; see
> me for a real set of concepts.
>
> Carl implicates, and links, the models behind those formalisms and synataxes with the
> same disdain he has for the notation. And here I object intellectually, as in a
> comparison, the solution he proposes has no different a set of ideas (from SDSI) as
> X.509 in general, and some specific profiles of that generic std in practice. This
> is strong reasoning which counters his own informal claims.
I'll let Carl defend himself, if he wishes; it's oblique to my point.
I was largely of a mind to dismiss him, and SPKI, as long as their
objections seemed rooted in a distaste for ASN.1, which I tended to
like, though without any real implementation experience beyond playing
with a GDMO compiler and an SNMP toolkit, both of which did most of the
work for me. It was when the issue of authorization came up, and all
of the work that I have already done to implement it, that it occurred
to me that it could be much simpler than we had designed it.
Again, I think I'll refrain from quoting, which has some disadvantages, but
I find it hard to place my comments effectively within the quotes. I think
that there is still a fundamental misunderstanding here. What you mean, for
example, by "an autonomous responder seeking to take human-style accountable
decisions", is not completely clear to me, mostly because in the ensuing
language I get completely lost. What I would mean by that term, had I used
it, is a typical server in an ordinary distributed application framework.
The server's job is, then, to decide whether a particular request should be
honored. The server is in no way capable of making a judgement, only of
enacting the judgement which its human administrator has made. That
predetermined judgement must be securely communicated to the running instance
of the program; this is the use of a certificate that I suggest.
The mechanism for making the judgement is not discussed here; names and their
meanings are certainly involved, and name certificates could, and probably must,
be relied on. That is why, in your export violation above, you *could* prove
that you had taken due care, because the Syrian national had presented you a name
certificate, issued by the Commerce Department, certifying that the presented
key belonged to someone for whom the export restrictions did not apply, and
upon which basis *you* executed the certificate authorising the release of
the restricted material, which the program could honor with indemnity.
Enough for now. It's taken me a long time to get this far, and I don't think
that a lot of the rest was particularly useful to comment on as long as I felt
that some of my assertions are not yet understood, and besides, I'll never get
this message posted.
I enjoy this discussion, even though it gives me a headache trying to understand
other people and make them understand me. Moreover, the fact that this is more
or less in public means that there are lots of people who will hear the debates
and make up their own minds, and the art is advanced.
Yours for light and heat,
brian
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: