[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: one possible motivation for X.509
> From: Carl Ellison <cme@cybercash.com>
> >Garage shops (in the US, at least) should be able to use code similar
> >to that, without having to reinvent the cert processing wheel.
>
> We have reason to re-invent the cert processing wheel -- just as the X.509
> folks have discovered on their own. SET's cardholder cert is a new
> invention, even if it parses as X.509. The attribute cert is a new
> invention. v.3's extensions are a new invention. They're all trying to
> incrementally get to where we jumped with SPKI by rejecting X.509 and its
> history and starting with a blank sheet of paper.
Oops - I meant re-invent code to parse certificates - each developer
rewriting X.509 libraries and macros from scratch for each application.
I didn't intend to impugne the SPKI format itself - there are good
reasons for its existence, some of which you stated very well in a
reply to Bill Buffam.
One of the I&A Forum topics was the use of X.509 attribute certificates
to perform authorization. The strawman proposal included three
types of authorizations - permissive bitmaps, restrictive bitmaps
and enumerated attributes which would be treated as either permissive
or restrictive. (The distinction, for those who weren't there,
was that an object with restrictive permissions, such as
"secret clearance" and "U.S. citizen", require the subject to
have all the permissions to access the object, whereas with
permissive permissions, such as "employee of Ford", "employee of
GM", or "employee of Chrysler" require the subject to have at
least one of the permissions.)
The problem with bitmaps and enumerated numbers (OIDs) is that
one needs a registry to equate "Secret" with 0x04. With lots of
application-specific attributes, attribute name registration
could become a problem. But once that's done, the access-granting
code is trivial - just mechanical ANDs and ORs.
The problem with SPKI free-form Auths is that access-granting
code is non-trivial if it has to deal with ensuring that things
like "employee of Chrysler", "Chrysler employee", "OU=Chrysler",
"Chryslr employee" (typo), and "OU=C" (use of ticker symbol
as organization name) are all treated as identical for
access-granting purposes. You still need an attribute registry
if you want to have a canonical form against which to check
Auth entries typed by human operators.
The problem of Authorization is not simple, and no one has the
answers yet. A diverse set of people thinking about the problem,
using a diverse set of tools, is the best way to come up with
approaches that are workable in practice. Once solutions have
demonstrated their usefulness, I doubt that certificate formats
(X.509 v3 or SPKI) will be a barrier to adoption - both formats
will adapt if necessary to accommodate whatever user requirements
must be satisfied.