[caops-wg] OCSP & Proxy Certs

[Mike Helm]

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?

>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).

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