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