Hello Mike & all, I'm sending this message again. Hope you receive it! Salut, Jesus Luna ----- Mensaje reenviado de jluna@ac.upc.edu ----- Fecha: Fri, 3 Feb 2006 12:31:24 +0100 De: jluna@ac.upc.edu Responder-A: jluna@ac.upc.edu Asunto: [caops-wg] Proxy Cert Revocation - Pros&Cons Para: caops-wg@ggf.org Dear all, As mentioned in the last teleconference, we are sending to the list a first version of "Proxy Rev Pros+Cons". Hope you like it :) ****Pros: **Improved security as every involved Proxy Cert will be included into the path validation prior being authorized by Grid relying parties. **Relying parties may have more control over their owned Grid resources as Proxy Revocation could be the mechanism to implement blacklists in those Authorization systems not supporting them. This could be implemented by using a fine-grained AA revocation support in Proxies with embedded Authorization information (i.e. CAS, VOMS). In this way, resource owners may be able to revoke authorization attributes, while identity providers would be in charge of revoking the authentication credential (the Proxy Certificate itself). **The EEC owner may be able to indirectly manage submitted jobs by revoking or suspending User Certificates. ****Cons: **A Proxy Certificate may be created for accessing more than one particular resource, while authorization attributes are typically issued in a finer-grained way. The use of fine-grained revocation would help to control the revocation of authorization attributes while avoiding conflict with other processes being executed on behalf of the same Proxy Certificate. In this case, the revocation of the Authorization Information would be done by the resource manager. **Small CAs may be required to operate a fault tolerant (24*7) OCSP service and in most of the cases to re-issue EECs in order to include the AIA extension. **If CAs are not willing to operate their own OCSP service, then a long term relationship with an appropriate OCSP provider should be established because the administrative and technical costs that such task involves may be too expensive for the CA. **Being short-lived, Proxy Certificate’s registration and identity validation may become a bottleneck at the RA/OCSP service. Also the mechanisms to securely perform such task should be developed (i.e. we require it to take place as an atomic and authenticated transaction). The solution to this problem should be highly scalable as the potential number of Proxy Certificates could be expected to be greater than EECs. For long Proxy Certificate hierarchies, the certificate path building process at the RA/OCSP may represent a sensible overhead for the service. In order to avoid such bottleneck, no proxy certificates should ever be registered for Identity Revocation. Only registered owners should be allowed to revoke their proxy certificates. However, this change would imply changing the semantics of the OCSP response for Proxy certificates. In this case, an unknown OCSP response for a Proxy certificate would be taken as valid identity. **The Proxy Revocation process will require developing the secure mechanisms to authenticate and authorize the requestor. If blacklist will be implemented through this mechanism, then low-latency or even real-time publication/notification of such revocation should be emitted to relying parties so jobs being executed with compromised credentials could be stopped as soon as possible. Note that pre-computed OCSP responses can not be used for this purpose. **It is recommended to adopt full chain validation because if an OCSP Request for a single Proxy Certificate is created –the full path is not included in the message-, then the OCSP Responder may become overloaded with the Proxy Path Validation process (i.e. performing the path discovery). Best regards from Barcelona, Oscar & Jesus ----- Fin del mensaje reenviado -----