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