[caops-wg] OCSP section 6.3

[Oscar Manso]

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