[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Summary Trust x Delegation
> In my mind, the issuer does not trust the recipient (verifier), nor
> does it request (politely or otherwise) that verifiers do anything.
> Rather the verifier trusts the issuer. The issuer does not create
> authorizations that can be delegated, the issuer merely provides a
> trustable service for use by subjects and verifiers.
This is getting pretty tiresome, but I like to emphasize any place
where there is agreement. The only point I want to make here is that
SPKI specifies (and x.509 does not forbid) that the verifier, being the
one with privileges to offer, typically expresses that trust via a
certificate. A criticism offered by Gerck, I think, was the lack of
explicitness in the implied trust of a CA's certificate. This is valid
in most browser environments, though it is not entirely outside the control
of the user.
> You might think that, in the real world, the DMV authorizes you to
> drive. But in reality, the DMV is just an administrative organization
> that carries out laws and regulations created by policymakers.
> If you are stopped by the police, you can present a drivers license
> as evidence that you are eligible to drive; the police and the courts
> trust that the DMV has done it's job in accordance with policy.
And the highway patrolman (verifier) honors the certificate(driver's
license) because of an implicit trust in the DMV (the issuer). There
is not an explicit declaration of trust (certificate) from the
patrolman to the DMV; as I said, it's implicit - it's his job. If SPKI
were the means used by the patrolman, that certificate *would* exist,
so that the patrolman's software would know that the key presented as
that owned by the DMV was one to trust. This is delegation of
authority from the DMV to the motorist, in that the patrolman, who is
actually granting you permission to drive, authorizes the DMV to
delegate that permission. As Tony said, the verifier is still central,
and in fact is the final root, even though in terms of human authority
the patrolman is actually carrying out the DMV's wishes, not the other
way around. Thank you, David, for offering an example of this sort.
> But if the DMV revokes your license, it doesn't "trust" or "request"
> the police to prevent you from driving, it merely makes an
> administrative determination that, according to policy, you are no
> longer eligible to drive.
>
If he were stationed at a roadblock, which no one got through without
his permission, or at a guard station, it would be easier to see that
he alone had the power to grant the privilege, and was therefore honoring
an expression of trust by the DMV.
> In the X.509 model, the verifier is central. The verifier controls
> access to resources, and it's up to the verifier to collect whatever
> information it needs to make a decision. The verifier enforces policy,
> and the verifier decides which issuers it trusts. The issuer may write
> it's own policy (Certification Practice Statement), but its up to the
> verifier to read the CPS and decide to what extent it will rely upon
> certificates created by that issuer.
>
Absolutely. The only difference in SPKI's approach is to automate and
secure the verifier's choice of whom to trust. The human trust choice
is expressed through certificates. Bill's point must always be kept in
mind, that once given, a resource can not be taken back, but our point
is that the verifier will not grant anyone access through the
certificate mechanism that was not explicitly authorized or delegated
with his permission.
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