[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

I&A Forum complex authorizations

At 08:59 AM 7/19/96 -0400, David P. Kemp wrote:

>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.

Yup -- it's nice -- fast.  However, I'm afraid you'll either run out of bits
or have to go to an indefinite-length bit string that ASN.1 provides and
once you've done that, you have more complexity just moving the bit string
around than you saved with the 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 registry doesn't have to be global...can be but doesn't have to be.  A
given writer of access policy will state what has to be present and it's up
to the certificate holder to acquire those <auth>s in the desired format.
If we ever find people asking for the same thing (semantically) in different
formats, we can call for a central discussion list and registry of suggested
formats (perhaps in an RFC).

However, you're right that a complex authorization policy isn't easy.  The
closest I've come to finding a way to express it is in PROLOG.  In free time
(if I ever get any), I'll write up a PROLOG method of specifying what [BFL]
called a Policy.

>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.


 - Carl

|Carl M. Ellison          cme@cybercash.com   http://www.clark.net/pub/cme |
|CyberCash, Inc.                              http://www.cybercash.com/    |
|207 Grindall Street           PGP 2.6.2: 61E2DE7FCB9D7984E9C8048BA63221A2 |
|Baltimore MD 21230-4103       T:(410) 727-4288     F:(410)727-4293        |