[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: The notion of an ``individual'' (e.g. person, corporation, process, or machine) is not required
>
> As should be evident from my mail sequence, Im trying to prepare
> a SPKI/SDSI pilot to help propel adoption of the ideas, and (of course)
> one element is to fixup the legal stuff so at least people know where
> they stand in relation to an issuer, and the act of issuance.
A laudable effort.
> Whilst academically, individuals as a system notion may not exist,
> legally they will always exist. Sorry if this offends you; its just
> true. As those who control private keys, they will be responsible, and
> the SDSI notion which is in concordance with SPKI does assert that
> essentially there is a proxy relationship between the [(re)liable]
> party and key, and a "speaking act" occurs.
It doesn't offend me; it merely doesn't belong in the PKI. I agree that
the PKI should support it.
> In a B3-DAC conforming capability list design, normally the protection
> system knows about and controls who has capabilities. (I don't know if
> any such animal actually exists, BTW) and can mediate in the
> transference of permissions, change of domains etc. In the SPKI environment,
> there is no such central protection system.
Not by design of the PKI, no. If somehow the PKI cannot support that,
we have more work to do.
[skipping to minimise bandwidth, not your arguments, Peter...]
> Hopefully, one can see Im looking for the angle
> by which legal reliance properties can be controlled technically,
> without upsetting the intent of the SPKI system
> or the kinds of flexibilities it wishes to engender,
> when used in a public environment where there is
> just no escaping legal stuff.
>
> Peter.
>
This answer probably requires more thought than I'm giving it for the
moment; I'm answering somewhat hastily, because I don't want us to get
so far down the wrong track that we get lost.
First let me say that all of your stated requirements are, to my mind,
valid. I'd like to say also that I don't believe that certificate
structure is the correct mechanism to meet them. That is, if I may
speak for all of us, the primary argument of SPKI: that existing
notions of certification that we found were both too much and too
little. Too much because they tried to cram all kinds of things into
one kind of certificate to get it to do everything; too little because
it didn't allow for simple authorizations of previously unspecified
kinds.
I believe that all of the issues you raise have to do with the trust
models being used in the certificate-using environment, to which SPKI
attempts to be completely neutral. Specifically, the question is, "who
has authority to grant access to a resource?". In all cases, if the
answer is not "the one who has the power to fulfill it", there is
nothing any PKI can do to stop inappropriate access. Therefore, if
there is a third party (the central system) which has a right or a duty
to control access, it had better have the power to limit it.
The "central system" is therefore the final verifier, and hence
necessarily the issuer, of all privilege. Other certificates issued by
parties whose wishes it chooses to honor (subject to its policy) will
convey those wishes securely, but the central system, being the one
with privileges to grant, is the entity granting access. This follows
from the notion that you can't prevent anyone from doing anything with
a resource once granted, unless you control the means of doing it. So
I believe that all of your concerns, while valid, should not (and, I
believe, *can* not) be addressed by the certificate structure itself,
but by the trust models implemented by certificate-using systems.
brian
Brian Thomas, CISSP - Distributed Systems Architect bt0008@entropy.sbc.com
Southwestern Bell bthomas@primary.net
One Bell Center, Room 34G3 Tel: 314 235 3141
St. Louis, MO 63101 Fax: 314 235 0162