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

Delegation and Policy

I offer these examples to address questions raised by some regarding delegation,
tags-as-capabilities, tags-as-attributes, needs for policy,and more. If I have it wrong, please feel free to point this out.

If a certificate is issued with delegation, it is implied that
the keyholder may use their key to certify other key/keyholders.

That is, for a set of tags T, assuming may-delegate,

        KX!(KY,T) validates KY!(KZ,T') for T' = subset(T).

The nature of the issuer, subject and tags make some delegations natural and
others absurd.  "Subject, may-login" seems a natural candidate to delegate, and looks like a capability.  "Subject, has scar on left cheek" appears more like
an attribute, and delegation seems out of the question.  Unfortunately this distinction likely cannot be codified.

A related case that kept nagging at me involved delegation of capability,
where the last-line certifiers must apply this capability to certify what
almost seems the same, but is not.  Consider this example, a plausible
future where my personal key asserts my license-to-drive.

        Let X represent the root authority for the department of
        motor vehicles (to issue driver's licenses).  As X cannot
        possibly deal with the mass of people who need licenses,
        they delegate this capability to regional offices Y, where
        cadres of examiners Z to do the real work.

        Let T represent the tag "may issue license-to-drive".

        Assume KX!(KY,T) [may-delegate] and KY!(KZ,T) [no-delegate].

        Z examines me, determines I am fit to drive, and certifies
        such by signing my key KI with tag ... what?  Certainly not
        with any derivative of "may issue license-to-drive", which
        they are not allowed to delegate in any case.

        Somewhere, my key must gain the tag "HAS licence-to-drive".

    One scenario would have Z simply issue me KZ!(KI,"has-license").

    When I later get pulled over for speeding, I hand my certificate
    (in a picture-ID smartcard) to the officer, whose reader transmits
    it to X (the service) for a validation check.  But this means that
    X must collapse the Z-Y-X chain every time I get pulled over, and
    also relies on the persistence of the Z-Y-X chain.

    A reasonable scenario would have Z still form the certificate, but
    immediately submit it to X for validation.  The result could be a
    CRCert that reads KX!(KI,"has-license") directly.  But this means
    the chain must be collapsed whenever Z issues a license.

    Clearly, Z would submit their own certificate KY!(KZ,"may-issue")
    to X when they joined the staff, cutting Y out of the chain and
    gaining the CRCert KX!(KZ,"may-issue"), but with no delegation.

    (Note that the intersections occur on the "may-issue-license",
    tag, not on any "has-license" tag.)

    Now X has a cert-conjunction policy, to wit:

        WHERE:   KX!((sub1),"may-issue") AND (sub1)!((sub2),"has-license")

        GRANT:   KX!((sub2),"has-license")

Does this capture the right idea?

A more interesting question is how SPKI might facilitate the manner whereby the
"Authority-To-Issue-License-To-Drive" mesh gets reliably and securely linked
to the "Authority-To-Pull-People-Over-For-Speeding" mesh.  Or more generally,
how do distinct authority-meshes benefit from each others certifications?

____TONY____ (just stirring the pot).