[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
I just read Tony's long note about tag-ids and meshes of certificates.
Here are some comments:
(1) If A delegates to B and B delegates to C, it isn't necessary that
B know about his delegation from A at the time of B's delegation to C.
For example, B may issue a certificate to C:
(tag (read-file (* prefix "//usr/spool/mail/B"))))
before the system (A) even gives B any files (with associated permissions)
to read. (E.g. I give my secretary permission to read my email, even before
there is a file to specifically give permission about.)
Or, I may delegate to my laptop-key any permissions that are allocated
to my main key. Then, when I'm travelling, more permissions are granted
to my main key. My laptop key can use those permissions, even though they
where unknown at the time I passed them from my main key to my laptop key.
Thus, I am uncomfortable with a scheme where you can only delegate a
permission (or a subset) AFTER you have received it yourself, and I am
uncomfortable with a scheme that requires that you can not (try and)
delegate more than you have received. The intersection rules keep you
from actually delegating more than you received, and so we don't need
to have that rule implemented two different ways...
(2) In the SDSI model, it is not the verifier who has to rummage around to
find the appropriate certificates, but the requestor. This is important
for appropriately balancing the system workload, I think. Particularly
if the certificates may be somewhere else (i.e. the verifier doesn't
have them in hand.)