[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: definition of cert - trust in SPKI certs
>
> However, trust is not transitive.
>
My involvement in SPKI arose because of issues of this nature. Trust is
transitive to the extent that I (as verifier) say that it is transitive.
Tony and Bill's responses are useful in illustrating this, but my bit is
that the primary purpose of a certificate is to convey my wishes as user
to my software agents in cyberspace. The point is that trust is not
*implicitly* transitive, but *explicitly*.
If I issue a certificate to Jon as Bank President, then I accept full
responsibility for my program's trust in his key. The nature of the
role of "Bank President" which I entrust to him by the certificate is
such that I am explicitly trusting those whom he certifies in roles
relating to his role. I would not be wise to do this in the absence of
assurance by him that he stands behind the actions of every key that he
certifies in this context. In turn, he would not issue such assurances
without assurances to him of the employee's trustworthiness and, as a
final safeguard, a bonding agreement, which the bonding company would
not offer without assurances of its own which it gains by background
checks; etc.
Note that none of that participates in the structure of the certificate,
but each party, aware of that to which he commits thereby, gathers
assurances satisfactory to himself and appropriate to the risks
involved, and certifies others appropriately. Nothing in certificate
structures or protocols can replace this process, but they merely
allow me to execute what I have already chosen to believe, including
trusting others to convey trust. As Bill points out, this is easy to
lose control over, but it is what is intended.
> This means that you could trust 100% the issuer's key as authoritative to
> do the binding of another key (the subject) to an auth field under the
> validation hypothesis and, yet, you do not trust that other key (ie, the
> subject) in relationship to those attributes in the auth field.
>
> In other words, the fact that you trust Jon as the Bank President does not
> mean that you must trust Mary as your account manager -- as she was just
> appointed by him! So, you cannot accept Jon's certificate -- even though
> it is a valid certificate by SPKI's rules.
The role of Bank President means *exactly* that in the real world; certificates
merely extend that to cyberspace. Jon's appointment of Mary to her position
is consummated by papers signed by him authorising her in this role. These
papers are satisfactory enough evidence of his conveyance of authority that
if she misbehaves in her role he can be held legally liable, for negligence
if not for complicity.
> Another point is that Mary may not have agreed with Jon's appointment and
> the verifier has no way of knowing this because the certificate is signed
> by Jon only.
>
If she acts in the appointed role, thus giving me the opportunity to choose
whether to trust her, her feelings about the job are moot; functionally
speaking, she agrees with the appointment, QED.
> However, if Mary also co-signs the certificate that still proves nothing
> because the verifier has no way of knowing that Mary *is* Mary -- say, by
> independent channels of information and must only trust Jon, again.
The verifier believes that Mary's *key* is Mary, and more importantly,
is someone duly authorised to act on the bank's behalf, because Jon said
so, and because I said I would trust Jon when he did.
>
> -> How the trust in that issuer's
> -> key is established is outside the scope of this one certificate.
> ->
>
> This is an interesting question, because as the certificate does not say
> that -- how and to what effect trust was established -- it is difficult
> for the verifier to "remember" exactly how it was that such trust was
> established and what are its limits, both in time as well as in scope.
Such questions are outside the capacity of my dull and ignorant cyber-agents,
and thus outside the scope of certificate structures. If I say I trust
someone, I expect my program to carry out that trust, not to judge whether
I should have done so. I'm still in charge here, not some automaton.
I chose not to respond in detail to the rest of your note, not from
lack of interest but lack of time. The thrust of it seems to be, as
above, on mechanising means of assurance in order to establish trust.
This is, of course, an interesting topic, and should be pursued
further. The pages you mention offer a forum for this, which I believe
I will follow. However, we must separate high-level from low-level
questions, and SPKI, as a certificate structure, does not and should
not deal in those issues. PolicyMaker, being a robust and flexible,
if computationally more expensive, mechanism, comes a long way into
that realm, and we have often proposed strategies which incorporate
it in SPKI deployments. MCs may go beyond this, but it's new ground.
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
Follow-Ups: