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

cert chain satisfaction hints

-----BEGIN PGP SIGNED MESSAGE-----

Jim,

	when 5-tuple reduction fails to find a certificate chain to validate a 
request, it should give the caller hints about what would be needed to 
satisfy that request -- or at least to make progress.  One hint is available 
automatically:  the cert which was looking for a predecessor cert (if 
you're working backwards from the request) or the cert looking for a 
successor (if you're working forward from an ACL entry).  If there were 
multiple possible threads, only one of which had to be satisfied, then there 
might be multiple raw ends which could be reported back to the caller.

	Of course, as Ron keeps pointing out, it's the job of the requester to find 
and supply the right certificates, so the verifier would probably just ship 
the relevant certificates back to the requester and let him determine what 
to do next.

 - Carl


At 09:19 AM 4/9/97 -0400, jar@ornl.gov wrote:
>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
>--------------
>Ron wrote: 
>Excellent questions, and an important ones for making these systems
>workable in practice.
>
>There is obviously some negotiation that must take place between the
>requestor and the server so that the server can end up having the
>certificates it needs to see that the request is appropriately
>authorized.  The requestor probably doesn't want to give the server
>all of its certificates a priori, since there is privacy loss there.
>But the requestorr may not even know a priori what is on the ACL.  Furthermore,
>some of the certificates needed may be available from third parties---who
>should go get them?  In SDSI (see the original paper from my web page),
>the requestor makes a request, the server can deny it but tell the
>requestor what group membership is needed, and the requestor can repeat
>the request with appropriate group membership certificates.  I think that
>this sort of approach is likely to be the most workable in practice...
>
>Does this make sense?
>
>	Cheers,
>	Ron
>==============================================================================
>
>
>
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBM1KcPVQXJENzYr45AQG0iAQAivD4phXS8WMOZRgDUNPzJXcCdB6fn0Yo
ySz7plCMqsJ3X+KWCARqNyGY8VowjtsVikfmbc3fZAYrdQ/zvhO0qeJs7sAKayRg
YKvIuYgyFVOuUdZbsOb3b/PKYJYeuqsmHCAbetbpLR4d7qbUU+TdpfNEGkUKiSW4
OOyHUvpOrmA=
=ylA0
-----END PGP SIGNATURE-----
References: