New combining algorithms profile and a potential issue in 3.0 core spec

[Erik Rissanen <erik@axiomatics.com>]

All,

I have uploaded a new working draft of the combining algorithms profile.

I have generalized the on-permit-apply-second algorithm so it can take
a third child which is applied in case the first child ("the condition")
returns N/A or Deny. This is the if-then-else feature which we discussed
earlier on the list.

I also made some other changes to the algorithm. It used to be "clever" in
case of different flavors of Indeterminate. But I realized that doing so
is dangerous and undesirable for this algorithm, so I simplified
the error handling. Let me explain why.

The purpose of this algorithm is to allow using conditions in policies.
For instance, someone could write a policy like this:

PolicySet Y [on-permit-apply-second]
  Policy A, Rule, Condition: the subject has an account in corporate LDAP
  PolicySet X
    ... policies which apply to these subjects ...

Now, when the PolicySet X is authored, it is likely to be done with the
assumption that the user has an ldap account, since this is what is
tested for in the condition. The author would assume that the policy set X
is not evaluated if the condition is false.

However, in WD 03 of the profile, if Policy A (with the condition) returns
an Indeterminate{P} or Indeterminate{DP}, the policy set X is evaluated
anyway to determine the flawor of Indeterminate which should be
returned as a whole for policy set Y.

But since the policy A was indeterminate, we don't really know whether
the condition is true or not, so we might in fact be in a situation
where we violate the assumptions which were made when X was authored. 
That is,
in this case, the user might not have an account in ldap.

That in turn means that policy set X may malfunction and behave incorrectly.
That could in WD 03 lead to an incorrect N/A or the wrong flavor of
Indeterminate from the on-permit-apply-second combining algorithm.

The potential generalization of the algorithm to three children would mean
that to discover the flavor of Indeterminate, one would evaluate both
children and then use a flavor depending on the result. Also, when the two
children agree on the decision, then one could even make a defined decision
even if the first child (the condition) is Indeterminate. I made a table
which I have attached to the end of this email which lists all the cases.

However, if we consider that if it is not known whether the condition holds,
then we cannot really trust the result of either of the children, so
the values on the left in the table could be seen basically as random,
meaning that an algorithm which tries to be smart can potentially return
_any_ decision randomly.

Do note that already the WD 03 version of the algorithm is dangerous since
the wrong flavor of Indeterminate could influence a nesting combining 
algorithm
to do the wrong thing.

So therefore I did not use smart Indeterminate handling in the combining
algorithm when I generalized and I have removed the smartness from
the case where there are only two children as well. This applies to the
case when the first child is Indeterminate{P} or Indeterminate{DP}.
The case of Indeterminate{D} should be safe since that implies that there
is no way the second child should be evaluated, regardless of the error. So
I kept that case as it was.

One more thing: when I thought about this algorithm, I realized that we have
a similar issue with plain 3.0 targets. In sections 7.12 through 7.14 
the spec
tells to evaluate the children and combine them in case the target is
Indeterminate. This is to determine the flavor of Indeterminate, but if
target is failing, we don't really know whether the children behave
as intended either.

I think we should do an errata on the core spec because of this and let the
Policy/PolicySet always be Indeterminate{DP} in case of a target which is
Indeterminate.

Best regards,
Erik

Here is the table for choosing a decision among two policies if
it is not known which of the two should be used:

Permit Permit -> Permit
Permit Deny -> Indeterminate{DP}
Permit Indeterminate{P} -> Indeterminate{P}
Permit Indeterminate{D} -> Indeterminate{DP}
Permit Indeterminate{DP} -> Indeterminate{DP}
Permit NotApplicable -> Indeterminate{P}
Deny Permit -> Indeterminate{DP}
Deny Deny -> Deny
Deny Indeterminate{P} -> Indeterminate{DP}
Deny Indeterminate{D} -> Indeterminate{D}
Deny Indeterminate{DP} -> Indeterminate{DP}
Deny NotApplicable -> Indeterminate{D}
Indeterminate{P} Permit -> Indeterminate{P}
Indeterminate{P} Deny -> Indeterminate{DP}
Indeterminate{P} Indeterminate{P} -> Indeterminate{P}
Indeterminate{P} Indeterminate{D} -> Indeterminate{DP}
Indeterminate{P} Indeterminate{DP} -> Indeterminate{DP}
Indeterminate{P} NotApplicable -> Indeterminate{P}
Indeterminate{D} Permit -> Indeterminate{DP}
Indeterminate{D} Deny -> Indeterminate{D}
Indeterminate{D} Indeterminate{P} -> Indeterminate{DP}
Indeterminate{D} Indeterminate{D} -> Indeterminate{D}
Indeterminate{D} Indeterminate{DP} -> Indeterminate{DP}
Indeterminate{D} NotApplicable -> Indeterminate{D}
Indeterminate{DP} Permit -> Indeterminate{DP}
Indeterminate{DP} Deny -> Indeterminate{DP}
Indeterminate{DP} Indeterminate{P} -> Indeterminate{DP}
Indeterminate{DP} Indeterminate{D} -> Indeterminate{DP}
Indeterminate{DP} Indeterminate{DP} -> Indeterminate{DP}
Indeterminate{DP} NotApplicable -> Indeterminate{DP}
NotApplicable Permit -> Indeterminate{P}
NotApplicable Deny -> Indeterminate{D}
NotApplicable Indeterminate{P} -> Indeterminate{P}
NotApplicable Indeterminate{D} -> Indeterminate{D}
NotApplicable Indeterminate{DP} -> Indeterminate{DP}
NotApplicable NotApplicable -> NotApplicable