[caops-wg] OCSP & Proxy Certs

[Mike Helm]

Jesus Luna writes:
[About revocations ... of short term/proxies]
> -Entities able to make revocation requests and even though the protocol 
> to use is not specified maybe we should take a similar text.

Maybe, altho as you mention later 
> Oscar and myself will try to comment something about this topic later, 
> as we have developed
> such mechanisms at the CertiVeR project.

As well as the OGRO configuration format ...
There's a standards document in here somewhere, but it's a little too early 
for that.  Maybe we should add some information about these R&D
projects that you all have done, at the least as appendices to the OCSP
document.  They may not be the last word on this but it will help
get the idea out there.  What do you think?

> -However I don't agree at all with the "Others can request 
> revocation...." maybe it is too open and in our case should be 
> constrained to Mike's comments below ("Who can revoke....").
 ....
> Here I would like to highlight again the possibility for the parties to 
> agree beforehand (at VO creation/planning) on a OCSP Responder
> maybe different from AIA, so it may be necessary to let them the 
> flexibility to configure such agreed OCSP Responders at some level:
> Maybe at the OCSP Policy/client configuration?

Have we done a good enough job of describing the different OCSP responder
usage scenarios or usage patterns?  There is a very good sequence of 
OCSP responder technical types, but the usage patterns were some of the
early motivators of this document.  The ones I remember:

The CA-related OCSP responder
The PMA or large scale clearinghouse: this is what 
   DOEGrids operates as a demo for EDG/EUGridPMA (http://amethyst.es.net/)
   and the product service Certiver offers them
   or something like corestreet in the US

The VO or site OCSP responder
   One of the motivators of the paper - sites like NERSC wanted a 
   local blacklist and emergency shutoff mechanism

The OCSP caching responder

There was also a meshing or chaining responder; I think the original
use case was this was a feature of a VO or clearinghouse OCSP in order
to glue together CA-linked OCSP responders.

All of this is in the document but is it clear?  Also, one can see
the patterns and models behind this (P2P, DNS, &al) - is it worth
spelling out those analogies?

> In any case it would be interesting to take the chance of current 
> EUGridPMA meeting maybe to pose the neccesity of having a (set of)
> Trusted OCSP Responders which I understand is the clearinghouse Mike 
> mentioned here. I think that Tony Genovese is talking about a
> Cert Validation Service so it would be interesting to hear about this topic.
> 
> >Conclusions:
> >We should recommend CA operators include an AIA URL for OCSP, and
> >stand up a server.  
>  
> >
> Or specified at a policy agreed beforehand as mentioned above.

This is ok, but in a world of Grids with porous boundaries, this 
can make interoperability harder.  Suppose "CA alpha" doesn't do
OCSP URL's because it's in a Grid where an OCSP responder is assumed
(by policy like you mention).

A user with a CA alpha cert wants to work with users in the
Modern-Grid project, and all their CA's have OCSP responders and
extensions in their certs, and no central OCSP responder. 

So the system and security admins have
an OCSP problem with CA alpha's hosts and users.  On the other hand,
CA alpha's customer base might not notice a problem - their
reply party policies will either 
a) use the AIA extension they find, and be happy with that; or more likely
b) use the agreed-on central OCSP resource, configured to deal with
Modern-Grid's different OCSP convention

It is clearly _better_ that a VO or Grid set up a central 
responder in order to make sure its own policies are used, isn't it?
Should we make this recommendation?

Also, in this scenario, I think there are problems moving the proxy
cert revocation information  between the different kinds of grids,
should that be of interest.  Modern-Grid's OCSP responder might know
of CA-alpha-based proxy certs that are revoked, and are worth reporting,
but it has no idea about what place to deliver that information.

I don't think we've figured out how to do that, but at least having 
the EE cert carry an AIA OCSP extension could be the starting point
(where to look).

> recommendation
> could be reinforced in a near future. TERENA's TACAR repository could be 
> also a good idea

Terena sounds like a good focal point - are they interested?

> >OCSP client software must ignore "unknown" responses about proxy
> >certs - no info is no info in this case.
> >
> OK, but should it be also a config option for those clients whose OCSP 
> provider does not
> support proxy revocation?

How do we need to express this?  What I want to do is make sure
we don't recommend a software engineering problem.  I think we can
expect that very few proxy certs will ever be revoked (but the ones you
want revoked, you really want them revoked).