[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: X.509 ACs vs. SPKI?
> From: "Ellison, Carl M" <carl.m.ellison@intel.com>
>
> Perhaps I used the wrong word. The fact remains that the code that
> interprets a full X.509 certificate (including all extensions) needs
> to be aware of (to embody) the definitions found in some paper
> document. This is by contrast with SPKI certificates that can be
> processed through tuple-reduction without any special knowledge about
> such paper documents. That is why SPKI can have a single Trust Policy
> engine while X.509 requires a different one for each application (in
> the limit, for each root key).
There are only two places that the policy written in a paper document
can be understood/interpreted/enforced - in applications and in the
user's brain. To the extent that application engines perform automated
reduction, the user's workload (and ability to make mistakes) is
reduced.
Claiming that SPKI "can have" a single engine while X.509 "requires" a
different one for each root is one way of spinning it. But I would say
SPKI permits only a single engine, whereas X.509, which defines no
authorization mechanism itself, provides extensions identified by OIDs
which can select the engine to be used. Automated authorization is not
a mature field; there are numerous candidates: NIST's Role Based
Access Control, SPKI tuples, Novell's Security Attributes, the DoD's
SDN.801, and many others. In 10 years, perhaps everyone will agree
that SPKI tuple-reduction is a suitable mechanism for automated
authorization decisions, and everyone's X.509 root cert will have an
extension that specifies an SPKI tuple reduction engine in conjunction
with some application-domain-specific parameters.
As for human-interpreted policy processing, one size will never fit
all. VeriSign has 4 public assurance classes, the U.S. DoD defines 5
classes although only 2 are presently used, and other governments and
organizations have multiple CPs. Harmonization (and elimination of
policy mapping) would be great, but it won't happen quickly, if ever.
Policy Qualifiers can be used to advertise quantitative information
such as Reliance Limits from the issuer to the RP, but if the intent is
automated processing rather than simply displaying information to the
user, I believe a different extension, specifying a "standard engine"
should be used. The fewer engines applications have to support, the
better, but I don't think the market is yet convinced that SPKI tuples
are capable of supplanting RBAC, DoD PRBAC/LRBAC, other chaining
mechanisms, and plain old ACLs for all public-key-based authorization
applications.
That is why X.509 allows a choice of engines, including "display this
to the user", messy though the choice may be.
Follow-Ups: