[caops-wg] OCSP & Proxy Certs

[Jesus Luna]

Dear all,
Mike's email is pretty comprehensive and there are several interesting 
points to comment. I'll try to make it in a couple of emails (hope so!)...

Mike Helm wrote:

>Time limits - minutes to weeks (potentially longer)
>  
>
I can see that these "longer lived" proxy certificates are like the kind 
of credentials that you commented in your last email (something related 
with OSG Consortium).
IMHO it looks like in the worst of the cases they can be treated like 
EEC...or even SLC (which seems to be one hot topic at the in-progress 
EUGridPMA meeting),
in any case hope we can found that they can be covered by the mechanisms 
described the OCSP Reqs document (at a glimpse I don't see a reason for 
the opposite).

>Services using proxy certs
>Will have access to the end entity certificate that
>   tops the proxy chain
>  
>
This is enough information for the OCSP Responder -should it be aware of 
Proxy Certificates statuses-.

>SLCS - short lived certificate services
>  
>
I was not aware of such concept, but reading the TAGPMA document at:
http://www.tagpma.org/files/IGTF-AP-SLCS-20051115-1-1.pdf
I've found that in section "4.3 Revocation" the following is stated: "It 
is assumed that the Short Lived Certificates will not need to be revoked 
because their life time is shorter
than the update cycle of most CRLs. If revocation is supported, then 
revocation requests can be made by certificate holders, Site identity 
managers and the SLCS CA.
These requests must be properly authenticated. Others can request 
revocation if they can sufficiently prove compromise or exposure of the 
associated private key.
Individual holders of a SLCS certificate must request revocation if the 
private key pertaining to the certificate is lost or has been 
compromised, or if the data in the certificate are no longer valid."

Most of the text is pretty similar to Mike's conclusions at the end of 
this email and the interesting point here are from my point of view the 
followings:
-Entities able to make revocation requests and even though the protocol 
to use is not specified maybe we should take a similar text.
-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....").

BTW in some place I read that SLC must contain AIA extension with OCSP 
info...

>Who can revoke proxy certs (or who wants to revoke them)?
>Let me list some possibilities, from less controversial to more,
>and then discuss some usage scenarios.
>- The EE certificate owner
>- A lower generation proxy cert from the chain
>- the proxy cert itself
>
>- the affected resource owner
>- a local security officer
>
>- The EE cert issuer or any member of that chain
>
>The latter Jesus mentioned in his message ... and it seems weird
>to me.  
>
My terrible mistake I was trying to express with words a concept related 
to the "branch pruning" slide from the PPT being commented, where the 
Proxy Cert should
be revoked in some entity above in its Cert Path has been revoked    :)

>>From this I conclude that the only AIA that's safe is the EE's
>link to his issuing CA's OCSP responder; or, an OCSP server acting
>as a clearinghouse - community resource (like certiver, or the 
>DOEGrids demo for EUGridPMA).
>  
>
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?
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.

>Since not every CA can do this, we should recommend some agency
>(IGTF? commercial?) stand up clearinghouse OCSP responders which
>can become well-known & trusted resources
>  
>
Maybe at PMA's Authentication profiles or at some simmilar document this 
recommendation
could be reinforced in a near future. TERENA's TACAR repository could be 
also a good idea
for a service like this and maybe interesting to mention there now that 
NREN Grids are being
commented at their taskforces.

>A protocol for permitting authenticated updates (registering of 
>revoked proxy certs) may need to be developed
>  
>
Oscar and myself will try to comment something about this topic later, 
as we have developed
such mechanisms at the CertiVeR project.

>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?

>I am sure there is much more to say about this and other views.
>I have some document comments about some minor points but I have a
>plane to catch and will get back to that in a day or 2.
>  
>
Have a nice travel Mike and hope to read from you soon!

Regards a todos!

-- 

<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
o o o Jesus Luna Garcia         |   Polytechnic University of Catalonia
o o o PhD Student               |   Department of Computer Architecture
o o o phone:  +34 93 401 7187   |   Campus Nord. www.ac.upc.es
U P C fax:    +34 93 401 7055   |   C/Jordi Girona 1-3, Modul D6-116
      E-mail: jluna at ac.upc.es   |   Barcelona 08034 SPAIN
<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>