Hello,
About this topic we would like to comment that -in analogy to non Grid
PKIs- revocation of a N-level Proxy Certificate should only be performed
by its Issuer (N-1 level entity, does not matter if it is an EEC or
another Proxy) *and* by any other entity up to the Root CA itself (that
is hierarchy levels N-2...0). When a certificate is revoked, then their
issued certificates (again does not matter if EEC or Proxies) should be
considered revoked.
The "one-request" mechanism proposed in OGRO (embedding the whole Proxy
Cert Path in one OCSP Request ) could manage this proposal with some
modifications, because when the OCSP Response is received then it could
invalidate the Cert Path just below the certificate whose status is not
"Good".
We have been exploring also the "direct Proxy revocation" method: when a
Proxy is destroyed or revoked for any other reason then an
"administrative" message is sent to the OCSP Service so the revocation
is done directly in its certificate status database. The authorization
checking on such admin message is based on a very simple system that
verifies if the issuer (message originator) is able to revoke such
credential (i.e. is part of the Certificate Path and can be found in any
level above the Certificate being revocated).This should be customizable
by the relying party, i.e. in a new rule of the Grid Validation Policy.
Based on this, we don't think encoding the AIA into the Proxy
Certificate should be mandated, but instead it would be better to apply
the same provisions of section "4.4 Responder discovery" (from the
current version of the document). In any case a mechanism like OGRO's
Grid Validation Policy may deliver this feature to relying parties.
We hope to have understood the same idea that you presented with the PPT
back at the GGF15, but in any case please let us know what you think.
Regards,
Oscar & Jesus
