[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Possible SPKI simplifications
Kudos to Stefek and Steve for getting the minutes out quickly!
This message proposes three possible simplifications to SPKI. Apologies if
this reopens areas that have already been extensively discussed.
--- Threshold Subjects ---
Let me start by explaining what I see in SPKI -- in particular, the motivating
example I think about, and how SPKI fits in. This should provide some coherent
rationale for possible simplifications (as opposed to the visceral "That's ugly,
throw it out!" reaction).
I view certificates as being one form of input to authorization engines. In the
terminology of the draft, and authorization engine is a VERIFIER. Certificates
record assertions that an authorization engine uses along with other inputs
(e.g., policy descriptions) to make authorization decisions. Certificates are
useful to concisely capture such assertions (both input and result) in a way
that can be securely communicated in a distributed environment. By restricting
the goal to that of communicating input and result assertions, the complexity
of expressing arbitrary authorization policies is avoided. The authorization
policy engine might be something like PolicyMaker (which I assume is familiar
to list members) or Adage (http://www.opengroup.org/RI/www/adage/index.html) --
both of these systems contain policy languages that are far more expressive
(and hence complex) than anything that ought to go into an SPKI certificate.
This leads me to want to leave out anything whose goal is to explain how to
make authorization decisions rather than capture inputs to or results from that
decisions. This is a form of policy-mechanism separation, and I view SPKI as
mechanism. So, the first thing I think ought to be done is:
[I] Remove Threshold (k-of-n) subjects.
Threshold is a fine and useful policy, but it's policy, and SPKI ought to be
limited to simpler mechanisms. SPKI ought to make it possible for a PROVER who
knows that a k-of-n authorization policy is being used to present the k
certificates that the verifier requires, but it shouldn't encode the
authorization policy itself. As indicated in the minutes, this is the beginning
of a slippery slope towards encoding arbitrary authorization policies (the next
one will be weighted k of n, where each of the n subjects has a different
weight, and the weights of the subjects used must sum to k ...).
--- *-form Set Algebra ---
On the next item, we seem to have a "smart minds think alike" effect.
Markku-Juhani Saarinen writes:
> We do not need a general "intersection algebra" because a application
> can intersect two auths in the same (or compatible) DOI in a way
> that is fit for that particular application.
>
> One might have a general SPKI library to which a caller (i.e. an
> application) supplies two callback functions:
> 1) Check that this auth is in caller's DOI
> 2) Intersect the raw auth data
The important point is that that with respect to SPKI, intersection is a
"native" method that given two <foo>'s returns a single result <foo> or
null, as opposed to being based on domain independent list manipulations.
Carl Ellison writes:
> I probably went overboard in my elaboration of
> what can combine with what to produce what. [It's the mathematician in me
> :).] We might have too many *-forms. What we need for sure is a way to
> specify numeric ranges (for banking, purchase orders, etc.) and a way to
> specify pathname completion (for access to file systems).
I agree, and in addition to range and pathname, I would add a suffix mechanism
to do hostname wildcarding (e.g., *.research.foo.com), but leave out all the
list and set algebra. This leads to the suggestion:
[II] Delete all the *-forms except for prefix, range, and "(*)". Add
a suffix form to deal with hostname wildcarding.
[Issue 1]: Should the "*" tag be deleted from all forms except "(*)" as
redundant, or is this useful as a flag indicating that the expression is
domain-specific?
Note that this is attempting to reopen and reverse the conclusion on
Closed Issue 7) in the draft.
What is lost with this proposal is the ability to produce arbitrary "union"
certificates such as the "spend from two bank accounts" example in 4.3.3.1.2 on
p.48 of the draft. I don't think this is a major loss for two reasons. First
of all, for a small number of target objects (e.g., 2, 3, or 5), issuing a
certificate for each target is not a problem, so the real issue is scaling to
larger numbers like 20, 30 or 50. The problem with larger numbers is that the
"union" approach leads to complexity -- with arbitrary sets of 20, 30 or 50
accounts floating around in certificates, how do you figure out what the
authorization policy was, or which certificates have to be revoked to change
that policy?
A better approach is to use group membership -- create an object group that
contains the 25 accounts that Alice can spend from and then require Alice to
present two certificates:
- One that authorizes her to spend from any account in the group.
(Alice's key is the subject).
- One that verifies that the account she wishes to spend from is
in that group. (the account is the subject).
These certificates could easily come from different issuers (e.g., one
that controls corporate approval policy, and one that manages financial
accounts and relationships with banks). The resulting simplicity win is
that it is quite likely that there are subjects other than Alice who
will be authorized to spend from the same account group.
Group naming is a potential tarpit -- one possibility is to use SDSI's
approach of making the name relative to an issuer, so that a group's
global name includes some master issuer's <prinicipal>.
Now a couple more issues:
[Issue 2]: Does the detailed approach to object group membership (probably
based on tag values) need to be spelled out in the SPKI document?
[Issue 3]: The prefix and suffix operations proposed in the draft and above
are character by character (i.e., string) operations. The motivating examples
are component by component (e.g., filename, hostname) operations. Should the
prefix and suffix operations instead be specified as component by component?
This would involve specifying the component delimiter in addition to the
prefix or suffix.
--- SDSI Names ---
Based on the above discussion about group membership as a substitute for large
"union" certificates, I would observe that an object group to which we only
ever grant authority to one key is a late binding mechanism. Now, it is
certainly the case that a "group of 1" is not the most obvious way to do name
binding, but the group mechanism generalizes to some other useful lste binding
environments. Consider a cross-company collaboration in which Company X wants
to control what documents can be seen by people in Company Y, but wants Company
Y to control who can see them (since the folks in charge at Company Y know more
about their employees than the folks in charge at Company X). A group of the
documents that can be accessed solves this problem, in a fashion similar to the
bank account example. The sort of group membership I have in mind can be
implemented via tag extensions rather than changing <issuer> and <subject>
(I think two tags suffice, one that says "is a member", and one that captures
trust in membership certificates issued by other issuers). So, the final
proposal is:
[III] Delete SDSI names in favor of an object group mechanism.
Let me admit here that I'm less confident about this than the other two
proposals -- in particular, I'm interested in strong rationales supporting the
need for late binding of subjects in the fashion that SDSI does it. Chaining
through multiple indirections is definitely a bit awkward with object groups,
but my guess is that long chains aren't particularly useful in practice. A
disadvantage of using object groups to do chaining is that the chain is
specified by listing its links and for long enough chains, assembling the
chain from its links becomes non-trivial (like matching dominoes if you're
familiar with that).
If we stick with SDSI names, I think we should at least bring the binding
mechanism around to this methodology -- It seems to me that <issuer-name> is
the wrong way to do the name to key binding because the binding is a side
effect rather than the main purpose of the certificate. Take the example in
section 4.3.2.1, and change the tag from "(*)" to "(telnet (suffix foo.com)
bar)". The resulting certificate not only binds "fred" to a key but also
authorizes that subject to telnet to *.foo.com as bar. If I want to revoke the
binding, I have to revoke the telnet privilege as well (and vice-versa). IMHO,
it's better to do the binding as a separate certificate, using a tag field,
viz:
(cert
(issuer <principal-1>)
(subject <principal-2>)
(tag (sdsi-name fred)) )
"<principal-1> says <principal-2> has sdsi-name fred"
rather than the current:
(cert
(issuer (name <principal-1> fred))
(subject <principal-2>)
(tag (*) ) )
"<principal-1>'s fred says <principal-2> may exercise all (fred's) authority"
--David
============================================================================
David L. Black THE OPEN GROUP Voice: +1 (617) 621-7347
The Open Group Fax: +1 (617) 621-8696
Eleven Cambridge Center RESEARCH E-Mail: d.black@opengroup.org
Cambridge, MA 02142 INSTITUTE http://www.opengroup.org/~dlb/
============================================================================
Follow-Ups: