[caops-wg] OCSP - proxy certs

[Jesus Luna]

Mike Helm wrote:

>Olle Mulmo writes:
>  
>
>>I would say that your responder got confused up by the proxy certs. 
>>Possbily also that that it is one of the responders that cannot handle 
>>multi-certificate requests (array count > 1).
>>    
>>
>
>I think (guess) it is more likely the latter, but don't know.
>I will try to rig up some kind of test that can see what 
>our demo OCSP responder can do with a couple chained CA's
>and an EE cert (probably as close as ESnet can get rite now).
>
>I think what we should do is request developers of client and
>OCSP server code support properly parsed multiple cert
>OCSP requests but recommend against using them.  This sounds 
>ridiculous but until we fully understand how the commercial
>servers work...
>  
>
About this point we would like to tell you about our practical 
experience obtained  with the implementation of OCSP (CertiVeR API) into 
GT4:
-First of all RFC2560 defines a request structure containing a 
"requestList" element, in other words any OCSP Provider compliant with 
such recommendation should provide this support.
-Our OCSP client library parses each certificate from the Proxy´s chain 
as "Request" elements of such "requestList", which means that it is 
client's responsability to obtain such chain (which in fact is provided 
by GT4 APIs ie when initializing a Proxy).
-When the OCSP Responder parses the "requestList" it will obtain the 
"CertStatus" for each contained certificate as follows: i) From the Root 
to the EEC it will respond with any of the good, revoked or unknown 
statuses,  ii) for any ProxyCertificate contained it will never respond 
a "good" status just because it would be very expensive to register 
every Proxy Certificate into the CA. However any standard Responder may 
generate an "unknown" status.
-When the client library receives the OCSP Response and parses each of 
the "SingleResponse" structures it will conclude that a Proxy 
Certificate is revoked if its "CertStatus" has such value, otherwise it 
will be considered as Valid.

The process described above could be implemented with any RFC2560 
compliant OCSP Provider and will consider a Proxy Certificate as Revoked 
if any certificate from the EEC to the correspondent CA has been 
revoked. However further support for fine-grain Proxy Certificates 
revocation could be developed just as we have done with CertiVeR:
-When a subject wants to delete a Proxy Certificate before ending its 
Validity Period (i.e. executing a grid-proxy-destroy) then it notifies 
the revocation of such certificate to CertiVeR.
-CertiVeR authorizes the Revocation Request (Proxy's Unique Name feature 
eases such AuthZ) and registers corresponding revocation data 
(issuerKeyHash, issuerDNHash and Serial) into its database (for a 
description of CertiVeR revocation model take a look at www.certiver.com).
-From now on CertiVeR will able to respond with a final "Revoked" status 
for such Proxy Certificate, thus allowing a fine-grain revocation..

Best regards,

-- 

____________________
Jesus Luna Garcia
PhD Student. Polytechnic University of Catalonia
Barcelona, Spain
jluna at ac.upc.edu