[security-wg] OCSP Requirements - GGF Summary

[Mike Helm]

I'm not sure who's on what list, apologies for duplicates. Follow-ups to the caops-wg list
(probably need to subscribe to read).

I've extracted the GGF objects related to the OCSP Requirements document.
For convenience, some documents are made available in
URLs below, and the relevant portions of the minutes 
extracted.

The most recent update to the document that I know of:
http://www.lbl.gov/~mike/OCSP_Requirements_for_Grids.doc
(this is a pre GGF-14 version)

GGF-14 discussion (extracted from minutes)

We had a good discussion recently on the mailing list on the OCSP
draft
(https://forge.gridforum.org/projects/caops-wg/document/OCSP_Requirements_for_Grids).
Olle will be giving us a new version soon.  An implementation is
available.  Mike Helm said there are some outstanding issues:

  - How do we manage proxy certificates in relation to OCSP.  How
    would OCSP reply to queries based on proxy certificates?

  - How does OCSP fit in with other revocation services?  In what
    order are things done?  What do you as a relying party want?  What
    is more authoritative?

  - Assumptions about CRLs are implied by the OCSP document,
    essentially that they exist and they are useful.  We don't have a
    best practices for CRLs except in EU Grid minimum requirements.
    We don't revoke proxy certificates in CRLs today.

Olle referred to the OCSP Services Architecture diagram in the OCSP
document.  CRLs are published periodically.  The relying party uses
OCSP and/or CRLs.  Inconsistencies are inevitable, but it's okay.  CRL
issuers and OCSP responders say, "to the best of my knowledge, this
certificate is fine."  Is this resolvable, or should the discussion be
summarized in the document?  We don't have enough experience with OCSP
yet to document "best practices".  The paper should just mention that
there might be inconsistencies.

Olle described the "fire and forget" policy of proxy certificates.  We
should put our energy into constraining proxy certificate policies.
Short lifetime is the traditional argument for proxy certificates.
The Site AAA document lists requirements on maximum proxy lifetimes,
recommending that people re-check authorization each day.  One method
is to use MyProxy credential renewal.  Another way is to use an
authorization attribute, like a VOMS attribute, that can be refreshed.
We have no clear answer for this; we need experience.  The paper
should leave it open and describe our discussion of the issues.

Do we need a CRL profile for grids?  The OCSP document has
requirements for CRLs, including references to delta CRLs.  Does
anyone use anything other than "regular" CRLs?  Use of "suspensions"
has been discussed.

Action item: Olle will add text about managing proxy certificates to
the OCSP document.

[As far as I know, not much of the prior discussion was incorporated,
and no text was added or changed after GGF-14.]

GGF-15
[I could not attend most of this meeting, and wasn't able to make the OCSP
discussion.]
Slides (not sure whose)
http://www.lbl.gov/~mike/OCSP-GGF15.ppt
[Argument: Seems to be, need a general way of signalling how to find appropriate
OCSP responder for a given proxy cert.  I don't understand what the "branch-level
pruning" slide is about; slide #4 seems to list the alternatives.]

>From minutes:

Ollie - OCSP draft
Similar to Chicago meeting (GGF 14)
Special issues on proxy certificates - wrap up here

Suggested approaches:
Multi-level delegation - OCSP check will be done at higher level of
proxy, so if invalidation occurs at a lower level, it will kill the
whole branch

Which OCSP responder to trust?
When proxy uses AIA extension (=URL added), have to provide
intelligence to OCSP objects that identifies the appropriate response
and ensures authority of signer is appropriate.  Requires special
software at OCSP level, or use some portion of AIA URL and make sure
that OCSP signing certificate had corresponding name (yuck).  Best way
is for user to delegate a proxy cert to OCSP responder in such a way
that the cert has OCSP signature info.  Can have multiple URL's in one
cert or proxy.  Essentiallly this is a bucket of URL's and info on
what will be found at these URLs (note not CRL's!).  Clients can try
these sequentially; some undefined logic is implied here.
Requirements doc just says process them one by one.

A management interface is required for the OCSP responder.

Next steps: add the above, and try to get final comments from list.
Then ready to send to GGF editor and ask for public comment.

[As far as I know, no document changes based on this have yet occurred.]

Please look thru this and see if anything is missing and 
if there are any other issues that need to be addressed.
I am going to see if I can identify and / or summarize
some other discussion that has taken place on this topic.

Regards, ==mwh
Michael Helm
ESnet/LBL