[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
This note attempts to expand upon my previous note on adding/subtracting
permissions, which apparently wasn't clear enough (it confused Hal Finney;
see note below). My apologies; I hope this addition helps.
(1) A tag is supposed to grant a permission to do something. Possession
of the tag (appropriately signed) allows you to do that something.
(2) Possession of a tag never prohibits you from doing something, since
you never have to show THAT tag to anyone.
(3) If you have multiple tags in your possession, you are free to pick
whichever one suits your needs (i.e. whichever one allows you to
do what you want).
(4) Thus, a tag is like a traditional ``capability'' in that possessing
it confers ability.
(5) A user can thus express the permissions granted in terms of what
it allows him to do. The tag
(exec-ok P F)
is intended to say that he can apply program P to any program except F.
If we want to phrase this entirely positively, we would say that it is
(exec-ok P (* set A B C D E G H I J ... Z ))
in the case where A...Z are the available files.
(exec-ok P G)
is equivalent to
(exec-ok P (* set A B C D E F H I J ... Z ))
If an issuer issues both tags (exec-ok P F) and (exec-ok P G), then
he is really letting the user run P on any file he wishes, since the
user gets to choose which tag to use.
(6) These issues have little directly to do with certificate chains and the
intersection of tags in certificate chains. They have to do with
multiple tags by a single issuer when the issuer tries to think of the
tags in a "negative" manner (e.g. "excluding" certain files). The
"negative" aspects of the tag may be overcome by other tags by the
same issuer. The problem arises with MULTIPLE tags from the SAME
issuer when the issuer thinks that the tags have some NEGATIVE
flavor to them.
Does this help?
From: Hal Finney <firstname.lastname@example.org>
Subject: Re: adding/subtracting permissions ??
Ron Rivest, email@example.com, wrote:
> If you try to have "negative authorization", then you can get into
> trouble, independent of *-forms. For example, following Tony's
> example below, you might have a tag
> (exec-ok <program> <file>)
> (exec-ok P F)
> which is intended to mean: "You have permission to run program
> P as long as its input is not the file F." Independent of *-forms, what is
> it supposed mean if I have two certificates:
> (exec-ok P F)
> (exec-ok P F')
> for two different files F and F'? Clearly I can now run P on any
> program I like! (To apply P to F', I use the first certificate, and to
> apply it to F, I use the second. For any other file, I can use either
I thought the rules we were discussing for tag merging were applied in
the context of delegation. The original SPKI document discussed merging
with the assumption that the subject of the first cert was the issuer of
the second. Then resulting cert was supposed to be the "intersection" of
the tags, which was not really defined. The discussion for rules about
combining tags was being applied in that context, I thought.
In that case, if the first cert has an auth tag of (exec-ok P F) and the
second has (exec-ok P F') then I don't think there would be any good way
to merge them. The intersection of these two tags would properly be null.
This is not the same as having the same signer issue both of these
authorizations, which I agree would cause problems. The case we are
talking about is where the second auth is issued by a delagatee of the
> I think the problem you are proposing have little to do with *-forms, and
> arise from the "negative" nature of the authorization. What does it mean
> to have two certificates:
> (vacation-not-ok-on (* set Monday Tuesday))
> (vacation-not-ok-on (* set Monday Wednesday))
If the first cert is (vacation-not-ok-on (* set Monday Tuesday)), and the
second in the delegation chain is (vacation-not-ok-on (* set Monday)), we
should not merge these, because the second is actually asserting more power
than was delegated it by the first.
I don't think negative authorizations by themselves are necessarily a
problem. However they do cause trouble in the context of the proposed
merging algorithm, which was designed with positive authorizations