Hello again Milan, Please find below some other comments to your previous email, sorry for the late response and hope the CAOPS Meeting@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?