From this I conclude that the only AIA that's safe is the EE's
Let me list some assumptions and characteristics of proxy certs, and related services (please correct and add as needed). There's also some new things on the table that we need to consider. Proxy cert characteristics Autochthonous - typically generated on the spot, by the user or a delegated process Not likely to be "registered" anywhere (perhaps in myxproxy, see below) Different types (pre-, post- RFC3280, general, specific attributes) Different capabilities (attributes; dependent on conforming software) Time limits - minutes to weeks (potentially longer) Cascades of certs - delegated rights to create proxies given to processes Portable - software crypto store; private key can typically be copied to a new location Proxy certs are the means of crossing domain boundaries (not always, but one of the design points) [I think this is one of the points that is going to create the most trouble for proxy cert OCSP, if that's not already evident] Services using proxy certs Will have access to the end entity certificate that tops the proxy chain Whether they have access to a trust root for the EE cert or not, is the question that motivates a more general validation service, something to take up later New services MyProxy - this credential store service has become more important in the past year or so, and developing in tandem is SLCS - short lived certificate services Bridge existing authentication to an X.509 - generating CA; this may be operated together with a MyProxy service (see http://myproxy.ncsa.uiuc.edu/) MyProxy can store and manage key pairs for various usage scenarios. 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 I put these in 3 groups. The first, the proxy cert & EE cert, just seem to me to be instances of the same "agent". The 2nd is one of the motivations for this work: we should provide a means for resource owners to protect their resources, w/o causing unnecessary problems for EE cert holders. The latter Jesus mentioned in his message ... and it seems weird to me. As a CA operator I can't imagine a scenario where I would revoke a user's proxy cert. It seems like it's out of my scope as CA manager (it's something like your bank manager telling you where to spend your money). Thinking about our PKI architecture ... I don't think we would or could permit our root CA to revoke the EE certs in the subordinate CAs. The CRL-reading software probably wouldn't understand it. Some conclusions I draw: 1) The user (EE Cert) & the site security folks (group 2) are 2 separate anchors for proxy cert trust 2) The CA revoking sub certificates and the EE revoking proxy certificates are somewhat different - does this change how we manage revocation info (That is, in CA, Isub(n) can revoke EEsub(n+1), but EE and any Proxy sub(n) can revoke Proxy sub(n or greater)) Observation: Group 2 - site security - is fuzzy. In every local context it probably is clear but there will be many variants, and thus the right to revoke is going to vary, yes? MyProxy particularly introduces a new player. If myproxy is set up as an enterprise service, or VO service &c, then the server manager has some role independent of the other 3 groups. Does the MyProxy manager have the right to revoke proxy certificates held in this store? Let's suppose there's a perfect infrastructure, where all the CAs issue EE certs with AIA URLs to their OCSP responders. Suppose EE proxy generators cause the proxy certs to inherit this AIA URL. An application encountering a proxy certificate will find a CA OCSP responder that it can query. (An application - something doing real work, as opposed to security :^) Suppose this infrastructure includes a MyProxy service that installs its own OCSP responder URL; the application will find that (does it still find the remote OCSP responder or not)? Suppose this infrastructure has its own local OCSP responder, for caching and to meet local security needs. The application will find this URL. Now imagine that a proxy cert crosses a domain boundary. Perhaps the myproxy responder, or Domain1's local responder, are local-only servers and cannot answer outside their domain. What happens to the application when it tries to act as an OCSP client? 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). This seems to lead to a recommendation that CA OCSP responders develop the capability to store & return info on their clients' proxy certs. This is a tall order, but not insurmountable. Now let's look at this from the EE's point of view. I have some chain of proxy certs, and I've set off a job that I need to stop. I want to revoke the proxy cert or certs it's using. How do I do this? Well, in general I have an AIA URL in my own cert, and I may or may not have some knowledge of a clearinghouse OCSP server. I could run a simple script that delegates a proxy ocsp responder right to some service. How do I limit that right? Or, could I just register the proxy cert I want to revoke, thru an authenticated process to the OCSP service I want to use for registering this revocation? OCSP doesn't have a UI or protocol for this phase of its work; it seems to me we are the point of describing an extension protocol for this UI. Let's look at the revocation problem from the local security point of view. They can meet their needs by standing up a local OCSP responder, and persuading their community to use it on their resources. But they would like to protect themselves from problems they don't know about, which include security problems arising in closely linked domains. For example, Supercomputer Site A and Big University B are closely linked. "A" would really like to know about local revocations in "B" to keep problems from spreading. "A" and "B" could establish an agreement to replicate data back and forth from local blacklist - OCSP responder databases. A more generalizable and scalable arrangement might be: "A" and "B" could agree to use a standard evaluation algorithm, which orders OCSP revocation as (local, then clearinghouse, then EE AIA); and adopt a relationship with clearinghouse OCSP's and CA OCSP's, permitting the local site to upload proxy cert revocation information to the databases of these CA's. MyProxy manager, if permitted to deal with this, seems more like a variant of the EE case. The myproxy manager needs to be able to act on the credential store's customers' behalf in the same way the customer would behave. Conclusions: We should recommend CA operators include an AIA URL for OCSP, and stand up a server. 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 A protocol for permitting authenticated updates (registering of revoked proxy certs) may need to be developed OCSP client software must ignore "unknown" responses about proxy certs - no info is no info in this case. 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. Thanks, ==mwh Michael Helm ESnet/LBL