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

Re: Certs

> 
> Ron,
> 
> For complicated policy decisions where group membership will not suffice to 
> grant authorization (e.g., remote online operation of scientific instruments), 
> more complicated mechanisms are needed. For example, I might need certificates 
> to certify training, to certify payment, and to certify a time reservation to 
> get a certificate to unlock the machine at the appointed time. 
> 
> Now, suppose I am missing one. How do I know which it is, and where to get it? 
> Will I have to spend my life tracking down certificates so I can get my job 
> done? Such a spectre kind of frightens me. I think some sort of mechanism for 
> doing all these things has to go along with the SPKI/SDSI proposal or else it 
> will end up making life more complicated. Have we just ended up by replacing the 
> X.509 CA mechanism with a more complicated authorization certificate directory?
> 
> Maybe we need something like an OCP (obtain certicifate pointer) that will list 
> the URLs that issue the required certificates so it can all be done 
> automatically. So, the resource is contacted and sends the OCP to the requestor. 
> The requestor('s proxy) contacts the URLs to check on his certificate store. The 
> actual requestor may have to be bothered to answer some questions to obtain new 
> certificates, but hopefully this is minimized. Then the correct certificate 
> bundle is presented back to the resource.
> 
> Jim Rome
> ORNL


My vision for this has always been a policy certificate.  This is a cert
that basically embodies the PolicyMaker ideas, and indeed could be input
to PolicyMaker.  If a requestor wishes to make use of a resource, and has
not gotten access before, one of the things that could be on a cert server
would be a policy cert for the resource.  This policy cert would specify
the terms (stated, most likely, in terms satisfiable by certificates)
under which anyone would be granted access.

The API that I have begun to sketch out requests a chain of certificates
from the key of the server (found, presumably, by name from a certificate
directory) to his own key, including the desired permission.  This amounts
to a query-by-example on a theoretical cert (in Carl's 5-tuple notation):

    (server, requestor, delegation, permission, now-til-I-need-it)

If such a certificate exists, or an explicit chain can be constructed,
so much the better, and, of course, if multiple chains exist,
preference would likely be given to shorter ones.  If not, and a policy
certificate existed, the policy could be evaluated in a way that
provided QBEs for certs that would satsify it.  The policy certificate
would have a null subject, since its meaning is "the set of all
subjects which can satisfy the policy".  The QBEs could be executed,
and if any failed (or, for that matter, if any partial chains could be
constructed), they could be presented to the user as options to be
pursued in order to gain the permission required.  Alternatively, the
policy cert could simply be displayed so that you could go get what you
needed - if you could figure it out from the policy, of course.

Thanks again to Matt, Joan, and Jack for the PolicyMaker paper; it has
really gotten me going.

brian


Brian Thomas, CISSP - Distributed Systems Architect  bt0008@entropy.sbc.com
Southwestern Bell                                    bthomas@primary.net
One Bell Center,  Room 34G3                          Tel: 314 235 3141
St. Louis, MO 63101                                  Fax: 314 235 0162