[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Designer Certs
David Kemp writes (in cert-talk):
> > From: "Brian M. Thomas" <bt0008@entropy.sbc.com>
> >
> > The important thing to realize here is another basic difference in SPKI
> > thought, which is that the verifier is the ultimate authority. Again,
> > that's not anarchistic, it's just recognition of the reality that every
> > end entity can and will do as it pleases. If I want to make up an
> > attribute, and give it to you, I'm the only one that can give you what
> > that attribute stands for, hence I'm the final verifier, and I know
> > what it means. There is no need at all for any ISO committees; I don't
> > have to agree with anyone but myself on what it means.
>
> So SPKI is unable to address the situation where the DMV certifies a
> person's age and any other party verifies it? Are you claiming that
> the liquor store clerk has to define a syntax for the "birthdate" auth
> and issue a cert to DMV before the DMV can certify individuals who
> in turn pass their certs back to the clerk?
I think what he means is that SPKI is a layered solution,
where X.509 is a monolithic solution.
Unlike X.509, SPKI is not a complete solution to the problem
of certificates. It defines a mechanism for exchanging and
structuring certified data, and leaves the question of what
that data is mostly undefined.
Because of this, you need higher-level standards. The SPKI
idea is that there would be a number of kinds of high-level
certificate schemas, instead of everyone trying to fit all
possible uses of the "certificate" concept into one format,
with one predefined semantics.
This comes from a weird idea that has gained some currency
in American software design circles, which is that it's
important to separate mechanism from policy. It's uncertain
where this idea originated. It may not have been proposed
in compliance with the correct ISO procedures...
Curtis