[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.
Amen!
- 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 |
+--------------------------------------------------------------------------+