[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Summary Trust x Delegation
> From: Bill Frantz <frantz@netcom.com>
>
> A much more important reason is that even if I can calculate "trust" to
> nine decimal places, it does not help me with delegation. I have no
> technical way to prevent effective delegation, so I must trust the
> recipient of every certificate I generate with regard to delegation.
>
> As I have said before, I think the "don't delegate" state on a certificate
> is pernicious. People will think it gives them a protection they don't
> have. Making it the default compounds the problem.
>
> "Don't delegate" needs to be clearly documented as a polite request to
> verifiers and other parts of an implementation not to honor certificates
> delegated from the certificate having that attribute. ...
This thought process (i.e. this mental model of thinking about SPKI
certificates) seems backwards to us X.509 types.
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.
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.
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.
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.
Follow-Ups: