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

Tag Conditionals (was Re: Delegation and Policy)

Brian Thomas wrote:
[snip]
>     Your example of policy would likely solve the problem, but
>inelegantly, it seems.  A more straightforward solution would involve
>the ability to grant only the ability to grant or delegate a privilege
>without being able to make use of it directly.

I was looking for that straightforward solution, and had attempted a
construct of the form:

TZ:   (tag (drivers-licence (* set (capacity may-issue has-been-issued))).

I believe Ron Rivest had pointed out that, to wit, a chain-validation should
fail if the result still contains *-forms.  That is, the "final subject"
certificate(s) must have constant parameters.  But perhaps I am wrong, and
at least he meant that a certificate query of the form

    Is cert C valid to authorize X? (for X constant)

must necessarily intersect to a constant to be valid.  In either case, the
license examiner granted tag TZ could certify my key KI with the tag:

TI:   (tag (drivers-licence (capacity has-been-issued))

And now TI = subset(TZ).

>I also should not bring up the conflict-of-interest possibilities whereby
>someone privileged to grant a license should not be allowed to grant it
>to himself, so I won't.  This could, of course, be handled by a policy,
>and probably no other way.

Yes, this is the hard part.

Here are suggestions that would extend *-forms, in that the tags would
have parameters that refer to (and test against) values in the cert header.
They still have flaws, but maybe someone can work them out.  I think the
functionality would prove useful in lieu of full-up algorithms:

This one borrows the C-language tri-glyph contruct:

TZ:  (tag (drivers-licence
            (* set ( capacity (delegate ? may-issue : has-been-issued )))))

Here, a cert issued with "may-delegate" gives the tag allowance to continue
certifying "may-issue-license", otherwise resolves to only certifying "has-
been-issued-license".  Higher authority Y can grant Z "no-delegate" so that
Z cannot certify more license-grantors, but can grant licenses.  Maybe.

I imagine that an "intersection pre-processor" reduces the tri-glyphs to
a constant, or at least a non-conditional parameter, prior to intersection.

Another tag-embedded test could replace "delegate ?" with "SUBJECT == ISSUER ?"
as a condition on award of parameter(s).  This may prevent self-certification
(on a single key) but here we want subject <> issuer for both the delegation of
right-to-issue and non-delegation of right-to-drive. Still does not exactly
fix the problem.  Maybe some combination?

(This is fun! Do people get paid to do this? :)

____TONY____
(ERROR: .sig authentication failure)