[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Java programs, etc.
>Your note makes a good point---the only person who can really specify
>a "custom intersection program" should be the one who is actually
>the verifier at the end of the chain (i.e. the original authorizer).
>Parties in the middle of the chain should not be able to do such a
>thing...
Unless they were doing so in the context of creating a fresh certificate.
Consider the ways in which credit beureaux work. They take in a mish
mash of subjective impressions and on the basis of it peddle what they
puprort to be objective fact.
An organisation performing certificate intersection tasks sounds to me
like its providing a value added service. Linear analysis of chains does
not seem like its sufficiently usefull to be worth making it an SPKI cliche.
The benefit of offloading processing cost onto another system is unlikely
to be great enough to justify the cost of adding in another link!
What might be worth investigating however is a model in which certificate
interpretation was performed by specialist server (eg at a firewall boundary).
Such a server might provide "summary" certificates to its clients which
would be used to authorize low level actions. This system might be based on
lightweight MAC type authentication since non-repudiation might not be
an issue.
All a custom interpretation system is then is a basis for issuing certificates.
If you refer to the scheme under which certificates are issued using a URL
you then proceed towards the PICS model - which was in any case originally
just a simplified trust model.
Phill
Follow-Ups: