[caops-wg] Version 06-09 of the OCSP document.

[jluna at ac.upc.edu]

Hello again Milan,
Please find below some other comments to your previous email, sorry for the late
response and hope the CAOPS Meeting at Tokio was OK!

Best regards,
Oscar & Jesus

>Throughout the document:
>I'd rather skip all referencing to "blacklisting". It is being used here in
>a pure authorization meaning - denying somebody access to a
>resource. I don't think authorization decisions should be handled by
>invalidating the result of authentication.

JLG:
Let me cite here a previous email exchanged with David Chadwick a few months
ago, precisely about 
blacklist-like mechanisms and OCSP:

"Of course. CRLs, revocation, OCSP are all black list mechanisms. The
alternative is to have white lists and to ask the issuer if a cert is on
its white list or not. But this is a different type of validation to the
one that I am talking about with the CVS. It is only an initial
important first step in validation."


>5.5 Responder Discovery
>----------------------
>- I'm not sure I understand the section properly.
>"Any OCSP server acting as Clearinghouse or Trusted Responder MUST be
>contacted first."
>- Why?

JLG: 
Clearinghouses & Trusted Responders sign OCSP Responses with a private key
issued by an authority
in which the relying parties implicitly trust (ie IGTF). Compare versus
Authorized Responders 
signing OCSP Responses with a private key in which relying parties must trust
explicitly. 


>6.3. Revocation Information Sources
>-----------------------------------
>"blacklist" again

JLG:
Pls refer to first response and previous email.

> 8.2.1 Delta CRLs
> ----------------
>  - I don't seem to see the point here. Let me try to express my
>    reading of the section:
>
> "One of the problems with current Grid CAs' full CRLs is
> their long expected lifetime, i. e. the nextUpdate pointing
> to at least 7 days in the future. This behavior is motivated
> by the software used by Grids
> (OpenSSL) and by the potential network problems. However,
> this usage of nextUpdate takes out the possibility of
> expressing the CRL issuance frequency in the CRL itself (some
> CAs issue them several times a day but the the only place to
> find out the frequency is their CP/CPS). The Delta CRLs are
> proposed to solve the problem - their nextUpdate would
> reflect the actual CRL issuance frequency so that the OCSP
> responder feed with them could provide the more appropriate
> value for the nextUpdate in the response."
>
>   Am I reading the section right?
>
>   If I am, doesn't that effectively mean that there would be
> a new delta CRL issued with every full one (or at least with
> every full CRL containing no new revocation records)?
>
>

OM:
Milan, your summary of the section is correct.
However, your conclusion is not. When a full CRL is issued,
there are no deltaCRLs to issue because such D DeltaCRLs
always refer to the full CRL that was issued last.
In any case, I don't see what is the point you want to make.
Do you propose rephrasing the section?


>9.1 OCSP Service Architecture
>-----------------------------
>What are the "OCSP High Level Responders"?

JLG:
Please find explanation in section 7.1.3 adcording to the Relying Party's point
of view.


>OCSP Client Configuration Examples
>----------------------------------
>The actual example is missing.

JLG:
Appendix B.1, page 21?