RE: [caops-wg] OCSP & Proxy Certs
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.
Following up on discussions at the EUgridPMA and post-meeting discussiions, I'm really nervous about the fragility of a network of OCSP responders.... that's just for the CA's and doesn't really address the issue that Mike raises of how we set up a network of responders that will do what we want with proxy certificates. For what it's worth, there seem to be a number of wireless providers in airports, etc. that I'm seeing recently who are supplying OCSP information that Firefox chokes on and so it won't allow me connect to the site. Being a typical user, I don't give damn about the PKI infrastructure, I just wantto chckmy email and I don't want have to spend an even longer time screwing around ... as a result, I now use IE to connect to wireless systems for payment, registration etc. Also, IE doesn't seem to cache the DNS and so as I move from airport to airport, it is more likely to do the redirection to the new registration page in a timely fashion than Firefox. (I suspect that the same issue is involved in the OCSP error code I receive, but I haven't bothered to look it up. BC
"Cowles, Robert D." writes:
Following up on discussions at the EUgridPMA and post-meeting discussiions, I'm really nervous about the fragility of a network of OCSP responders.... that's just for the CA's and doesn't really address the issue that Mike raises of how we set
I think I have mentioned this here, but certainly at SLCCC and OSG consortium, that some deployment scenarios for OCSP may not improve the situation we have now. They would replace an individual relationship with a CA and a local CRL file that had to be updated, with an individual relationship with a CA, and a (usually) networked-based URL that would have to be checked. On the face of it that might be worse, since network overhead and partitioning might cause problems; but the devil is in the details. To me this suggests you wind up with both: OCSP for more real-time and caching data, CRLs for backup. However, we have argued out this scenario and counters to it, and a lot of that has dropped out of the paper as a result. But see sections 4.2 and figure 1 in section 7. I think I can say we are recommending a site, and/or VO, clearinghouse trusted responder; strongly enough? But to build that we are probably going to have to start with something more general. It seems to me the foundation for this is getting CA's to each establish an OCSP responder, provide some mechanism for registering proxy revocations, and stamping their EE certs with the CA's responder URL. Organizations can build their own responders based on this info, instruct their clients as they see fit, and identity providers who need to serve many different communities don't have to make exceptions for each.
On Jan 29, 2006, at 13:57, Cowles, Robert D. wrote:
For what it's worth, there seem to be a number of wireless providers in airports, etc. that I'm seeing recently who are supplying OCSP information that Firefox chokes on and so it won't allow me connect to the site.
I think what you are getting at is the common Catch-22 situation where the wireless provider redirects any HTTP access to the payment portal until you have paid the access fee. Of course, the payment is secured using an SSL channel, Firefox tries to contact the Verisign OCSP responder in order to verify certificate status -- and retrieves a second set of the portal HTML pages instead of an OCSP reply. An implementation/configuration issue, which would disappear quickly had OCSP status checking actually been in use... /Olle
Readability/usability pass here: http://www.lbl.gov/~mike/OCSP_Requirements_for_Grids-06-01.doc Particular change - handling of "unknown" There are some other things I want to get in some other sections, but -- Proxy section next Sorry for the time this is taking & the lateness. Thanks, ==mwh
Proxy cert handling draft here: http://www.lbl.gov/~mike/OCSP_Requirements_for_Grids-06-03.doc With line nos: http://www.lbl.gov/~mike/OCSP_Requirements_for_Grids-06-03-lines.doc I separated the change tracking so the proxy additions look different. Also added author info, some formatting changes (probably need a few more). I suggest we concentrate on what we agree on, so we can accept changes and get a cleaner copy, and leave things that need further discussion. At the end are some topics that need to be addressed. I haven't gotten to O&J's pros-cons material yet, and there is some more readability things to do. Mike Helm writes:
Readability/usability pass here: http://www.lbl.gov/~mike/OCSP_Requirements_for_Grids-06-01.doc Particular change - handling of "unknown" There are some other things I want to get in some other sections, but --
Proxy section next
Sorry for the time this is taking & the lateness.
Thanks, ==mwh
Rqmts doc readers will note some discussion about delta CRLs, provided by Oscar or Jesus at some point, and some remarks in the end notes about combining some of the delta CRLs. I have no practical experience using delta CRLs - Oscar & Jesus perhaps, or maybe others outside of Grids, should speak up with real experience. Our (DOEGrids) customers haven't been able to use delta CRLs, altho our CA product can produce them. I don't believe openssl can currently support delta CRLs directly, at least current documentation disclaims this, altho don't know what problems result. (Perhaps openssl just treats them as another CRL in the same CA's series without understanding how to integrate them, or perhaps some attribute will trigger evaluation failure - don't know.) Reviewing the discussion in RFC 3280 5.2.4, it appears that delta crls contain their own thisupdate/nextupdate attributes. True? Applications are supposed to be able to combine the base CRL & deltas to produce a new effective CRL (that's how I read the RFC). Could we use this to reduce the size of the "cautionary period"? eg base delta delta delta delta delta base crl 1 2 3 4 5 crl t0 ... t1 ... t2 ... t3 ... t4 ... t5 ... t6 This would be useless to most or all current Grid customers, but it could be used by a conforming OCSP responder, which could also report the shorter update expectations to the relying party. I think we may have the components to test this in the ESnet-DOEGrids test OCSP responder. I believe one of the other co-authors runs a CA service that could produce delta CRLs, too. I don't know if there are many CAs with that capability - I think I know of another European one, and perhaps one in Asia. If I am reading the RFC right and current products seem to support this, we should recommend this "system configuration" to improve the quality of revocation info in Grids. This is a real improvement over the current state of affairs and will meet the needs of security officers much better, in my opinion. Of course, we'll have to get their reading on it. It also seems relatively forgiving, in that a variety of delta production schedules including "none" can be supported. Thanks, ==mwh
OCSP doc audio conference 2/6/2006 8:02:15 AM Some sketchy minutes Attendees: A Sill, Oscar M, J Luna, mwh, O Mulmo, R Cowles? AI: Oscar/Jesus will send text to the group, relaying Chadwick's proxy revocation ideas; mwh to incorporate above O/J will send some more delta CRL - related text to the group Authorized responder detail (see below) -> doc mwh will do new edit (probably Tue/Wed) mwh will do slides about edits, send to group (Wed/Thu) Decisions: Ok to accept changes in current document - group will continue to send comments to the list on current content and changes. Discussion: Alan Sill: OCSP doc drifts into dangerous, authZ territory mwh: Not too much - no viewpoint on certs. Do need authZ for some service supporting proxy cert revocation and blacklisting; not really a part of OCSP but part of the service provisioning Oscar: Dave Chadwick thinks proxy rev might play a role in blacklisting; make sure to distinguish between authentication & authorization functions; more .... DC will introduce a validation service proposal of some kind at GGF 16 in AuthZ WG. O: [more] proxy cert revocation important but not authZ mechanism Will send text to list Discussion Delta crls O: We have a demo service [model of how to produce & manage delta crl's] O: cautionary period Send to list how to define cautionary period Is mwh's reading of delta crl standard & use correct? [The certiver folks will send some material on this] O: agree OCSP good way of managing delta crl's for clients Discussion on 5.3 where we recommend [maybe, describe?] the use of non CRL database - will send some requirements for this Also expand to include CA w/ no delta CRLs We agree w/ most of the document - ok to accept changes and proceed to next rev Question about Authorized Responder, and weaknesses of current CAs: Many CAs are offline most of the time, and their hosting environment may not be comfortable with a full-fledged 24 x 7 service such as OCSP. Olle: Auth OCPS responder can issue responder certs in batch -- will put in doc Addresses one of these problems (the 99.999% uptime problem is out of scope but will be noted). mwh noted a possible GGF attendance problem; may not be present at Athens after all. Will forward slide summary to CAOPS chairs & the group.
The cleaned draft here: http://www.lbl.gov/~mike/OCSP_Requirements_for_Grids-06-04.doc There are a minimal number of content changes here, mostly in references, and some formatting. The only change is the deletion of the old 5.5 proxy section. Other edits coming as per phone call. The -03 versions are still present if people want to critique carefully.
Sorry, won't be able to proceed to GGF-16. More work on the draft will follow shortly, however. Thanks, ==mwh Michael Helm ESnet/LBL
On Feb 8, 2006, at 5:36 PM, Mike Helm wrote:
Sorry, won't be able to proceed to GGF-16.
(Was there ever any explanation as to why?...)
More work on the draft will follow shortly, however.
Have observed some traffic on the IETF list on OSCP there. I assume you have been monitoring this and will fold it in? Alan ==================================================================== : Alan Sill, Texas Tech University Office: Admin 233, MS 4-1167 : : e-mail: Alan.Sill@ttu.edu ph. 806-742-4350 fax 806-742-4358 : ====================================================================
Alan Sill writes:
Have observed some traffic on the IETF list on OSCP there. I assume you have been monitoring this and will fold it in?
Do you mean the so-called lightweight profile? There is some sense of overlap. Probably the best thing to do is to write what we want, and wait for IETF to finish before incorporating anything (it's still a draft). For people who want to look at it it's here: http://www.ietf.org/internet-drafts/draft-ietf-pkix-lightweight-ocsp-profile... I think what drove this is the nonce - freshness problem, which Olle wrote extensively about. There are some other things in it that might be useful but we should be cautious about citing it until it gets published as an RFC.
Just encase you did not guess it; I will not be able to attend either. The reason given does not make sense. If it is true DOE is dropping a lot of support for Grids. Tony...
We don't know why the trip was spiked. Perhaps we will learn eventually; know nothing now, tho. Thanks, ==mwh
Hello again Mike, We attach our comments about the cautionary period and use of delta CRLs. We would like to thank Alan for his pointer to the draft being produced by the IETF people. We introduced some comments related with it... Jesus & Oscar
Next rev here: http://www.lbl.gov/~mike/OCSP_Requirements_for_Grids-06-05.doc Delta CRL work, some more on proxy certs and the problems issues, more architecture discussion, some more explanatory material in section 3 about ocsp and crl issues. I tried to address O&J's pros-cons list, and David Chadwick's remarks (to the extent I could). I have quite a few comments in the document representing problems (mainly missing text) that need to be filled in, mostly minor things. I think the controversial issues are all in the text now. I will put together some slides for Olle, or Christos/Darcy, to use for discussion, should post on Sunday. Regards, ==mwh
Next rev here: http://www.lbl.gov/~mike/OCSP_Requirements_for_Grids-06-06.doc Rev with all the changes accepted (clean copy for reposting): http://www.lbl.gov/~mike/OCSP_Requirements_for_Grids-06-07.doc http://www.lbl.gov/~mike/OCSP_Requirements_for_Grids-06-07-lines.doc I think this has the content in it that I felt I needed to get in; the proxy section still has some missing text (see mailing list discussion) including some of the pro-con discussion. I also need help with the authorized proxy responder. There are many comments left in the document, some of which can be dealt with as part of a readability edit. A slide summary shortly.
Added an appendix at the last minute: Rev with all the changes accepted (clean copy for reposting): http://www.lbl.gov/~mike/OCSP_Requirements_for_Grids-06-08.doc http://www.lbl.gov/~mike/OCSP_Requirements_for_Grids-06-08-lines.doc Slides for CAOPS: http://www.lbl.gov/~mike/OCSP-Requirements-for-Grids.ppt Thanks, ==mwh
participants (6)
-
Alan Sill -
Cowles, Robert D. -
Mike Helm -
Olle Mulmo -
Oscar Manso -
Tony J. Genovese