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@ac.upc.es | Barcelona 08034 SPAIN <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>