Re: [caops-wg] OCSP requirements - final(?) version uploaded
Forgot 2 things: p4 While OCSP supports querying of multiple certificates in a single request, it is rarely used in practice or even supported in common off-the-shelf implementations suggest We recommend that developers of OCSP responder software for Grids support multiple certificate queries in their products. We enourage? recommend OCSP service providers provide this support also. [This is another complication that needs to be added to the discussion in 4.7; don't think I hit it] 4.7 - discussion about delta CRL's. This seems to be a discussion about 2 recommendations: 1) CA's - publish your CRL's directly to the (some) OCSP responder(s) 2) use delta CRL's to reduce size Can we slim down those 2 paras to essentially say just that? There is a need for a CRL req doc to pick up the more detailed argument.
Hello Mike and Olle, Thanks a million for all the very interesting points that have been raised about the document. We have been following your discussion with great interest. I agree with Olle that the best is to create and follow a different thread for each topic being raised. However, given the fact that the discussion thread about section 6.3 has become a little bit mixed up among sections 4 and 6 I propose to open a new one here. At the end of the first paragraph, section 6.3 describes
For trust evaluation purposes, the responder may want to quantify an upper bound and/or approximation of the current latency, and convey that to the relying party. To date, there is no well-defined technical means of augmenting an OCSP response with such "cautionary period" information, to borrow language from Appendix B in [RFC3125]. Specifying such an OCSP response extension is out of scope for this document.
Well, first of all I would like to apologise because when we wrote such paragraph I was not right when I mentioned that the cautionary period is not present in the OCSP Response. In fact, the cautionary period can be inferred from the OCSP Response - and the CRL - by applying the formula CautionaryPeriod = NextUpdate - ThisUpdate The CautionaryPeriod indicates the interval of time during which a change on the status on a cert may not be reflected on the OCSP response being provided. Therefore this parameter has great importance to evaluate the quality of an OCSPResponse because its value its reversely proportional to the quality of the response. The lower the cautionary period the higher the quality of the response. In other words, the client may request a certain QoS which will be provided if supported by the OCSP/CA connection.
- discussion about delta CRL's.
This seems to be a discussion about 2 recommendations: 1) CA's - publish your CRL's directly to the (some) OCSP responder(s) 2) use delta CRL's to reduce size
Can we slim down those 2 paras to essentially say just that?
DeltaCRLs allow to improve the efficiency and QoS of an OCSP Response (by reducing the CautionaryPeriod). However, the publication of DeltaCRLs complicate considerably the protocol required to validate a certificate from the client's point of view. Consequently, most CAs do not even generate them. This is why we suggest to recommend the use of DeltaCRL just as mentioned in the last paragraph of section 6.3. Given the fact that most CAs do not generate deltaCRLs, the last paragraph on this section suggests a mechanism to implement such feature on an OCSP Responder using normal CRLs as source of information (it does not necessarily have to be the CA the entity in charge to push the DeltaCRLs into the responder). Oscar
On Jun 2, 2005, at 18:04, Oscar Manso wrote:
In fact, the cautionary period can be inferred from the OCSP Response - and the CRL - by applying the formula
CautionaryPeriod = NextUpdate - ThisUpdate
The CautionaryPeriod indicates the interval of time during which a change on the status on a cert may not be reflected on the OCSP response being provided.
I think we are confusing two things here: latency and frequency. t0: CA operator presses the "revoke" button t1: CRL gets timestamped t2: CRL gets published t3: CRL is fetched /pushed over to OCSP responder t4: OCSP responder has updated its revocation database What you call CautionaryPeriod above defines an upper bound of the time between t1 of CRL#n to t2 of CRL#(n+1) -- that is, the frequency or interval with which updates will be available. While this is important, I would argue that a Cautionary Period as described in the RFC is the _latency_, i.e. the time between t0 and t4 for a particular revocation to get into effect. The document should be improved to cover both of these features and point out the issues associated with them. Does anyone have any better words than "publishing interval" (frequency?) and "cautionary period" (latency?) for these things? /Olle
On Jun 3, 2005, at 08:38, Olle Mulmo wrote:
t0: CA operator presses the "revoke" button t1: CRL gets timestamped t2: CRL gets published t3: CRL is fetched /pushed over to OCSP responder t4: OCSP responder has updated its revocation database
Of course, t4 may not necessarily be associated with t1,t2,t3 in the general case. In fact, t4<t1 would be possible in some scenarios (the OCSP responder reading directly from the CA database). /Olle
The document should be improved to cover both of these features and point out the issues associated with them. Does anyone have any better words than "publishing interval" (frequency?) and "cautionary period" (latency?) for these things?
Olle, I agree with you in that, when talking about CRLs, the cautionaryPeriod interval theoretically corresponds to the frequency at which CRLs are supposed to be published. However, in practice many CAs publish a new CRL as soon as they revoke or suspend a new certificate, independently of the refreshment frequency published. On the other hand, when using OCSP, the thisUpdate and nextUpdate interval does not have the meaning of frequency because the usage of such mechanism does not imply publishing responses at periodic intervals of time. Therefore, in the case of OCSP, the interval does not necessarily correspond with the interval set by any CRL. Instead, it can be set/used to give an idea of the precision of the response being provided (which, as we already mentioned, depends on the quality of the connection set between a CA and the OCSP) If the term cautionaryPeriod is confusing maybe we could name it precisionInterval. But in any case, we believe that it is important to introduce such term in the document. Oscar
Olle Mulmo writes:
On Jun 3, 2005, at 08:38, Olle Mulmo wrote:
t0: CA operator presses the "revoke" button t1: CRL gets timestamped t2: CRL gets published t3: CRL is fetched /pushed over to OCSP responder t4: OCSP responder has updated its revocation database
Of course, t4 may not necessarily be associated with t1,t2,t3 in the general case. In fact, t4<t1 would be possible in some scenarios (the OCSP responder reading directly from the CA database).
From my point of view, the message I want to get out in this document includes "OCSP can get you real time revocation information!" That really means, we can make a better real time approximation
What about this tack. than CRL's. So 6.3 should describe how we could do that. That's what I think it is trying to do. It may be doing something else too, but that's all I read into it. Here's my "mock" re-write of this section: A certificate can be revoked, but information about this revocation can take a considerable amount of time to reach a relying party: forever, if CRL's or OCSP checking is not available; at least 24 hours and often many days in typical Grids today; perhaps an hour or more in typical OCSP responders and CRL generation systems in use today. Delays in propagating revocation info longer than a few hours are unacceptable to most security professionals. Currently, most CA's produce CRLs that are only published on their public repositories. OCSP responders and other consumers of CRLs must periodically poll this repository and download new CRLs. A CRL for a large CA may be quite large and downloading a complete list may take a long time. We recommend that Grid CA's produce a CRL whenever a revocation takes place. Since this can be quite burdensome on the CA and on the consumer we recommend that large CA's produce delta CRL's [RFC 3280 5.2.4 p 55] as well as full CRL's. We recommend that CAs adopt a _push_ model for CRLs and publish directly to the OCSP service, where possible. OCSP server developers and deployers should plan for this configuration [or something]. What do you all think of this? Is it compatible with what you want to do? What else needs to be said?
participants (3)
-
Mike Helm -
Olle Mulmo -
Oscar Manso